nedoPC.org

Расширенные правила форматирования текста в ii/idec:

https://club.hugeping.ru/rOf069UX8K24yAzvWa9N

Пока работают только на этом конкретном сервере написанном на Go - надо такое в мою PHP-ноду тоже добавить...

P.S. Например там отображаются добавленные в текст сообщения картинки в формате XPM

В своё время забыл опубликовать тут скриншоты текстового клиента IDEC, написанного на питоне:

Настроил Rewrite чтобы урл для ii-клиентов был проще - теперь вместо домен/ii-point.php?q=/ можно просто писать домен/iii/
т.е. чтобы запросить список эх в текстовом виде надо вызвать https://sprinternet.io//iii/list.txt
(к этому же серверу можно по http:// обращаться, но через порт 8080: sprinternet.io:8080/iii/list.txt)
А открыв http://sprinternet.io:8085 можно перепрыгнуть прямиком в веб-интерфейс моей ii/IDEC-ноды по старому адресу...

Стал раз в сутки по апачи логам считать самых активных качальщиков ноды - в списке как другие ноды сети IDEC, так и боты типа Google, Facebook и Yandex:
Строка пишется внизу вебстранички слева...

P.S. Плюс ещё в специальную эху посылаю ежедневный отчёт - вот например данные за 2 октября:
см. https://sprinternet.io/iii-web.php?echo=spnet.stats

Ради интереса посчитал статистику по соответствию хешей названиям мессагов

В старом ii архиве (46481 штук):

81.6% названий соответствуют хэшам
18.4% не соответствуют (например сообщения были отредактированы уже после того как сервер их посчитал)

В новых ii/IDEC мессагах (20760 штук):

28.0% названий соответствует хэшам
0.4% соответствуют после приведения к нижнему регистру (значит была подмена на Z вместо z)
71.6% не соответствует (почему стало так много непонятно)

P.S. В-принципе наверное понятно - очень много ранних RSS-ботов генерировали неправильные хеши...

Первоначальный автор протокола ii (которому в марте этого года стукнуло 10 лет [протоколу стукнуло - не автору]) решил тряхнуть стариной и выкатил свой новый ii-сервер пропиарив его на лоре

https://www.linux.org.ru/forum/general/17755587

P.S. А лор похоже уже не торт...

Автор сети и протокола ii (теперь он ходит в сеть ii под ником iiii) воссоздал эху про старые компьютеры у себя на узле http://ii.blcat.ru, составив её из старых сообщений старых эх oldpc.51t.ru (2020) и old.pc (2022) - я держу копию эхи у себя:

https://sprinternet.io/iii-web.php?echo=retro.talks

Автор зарелизил облегченный ii-сервер, в составе которого уже есть эха retro.talks на почитать

Для отправки сообщения от клиента к узлу ii/IDEC с самого начала применяется следующий формат:
Пример:
Это сообщение заворачивается в base64url и засылается на узел либо через метод GET:
URL/u/point/PAUTH/B64STRING
либо через метод POST:
URL/u/point
pauth=PAUTH&tmsg=B64STRING
где PAUTH - строка авторизации для данного пользователя (поинта) - по сути пароль (который должен быть свой для каждого поинта).

Как можно видеть тут прямым текстом в сеть передаётся пароль - даже в случае https:// если он идёт через GET, то он считай засвечен (а в случае http:// будет засвечен и через POST), поэтому я думаю можно сделать альтернативный способ аутентификации пользователя скажем через подпись 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)

т.к. ii/IDEC передаёт сообщения в UTF-8, то там можно не только русский текст гнать, но и например emoji

Нашлась VK-шная копия пропавшей обзорной статьи про IDEC от сентября 2018:

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

(копия датируется 2020 годом)

P.S. Немного из истории создания IDEC (эха ii.14 ни у кого не сохранилась):

https://web.archive.org/web/20170515203311/http://club.syscall.ru/:ii.14

2 последних старожила IDEC отвалились - это hugeping.tk / club.hugeping.ru (нода ping) и idec.spline-online.ru (нода tavern)
осталась относительно новая нода tgi - https://tgistation.ru (создана в 2021 году, но её сисоп не выходит на связь)
и моя нода, которая недавно сменила название на spnet - https://sprinternet.io/iii/
а также уже месяц существует новый вебсайт-нода http://ii.blcat.ru от создателя ii (соответственно эта нода не поддерживает навороты IDEC)...

Сага от создателя ii продолжается

https://www.linux.org.ru/news/internet/17797879

А тем временем появилась новая нода fox на движке от отвалившегося hugeping на языке Go и она фетчит все эхи какие может найти, включая мои:

В начале ноября я на своей ноде сделал поддержку более универсальных запросов.

Всё также можно делать запросы в стародавнем стиле ii:

нода/u/e/retro.talks/english.talks

Всё также можно делать запросы со "слайсами" в стиле IDEC (когда диапазон указанный в конце распространяется на все перечисленные эхи):


Но теперь появляется возможность писать диапазоны не только в конце, но и в середине списка эх (как я уже вчера докладывал):


Причём вместо -1:1 можно написать волшебное слово last:


Также в середине списка можно указать волшебное слово all если вдруг какую-то среднюю эху надо выкачать целиком:


И это уже похоже на то, что предлагалось пользователем revoltech, а я даже сделал возможным указывать хеш, начиная с которого надо возвращать список хешей:


Более того - можно указывать только первые символы хеша


Главное чтобы оно было не цифрой, иначе оно будет ругаться.

А таже анонсированный создателем ii новый способ ограничения ответа /u/e/lim/N/...


По идее lim можно использовать вместе со слайсами, но только если lim указывается правее слайсов


т.е. [-]N:M действует влево (как и all, last и hash), а lim действует вправо!

Ну и напоследок - выдача сообщений сохранённых на этой конкретной ноде позже какого-то времени


(если время совпадает, то такое сообщение тоже возвращается)

Также сделал хак для поддержки /lim/N/u/e/...


работает также как и



Также исправил то, что никогда в PHP-шной ноде не поддерживалось - N:0 должно означать всё, начиная с N-го - теперь я заменяю количество 0 на 999999999 (один миллиард минус 1) т.к. вряд ли когда-нибудь в ii/IDEC будут эхи с количеством сообщений больше миллиарда - ограничение такое сделал ещё и из-за того, что у меня в /u/e/ теперь unixtime может пролетать и для простоты он у меня определяется как число >=1000000000 что соответствует Sun Sep 09 2001 01:46:40 GMT+0000 (не думаю, что в ii/IDEC когда-либо попадутся сообщения сохранённые ранее сентября 2001 года).

P.S. Имено "сохранённые" т.е. эта метка времени для проверки времени сохранения файла сообщения (когда оно было сохранено на данном узле), а не времени в заголовке сообщения (когда оно было создано на узле отправителе)...