Компьютерная сеть IDEC и возможные пути её развития

[Shaos]

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

https://club.hugeping.ru/rOf069UX8K24yAzvWa9N

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

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

[Shaos]

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

screen-20211216-100440.png

screen-20211216-100452.png

[Shaos]

Перенёс тему в подфорум "Проект nedoPC"

P.S. Интересным побочным эффектом перетаскивания ноды IDEC на сервер спринтернета стало то, что теперь к ней стало можно обращаться и по https://

https://sprinternet.io/iii-web.php

P.P.S. Блин, гугол начал активно индексировать там контент через https://

Настроил 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-ноды по старому адресу...

[Shaos]

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

Code: Select all

Last day top uplinks: tavern 41.7MB (5/hr), tgi 4.1MB (2/hr), ping 3.2MB (5/hr), Google 0.8MB (1/hr), Facebook 0.1MB

Строка пишется внизу вебстранички слева...

P.S. Плюс ещё в специальную эху посылаю ежедневный отчёт - вот например данные за 2 октября:

TOP10 VISITORS:

[1] Google point=108 web=899 26.6MB <--- Google (4/hr)
[2] 62.109.31.x point=48 web=0 16.4MB <--- tavern (2/hr)
[3] DataForSeoBot point=0 web=26 8.3MB
[4] 92.63.98.x point=72 web=0 4.7MB <--- tgi (3/hr)
[5] 95.165.9.x point=144 web=0 3.7MB <--- ping (6/hr)
[6] 95.217.57.x point=0 web=1 1.1MB
[7] 24.6.124.x point=3 web=46 0.4MB
[8] 92.246.138.x point=0 web=1 0.1MB
[9] YandexBot point=0 web=17 0.1MB
[10] 172.56.46.x point=0 web=4 0.0MB

см. https://sprinternet.io/iii-web.php?echo=spnet.stats

[Shaos]

Далее по всему этому считается хэш SHA256 (32 байта), бинарное представление которого переводится в base64 (что даёт 43 символа), от которого берутся первые 20 символов (46.9% от всей строки), но т.к. base64 наряду с буквами A...Z a...z и цифрами 0...9 ещё имеет 2 дополнительных небуквоциферных символа + и / для пущей читабельности они заменяются на символы A и z (именно так - большая A и маленькая z) - уникальность хэша от этого немного портится (покрытие уменьшается в 1.88 раз с 64^20 до 62^20, что даёт 7e35 вариаций), но хэш становится "безопасным" для передачи как угодно.
...
P.S. А вот относительно новый сервер ii-go, написанный на Go, заменяет небуквоциферные символы на A и Z (большую) - собственно так и было написано в документации (как пример). И плюс к этому разрешает редактировать сообщение после того как ему уже присвоен ID и оно сохранено на сервере (и даже уже передано на другие сервера) - при этом содержимое сообщения меняется, но его хэш остаётся прежним, что несколько противоречит всей концепции.

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

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

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

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

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

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

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

[Shaos]

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

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

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

[Shaos]

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

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

[Shaos]

Автор сети и протокола 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 на почитать

Nastene Retro 98 : версия сервера для старых систем. Для python 2.5-2.7, только lite интерфейс, вырезано всё, что можно.

Идеальный вариант для ваших серверов с Debian Etch (или в Etch максимум 2.4? тогда ничего не поделаешь, придётся обновиться до Lenny)

В комплекте архив эхи retro.talks, будет что почитать долгой зимней ночью. И на станции уже сразу есть контент. К сожалению, заметки о Debian Sarge туда не попали в связи с их ненаписанностью, но будут доступны позже в эхе.

http://ii.blcat.ru/s/nastene-retro-98.tar.gz

[Shaos]

Интересный способ идентификации сообщений выбран в ii (перекочевавший затем в IDEC и использующийся в двух самых старых серверах реализующих этот протокол - ii-php написанном на PHP и iing написанном на Python) - сервер формирует текст сообщения для сохранения добавляя к нему заголовки, а именно:

1. tags - теги (используются только для `repto` и для идентификатора `ii/ok`)
2. echoarea - основная эхоконференция, в которую помещается сообщение
3. date - число секунд от эпохи unix, в utc
4. msgfrom - отправитель
5. addr - адрес отправителя (практического смысла не имеет, служит для того, чтобы узнавать, с какой станции пришло сообщение)
6. msgto - пользователь, которому предназначено сообщение (либо All)
7. subj - тема сообщения
8. пустая строка
9. и далее - текст сообщения

Пример из документации:

Code: Select all

ii/ok/repto/IZXhLBKJx0rhx0lXYu3L
im.16
1455789357
Vasya
Lunar, 2
Pupkin
Re: Мое первое сообщение в эху

текст сообщения

(в данном случае наличие ключевого слова repto в тегах означает, что это сообщение является ответом на сообщение с указанным ID - здесь IZXhLBKJx0rhx0lXYu3L)

Далее по всему этому считается хэш SHA256 (32 байта), бинарное представление которого переводится в base64 (что даёт 43 символа), от которого берутся первые 20 символов (46.9% от всей строки), но т.к. base64 наряду с буквами A...Z a...z и цифрами 0...9 ещё имеет 2 дополнительных небуквоциферных символа + и / для пущей читабельности они заменяются на символы A и z (именно так - большая A и маленькая z) - уникальность хэша от этого немного портится (покрытие уменьшается в 1.88 раз с 64^20 до 62^20, что даёт 7e35 вариаций), но хэш становится "безопасным" для передачи как угодно.

При передаче сообщения между сервером и клиентом также используется base64 (но только всего сообщения) - в виде base64url, в котором + заменяется на - а / заменяется на _

Для отправки сообщения от клиента к узлу ii/IDEC с самого начала применяется следующий формат:

1. echoarea
2. msgto
3. subject
4. empty string
5. repto
6. message text

If repto starts with @repto:, the node places the tag repto. Otherwise the string belongs to the message text.

Пример:

im.16
All
Тестируем

@repto:2hEUbMAxKSA83vcmgU4s
И вот я пишу своё первое письмо в нашу секту.
Меня видно?

Это сообщение заворачивается в 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)

[Shaos]

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

[Shaos]

Нашлась 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

[Shaos]

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)...

[Shaos]

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

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

[Shaos]

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)...

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

[Shaos]

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

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

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

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

Code: Select all

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/english.talks/-1:1
retro.talks
XOjs0DTBN77YYkJT2drY
english.talks
HOYW7nXXHb3HPKAFLz1w

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

Code: Select all

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/-2:2/english.talks/-1:1
retro.talks
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
HOYW7nXXHb3HPKAFLz1w

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

Code: Select all

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/zx.spectrum/-2:2/english.t…
retro.talks
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
zx.spectrum
1cKGi833VgPtcN7D7uDs
ZryriIaG5IJqKHX3C6kl
english.talks
HOYW7nXXHb3HPKAFLz1w

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

Code: Select all

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/-3:3/english.talks/all/zx.…
retro.talks
yceDK3BmBJnfAZQlktjd
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w
zx.spectrum
ZryriIaG5IJqKHX3C6kl

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

Code: Select all

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/5B3Tra1DRJEcymDcA6Gi/engli…
retro.talks
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w
zx.spectrum
ZryriIaG5IJqKHX3C6kl

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

Code: Select all

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/5B3T/english.talks/all/zx.…
retro.talks
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w
zx.spectrum
ZryriIaG5IJqKHX3C6kl

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

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

Code: Select all

> curl -XGET https://sprinternet.io/iii/u/e/lim/3/retro.talks/english.talks/zx.spe…
retro.talks
yceDK3BmBJnfAZQlktjd
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w
zx.spectrum
MPaCqYswUePWAAfiioBL
1cKGi833VgPtcN7D7uDs
ZryriIaG5IJqKHX3C6kl

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

Code: Select all

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/-4:4/lim/3/english.talks/z…
retro.talks
H50pJyclcYjeJbXBAi8k
yceDK3BmBJnfAZQlktjd
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w
zx.spectrum
MPaCqYswUePWAAfiioBL
1cKGi833VgPtcN7D7uDs
ZryriIaG5IJqKHX3C6kl

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

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

Code: Select all

> curl -XGET https://sprinternet.io/iii/u/e/retro.talks/english.talks/zx.spectrum/…
retro.talks
english.talks
HOYW7nXXHb3HPKAFLz1w
zx.spectrum

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

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

Code: Select all

> curl -XGET https://sprinternet.io/iii/lim/3/u/e/retro.talks/english.talks
retro.talks
yceDK3BmBJnfAZQlktjd
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w

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

Code: Select all

> curl -XGET https://sprinternet.io/iii/u/e/lim/3/retro.talks/english.talks
retro.talks
yceDK3BmBJnfAZQlktjd
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w

Также исправил то, что никогда в 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. Имено "сохранённые" т.е. эта метка времени для проверки времени сохранения файла сообщения (когда оно было сохранено на данном узле), а не времени в заголовке сообщения (когда оно было создано на узле отправителе)...