shaos> это как так? перечисляемые расширения были основной фишкой IDEC :(

Ну а теперь три из них являются частью стандарта, а остальные — нет. Вообще нет. Если я всё правильно понял.

revoltech> три из них являются частью стандарта

Пардон, /u/push не увидел. В таком варианте — даже четыре.

А как же делать кастомные расширения теперь?...

shaos> это как так? перечисляемые расширения были основной фишкой IDEC :(

Перечисляемые расширения вынуждают стандартизировать расширения. Придём к джабберу, где у каждого свой зоопарк и по факту в рамках сети рабоает только основа стандарта и пара расширений. Нафиг-нафиг.

А так, никто не мешает лепить любые расширения у себя. Просто не надо полагаться на то, что их будут поддерживать. Ситуация ровно та же, только более свободная.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> Ну у него эхи без цифр, значит уже наполовину IDEC ;)

Да не было в ii требования эх с циферками. Это была просто договорённость, а не стандарт. Эхи без циферек там прекрасно работали всю дорогу.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Вобщем мне никогда не нравилось, что в /u/point у вас пароль идёт прямым текстом (ну скажем https:// и POST ещё ок, но если речь идёт о ретроклиентах, которые умеют только http:// ?)

Для несекьюрных каналов можно попробовать альтернативный способ аутентификации пользователя скажем через подпись HMAC-RIPEMD-160-96. Алгоритм HMAC это hash-based message authentication code (код аутентификации сообщения на основе хеша), который использует один секретный ключ, известный обеим сторонам, и над каким-то стандартным хешом - в данном случае это RIPEMD-160 (алгоритм хеширования с наименьшей длиной хеша, который ещё не сломали), причём этот алгоритм был представлен ещё в 1992 году (т.е. ему уже 32 года!) - он в частности используется в биткоине (вместе с SHA-256). Ну и для укорачивания такой подписи берутся первые 96 бит (12 байт). Это всё стандартизовано на уровне RFC:

RFC2104 (February 1997) - HMAC: Keyed-Hashing for Message Authentication
https://datatracker.ietf.org/doc/html/rfc2104

RFC2286 (February 1998) - Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
https://datatracker.ietf.org/doc/html/rfc2286

RFC2857 (June 2000) - The Use of HMAC-RIPEMD-160-96 within ESP and AH
https://datatracker.ietf.org/doc/html/rfc2857

Конечно было бы лучше использовать SHA-256, но RIPEMD-160 проще в вычислительном плане, а нам надо будет его считать на слабых платформах. Вобщем суть такая - секретный ключ (это может быть строка текста длиной до 20 символов) загружается на узел через секьюрное соединение (https:// или скажем через емейл сисопу) один раз. Далее когда пользователь хочет отправить сообщение на узел (в описанном выше формате) по несекьюрному каналу, то его клиент считает по телу сообщения и секретному ключу подпись HMAC-RIPEMD-160-96 и посылает 12-байтовый результат как PAUTH (можно наверное в base64url его завернуть), а сервер при получении будет считать по полученному телу сообщения свой вариант HMAC-RIPEMD-160-96 и будет сравнивать с присланной подписью - если результат совпадёт, то отправитель считается аутентифицирован (плюс будет проверена целостность самого сообщения). До кучи в урл можно добавить кодировку, на тот случай если софт поинта не поддерживает UTF8:

URL/u/point2/koi7/B64AUTH/B64STRING

для больших сообщений можно задействовать метод POST:

URL/u/point2/koi7/B64AUTH
TEXT

причём тело сообщения в данном случае можно заслать прямым текстом без кодировки (Content-Type: plain/text)

Обсуждаем? :)

Ну т.е. теперь исключается сама возможность торкнуться на узел специальным образом, чтобы узнать одним списком а какие собственно расширения он поддерживает...

Да - в /x/features поддерживаемые кодировки можно перечислить таким макаром:

/u/point2/utf8
/u/point2/koi7
/u/point2/koi8r
/u/point2/cp866
/u/point2/cp1251

При получении узел будет сам переконвечивать это в UTF-8 (если пришёл не UTF-8)

https://github.com/idec-net/new-docs/blob/master/iibonds.md

Минусы оригинального ii:

- Название эхоконференций от 3 до 60 символов, эха обязана заканчиваться на постфикс (точка и число).
- Когда в эхе накапливается по 3000 сообщений и более, получать индекс со станции становится долго.
- Из-за предыдущей причины приходилось "перекатывать" эхи, периодически переходя из одной в другую

Наши улучшения

- Название эх от 3 до 120 символов, из них обязательный символ - только точка (без цифровых постфиксов)
- Небольшие расширения, которые помогают экономить трафик, защищают от переполнения эх и делают ещё пару полезных вещей.

ВСЁ!

AL>> Словарик будет отдельным документом.
tuple> Лучше в самом документе словарик иметь.

Словарик не является частью стандарта.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos>> это как так? перечисляемые расширения были основной фишкой IDEC :(
revoltech> Ну а теперь три из них являются частью стандарта, а остальные — нет. Вообще нет. Если я всё правильно понял.

Всё так. Расширения стандарта это путь вникуда. Лучше потихоньку принимать в стандарт полезняшки, если они будут действительно нужны.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> А как же делать кастомные расширения теперь?...

Я ж говорю, важна поддержка стандарта. Что там кто себе сбоку наворотил, это их личное дело и не должно влиять на всю сеть.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> Вобщем мне никогда не нравилось, что в /u/point у вас пароль идёт прямым текстом (ну скажем https:// и POST ещё ок, но если речь идёт о ретроклиентах, которые умеют только http:// ?)
shaos> Для несекьюрных каналов можно попробовать альтернативный способ аутентификации пользователя скажем через подпись HMAC-RIPEMD-160-96. Алгоритм HMAC это hash-based message authentication code (код аутентификации сообщения на основе хеша), который использует один секретный ключ, известный обеим сторонам, и над каким-то стандартным хешом - в данном случае это RIPEMD-160 (алгоритм хеширования с наименьшей длиной хеша, который ещё не сломали), причём этот алгоритм был представлен ещё в 1992 году (т.е. ему уже 32 года!) - он в частности используется в биткоине (вместе с SHA-256). Ну и для укорачивания такой подписи берутся первые 96 бит (12 байт). Это всё стандартизовано на уровне RFC:
shaos> RFC2104 (February 1997) - HMAC: Keyed-Hashing for Message Authentication
shaos> https://datatracker.ietf.org/doc/html/rfc2104
shaos> RFC2286 (February 1998) - Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
shaos> https://datatracker.ietf.org/doc/html/rfc2286
shaos> RFC2857 (June 2000) - The Use of HMAC-RIPEMD-160-96 within ESP and AH
shaos> https://datatracker.ietf.org/doc/html/rfc2857
shaos> Конечно было бы лучше использовать SHA-256, но RIPEMD-160 проще в вычислительном плане, а нам надо будет его считать на слабых платформах. Вобщем суть такая - секретный ключ (это может быть строка текста длиной до 20 символов) загружается на узел через секьюрное соединение (https:// или скажем через емейл сисопу) один раз. Далее когда пользователь хочет отправить сообщение на узел (в описанном выше формате) по несекьюрному каналу, то его клиент считает по телу сообщения и секретному ключу подпись HMAC-RIPEMD-160-96 и посылает 12-байтовый результат как PAUTH (можно наверное в base64url его завернуть), а сервер при получении будет считать по полученному телу сообщения свой вариант HMAC-RIPEMD-160-96 и будет сравнивать с присланной подписью - если результат совпадёт, то отправитель считается аутентифицирован (плюс будет проверена целостность самого сообщения). До кучи в урл можно добавить кодировку, на тот случай если софт поинта не поддерживает UTF8:
shaos> URL/u/point2/koi7/B64AUTH/B64STRING
shaos> для больших сообщений можно задействовать метод POST:
shaos> URL/u/point2/koi7/B64AUTH
shaos> TEXT
shaos> причём тело сообщения в данном случае можно заслать прямым текстом без кодировки (Content-Type: plain/text)
shaos> Обсуждаем? :)

Да чего тут обсуждать? Нормальное расширение -- делай.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> Ну т.е. теперь исключается сама возможность торкнуться на узел специальным образом, чтобы узнать одним списком а какие собственно расширения он поддерживает...

Почему? Хочешь сказать, что со старым стандартом исключалась сама возможность получить у тебя /list.txt с хешиками?

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> https://github.com/idec-net/new-docs/blob/master/iibonds.md
shaos> Минусы оригинального ii:
shaos> - Название эхоконференций от 3 до 60 символов, эха обязана заканчиваться на постфикс (точка и число).
shaos> - Когда в эхе накапливается по 3000 сообщений и более, получать индекс со станции становится долго.
shaos> - Из-за предыдущей причины приходилось "перекатывать" эхи, периодически переходя из одной в другую

Имеет смысл читать ii, а не кривую документацию по IDEC.

shaos> Наши улучшения
shaos> - Название эх от 3 до 120 символов, из них обязательный символ - только точка (без цифровых постфиксов)
shaos> - Небольшие расширения, которые помогают экономить трафик, защищают от переполнения эх и делают ещё пару полезных вещей.
shaos> ВСЁ!

Да.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

https://vk.com/@hatahack-ii-idec

> На официальном сайте сказано о наличии “филиала” IDEC в сети Tor по адресу mtgbjhifvi4sl773.onion, но сейчас он не работает (закрыт по причине непопулярности). Клиенты IDEC Mobile и CutieFeed по заверениям разработчика поддерживают настройки прокси, и в том числе успешно тестировались им на сетях Tor и i2p.

AL> Имеет смысл читать ii, а не кривую документацию по IDEC.

Между прочим, а где её найти? На лоре ссылки на умерший 51.ru, который тот самый с девочками, судя по веб-архиву. В интернете - IDEC.

shaos> Да - в /x/features поддерживаемые кодировки можно перечислить таким макаром

Вот это в стандарт точно тащить не надо. Кому в 2024 году нужно что-то, кроме UTF-8? А всякие кои и 1251 за пределами постсовка и раньше никому не нужны были.

По передаче паролей — ума не приложу, как люди с паролями по plain http раньше жили. Конечно, времена поменялись, но зачем городить огород с хэшами? Не проще ли сделать что-то типа HOTP/TOTP и использовать одноразовый код в качестве authstring, если уж так приспичило? Но опять же, это вопрос реализации, в стандарт это тоже тащить не стоит, имхо.

tuple> > На официальном сайте сказано о наличии “филиала” IDEC в сети Tor по адресу mtgbjhifvi4sl773.onion, но сейчас он не работает (закрыт по причине непопулярности)

Это очень старый onion-адрес, сейчас они гораздо длиннее. Такие уже даже давно не резолвятся вроде бы.

tuple>> > На официальном сайте сказано о наличии “филиала” IDEC в сети Tor по адресу mtgbjhifvi4sl773.onion, но сейчас он не работает (закрыт по причине непопулярности)
revoltech> Это очень старый onion-адрес, сейчас они гораздо длиннее. Такие уже даже давно не резолвятся вроде бы.

Это единственный известный onion-адрес, увы. Про другие никто не распространялся, возможно они есть и живут своей жизнью у кого-то, но закрыто - только для себя.

AL>> Имеет смысл читать ii, а не кривую документацию по IDEC.
tuple> Между прочим, а где её найти? На лоре ссылки на умерший 51.ru, который тот самый с девочками, судя по веб-архиву. В интернете - IDEC.

Не знаю. Мы уже давно отдельно.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Ну я добавил их в /x/features и типа сразу видно что оно у меня есть ;)

> Да.

Ну дык значит bloat уже на половину IDEC :)

O - вот этот текст я искал ;)

Оригинал давно протух…

Ну это типа кастомное расширение

HOTP потяжелее наверное - и там ведь ещё больший «огород с хешами» ?

blcat

чортова автоисправлялка…

> Вот это в стандарт точно тащить не надо. Кому в 2024 году нужно что-то, кроме UTF-8? А всякие кои и 1251 за пределами постсовка и раньше никому не нужны были.

cp1252 ещё можно добавить т.к. оно ещё вполне в ходу :)

https://en.wikipedia.org/wiki/Windows-1252

"It is the most-used single-byte character encoding in the world. Although almost all websites now use the multi-byte character encoding UTF-8, as of July 2024 1.2%[4] of websites declared ISO 8859-1 which is treated as Windows-1252 by all modern browsers (as demanded by the HTML5 standard[5]), plus 0.3% declared Windows-1252 directly,[4][6] for a total of 1.5%. Some countries or languages show a higher usage than the global average, in 2024 Brazil according to website use, use is at 3.4%,[7] and in Germany at 2.7%.[8][9] (these are the sums of ISO-8859-1 and CP-1252 declarations)."

shaos> HOTP потяжелее наверное - и там ведь ещё больший «огород с хешами» ?

Нет, не больший. И преимущество оного в том, что можно в случае с TOTP вынести этот нюанс в какой-нибудь Aegis/Authy/гугловский аутентификатор, а в случае с HOTP — вообще в отдельный аппаратный ключ. И не нагружать бедный ретроклиент.

Ну вот - аппаратный ключ городить ещё

А на сторонние аутентификаторы совсем не хочется завязываться - всё должно работать даже в случае тотального отключения глобальных сервисов...

shaos> А на сторонние аутентификаторы совсем не хочется завязываться - всё должно работать даже в случае тотального отключения глобальных сервисов...

Сторонний аутентификатор, работающий так же, как и всё вышеперечисленное, пишется максимум за полчаса на любом мейнстримном ЯП.

https://www.rfc-editor.org/rfc/rfc6238

Кстати - если этот номер перехватить, то его ведь можно тут же зареюзать пока время не прощло?

В моём случае зареюзать не получится т.к. оно зависит от контента

" All the communications SHOULD take place over a secure channel, e.g.,
Secure Socket Layer/Transport Layer Security (SSL/TLS) [RFC5246] or
IPsec connections [RFC4301]."

Это show stopper...

shaos> Кстати - если этот номер перехватить, то его ведь можно тут же зареюзать пока время не прощло?

Нельзя. Ну как минимум сервер должен такие попытки пресекать и заставлять пользователя ждать следующее 30-секундное окно. Это в случае TOTP.

Легитимный пользователь в пределах 30 секунд 2 сообщения не отправит. А если надо, пусть отправляет через /u/push.

shaos> " All the communications SHOULD take place over a secure channel, e.g.,
shaos> Secure Socket Layer/Transport Layer Security (SSL/TLS) [RFC5246] or
shaos> IPsec connections [RFC4301]."
shaos>
shaos> Это show stopper...

Это should, а не must, а на самом деле пофигу вообще. Между клиентом и сервером только начальная регистрация ключа должна быть секьюрной.

should = must

Американцы не любят слово must

т.е. ты предлагаешь вводить код ручками при каждой посылке? Нет спасибо :)

В моём варианте всё считается автоматически - нажал на Send и оно ушло…

shaos> Ну я добавил их в /x/features и типа сразу видно что оно у меня есть ;)

Ну так и оставь их в /x/features. Никто ж не мешает ;)

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos>> Кстати - если этот номер перехватить, то его ведь можно тут же зареюзать пока время не прощло?
revoltech> Нельзя. Ну как минимум сервер должен такие попытки пресекать и заставлять пользователя ждать следующее 30-секундное окно. Это в случае TOTP.
revoltech> Легитимный пользователь в пределах 30 секунд 2 сообщения не отправит. А если надо, пусть отправляет через /u/push.

Ты шутишь сейчас? Лигитимный пользователь может подряд сколько угодно сообщений подряд отправлять. А /u/push вообще не для пользователей, а для других узлов сети. В том же цезии я не отправляю по одному сообщению, а отвечаю сразу на всё, что нового прилетело, а потом они пачкой по одному улетают. Зачем ломать клиенты?

Или ты предполагаешь, что клиент, отправив сообщение, будет ждать 30 секунд перед отправкой следующего? Нафиг такой клиент нужен тогда?

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

А у пуша какой пароль - пользовательский или особый сисоповский? Надо код ii-php поглядеть…

В новой спеке написано «строка авторизации узла» что по видимому намекает на специальный пароль

Тоже надо сделать свой вариант :)

Кстати зачем там echoarea если имя эти есть в каждом сообщении?…

А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?

shaos> А у пуша какой пароль - пользовательский или особый сисоповский? Надо код ii-php поглядеть…

По хорошему особый сисоповский должен быть. Потому что пуш для межузлового взаимодействия. Поини в принципе не может слать пуш, так как в пуше уже зарегистрированные сообщения летят, а не пользовательские.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> В новой спеке написано «строка авторизации узла» что по видимому намекает на специальный пароль
shaos> Тоже надо сделать свой вариант :)
shaos> Кстати зачем там echoarea если имя эти есть в каждом сообщении?…

Для обратной совместимости. Пуши к нам тоже из ii приехали, вроде.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos> А у пуша какой пароль - пользовательский или особый сисоповский? Надо код ii-php поглядеть…

Емнип он совпадает с паролем к sysop.php

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

ahamai> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?

Кстати, да, присоединяюсь к вопросу. Как в одном запросе слайсить сразу несколько эх с разными смещениями и лимитами? Например, мы запрашиваем содержимое трёх эх и выяснили, что из первой надо забрать только 3 последних сообщения, из второй — 10, а из третей — 50. И что, здесь три отдельных запроса городить придётся?

ahamai> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?

Например: https://club.hugeping.ru/u/e/idec.talks/-1:1

AL> Внёс правки по итогам замечаний и предложений. URL тот же: http://s.spline-online.ru/idec.html
AL> PS: Перед окончательной публикацией дождусь реакции hugeping.

Вроде бы всё нормально! У меня был вопрос про push как часть стандарта. Он нужен только когда нода не имеет реального IP адреса? С другой стороны, как тогда поинта забирают с неё сообщения? Какой-то изолированный сегмент сети?

С другой стороны, всё равно эта часть возможна только за счёт предварительной договорённости нод (выдача пароля), так что думаю - наличие push в стандарте не приговор, а лишь означает, что ПРИ НЕОБХОДИМОСТИ этот механизм может использоваться. То-есть, для работы в обычном режиме нам по прежнему push не нужен...

Про фичи - по идее они полезны были бы для определения, например, поддерживает ли нода слайсы. Но на практике, tgistation их не поддерживает, но в фичах есть u/e. В общем, я не жалею, что их больше нет. Стало проще. Меньше комбинаций. Ориентироваться можно на фактически получаемые данные.

P.S. Я бы оставил ещё повисеть драфт, мы же никуда не спешим? Вдруг кто-то что-то вспомнит. :)

hugeping> ahamai> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?
hugeping>
hugeping> Например: https://club.hugeping.ru/u/e/idec.talks/-1:1

Вопрос в том, что делать, когда в запросе НЕСКОЛЬКО эх. Можно ли указать диапазоны отдельно для каждой?

Это одна эха

hugeping>> ahamai> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?
hugeping>>
hugeping>> Например: https://club.hugeping.ru/u/e/idec.talks/-1:1

revoltech> Вопрос в том, что делать, когда в запросе НЕСКОЛЬКО эх. Можно ли указать диапазоны отдельно для каждой?

Не делал никогда так, но в стандарте написано что нет.

/u/e/area.one/area.two/0:10 запрашивает первые десять сообщений в индексе, а /u/e/area.one/area.two/-10:10 запрашивает последние десять сообщений в индексе.

Тогда я вообще не понял, чо это экономит, когда вместо одного запроса у нас отделный на эху. А запрос вещь дорогая, нагрузки на сервер, хедеры, все дела. Смысл, чтобы всё делать одним запросом.

2Shaos, хочу с тебя дёргать только последних 100 хедеров, как у тебя нода устроена?

hugeping> P.S. Я бы оставил ещё повисеть драфт, мы же никуда не спешим? Вдруг кто-то что-то вспомнит. :)

Солидарен. Оставить повисеть на неделю-две.

AL>> Внёс правки по итогам замечаний и предложений. URL тот же: http://s.spline-online.ru/idec.html
AL>> PS: Перед окончательной публикацией дождусь реакции hugeping.
hugeping> Вроде бы всё нормально! У меня был вопрос про push как часть стандарта. Он нужен только когда нода не имеет реального IP адреса? С другой стороны, как тогда поинта забирают с неё сообщения? Какой-то изолированный сегмент сети?

Ну по сути да. Если вдруг есть узел в сети с ограниченным доступом в интернет, например. Поинты у него локальные, а наружу только пуши до аплинка. Ситуация гипотетическая и с каждым годом всё менее вероятная, хотя, с другой стороны, с этими всеми взаимными блокировками может оказаться всякое :)

hugeping> С другой стороны, всё равно эта часть возможна только за счёт предварительной договорённости нод (выдача пароля), так что думаю - наличие push в стандарте не приговор, а лишь означает, что ПРИ НЕОБХОДИМОСТИ этот механизм может использоваться. То-есть, для работы в обычном режиме нам по прежнему push не нужен...

Ну да. В обычном режиме push не нужен.

hugeping> Про фичи - по идее они полезны были бы для определения, например, поддерживает ли нода слайсы. Но на практике, tgistation их не поддерживает, но в фичах есть u/e. В общем, я не жалею, что их больше нет. Стало проще. Меньше комбинаций. Ориентироваться можно на фактически получаемые данные.

Ну вот не будет фич. Будет просто стандарт. Остальное вообще не важно вне рамок каких-то локальных приколов.

hugeping> P.S. Я бы оставил ещё повисеть драфт, мы же никуда не спешим? Вдруг кто-то что-то вспомнит. :)

Ну спешить некуда.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

ahamai>> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?
revoltech> Кстати, да, присоединяюсь к вопросу. Как в одном запросе слайсить сразу несколько эх с разными смещениями и лимитами? Например, мы запрашиваем содержимое трёх эх и выяснили, что из первой надо забрать только 3 последних сообщения, из второй — 10, а из третей — 50. И что, здесь три отдельных запроса городить придётся?

Бери один по максимальному смещению.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

hugeping>> ahamai> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?
hugeping>>
hugeping>> Например: https://club.hugeping.ru/u/e/idec.talks/-1:1
revoltech> Вопрос в том, что делать, когда в запросе НЕСКОЛЬКО эх. Можно ли указать диапазоны отдельно для каждой?

Нельзя, так как незачем.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Ничё не понял. Если щас задать несколько эх и дать срез, он со всех по n сообщений запросит или только с последнего

Вечером на shaos потестю. Если первое, то мне подходит

https://sprinternet.io/iii/u/e/lor.opennet/bot.habr.rss/-2:2

lor.opennet
xfSBW60zRzlgSwVk76AQ
LhwoSH409gDoNlImRkqj
bot.habr.rss
qXIZLzo3Qe9lx8MA8agu
AAGRBdSX5ijxRWvXecPm

ок

другие станции

http://hugeping.tk/u/e/retro.talks/idec.talks/-2:2

retro.talks
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
idec.talks
Jr1i7Uh3aExR45L4mILq
lQojMgQzCqNwlULJtw3g

думаю, это и есть стандарт.

2shaos - я с тебя буду грабить только последние 100 сообщений. и так благодаря /x/h трафик между станциями упал с 12 мб до 2 мб, а так вообще урежется :)

ahamai> Ничё не понял. Если щас задать несколько эх и дать срез, он со всех по n сообщений запросит или только с последнего

Со всех запросит. В стандарте есть пример, я его прислал. Но ты похоже его даже не читал.

https://club.hugeping.ru/u/e/idec.talks/std.hugeping/-1:1

Тогда не понял, почему стандарт такой, если в каждой эхе разное количество новых сообщений. :) Ладно, поняли-разобрались. Стандарт читал но как-то не задумывался об этом, задумался только сегодня в тронвае :)

2shaos - фетчеры обновил

у меня sf работает так: запрос вида /u/e/эха1/эха2/эха3?sf=хэш1/хэш2/хэш3, и она ищет указанные хэши в эхах, если находит, начинает выдачу эх с них. сначала не вклчая сами хэшN, но несколько дней назад я сделал, чтобы включали, на всякий случай, 21 байта не жалко, зато можно убедиться, какой именно хэш

а какие бывают текстовые игры, применимые в эхах?

помню в ru.golovolomka в данетки играли. в vga.planets, вроде, только нетмейлом играли, как там эхи использовались, не вспомню. кто ещё что может вспомнить?

> 2Shaos, хочу с тебя дёргать только последних 100 хедеров, как у тебя нода устроена?

-100:100

У меня стандартный IDEC

Был :)

ahamai> а какие бывают текстовые игры, применимые в эхах?
ahamai>
ahamai> помню в ru.golovolomka в данетки играли. в vga.planets, вроде, только нетмейлом играли, как там эхи использовались, не вспомню. кто ещё что может вспомнить?

В быки-коровы можно играть везде, где есть запрос-ответ, хоть морзянкой.

Вот тут я пытался это пообсуждать месяц назад:

c8zTIjCQQ1RyAA264WnN

Вот тут можно тред поглядеть:

http://tgistation.ru/echo/subj/8/%D0%98%D0%B3%D1%80%D1%8B%2520%D0%BF%D0%BE%2520ii%2520/

P.S. Надо у меня чтоли тоже показ тредов поддержать, но только не линейно, а деревом - как на ixbt было или как комменты на слешдоте например…

у меня тред 404 выдаёт. подними тему, чтобы на hugeping в форумах высвечивалась :)

ну как минимум в беседке была викторина, основаная на каком-то irc-боте, типа даёт вопрос и вариант п****ц, потом открывает буквы

Странно - линк не открывается:

http://tgistation.ru/echo/subj/8/%D0%98%D0%B3%D1%80%D1%8B%2520%D0%BF%D0%BE%2520ii%2520/

А через ping?

https://hugeping.tk/forum/c8zTIjCQQ1RyAA264WnN/1

Ага. Интересно. А что если играть в текстовые игры на instead? Я за последние лет 15 или сколько там, прошёл ровно одну игру, "День яблока". Остальные не осилил. Кота и ещё несколько игр прошёл только по солюшнам, потому что сам даж не знал чё там и где.

А тут сделать в эхах массовое прохождение. Причём эх должно быть на каждую игру две, первая с лимитами на ход/ходы, отзаявкой неактивных участников, заявкой новых в очередь, и массовым прохождением игр толпой. Второе - полная анархия, где все делают ходы тогда, когда хотят, и то и другое интересно, и то и другое весело.

Ну и всё это сделать эксклюзивом нашей сети. Я помню, как году в 1997 играли в дюк нюкем на одной клавиатуре толпой, кто-то отвечал за стрельбу, кто-то за прыжки, кто-то за передвижение. Это было весело. И так, можно толпой проходить игру, и больше ответственности, и больше интереса.

> По хорошему особый сисоповский должен быть. Потому что пуш для межузлового взаимодействия. Поини в принципе не может слать пуш, так как в пуше уже зарегистрированные сообщения летят, а не пользовательские.

Может тогда как-то почётче это в стандарте про push проговорить?

да, я так и поставил, вроде всё работает как и задумано

у меня вроде вообще не было стандарта на push, я его и не поддерживал, но в push-нодах всегда был отдельный пароль

push-ноды для меня были как партизанские станции, которые раскидываешь по бесплатным php-хостингам и с ними живёшь. на серьёзных станциях он не был предусмотрен, потому что серьёзные станции только фетчат и на них нельзя что-то вливать

ahamai> Ничё не понял. Если щас задать несколько эх и дать срез, он со всех по n сообщений запросит или только с последнего

Со всех, если я правильно понял типавопрос.

+++ Caesium/0.4 RC1

ahamai> Тогда не понял, почему стандарт такой, если в каждой эхе разное количество новых сообщений. :) Ладно, поняли-разобрались. Стандарт читал но как-то не задумывался об этом, задумался только сегодня в тронвае :)

Потому что не надо байто**ить. Сильно помогает в подавляющем числе случаев.

ahamai> 2shaos - фетчеры обновил

+++ Caesium/0.4 RC1

ahamai> у меня sf работает так: запрос вида /u/e/эха1/эха2/эха3?sf=хэш1/хэш2/хэш3, и она ищет указанные хэши в эхах, если находит, начинает выдачу эх с них. сначала не вклчая сами хэшN, но несколько дней назад я сделал, чтобы включали, на всякий случай, 21 байта не жалко, зато можно убедиться, какой именно хэш

А если хеш в блеклисте или вообще удалён? Ну и сложно это в реализации и не особо незачем.

+++ Caesium/0.4 RC1

>> По хорошему особый сисоповский должен быть. Потому что пуш для межузлового взаимодействия. Поини в принципе не может слать пуш, так как в пуше уже зарегистрированные сообщения летят, а не пользовательские.
shaos> Может тогда как-то почётче это в стандарте про push проговорить?

Хорошо. Принимается.

+++ Caesium/0.4 RC1

А ещё можно передавать сохранения игр, проходя их по очереди. Те же дварфы (dwarf fortress). Много чего можно сочинить.

tuple> А ещё можно передавать сохранения игр, проходя их по очереди. Те же дварфы (dwarf fortress). Много чего можно сочинить.

У нас нельзя передавать файлы в общем случае. Да и бородачи нынче не те. Я так и не освоил новый интерфейс.

+++ Caesium/0.4 RC1

tuple> А ещё можно передавать сохранения игр, проходя их по очереди. Те же дварфы (dwarf fortress). Много чего можно сочинить.

Можно передавать уровни сокобана в plaintext-формате (.sok).

Хэш в блеклисте это вообще ничего не меняет, нужны же "сообщения от", если в файле эхи сообщение есть, то от него и пойдёт. Если хэша нет, то отдастся вся эха. По сравнению с текущим случаем, преимуществ два - хэш гораздо более надёжный источник, чем количество сообщений, и не сработает только в одном случае: если конкретная нода инъектировала в эху сообщения сверху - но на это нужно иметь настолько серьёзные основания, что это повод говорить об этом в сисопской эхе. Ну и второе - точно отдадутся только самые новые сообщения, одним запросом (я думал, реализация срезов вообще не так работает, в текущем виде она вообще какая-то непонятная, почему на все эхи один лимит, если сообщений в базе мало)

реализация и sf и lim у меня это всего несколько строчек.

было

def echoareas(names):
    out = ''
    for ea in names:
        out += ea + '\n' + get_echoarea(ea,True)
    return out

стало

def echoareas(names, sf, lim=0):
    out = ''
    if sf: sf = set(sf.split('/'))
    for ea in names:
        dllist = get_echoarea_f(ea)
        if sf:
            newhash = [x for x in dllist if x in sf]
            if newhash:
                dllist = dllist[dllist.index(newhash[0]):]
        if lim: dllist = dllist[-lim:]
        dllist = '\n'.join(dllist)
        if dllist: dllist += '\n'
        out += ea + '\n' + dllist
    return out

не использовалось это никогда потому что я не вижу смысла экономить и так копеечный трафик. но на такой случай реализация в моей станции была

> Можно передавать уровни сокобана в plaintext-формате (.sok).

это всё не так весело, тут играешь в одиночку. а я именно про игры всей компанией и совместную вовлечённость

- если сообщений в базе мало
+ если новых сообщений в эхах разное количество, непонятно почему просто не запрашивать с каждой нужное (ну, или, с гарантией +1, +5 сообщений, это небольшой оверхед, по сравнению со случаем когда опращиваются одним запросом эхи с 1 и 110 сообщениями)
111
Вообще, связка h и sf реально сокращает количество запросов и реально экономит трафик. Если это кому-то важно.

> Можно передавать уровни сокобана в plaintext-формате (.sok).

А если и играть через эху? ;)

Понятия не имею, что это слово означает, но вопросы имеются - раньше я вообще никогда не задумывался, как работают слайсы.

Во-первых, формат. /u/e/ чётко определён, там перечисляются эхи. Почему не использовать что-то типа ?s=-100:100 или любой другой способ? Если в фетчер ii 0.3 просунуть такой формат url и запросить что-то с ii 0.3, фетчер упадёт, не растоссив пакет, потому что будет считать -100:100 хэшем сообщения. Зачем плодить неоднозначность просто на ровном месте, там, где есть куча способов её избежать?

Ладно, раз уж решили изнасиловать формат /u/e, почему не использовать /u/e/эха/срез/эха/срез. Это же для экономии трафика всё затевалось? А какая экономия, если у тебя может быть куча эх, и ради одной роботной, где всегда куча сообщений, тянется куча ненужных? А если поодиночке - то это лишние запросы, на медленном и нестабильном интернете каждый запрос это всегда больно, и он может даже не состояться (поэтому links решал там, где opera не могла ни одного сайта открыть). Формат /u/e был придуман ровно для того, что дёргать /e на каждую эху было медленно и неэффективно. Изначально были только /e и /m, но всё это было медленно и печально.

>>^^<><>>...<><>... я выиграл?

кривая и косая версия adventure. играть можно только на моей станции

http://ii.blcat.ru/play.advent

Не - ты делаешь ход посылая команду в эху, а некий бот верифицирует твой ход, модифицирует карту и посылает её обратно в эху в ожидании следующего хода…

по одному ходу скучно, надо сразу по много

тем более что sokoban игра с полной информацией и ходами только с одной стороны, её можно пройти одной командой

Ещё есть вариант найти мастера, сыграть в D&D.

P.S. Чур я бард-человек.

> Ещё есть вариант найти мастера,

тут новые пользователи появляются раз в пятилетку... :)

Складывается впечатление, что idec это пример плохого проектирования. Зачем менять устоявшуюся структуру запроса /u/e если можно этого не делать? Зачем вводить ограничение "количество сообщений в эхе может не совпадать со счётчиком", если можно этого не делать?

Формат /u/e был именно только для списка эх. Зачем добавлять туда что-то ещё? Почему не использовать, например /u/e?s=срез? Это значительно всё упрощает, это можно сувать куда угодно без разбора. А так алгоритм отдачи "всё эха" меняется на "последняя эха может быть не эхой":

ВЕСЬ ЗАПРОС СПИСОК ЭХ
ПОЛУЧИЛИ СПИСКИ
ЕСЛИ ЕСТЬ ЛИМИТ, УСТАНОВИЛИ

становится

ПОЛУЧИЛИ СПИСОК ЭХ
ПРОВЕРИЛИ ПОСЛЕДНЮЮ
ЕСЛИ ЭТО СРЕЗ, ТО РАСПАРСИЛИ СРЕЗ
СОХРАНИЛИ ЛИМИТ
УДАЛИЛИ ПОСЛЕДНЮЮ ЭХУ
ПОЛУЧИЛИ СПИСКИ
УСТАНОВИЛИ ЛИМИТ, ЕСЛИ ЕСТЬ

Команда lim появилась добавлением одного роута и одной строчки кода. Совместима с любым ii, хоть с ii-txt-0.1preprepre.

При этом корёжится список:
http://ii.blcat.ru/u/e/blcat.test/-100:100

ЧТО ТЫ ТАКОЕ? Эха? Нет точки, не эха. MSGID? по логике вроде бы да. У меня софт в расчёте на минималистичность и читаемость кода призван валиться при любых невалидных данных, а не разбираться, что это за ёжик.

Тут же появляется x/features. Это на каждый фетч надо ещё один запрос делать? Это не экономия трафика, это его расход. С какой-нибудь ?s= можно просто гонять url-ы и на любой клиент и на любой сервер, не задумываясь, поймёт ли он. А тут получается, надо прочитать x/features, потом подстроиться под сервера, давать ему срез или не давать. Лишний код, лишний трафик, лишнее переусложнение.

Сами же срезы не решают основной задачи "получить все нужные msgid одним запросом". Тебе нужно или обходить эхи по-очереди (привет, /e, от которого специально уходили для ускорения работы), или получать лишние сообщения. В стандарте не предусмотрено "хочу брать столько сообщений оттуда-то".

Кстати, ?sf потребовал добавления, по-моему, 4х строк кода и изменения одной. И он решает вопрос "получить только нужные msgid из нужных эх одним запросом".

И ещё. Для подсчёта по эхам нужно сделать ещё один запрос, чтобы получить текущее количество сообщений на сервере. Для ?sf этого не нужно, там делается ровно один запрос, а не три. И получает в итоге меньший бандл хэшей. И надёжнее, чем полагаться на количество сообщений.

Куча переусложнений там, где их можно было не делать, и при этом основная цель минимизации трафика до конца не доведена. Это пример плохого проектирования, как по мне.

ps. ?sf и ?h появились раньше, чем был сформирован стандарт iDEC.

добавил в архив сравнение станций

http://ii.blcat.ru:50000/compare

чёто боты по all=1 долбятся, сервер грузят, надо будет недоделанный архив скоро погасить, доделать, разобрать и перебрать

смотрю я на это и думаю, а давайте ru.humor.14 на бон вернём?

Не надо драматизировать :)

Индексы тоже пару строк кода добавляют (ну может чуть больше)

Для разнообразия можно множественные "слайсы" тоже сделать, типа

/u/e/echo.1/echo.2/-1:1/echo.3/-100:100/echo.4

будет означать, что echo.1 и echo.2 должны вернуть одно последнее сообщение, echo.3 должно вернуть 100 последних, а echo.4 должно вернуть всё - в этом случае всё будет логично и гибко ;)

кто будет переписывать цезий или фетчеры под замену стандартов? стандарты уже такие, какие получились. у меня вопрос - чому так?

> будет означать, что echo.1 и echo.2 должны вернуть одно последнее сообщение, echo.3 должно вернуть 100 последних, а echo.4 должно вернуть всё - в этом случае всё будет логично и гибко ;)

если менять это, то надо убирать неэхи из стрки для эх. чтобы оно прозрачно накладывалось, а не как у меня пишет -100:100 в файле списка, потому что на это вообще не рассчитвалась. в /u/e должны быть только эхи, это изначальный стандарт

Интересно, что ii.stat я взял с таверны, и сам добавляю туда еженедельную статистику, а там остался старый вариант остановившийся в 2018 году :)

Люди, дайте ii.14 у кого есть? Очень хочется в промежуточную историю окунутся между тем что было на alicorn и тем что сейчас - я письмо ake написал (у него на станции было), но он не отвечает...

Ещё момент - lor-opennet.17 есть в таверне тоже, только она там глючит (сразу после сбойного сообщение оно размножается)