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

Да - в /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

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

Это одна эха

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

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