|
nedoPC.orgCommunity for electronics hobbyists, established in 2002 |
|
Компьютерная сеть IDEC и возможные пути её развития
Author |
Message |
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23394 Location: Silicon Valley
|
https://web.archive.org/web/20211130125940/https://ii-net.tk/idec-doc/?p=mainIDEC (ii-like Data Exchange Convention) создан на основе протокола ii: https://web.archive.org/web/20210419081052/https://ii-net.tk/idec-doc/?p=iibondsПлюс ещё вот это: - https://www.linux.org.ru/forum/general/10247460- https://www.linux.org.ru/forum/talks/10258332- https://www.linux.org.ru/forum/talks/10267735Описание ii от автора (взято из вебархива https://web.archive.org/web/20140909193610/http://ii.51t.ru/): | | | | Quote: ii: говорил, говорит и будет говоритьii - это система для онлайн и оффлайн обмена сообщениями, вобравшая в себя лучшие идеи из форумов, твиттера, FIDO и git. Она имеет примитивное внутреннее устройство, которое позволяет вести дискуссии даже из консоли и всегда иметь на локальной машине копии сообщений. Реализация сервера написана на python 2, bottle.py (проверена работа в openbsd,linux,haiku). Любой ii-сервер может обмениваться трафиком со всеми подобными серверами или с конечными пользователями (через клиенты). Короткий faq- Это фидо? И да, и нет. Это сверхпростое фидо без нетмейла и аутбаунда, если кому-то это о чём-то говорит. - Это децентрализованная сеть? И да, и нет. Скорее, да. - Это кому-то интересно? Это кому-то практично. - И что тут делать? Общаться и собирать вместе тематические сообщества вместо ужасных соцсетей и сервисов. | | | | |
В настоящее время существует как минимум 7 узлов сети IDEC (последний в списке это архив старых ii-сообщений): http://idec.spline-online.mlhttps://club.hugeping.ruhttps://dynamic.lessmore.pwhttp://gears.headake.win/idec/ui2/https://idec.textgamesinfo.ruhttps://ii-net.tk/ii/ii-web.phphttps://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
|
14 Dec 2021 23:51 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23394 Location: Silicon Valley
|
Интересный способ идентификации сообщений выбран в ii (перекочевавший затем в IDEC и использующийся в двух самых старых серверах реализующих этот протокол - ii-php написанном на PHP и iing написанном на Python) - сервер формирует текст сообщения для сохранения добавляя к нему заголовки, а именно: - tags - теги (используются только для `repto` и для идентификатора `ii/ok`)
- echoarea - основная эхоконференция, в которую помещается сообщение
- date - число секунд от эпохи unix, в utc
- msgfrom - отправитель
- addr - адрес отправителя (практического смысла не имеет, служит для того, чтобы узнавать, с какой станции пришло сообщение)
- msgto - пользователь, которому предназначено сообщение (либо All)
- subj - тема сообщения
- пустая строка
- и далее - текст сообщения
Пример из документации: (в данном случае наличие ключевого слова 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 - на всём этом можно было бы городить распределённое хранилище файлов и т.д.
|
15 Dec 2021 23:27 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23394 Location: Silicon Valley
|
Поднял собственную ноду IDEC: http://shaos.net:8085
|
19 Dec 2021 06:35 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23394 Location: Silicon Valley
|
|
20 Dec 2021 00:03 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23394 Location: Silicon Valley
|
Наткнулся на статистику сети в графическом виде: https://grafana.lessmore.pw/d/vPKzlQKWk/idec?orgId=1Вот оттуда график активности за всё время её существования:
|
22 Dec 2021 04:46 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23394 Location: Silicon Valley
|
Форкнул версию сервера ii-php себе: https://gitlab.com/shaos/iii-php
|
22 Feb 2022 21:15 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23394 Location: Silicon Valley
|
Чото за полгода большинство узлов IDEC просрочили свои домены либо получили пустые страницы или редиректят на левые сайты Рабочих узлов по сути осталось только два: https://dynamic.lessmore.pwhttps://club.hugeping.ruну и мой узел (третий): https://shaos.net:8085т.к. я забирал и отправлял через spline-online.ml то мой узел получился отрезан от сети - на нём не появляются новые сообщения и с него ничего никуда не отправляется Надо налаживать контакты с одним из оставшихся в живых узлов... P.S. Есть один новый узел, не вошедший в стандартную статистику: https://tgistation.ru/На нём правда эх совсем мало (2 из которых локальные): и они похоже с июня не обновлялись...
|
18 Sep 2022 09:34 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23394 Location: Silicon Valley
|
В процессе расследования выяснилось, что от меня таки забираются сообщения и рассылаются по другим узлам - т.е. я могу со своего узла писать в глобальные эхи (и мои пойнты тоже могут). Также я добавил ещё один узел для фетча https://dynamic.lessmore.pw - теперь новые сообщения извне приходят ко мне в пределах 20 минут (о ней знают несколько узлов, но не все). Кроме того я добавил эху idec.test, которая используется для тестирования клиентов и веб-интерфейсов узлов. P.S. Надо научить веб-интерфейс сортировать сообщения в хронологическом порядке, а то щас они показывается в том порядке, в котором забрались извне. P.P.S. Основной оживший узел это http://idec.spline-online.tk/ - через него мои сообщения и уходят в сеть...
|
18 Sep 2022 15:16 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23394 Location: Silicon Valley
|
В декабре 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 байта целиком), а ~ и | могут использоваться для каких-то особых случаев (см.ниже). Этот подход можно использовать для встраивания бинарных файлов в текст сообщений как вложений (аля ююки), указывая имя файла после втавки (чтобы клиент знал с чем этот файл надо есть и надо ли):
Старые клиенты будут показывать такие сообщения как текст, а новые клиенты могут получать такие сообщения даже со старых узлов и показывать картинки как картинки или файлы как вложения (ряд иконок внизу сообщения), которые можно сохранить на диск на стороне клиента.
- Этот же ascii85+ можно использовать для уменьшения размеров бандлов на 6% сделав новый вызов в API - например /u/n/msgid/msgid/msgid... (вместо /u/m/... который может остаться для старых клиентов) - и результат работы этого вызова может выглядеть примерно так:
где в фигурных скобках будет 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:
в примере выше показано как можно повторять несколько раз бинарный кусок, объявленный в том же сообщении (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
|
28 Apr 2023 21:09 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23394 Location: Silicon Valley
|
Оказывается 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 fido7.su.hardw.other 20558 fido7.ru.military 15772 fido7.su.pol.news 14172 fido7.ru.fidonet.today 10932 fido7.su.formula1.info 5738 fido7.su.os2.faq 3122 fido7.obec.f3boh 2861 fido7.ru.binkd 2546 fido7.su.general 2508 fido7.su.medic 2441 fido7.su.cars 2165 fido7.ru.home 2034 fido7.xsu.useless.faq 1262 fido7.crimea.talk 1218 fido7.ru.windows.xp 1195 fido7.su.books 1179 fido7.su.hardw.schemes 989 fido7.f400.link 817 fido7.su.tormoz 806 fido7.ru.space 793 fido7.ru.husky 742 fido7.ru.film 643 fido7.ru.sat.news 618 fido7.ru.railways 570 fido7.ru.sex 528 fido7.ru.aviation 526 fido7.ru.unix.bsd 512 fido7.su.comp.old 484 fido7.su.chainik 482 fido7.ru.fidonet.digest 404 fido7.su.hamradio 383 fido7.ru.linux.chainik 365 fido7.fidonet.history 361 fido7.ru.ftn.develop 347 fido7.su.music 325 fido7.ru.bee.music 317 fido7.ru.mac 306 fido7.ru.sex.condoms 278 fido7.su.pol.history 278 fido7.ru.coffee.club 271 fido7.su.pol.theory 265 fido7.ru.golded 263 fido7.ru.military.navy 255 fido7.ru.space.news 252 fido7.ru.anti-ment 234 fido7.pvt.girls 222 fido7.su.kaschenko.local 200 fido7.su.kitchen 185 fido7.ru.moderator 178 fido7.n5020.crisis 177 fido7.su.ip.point 177 fido7.obec.pactet 173 fido7.ru.sport.other 173 fido7.su.pilot 172 fido7.ru.fips 164 fido7.ru.dogs 160 fido7.mo.bike 153 fido7.mo.mephi 153 fido7.n5020.point 153 fido7.pvt.dev.unique 153 fido7.ru.amiga 153 fido7.ru.anime 153 fido7.ru.biology 153 fido7.ru.cinick 153 fido7.ru.computer 153 fido7.ru.computerra 153 fido7.ru.hokku 153 fido7.ru.internet 153 fido7.ru.internet.icq 153 fido7.ru.internet.p2p 153 fido7.ru.linux 153 fido7.ru.ocr 153 fido7.ru.podmoskovie.talks 153 fido7.ru.pravoslavie.talk 153 fido7.ru.prikol 153 fido7.ru.radio.samopay 153 fido7.ru.russophobia 153 fido7.ru.science 153 fido7.ru.security 153 fido7.ru.sport.football.news 153 fido7.ru.suicide 153 fido7.ru.tv.program.announce 153 fido7.ru.unix.prog 153 fido7.ru.voip 153 fido7.spb.cars 153 fido7.spb.job.offer 153 fido7.su.astronomy 153 fido7.su.cbcs 153 fido7.su.hardw.hdd.repair 153 fido7.su.render 153 fido7.su.science 153 fido7.su.talks 153 fido7.ru.fido.internet 151 fido7.mo.restaurant 149 fido7.ru.rockwell 146 fido7.ru.suicide.poetry 136 fido7.mo.talk 134 fido7.ru.pol.opposition 134 fido7.su.c-cpp 134 fido7.su.tolkien 128 fido7.su.formula1 117 fido7.ru.unix.solaris 114 fido7.su.os2 113 fido7.mo.golyanovo 111 fido7.ru.books.computing 101 fido7.survival.guide 100 fido7.mo.sails 99 fido7.ru.cmm 98 fido7.ru.qico 98 fido7.cb.radio 97
|
31 Aug 2023 00:38 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23394 Location: Silicon Valley
|
|
04 Sep 2023 01:18 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23394 Location: Silicon Valley
|
| | | | 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/
|
04 Sep 2023 01:49 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23394 Location: Silicon Valley
|
С момента создания в декабре 2021 года эта нода IDEC крутилась на повермаке G4 с дебияном - я сегодня было полез снять оттуда архивы и обнаружил по логам, что один из узлов, с которых я забирал эхи, dynamic.lessmore.pw давно помер (да и idec.spline-online.ru тоже как-то заприлёг) - пока открывал и копировал логи (как оказалось частично коррапнутые) себе на основную линух-машину, файловая система повермака перешла в read-only - ребутнул комп, а он хлоп и отказался подниматься P.S. Перед ребутом uptime составлял 278 дней (по-видимому с момента последнего вырубания света). P.P.S. Видимо придётся перетаскивать ноду на PC с дебияном...P.P.P.S. Перетащил на ту же линух-машину, на которой крутится sprinternet.io - так что теперь станет возможен непосредственный обмен сообщениями между этими двумя системами...
|
22 Sep 2024 00:51 |
|
|
aviator
Maniac
Joined: 10 Dec 2008 08:39 Posts: 208 Location: Стокгольм, Швеция
|
Вообще сейчас сложно с подобными сетями обмена сообщениями. Кто-нибудь напишет что-нибудь крамольное, а привлекут администраторов узлов. Именно это всегда и останавливало от поддержки публичной BBS, узла FTN.
_________________ С уважением, Сергей.
|
22 Sep 2024 13:14 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23394 Location: Silicon Valley
|
Перенёс тему в подфорум "Проект nedoPC" P.S. Интересным побочным эффектом перетаскивания ноды IDEC на сервер спринтернета стало то, что теперь к ней стало можно обращаться и по https:// https://sprinternet.io/iii-web.phpP.P.S. Блин, гугол начал активно индексировать там контент через https://
|
22 Sep 2024 21:28 |
|
|
Who is online |
Users browsing this forum: No registered users and 3 guests |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|