nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 26 Apr 2024 10:37



Reply to topic  [ 12 posts ] 
Компьютерная сеть IDEC и возможные пути её расширения 
Author Message
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22589
Location: Silicon Valley
Reply with quote
https://ii-net.tk/idec-doc/?p=main

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

  • Чтение интересных RSS-лент и спокойное общение в одном приложении
  • Отсутствие лайков, фоточек, видосиков, свистелок и прочего непотребства: только текст
  • Грамотное, дружелюбное и неравнодушное население
  • Поддержка всех современных ОС
  • Простая интеграция своих скриптов, расширений, ботов и так далее
  • Полноценная работа в Offline
  • Распределённость и отказоустойчивость (сообщения разлетаются по всем серверам; последний сервер жив - сеть жива)
  • Минимальное потребление ресурсов на клиенте и техническая простота

Взгляд со стороны:

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


IDEC создан на основе ii

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

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


Протокол IDEC (ii-like Data Exchange Convention) форкнулся от ii и является его идейным продолжателем. Сообщество, работающее на основе ii-like Data Exchange Convention - то же самое, что и у ii. У нас одна БД сообщений и те же основные люди.


Описание 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.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
Там можно позадавать вопросы текущим мантейнерам стандарта :dj:

P.P.S. Актуальная статистика сети в графическом виде: https://grafana.lessmore.pw/d/vPKzlQKWk/idec?orgId=1

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

_________________
:dj: https://mastodon.social/@Shaos


14 Dec 2021 23:51
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22589
Location: Silicon Valley
Reply with quote
Интересный способ идентификации сообщений выбран в 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:
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 - на всём этом можно было бы городить распределённое хранилище файлов и т.д.

_________________
:dj: https://mastodon.social/@Shaos


15 Dec 2021 23:27
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22589
Location: Silicon Valley
Reply with quote
Поднял собственную ноду IDE:

http://shaos.net:8085


Attachments:
Screenshot from 2021-12-19 05-28-53.png
Screenshot from 2021-12-19 05-28-53.png [ 91.78 KiB | Viewed 6119 times ]

_________________
:dj: https://mastodon.social/@Shaos
19 Dec 2021 06:35
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22589
Location: Silicon Valley
Reply with quote
Сделал форвардинг с http://idec.shaos.net

_________________
:dj: https://mastodon.social/@Shaos


20 Dec 2021 00:03
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22589
Location: Silicon Valley
Reply with quote
Наткнулся на статистику сети в графическом виде:

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

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


Attachments:
idec8years.jpg
idec8years.jpg [ 19.16 KiB | Viewed 6054 times ]

_________________
:dj: https://mastodon.social/@Shaos
22 Dec 2021 04:46
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22589
Location: Silicon Valley
Reply with quote
Форкнул версию сервера ii-php себе: https://gitlab.com/shaos/iii-php

_________________
:dj: https://mastodon.social/@Shaos


22 Feb 2022 21:15
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22589
Location: Silicon Valley
Reply with quote
Чото за полгода большинство узлов IDEC просрочили свои домены либо получили пустые страницы или редиректят на левые сайты :(

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

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

P.S. Есть один новый узел, не вошедший в стандартную статистику:
https://tgistation.ru/
На нём правда эх совсем мало (2 из которых локальные):
Code:
    tgi.news
    tgi.station
    idec.talks
    pipe.2032
    zx.spectrum
и они похоже с июня не обновлялись...

_________________
:dj: https://mastodon.social/@Shaos


18 Sep 2022 09:34
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22589
Location: Silicon Valley
Reply with quote
В процессе расследования выяснилось, что от меня таки забираются сообщения и рассылаются по другим узлам - т.е. я могу со своего узла писать в глобальные эхи (и мои пойнты тоже могут).

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

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

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

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

_________________
:dj: https://mastodon.social/@Shaos


18 Sep 2022 15:16
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22589
Location: Silicon Valley
Reply with quote
В декабре 2021 в эхе idec.talks я предложил следующие пути развития IDEC:
Shaos wrote:
Я познакомился в ii/IDEC только в августе этого года, стал изучать как оно всё устроено и наконец на днях, воспользовавшись открытой реализацией ii-php, поднял свой узел - теперь у меня есть несколько мыслей по возможному будущему этой системы (либо системы, которая может отпочковаться от этой системы, но будет оставаться совместимой со старым IDEC API):

  1. Кроме 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:
    Посмотрите на эту весёлую картинку:
    {Abhdhj!$^390+-
     ...
     Bhdbdfjg}=funny.gif
    Старые клиенты будут показывать такие сообщения как текст, а новые клиенты могут получать такие сообщения даже со старых узлов и показывать картинки как картинки или файлы как вложения (ряд иконок внизу сообщения), которые можно сохранить на диск на стороне клиента.
  2. Этот же ascii85+ можно использовать для уменьшения размеров бандлов на 6% сделав новый вызов в API - например /u/n/msgid/msgid/msgid... (вместо /u/m/... который может остаться для старых клиентов) - и результат работы этого вызова может выглядеть примерно так:
    Code:
    msgid:{!"#$%&'()*+,-...}
    msgid:{0123456789...}
    msgid:{ABcded...}
    где в фигурных скобках будет ascii85+ сообщений (этот алгоритм не является url-safe, поэтому в других местах API где надо url-safe останется всё тот же base64url).
  3. Идея, что msgid является хэшом сообщения, с моей точки зрения является в ii ключевой, поэтому редактировать сообщения, сохранённые узлом (а тем более переданные на другие узлы) ни в коем случае нельзя! Ведь это поменяет контент и хэш уже не будет совпадать! Если же контент константен, то всегда можно восстановить msgid по самому сообщению, если вдруг msgid оказался утерян. Кроме того на стороне клиента (либо другого узла после фетча) можно проверить целостность сообщения, посчитав его хэш и сверив с msgid - если оно не совпадает, то либо это старое сообщение (отредактированное на узле, где это можно было делать, или посчитанное в стародавние времена, когда хэши в ii считались иначе), либо подменённое или испорченное новое сообщение - можно просто подсветить такое сообщение особым образом на клиенте и читатель сам будет решать, что ему с таким сообщением делать.
  4. Хэш msgid может быть не визуально рандомным как сейчас, а будет способным нести информацию о типе (или о версии) сообщения - например сервер принимая от клиента текстовое сообщения классического вида добавит в его список тэгов новый тэг trick/0 и посчитает хэш сообщения - елси хэш не начинается скажем с символа '0', то алгоритм инкрементирует значение в этом тэге (trick/1) и считает хэш ешё раз - если опять не стартует с '0', то инкрементируем ещё раз и т.д. пока хэш не станет начинаться с нуля (в среднем на подготовку "красивого" msgid должно уходить порядка 32 вычислений хэша - иногда меньше, иногда больше) - в этом случае все узлы точно будут знать, что все "новые" сообщения с msgid вида 0... являются новыми "обычными" сообщениями (чтобы отличить от старых сообщений с именами случайно начинающимися с 0 можно проверить наличие тэга trick в заголовке сообщения - если он есть, то это новый тип сообщения с возможными вложенными файлами). Если каждая точка системы точно знает, что это новое сообщение, то она также может проверить целостность сообщения пересчитав его хэш и сверив с msgid ( ведь новый стандарт должен будет явно запретить редактирование или подмену сообщения уже сохранённого узлом ; ). Старые узлы и клиенты будут передавать такие сообщения как самые обычные (если не запнутся на неизвестном тэге trick).
  5. Тип сообщения 1... может обозначать закодированный бинарный файл, когда в теле сообщения нет текста, а сразу идёт блок ascii85+ {...}. При посылке такого сообщения отправляющий клиент может задать новое ключевое слово @crc32:0xFFFFFFFF для указания контрольной суммы, которая при сохранении сообщения будет вставлена узлом в строку тэгов в виде .../crc32/0xFFFFFFFF и которую принимающий клиент может проверить после восстановления файла. Размер такого сообщения по понятным причинам будет ограничен - может быть даже придётся уменьшить текущий лимит 87кб до 32кб, чтобы эта реализация была совместима с ограниченными размерами памяти недокомпьютеров, которые могли бы участвовать в работе сети - в этом случае размер самого большого бинарного файла, который можно таким способом отправить, будет составлять порядка 26кб. Старые узлы и клиенты будут показывать такие сообщения как обычные текстовые.
  6. Тип сообщения 2... может обозначать составной объект, когда ранее отправленные сообщения типа 1... на самом деле являются кирпичиками, из которых строится большое сообщение. В теле такого сообщения могут перечисляться как блоки {}, так и ссылки на внешние сообщения типа 1:
    Code:
    ~1gjkwui4iuwqrezD56az
    ~1ui4iuwqrezD56azFejs
    ~{......}|это вставка блоба ascii85+ (комментарий после | до конца строки)
    ~1uwqrzFejsDSGFeekjkd|это ссылка на другой объект, который должен быть вставлен при сборке
    {....}=666.bin|это объявление именованного блоба (без вставки)
    ~666.bin
    ~666.bin
    ~666.bin|это вставка копии именованного блоба (всего 3 копии подряд)
    в примере выше показано как можно повторять несколько раз бинарный кусок, объявленный в том же сообщении (666.bin). Такой тип бинарного сообщения снимает любые ограничения на размер передаваемого объекта, который перед передачей может быть порублен на кусочки. При отправке такого сообщения также может быть использовано ключевое слово @crc32, которое как и в предыдущем случае будет вставлено узлом в строку тэгов при сохранении. Старые узлы и клиенты будут показывать такие сообщения как обычные текстовые (как в примере выше). В случае реализации сообщений 1 и 2 типов на уровне сети для передачи бинарных данных отпадёт необходимость в поддержке файлэх, которые выглядят несколько неестественно применительно к ii (например они не приспособлены для пересылки через последовательные каналы передачи данных, в то время как все остальные подсистемы IDEC представлены в текстовом виде и могут быть использованы через интерфейс терминала).
  7. В будущем при отправке сообщения от поинта узлу к ключевым словам можно будет добавить ещё и подпись @sign:0xFF...FF по алгоритму скажем HMAC-RIPEMD-160-96 (с одним секретным ключом известным отправляющей и принимающей стороне), если достаточно удостовериться в валидности посланного от поинта на свой узел (узел должен знать секретный ключ поинта - точно также как сейчас он знает пароль) и далее при сохранении сообщения на узле (после проверки валидности) такую подпись можно опустить, либо (в будущем) по алгоритму Ed25519 (с публичным и секретным ключами), если требуется проверка достоверности сообщения в пределах всей сети на любом узле и любом клиенте (это более тяжёлая реализация, которая требует наличия двух алгоритмов SHA512 и Curve25519, а также способов передачи публичных ключей всех активных участников сети на все вовлечённые узлы) - в этом случае sign/0x... переедет в строку тэгов для проверки достоверности послания в любой точке сети (и также для проверки целостности данных вместо CRC32), а старые узлы и клиенты просто будут игнорировать этот тэг, как неизвестный.
  8. Когда сеть разрастётся, возможно придётся отказаться от хранения всех сообщений на каждом узле (в идеале - когда все фетчат всех) - узлы могут быть разбиты на группы (с избыточностью) для хранения разных наборов объектов (скажем в зависимости от значений 2го и 3го символа в msgid). Существуют разнообразные алгоритмы распределённых хэшей, которые можно применить в данном случае для поиска объектов по хэшу (msgid) на сети ненадёжных узлов. В этом случае сеть можно будет использовать как распределённое хранилище подписанных объектов, которые можно будет задействовать при построении распределённых сайтов, мультиплеерных игр, криптовалют и т.д. Для старых узлов можно предусмотреть механизм, когда они подписываются на специальные скрытые эхи, в которые будут транслироваться копии объектов по группам - в этом случае эти узлы будут продолжать работать в старой парадигме IDEC, но в то же время они будут полезными в рамках новой распределённой сети объектов, раздавая сохранённые на них объекты при необходимости по запросу.
См. https://www.hugeping.ru/xDT61Ukip7E064VjCjt4

_________________
:dj: https://mastodon.social/@Shaos


28 Apr 2023 21:09
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22589
Location: Silicon Valley
Reply with quote
Оказывается USENET до сих пор существует :o

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

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

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

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

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

и fido7 :roll:

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

из которых 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

_________________
:dj: https://mastodon.social/@Shaos


31 Aug 2023 00:38
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22589
Location: Silicon Valley
Reply with quote
Подписался на кое-что через этот самый "вечный сентябрь" :)

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

_________________
:dj: https://mastodon.social/@Shaos


04 Sep 2023 01:18
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22589
Location: Silicon Valley
Reply with quote
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/

_________________
:dj: https://mastodon.social/@Shaos


04 Sep 2023 01:49
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 12 posts ] 

Who is online

Users browsing this forum: No registered users and 26 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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.