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

Shaos · Post by **Shaos** » 15 Dec 2021 06:51

https://web.archive.org/web/20211130125940/https://ii-net.tk/idec-doc/?p=main

Что может предложить наша сеть и технология:

Чтение интересных RSS-лент и спокойное общение в одном приложении

Отсутствие лайков, фоточек, видосиков, свистелок и прочего непотребства: только текст

Грамотное, дружелюбное и неравнодушное население

Поддержка всех современных ОС

Простая интеграция своих скриптов, расширений, ботов и так далее

Полноценная работа в Offline

Распределённость и отказоустойчивость (сообщения разлетаются по всем серверам; последний сервер жив - сеть жива)

Минимальное потребление ресурсов на клиенте и техническая простота
Взгляд со стороны:

Есть несколько серверов (грубо говоря, сайтов), за каждым из которых закреплены свои пользователи (поинты). Поинты пишут сообщения каждый на свой сервер. Через каждые 10-20 минут сервера скачивают друг у друга новые сообщения. В итоге на всю сеть одна общая база данных. Для установления цепочек синхронизации владельцы серверов сначала договариваются.

IDEC (ii-like Data Exchange Convention) создан на основе протокола ii:
https://web.archive.org/web/20210419081052/https://ii-net.tk/idec-doc/?p=iibonds

ii - протокол обмена сообщениями, который появился в 2014 году благодаря одному энтузиасту по имени Рома. В рамках ii развивалось сообщество под названием "Клуб хороших людей", которое по некоторым причинам (в том числе уход автора из проекта) прекратило своё существование.

Основные темы, где были представлены релизы ii и "Клуб":

https://www.linux.org.ru/news/opensource/10319264

https://www.linux.org.ru/news/opensource/10534550

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

Плюс ещё вот это более раннее:

Описание ii от автора (взято из вебархива https://web.archive.org/web/20140909193610/http://ii.51t.ru/):

ii: говорил, говорит и будет говорить

ii - это система для онлайн и оффлайн обмена сообщениями, вобравшая в себя лучшие идеи из форумов, твиттера, FIDO и git. Она имеет примитивное внутреннее устройство, которое позволяет вести дискуссии даже из консоли и всегда иметь на локальной машине копии сообщений.

Реализация сервера написана на python 2, bottle.py (проверена работа в openbsd,linux,haiku). Любой ii-сервер может обмениваться трафиком со всеми подобными серверами или с конечными пользователями (через клиенты).

Короткий faq

- Это фидо?
И да, и нет. Это сверхпростое фидо без нетмейла и аутбаунда, если кому-то это о чём-то говорит.

- Это децентрализованная сеть?
И да, и нет. Скорее, да.

- Это кому-то интересно?
Это кому-то практично.

- И что тут делать?
Общаться и собирать вместе тематические сообщества вместо ужасных соцсетей и сервисов.

В настоящее время существует как минимум 7 узлов сети IDEC (последний в списке это архив старых ii-сообщений):

http://idec.spline-online.ml
https://club.hugeping.ru
https://dynamic.lessmore.pw
http://gears.headake.win/idec/ui2/
https://idec.textgamesinfo.ru
https://ii-net.tk/ii/ii-web.php
https://alicorn.tk/ii-old/

Узлы имеют как обшие эхоконфренции, так и свои собственные. Я в ближайшее время планирую поднять свой сервер IDEC со своими собственными эхоконференциями

P.S. Недавно появился чат в телеге: https://t.me/idec_chat где можно позадавать вопросы текущим мантейнерам стандарта IDEC

P.P.S. Сделал свой форк серверной части: https://gitlab.com/shaos/iii-php и поставил на свой сервер http://idec.shaos.net/

P.P.P.S. С начала октября 2024 года официальный новый адрес моей IDEC ноды такой: https://sprinternet.io/iii-web.php

Shaos · Post by **Shaos** » 16 Dec 2021 06:27

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

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

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

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, в котором + заменяется на - а / заменяется на _

P.S. А вот относительно новый сервер ii-go, написанный на Go, заменяет небуквоциферные символы на A и Z (большую) - собственно так и было написано в документации (как пример). И плюс к этому разрешает редактировать сообщение после того как ему уже присвоен ID и оно сохранено на сервере (и даже уже передано на другие сервера) - при этом содержимое сообщения меняется, но его хэш остаётся прежним, что несколько противоречит всей концепции.

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

Shaos · Post by **Shaos** » 19 Dec 2021 13:35

Поднял собственную ноду IDEC:

http://shaos.net:8085

Shaos · Post by **Shaos** » 20 Dec 2021 07:03

Сделал форвардинг с http://idec.shaos.net на http://shaos.net:8085/ii-web.php для простоты запоминания...

Shaos · Post by **Shaos** » 22 Dec 2021 11:46

Наткнулся на статистику сети в графическом виде:

https://grafana.lessmore.pw/d/vPKzlQKWk/idec?orgId=1

Вот оттуда график активности за всё время её существования:

Shaos · Post by **Shaos** » 23 Feb 2022 04:15

Форкнул версию сервера ii-php себе: https://gitlab.com/shaos/iii-php

Shaos · Post by **Shaos** » 18 Sep 2022 16:34

Чото за полгода большинство узлов IDEC просрочили свои домены либо получили пустые страницы или редиректят на левые сайты

Рабочих узлов по сути осталось только два:
https://dynamic.lessmore.pw
https://club.hugeping.ru
ну и мой узел (третий):
https://shaos.net:8085
т.к. я забирал и отправлял через spline-online.ml то мой узел получился отрезан от сети - на нём не появляются новые сообщения и с него ничего никуда не отправляется

Надо налаживать контакты с одним из оставшихся в живых узлов...

P.S. Есть один новый узел, не вошедший в стандартную статистику:
https://tgistation.ru/
На нём правда эх совсем мало (2 из которых локальные):

Code: Select all

    tgi.news
    tgi.station
    idec.talks
    pipe.2032
    zx.spectrum

и они похоже с июня не обновлялись...

Shaos · Post by **Shaos** » 18 Sep 2022 22:16

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

Также я добавил ещё один узел для фетча https://dynamic.lessmore.pw - теперь новые сообщения извне приходят ко мне в пределах 20 минут (о ней знают несколько узлов, но не все).

Кроме того я добавил эху idec.test, которая используется для тестирования клиентов и веб-интерфейсов узлов.

P.S. Надо научить веб-интерфейс сортировать сообщения в хронологическом порядке, а то щас они показывается в том порядке, в котором забрались извне.

P.P.S. Основной оживший узел это http://idec.spline-online.tk/ - через него мои сообщения и уходят в сеть...

Shaos · Post by **Shaos** » 29 Apr 2023 04:09

В декабре 2021 в эхе idec.talks я предложил следующие пути развития IDEC:

Shaos wrote: Я познакомился в ii/IDEC только в августе этого года, стал изучать как оно всё устроено и наконец на днях, воспользовавшись открытой реализацией ii-php, поднял свой узел - теперь у меня есть несколько мыслей по возможному будущему этой системы (либо системы, которая может отпочковаться от этой системы, но будет оставаться совместимой со старым IDEC API):
Кроме base64 существует чуть более компактный способ представления бинарных данных в виде текста - это алгоритм ascii85, когда каждые 4 байта представляются 5-значным 85-ричным числом, где каждая "цифра" это символ от '!' до 'u', плюс буквы 'z' и 'y' несут особый смысл, кодируя четвёрки нулей и пробелов соответственно - в результате данные раздуваются не в 4/3=1.33 раз, как в случае base64 (или uue), а в 5/4=1.25 раз или меньше, что как минимум на 6% компактнее. Можно немного развить ascii85 для кодирования произвольных бинарных данных, назвав новую систему кодирования скажем ascii85+ задействуя остальные неиспользованные символы: 'x' может кодировать четвёрку 0xFF (это может помочь при кодировании прошивок ПЗУ), 'w' - четвёрку 0x80 (это может помочь при кодировании 8-битных беззнаковых WAV-файлов), 'v' - пока может использоваться для детектирования ошибки, фигурные скобки { и } могут выделять закодированный бинарный блок в тексте (наличие явно заданного стартового символа упрощает парсинг, а наличие явно заданного терминатора поможет обрабатывать пограничные ситуации, когда концовка файла не влезает в 4 байта целиком), а ~ и | могут использоваться для каких-то особых случаев (см.ниже). Этот подход можно использовать для встраивания бинарных файлов в текст сообщений как вложений (аля ююки), указывая имя файла после втавки (чтобы клиент знал с чем этот файл надо есть и надо ли):
Code: Select all
Посмотрите на эту весёлую картинку:
{Abhdhj!$^390+-
 ...
 Bhdbdfjg}=funny.gif
Старые клиенты будут показывать такие сообщения как текст, а новые клиенты могут получать такие сообщения даже со старых узлов и показывать картинки как картинки или файлы как вложения (ряд иконок внизу сообщения), которые можно сохранить на диск на стороне клиента.
Этот же ascii85+ можно использовать для уменьшения размеров бандлов на 6% сделав новый вызов в API - например /u/n/msgid/msgid/msgid... (вместо /u/m/... который может остаться для старых клиентов) - и результат работы этого вызова может выглядеть примерно так:
Code: Select all
msgid:{!"#$%&'()*+,-...}
msgid:{0123456789...}
msgid:{ABcded...}
где в фигурных скобках будет ascii85+ сообщений (этот алгоритм не является url-safe, поэтому в других местах API где надо url-safe останется всё тот же base64url).
Идея, что msgid является хэшом сообщения, с моей точки зрения является в ii ключевой, поэтому редактировать сообщения, сохранённые узлом (а тем более переданные на другие узлы) ни в коем случае нельзя! Ведь это поменяет контент и хэш уже не будет совпадать! Если же контент константен, то всегда можно восстановить msgid по самому сообщению, если вдруг msgid оказался утерян. Кроме того на стороне клиента (либо другого узла после фетча) можно проверить целостность сообщения, посчитав его хэш и сверив с msgid - если оно не совпадает, то либо это старое сообщение (отредактированное на узле, где это можно было делать, или посчитанное в стародавние времена, когда хэши в ii считались иначе), либо подменённое или испорченное новое сообщение - можно просто подсветить такое сообщение особым образом на клиенте и читатель сам будет решать, что ему с таким сообщением делать.

Хэш msgid может быть не визуально рандомным как сейчас, а будет способным нести информацию о типе (или о версии) сообщения - например сервер принимая от клиента текстовое сообщения классического вида добавит в его список тэгов новый тэг trick/0 и посчитает хэш сообщения - елси хэш не начинается скажем с символа '0', то алгоритм инкрементирует значение в этом тэге (trick/1) и считает хэш ешё раз - если опять не стартует с '0', то инкрементируем ещё раз и т.д. пока хэш не станет начинаться с нуля (в среднем на подготовку "красивого" msgid должно уходить порядка 32 вычислений хэша - иногда меньше, иногда больше) - в этом случае все узлы точно будут знать, что все "новые" сообщения с msgid вида 0... являются новыми "обычными" сообщениями (чтобы отличить от старых сообщений с именами случайно начинающимися с 0 можно проверить наличие тэга trick в заголовке сообщения - если он есть, то это новый тип сообщения с возможными вложенными файлами). Если каждая точка системы точно знает, что это новое сообщение, то она также может проверить целостность сообщения пересчитав его хэш и сверив с msgid ( ведь новый стандарт должен будет явно запретить редактирование или подмену сообщения уже сохранённого узлом ; ). Старые узлы и клиенты будут передавать такие сообщения как самые обычные (если не запнутся на неизвестном тэге trick).

Тип сообщения 1... может обозначать закодированный бинарный файл, когда в теле сообщения нет текста, а сразу идёт блок ascii85+ {...}. При посылке такого сообщения отправляющий клиент может задать новое ключевое слово @crc32:0xFFFFFFFF для указания контрольной суммы, которая при сохранении сообщения будет вставлена узлом в строку тэгов в виде .../crc32/0xFFFFFFFF и которую принимающий клиент может проверить после восстановления файла. Размер такого сообщения по понятным причинам будет ограничен - может быть даже придётся уменьшить текущий лимит 87кб до 32кб, чтобы эта реализация была совместима с ограниченными размерами памяти недокомпьютеров, которые могли бы участвовать в работе сети - в этом случае размер самого большого бинарного файла, который можно таким способом отправить, будет составлять порядка 26кб. Старые узлы и клиенты будут показывать такие сообщения как обычные текстовые.
Тип сообщения 2... может обозначать составной объект, когда ранее отправленные сообщения типа 1... на самом деле являются кирпичиками, из которых строится большое сообщение. В теле такого сообщения могут перечисляться как блоки {}, так и ссылки на внешние сообщения типа 1:
Code: Select all
~1gjkwui4iuwqrezD56az
~1ui4iuwqrezD56azFejs
~{......}|это вставка блоба ascii85+ (комментарий после | до конца строки)
~1uwqrzFejsDSGFeekjkd|это ссылка на другой объект, который должен быть вставлен при сборке
{....}=666.bin|это объявление именованного блоба (без вставки)
~666.bin
~666.bin
~666.bin|это вставка копии именованного блоба (всего 3 копии подряд)
в примере выше показано как можно повторять несколько раз бинарный кусок, объявленный в том же сообщении (666.bin). Такой тип бинарного сообщения снимает любые ограничения на размер передаваемого объекта, который перед передачей может быть порублен на кусочки. При отправке такого сообщения также может быть использовано ключевое слово @crc32, которое как и в предыдущем случае будет вставлено узлом в строку тэгов при сохранении. Старые узлы и клиенты будут показывать такие сообщения как обычные текстовые (как в примере выше). В случае реализации сообщений 1 и 2 типов на уровне сети для передачи бинарных данных отпадёт необходимость в поддержке файлэх, которые выглядят несколько неестественно применительно к ii (например они не приспособлены для пересылки через последовательные каналы передачи данных, в то время как все остальные подсистемы IDEC представлены в текстовом виде и могут быть использованы через интерфейс терминала).
В будущем при отправке сообщения от поинта узлу к ключевым словам можно будет добавить ещё и подпись @sign:0xFF...FF по алгоритму скажем HMAC-RIPEMD-160-96 (с одним секретным ключом известным отправляющей и принимающей стороне), если достаточно удостовериться в валидности посланного от поинта на свой узел (узел должен знать секретный ключ поинта - точно также как сейчас он знает пароль) и далее при сохранении сообщения на узле (после проверки валидности) такую подпись можно опустить, либо (в будущем) по алгоритму Ed25519 (с публичным и секретным ключами), если требуется проверка достоверности сообщения в пределах всей сети на любом узле и любом клиенте (это более тяжёлая реализация, которая требует наличия двух алгоритмов SHA512 и Curve25519, а также способов передачи публичных ключей всех активных участников сети на все вовлечённые узлы) - в этом случае sign/0x... переедет в строку тэгов для проверки достоверности послания в любой точке сети (и также для проверки целостности данных вместо CRC32), а старые узлы и клиенты просто будут игнорировать этот тэг, как неизвестный.

Когда сеть разрастётся, возможно придётся отказаться от хранения всех сообщений на каждом узле (в идеале - когда все фетчат всех) - узлы могут быть разбиты на группы (с избыточностью) для хранения разных наборов объектов (скажем в зависимости от значений 2го и 3го символа в msgid). Существуют разнообразные алгоритмы распределённых хэшей, которые можно применить в данном случае для поиска объектов по хэшу (msgid) на сети ненадёжных узлов. В этом случае сеть можно будет использовать как распределённое хранилище подписанных объектов, которые можно будет задействовать при построении распределённых сайтов, мультиплеерных игр, криптовалют и т.д. Для старых узлов можно предусмотреть механизм, когда они подписываются на специальные скрытые эхи, в которые будут транслироваться копии объектов по группам - в этом случае эти узлы будут продолжать работать в старой парадигме IDEC, но в то же время они будут полезными в рамках новой распределённой сети объектов, раздавая сохранённые на них объекты при необходимости по запросу.

См. https://www.hugeping.ru/xDT61Ukip7E064VjCjt4

Shaos · Post by **Shaos** » 31 Aug 2023 07:38

Оказывается USENET до сих пор существует

https://www.theregister.com/2023/08/30/usenet_revival/

и есть сервер с бесплатной подпиской:

https://www.eternal-september.org/

там даже есть группы relcom

https://www.eternal-september.org/groups.php?hierarchy=relcom

и fido7

https://www.eternal-september.org/groups.php?hierarchy=fido7

из которых Top100 по активности выглядит так:

Top100

Shaos · Post by **Shaos** » 04 Sep 2023 08:18

Shaos wrote:... и есть сервер с бесплатной подпиской:

https://www.eternal-september.org/

там даже есть группы relcom

https://www.eternal-september.org/groups.php?hierarchy=relcom

и fido7

Подписался на кое-что через этот самый "вечный сентябрь"

https://groups.google.com/g/relcom.comp.speccy/c/cIs7tNWefdI

Shaos · Post by **Shaos** » 04 Sep 2023 08:49

Shaos wrote:В процессе расследования выяснилось, что от меня таки забираются сообщения и рассылаются по другим узлам - т.е. я могу со своего узла писать в глобальные эхи (и мои пойнты тоже могут).

Также я добавил ещё один узел для фетча https://dynamic.lessmore.pw - теперь новые сообщения извне приходят ко мне в пределах 20 минут (о ней знают несколько узлов, но не все).

Кроме того я добавил эху idec.test, которая используется для тестирования клиентов и веб-интерфейсов узлов.

P.S. Надо научить веб-интерфейс сортировать сообщения в хронологическом порядке, а то щас они показывается в том порядке, в котором забрались извне.

P.P.S. Основной оживший узел это http://idec.spline-online.tk/ - через него мои сообщения и уходят в сеть...

Возвращаясь к сети IDEC - основной сервер опять поменял имя - теперь это http://idec.spline-online.ru/

Shaos · Post by **Shaos** » 22 Sep 2024 07:51

Shaos wrote:Поднял собственную ноду IDEC:

http://shaos.net:8085

С момента создания в декабре 2021 года эта нода IDEC крутилась на повермаке G4 с дебияном - я сегодня было полез снять оттуда архивы и обнаружил по логам, что один из узлов, с которых я забирал эхи, dynamic.lessmore.pw давно помер (да и idec.spline-online.ru тоже как-то заприлёг) - пока открывал и копировал логи (как оказалось частично коррапнутые) себе на основную линух-машину, файловая система повермака перешла в read-only - ребутнул комп, а он хлоп и отказался подниматься

: PowerMacG4-glitch.jpg (32.16 KiB) Viewed 1940 times

P.S. Перед ребутом uptime составлял 278 дней (по-видимому с момента последнего вырубания света).

P.P.S. Видимо придётся перетаскивать ноду на PC с дебияном...

P.P.P.S. Перетащил на ту же линух-машину, на которой крутится sprinternet.io - так что теперь станет возможен непосредственный обмен сообщениями между этими двумя системами...

aviator · Post by **aviator** » 22 Sep 2024 20:14

Вообще сейчас сложно с подобными сетями обмена сообщениями. Кто-нибудь напишет что-нибудь крамольное, а привлекут администраторов узлов. Именно это всегда и останавливало от поддержки публичной BBS, узла FTN.

Shaos · Post by **Shaos** » 23 Sep 2024 04:28

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

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

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

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

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

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

Re: Компьютерная сеть IDEC

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

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

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

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

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

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

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

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

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

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

Re: Компьютерная сеть IDEC

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

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