разговоры об ii/IDEC


\/ . revoltech to shaos @ Re: Стандарт 29/10/24 06:10

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

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

266SvQ... . ОТВЕТИТЬ



\/ . revoltech to revoltech @ Re: Стандарт 29/10/24 06:12

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

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

AAOwTv... . ОТВЕТИТЬ





\/ . Andrew Lobanov to shaos @ Re: Стандарт 29/10/24 06:46

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

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

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

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

XZKvlr... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Стандарт 29/10/24 06:46

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

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

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

qaM0nA... . ОТВЕТИТЬ



\/ . shaos to All @ Аутентификация поинтов через несекьюрное соединение 29/10/24 06:50

Вобщем мне никогда не нравилось, что в /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)

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

Arm3cW... . цепочка . ОТВЕТИТЬ



\/ . shaos to Andrew Lobanov @ Re: Стандарт 29/10/24 06:54

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

lyhVni... . ОТВЕТИТЬ



\/ . shaos to shaos @ Re: Аутентификация поинтов через несекьюрное соединение 29/10/24 06:59

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

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

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

Ccg6Qi... . ОТВЕТИТЬ



\/ . shaos to Andrew Lobanov @ Re: Стандарт 29/10/24 07:06

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

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

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

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

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

ВСЁ!

5AAPMN... . ОТВЕТИТЬ



\/ . Andrew Lobanov to tuple @ Re: Стандарт 29/10/24 06:53

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

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

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

U8PeEn... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Стандарт 29/10/24 06:53

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

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

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

KSk6fP... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Стандарт 29/10/24 07:43

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

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

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

RP2PNs... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Аутентификация поинтов через несекьюрное соединение 29/10/24 07:43

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> Обсуждаем? :)

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

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

YCgDLT... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Стандарт 29/10/24 07:43

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

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

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

nWfBZQ... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Стандарт 29/10/24 07:43

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> ВСЁ!

Да.

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

Wbu56b... . ОТВЕТИТЬ



\/ . tuple to revoltech @ Re: Станции ii/IDEC в .onion (Tor) 29/10/24 08:21

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

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

gFeXqo... . ОТВЕТИТЬ



\/ . tuple to Andrew Lobanov @ Re: Стандарт 29/10/24 08:34

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

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

nYd9p4... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Аутентификация поинтов через несекьюрное соединение 29/10/24 08:47

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

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

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

F1EFAg... . ОТВЕТИТЬ



\/ . revoltech to tuple @ Re: Станции ii/IDEC в .onion (Tor) 29/10/24 08:48

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

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

t2zAzB... . ОТВЕТИТЬ



\/ . tuple to revoltech @ Re: Станции ii/IDEC в .onion (Tor) 29/10/24 08:54

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

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

lwPwHz... . ОТВЕТИТЬ



\/ . Andrew Lobanov to tuple @ Re: Стандарт 29/10/24 10:14

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

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

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

nVJPOy... . ОТВЕТИТЬ













\/ . shaos to revoltech @ Re: Аутентификация поинтов через несекьюрное соединение 29/10/24 15:10

> Вот это в стандарт точно тащить не надо. Кому в 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)."

QAzg5U... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Аутентификация поинтов через несекьюрное соединение 29/10/24 15:19

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

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

pQPFMI... . ОТВЕТИТЬ



\/ . shaos to revoltech @ Re: Аутентификация поинтов через несекьюрное соединение 29/10/24 15:32

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

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

ovuX4I... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Аутентификация поинтов через несекьюрное соединение 29/10/24 15:42

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

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

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

3fBFYz... . ОТВЕТИТЬ







\/ . revoltech to shaos @ Re: Аутентификация поинтов через несекьюрное соединение 29/10/24 15:56

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

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

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

3hzbA9... . ОТВЕТИТЬ



\/ . revoltech to shaos @ Re: Аутентификация поинтов через несекьюрное соединение 29/10/24 15:58

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, а на самом деле пофигу вообще. Между клиентом и сервером только начальная регистрация ключа должна быть секьюрной.

Ey3fF6... . ОТВЕТИТЬ







\/ . Andrew Lobanov to shaos @ Re: Стандарт 29/10/24 17:58

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

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

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

U7ik2k... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Аутентификация поинтов через несекьюрное соединение 29/10/24 17:58

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

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

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

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

wT4maj... . ОТВЕТИТЬ





\/ . shaos to shaos @ Re: Аутентификация поинтов через несекьюрное соединение 29/10/24 20:52

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

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

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

AcIXYp... . ОТВЕТИТЬ





\/ . Andrew Lobanov to shaos @ Re: Аутентификация поинтов через несекьюрное соединение 30/10/24 06:50

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

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

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

l3ygMB... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Аутентификация поинтов через несекьюрное соединение 30/10/24 06:50

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

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

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

aZA9tp... . ОТВЕТИТЬ



\/ . doesnm to shaos @ Re: Аутентификация поинтов через несекьюрное соединение 30/10/24 07:07

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

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

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

XbQrY5... . ОТВЕТИТЬ



\/ . revoltech to ahamai @ Re: Срез 30/10/24 08:05

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

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

KTwLdL... . ОТВЕТИТЬ





\/ . hugeping to Andrew Lobanov @ Re: Стандарт 30/10/24 08:01

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

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

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

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

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

SSN8S1... . ОТВЕТИТЬ



\/ . revoltech to hugeping @ Re: Срез 30/10/24 08:07

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

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

4QGHlM... . ОТВЕТИТЬ





\/ . hugeping to revoltech @ Re: Срез 30/10/24 08:15

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 запрашивает последние десять сообщений в индексе.

iMFf6Q... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Срез 30/10/24 08:39

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

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

58Qg7t... . ОТВЕТИТЬ



\/ . tuple to hugeping @ Re: Стандарт 30/10/24 09:27

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

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

2r6fNk... . ОТВЕТИТЬ



\/ . Andrew Lobanov to hugeping @ Re: Стандарт 30/10/24 09:28

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. Я бы оставил ещё повисеть драфт, мы же никуда не спешим? Вдруг кто-то что-то вспомнит. :)

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

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

ICqQO9... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Срез 30/10/24 09:28

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

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

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

p1xgqn... . ОТВЕТИТЬ



\/ . Andrew Lobanov to revoltech @ Re: Срез 30/10/24 09:28

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

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

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

NhzSEe... . ОТВЕТИТЬ



\/ . ahamai to Andrew Lobanov @ Re: Срез 30/10/24 10:00

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

71Q2T9... . ОТВЕТИТЬ





\/ . ahamai to ahamai @ Re: Срез 30/10/24 10:45

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 мб, а так вообще урежется :)

eCh5Ha... . ОТВЕТИТЬ



\/ . hugeping to ahamai @ Re: Срез 30/10/24 10:21

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

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

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

lQojMg... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Срез 30/10/24 10:50

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

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

Wo8PwA... . ОТВЕТИТЬ



\/ . ahamai to hugeping @ Re: Срез 30/10/24 10:53

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

ohvLHz... . ОТВЕТИТЬ



\/ . ahamai to All @ игры в эхах 30/10/24 11:43

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

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

tzzauT... . цепочка . ОТВЕТИТЬ



\/ . shaos to ahamai @ Re: Срез 30/10/24 12:09

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

-100:100

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

Был :)

2UobhB... . ОТВЕТИТЬ



\/ . revoltech to ahamai @ Re: игры в эхах 30/10/24 12:09

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

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

aKyOAC... . ОТВЕТИТЬ



\/ . shaos to ahamai @ Re: игры в эхах 30/10/24 12:24





\/ . ahamai to shaos @ Re: Игры по ii 30/10/24 12:34

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

SgRJ33... . ОТВЕТИТЬ







\/ . ahamai to shaos @ Re: игры в эхах 30/10/24 12:55

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

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

rsoRao... . ОТВЕТИТЬ



\/ . ahamai to ahamai @ Re: игры в эхах 30/10/24 12:57

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

mFjPUN... . ОТВЕТИТЬ



\/ . shaos to Andrew Lobanov @ Re: Аутентификация поинтов через несекьюрное соединение 30/10/24 12:53

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

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

tIlaQA... . ОТВЕТИТЬ





\/ . ahamai to shaos @ Re: Аутентификация поинтов через несекьюрное соединение 30/10/24 13:02

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

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

dOSq2V... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: Срез 30/10/24 13:32

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

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

+++ Caesium/0.4 RC1

cjwEpC... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: Срез 30/10/24 13:32

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

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

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

+++ Caesium/0.4 RC1

oyIOoN... . ОТВЕТИТЬ



\/ . Andrew Lobanov to ahamai @ Re: Срез 30/10/24 13:32

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

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

+++ Caesium/0.4 RC1

mK7EJU... . ОТВЕТИТЬ



\/ . Andrew Lobanov to shaos @ Re: Аутентификация поинтов через несекьюрное соединение 30/10/24 13:32

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

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

+++ Caesium/0.4 RC1

JxWAQI... . ОТВЕТИТЬ



\/ . tuple to ahamai @ Re: игры в эхах 30/10/24 14:16

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

9PdbEo... . ОТВЕТИТЬ



\/ . Andrew Lobanov to tuple @ Re: игры в эхах 30/10/24 15:25

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

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

+++ Caesium/0.4 RC1

XV2zTp... . ОТВЕТИТЬ



\/ . revoltech to tuple @ Re: игры в эхах 30/10/24 17:34

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

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

4N81Ep... . ОТВЕТИТЬ



\/ . ahamai to Andrew Lobanov @ Re: Срез 30/10/24 18:42

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

реализация и 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
====



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

E8HPIq... . ОТВЕТИТЬ



\/ . ahamai to revoltech @ Re: игры в эхах 30/10/24 18:44

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

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

557aj9... . ОТВЕТИТЬ



\/ . ahamai to ahamai @ Re: Срез 30/10/24 18:49

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

3SXU4Z... . ОТВЕТИТЬ





\/ . ahamai to Andrew Lobanov @ Re: Срез 30/10/24 19:32

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

Во-первых, формат. /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, но всё это было медленно и печально.

6UqbDy... . ОТВЕТИТЬ







\/ . shaos to ahamai @ Re: игры в эхах 30/10/24 20:40

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

TgyRrg... . ОТВЕТИТЬ





\/ . ahamai to shaos @ Re: игры в эхах 30/10/24 20:51

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

qNsQ3y... . ОТВЕТИТЬ







\/ . ahamai to All @ Разбор idec 30/10/24 23:20

Складывается впечатление, что 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.

cQozlz... . цепочка . ОТВЕТИТЬ







\/ . shaos to ahamai @ Re: Разбор idec 31/10/24 03:17

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

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

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

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

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

3PasI6... . ОТВЕТИТЬ



\/ . ahamai to shaos @ Re: Разбор idec 31/10/24 03:30

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

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

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

h7Htet... . ОТВЕТИТЬ



\/ . shaos to ahamai @ Re: тестовый архив 31/10/24 03:22

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

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

0znI8z... . ОТВЕТИТЬ



shaos to shaos @ Re: тестовый архив 31/10/24 03:39

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

7n8wAA... . ОТВЕТИТЬ


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 .22. 23 24 25 26 27 28 29 30 31