> Добавил в блеклист.

Да - теперь в логах чисто - СПС!

пишу тестовое сообщение

Всем привет

Я познакомился в 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 байта целиком), а ~ и | могут использоваться для каких-то особых случаев (см.ниже). Этот подход можно использовать для встраивания бинарных файлов в текст сообщений как вложений (аля ююки), указывая имя файла после втавки (чтобы клиент знал с чем этот файл надо есть и надо ли):

Посмотрите на эту весёлую картинку:
{Abhdhj!$^390+-
 ...
 Bhdbdfjg}=funny.gif

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

2) Этот же ascii85+ можно использовать для уменьшения размеров бандлов на 6% сделав новый вызов в API - например /u/n/msgid/msgid/msgid... (вместо /u/m/... который может остаться для старых клиентов) - и результат работы этого вызова может выглядеть примерно так:

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:

~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, но в то же время они будут полезными в рамках новой распределённой сети объектов, раздавая сохранённые на них объекты при необходимости по запросу.

Shaos

shaos> Всем привет

shaos> Я познакомился в ii/IDEC только в августе этого года, стал изучать как оно всё устроено и наконец на днях, воспользовавшись открытой реализацией ii-php, поднял свой узел - теперь у меня есть несколько мыслей по возможному будущему этой системы (либо системы, которая может отпочковаться от этой системы, но будет оставаться совместимой со старым IDEC API):

Предложения весьма занимательные, но с моей точки зрения теряется главное примущество idec - дубовость.

Есть ли смысл в осмысленных msgid, если мы всегда практически бесплатно можем прочитать теги?

Когда доползу до компа, постараюсь ответить более развёрнуто.

Касательно рассуждений о хэше для сообщений, пришла мысль, что IDEC это практически контентно-адресуемая сеть и можно как-то прикрутить её к IPFS (или наоборот) для хранения сообщений.

> Хэш msgid может быть не визуально рандомным как сейчас, а будет способным нести информацию о типе (или о версии) сообщения

Мне кажется такую функциональность проще реализовать в виде варианта запроса индекса, который будет возвращать (кроме идентификатора и закодированного сообщения) строку с тегами, либо отдельным суффиксом у ID. Правда, хранение метаданных в ссылке напоминает костыль в gopher, когда префикс в URL определяет то, как клиент будет отображать полученное содержимое.

> Предложения весьма занимательные, но с моей точки зрения теряется главное примущество idec - дубовость.

Ну с годами idec уже не такой дубовый стал и совсем не маленький, как у вас тут принято считать ;)

> Есть ли смысл в осмысленных msgid, если мы всегда практически бесплатно можем прочитать теги?

Не бесплатно. Чтобы посмотреть тэги, надо найти и прочитать сообщение. Если оно одно, то может и не долго, а если в списке их тысячи?. А так мы по списку можем видеть что есть что (ну разве что с вероятностью 1/64 это может быть "false positive", пришедший от старых нод или взятый из старых архивов, у которого случайно msgid начинается с 0).

> Касательно рассуждений о хэше для сообщений, пришла мысль, что IDEC
> это практически контентно-адресуемая сеть...

Ну по сути так оно и есть :)

> ...и можно как-то прикрутить её к IPFS (или наоборот) для хранения сообщений

А зачем прикручивать, если IDEC по сути вполне годится на роль "downsized IPFS"? ;)
Самая первая версия IPFS v0.1 появилась в феврале 2015, а самая первая версия ii v0.1 - в марте 2014. Получается IPFS это "upsized ii" :)
А так внутри IPFS есть "Distrubuted Hash Map", который есть последний пункт моих мыслей применительно к IDEC :)
И как над IPFS появилась криптовалюта Filecoin, над IDEC может в перспективе появится IDECoin и всё забурлит и запенится ;)
Шутка...

>> Хэш msgid может быть не визуально рандомным как сейчас, а будет способным нести информацию о типе (или о версии) сообщения
> Мне кажется такую функциональность проще реализовать в виде варианта запроса
> индекса, который будет возвращать (кроме идентификатора и закодированного
> сообщения) строку с тегами, либо отдельным суффиксом у ID. Правда, хранение
> метаданных в ссылке напоминает костыль в gopher, когда префикс в URL определяет
> то, как клиент будет отображать полученное содержимое.

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

Несколько комментариев к моему изначальному сообщению.

- Чтобы исключить кривотолки и неправильные реализации, надо явно прописать алгоритм создания хэша, который реализован в ii-php и iing (и скорее всего в старом ii, судя по статистике использования символов в хэшах архивных сообщений), чтобы недвусмысленно было написано, что 2 небуквоциферных символа в base64 надо заменять на A (большую) и z (маленькую), а то сейчас в документации написано "for example A and Z" и новые реализации пытаются следовать документации, получая несовместимые решения (ii-go).

- При поддержке вложений в новоявленном формате ascii85+ чтобы отличить их скажем от исходника на языке Си или JSON-а в начале сообщения можно добавить ключевое слово @attach за которым будет идти число включений и сервер будет убирать это в строку тэгов сохранённого сообщения например .../attach/3 будет означать, что по ходу сообщения должно встретиться 3 вложения в формате ascii85+ (правда это означает, что в этом же сообщении не может встретится кусочек программы на C/C++/Java или JSON, хотя можно добавить правило парсинга, что между ==== и ==== искать вложения ненадо)...

>> Предложения весьма занимательные, но с моей точки зрения теряется главное примущество idec - дубовость.
shaos> Ну с годами idec уже не такой дубовый стал и совсем не маленький, как у вас тут принято считать ;)

Реализация всё ещё пишется за несколько часов :) Да и не повод дальше усложнять. Давай пойдём моим любимым путём: какие проблемы ты решаешь? :)

>> Есть ли смысл в осмысленных msgid, если мы всегда практически бесплатно можем прочитать теги?
shaos> Не бесплатно. Чтобы посмотреть тэги, надо найти и прочитать сообщение. Если оно одно, то может и не долго, а если в списке их тысячи?. А так мы по списку можем видеть что есть что (ну разве что с вероятностью 1/64 это может быть "false positive", пришедший от старых нод или взятый из старых архивов, у которого случайно msgid начинается с 0).

С моей точки зрения этот false positive с такой высокой вероятностью ломает всю затею. А найти и прочитать сообщение в общем случае это O(1). Другое дело, что в зависимости от конкретной платформы и конкретной реализации в абсолютных величинах это может быть долго. Я догадываюсь куда именно ты клонишь.

shaos> Несколько комментариев к моему изначальному сообщению.
shaos> - Чтобы исключить кривотолки и неправильные реализации, надо явно прописать алгоритм создания хэша, который реализован в ii-php и iing (и скорее всего в старом ii, судя по статистике использования символов в хэшах архивных сообщений), чтобы недвусмысленно было написано, что 2 небуквоциферных символа в base64 надо заменять на A (большую) и z (маленькую), а то сейчас в документации написано "for example A and Z" и новые реализации пытаются следовать документации, получая несовместимые решения (ii-go).

ii-go это анархическая реализация. Взять хоть редактирование сообщений :)

shaos> - При поддержке вложений в новоявленном формате ascii85+ чтобы отличить их скажем от исходника на языке Си или JSON-а в начале сообщения можно добавить ключевое слово @attach за которым будет идти число включений и сервер будет убирать это в строку тэгов сохранённого сообщения например .../attach/3 будет означать, что по ходу сообщения должно встретиться 3 вложения в формате ascii85+ (правда это означает, что в этом же сообщении не может встретится кусочек программы на C/C++/Java или JSON, хотя можно добавить правило парсинга, что между ==== и ==== искать вложения ненадо)...

Есть ли смысл в таких аттачах? Тело сообщения не должно превышать 64КБ. Может проще аттачи распространять по отдельной схеме, и хэши на аттачи кидать в теги собщения? :)

> Реализация всё ещё пишется за несколько часов :)

Это далеко не так ;)

> Да и не повод дальше усложнять.

Это небольшие инкрементальные улучшения, которые могут вывести IDEC на орбиту современных технологий ;)

> Давай пойдём моим любимым путём: какие проблемы ты решаешь? :)

Ну для начала - добавляет бинарных данных в рассылки.

> С моей точки зрения этот false positive с такой высокой вероятностью ломает всю затею.

Ну почему? Есть разница 100% сообщений надо вычитать, чтобы отфильтровать из них бинарные объекты или 1.56%? ;)

> А найти и прочитать сообщение в общем случае это O(1).

Скорее O(n)...

> Есть ли смысл в таких аттачах? Тело сообщения не должно превышать 64КБ.

Есть смысл, если надо заслать что-то маленькое вместе с сообщением (бинарь программки например, или заархивированный исходник).

> Может проще аттачи распространять по отдельной схеме, и хэши на аттачи кидать в теги собщения? :)

и это тоже можно сделать ;)

ну или по классике - в теле письма писать URL на ii-объект:

1KpcmGrc9pUtZQ6Puv1z

По поводу общих поинтов - PGP/GPG тяжеловат потому как многообразен - надо что-то одно широко известное выбрать и поддержать, но только цифровую подпись - без шифрования (которое в IDEC по-моему противопоказано), например можно взять отданный в общенародное достояние алгоритм Ed25519, существующий уже 10 лет и не подпадающий ни под какие патенты - в нём есть 32-байтовый публичный ключ и 64-байтовый секретный ключ (половина из которого это копия публичного ключа). Публичные ключи распространяются по всем узлам и клиентам (например посредством специальной эхо-конференции от имени пользователя как поинта своего узла) и идентифицируют глобальных пользователей (которые всё также могут оставаться поинтами на своих узлах). К сообщению подписанному цифровой подписью Ed25519 цепляется 64-байтовя signature (в строке тэгов после тэга signature/ например как 128-символьная шестнадцатиричная строка либо как 103-символьная строка в кодировке BASE32 либо как 86-символьная строка в кодировке BASE64URL, либо как 80-символьная строка в кодировке ASCII85 где символ / подменён скажем на | - хотя наверное надо таки использовать BASE64URL как родной способ кодирования бинарных данных в IDEC). Чтобы проверить валидность сообщения, по имени пользователя (msgfrom) берётся его публичный ключ (предварительно распространённый) и по телу сообщения проверяется его цифровая подпись, чтобы удостовериться, что письмо не подменено или не подписано поддельным ключом.

Подробнее про внедрения Ed25519: https://ianix.com/pub/ed25519-deployment.html

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

Добавил на своей ноде.

На клиенте:
Чтобы отправить сообщение кому-то, отправляем его в эху mailto.{имя ноды}.{номер поинта}. Например, mailto.ake.100
Чтобы прочитать свои входящие, указываем для получения ноду mailfor.{строка авторизации}.

В интерфейсе ноды:
Входящие - http://gears.headake.win/idec/ui2/directmail/inbox
Отправить сообщение - http://gears.headake.win/idec/ui2/directmail/send (адрес вводится в обычном формате "nodename, 123")

Реквизиты для тестов

Адрес пользователя: ake, 5
Строка авторизации: jfmq66fj6e

Адрес пользователя: ake, 6
Строка авторизации: 7uyoxz2fj4

О грустном - клиентах и разных подводных граблях.

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

И всё-таки, зачем кому-то и дальше усложнять idec?

Если его существующие возможности не устраивают, то почему не взять что-то готовое? Это выглядит, как попытки изобрести велосипед. В чём тут может быть выигрыш? Нет, ну если просто очень хочется написать что-то своё, то вопросов нет. Не подумайте, что я кого-нибудь отговариваю - мне просто не понятны мотивы.

Кто-нибудь смотрел для сравнения, например, https://public-inbox.org/README.html ? Это очень простой механизм, который использует готовые решения и протоколы для всего. Например децентрализованная сеть там за счёт Git. К тому же оно используется самими разработчиками Git. Кто-то может оценить, в чём возможные преимущества реализации этих же функций на idec заново?

base32 это большие буквы и некоторые цифры - уж лучше обычный hex тогда

а так вроде всё логично :)

И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)

shaos> И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)

Если бы знал, то не спрашивал бы. Философия, стоящая за idec, для меня не вполне понятна. Я просто пользуюсь тем, что есть, для чисто практических целей.

Сам я никогда не делаю ничего сверх необходимого. Правда мои личные потребности могут кого-нибудь очень удивить, но я никогда и не претендовал на их объективную сущность :)

shaos> И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)

Я лично считаю, что расширения нужно вводить только тогда, когда они нужны позарез.

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

Но я, естественно, не претендую на какой-то значимый голос в сообществе. Мой анархичный ii-go на данный момент меня полностью устраивает. И если при внедрении расширений, наследие будет работать как и работало -- вообще замечательно. На своей ноде я вряд ли буду делать что-то дополнительное, но с интересом понаблюдаю за движухой.

>> Реализация всё ещё пишется за несколько часов :)

shaos> Это далеко не так ;)

ii подмножество idec. Если речь про ii, то всё-ещё так. :)

ake> Добавил на своей ноде.

ake> На клиенте:
ake> Чтобы отправить сообщение кому-то, отправляем его в эху mailto.{имя ноды}.{номер поинта}. Например, mailto.ake.100
ake> Чтобы прочитать свои входящие, указываем для получения ноду mailfor.{строка авторизации}.

У меня были похожие вещи на старой ноде (на основе iing). У меня было понятие виртуальной эхи. Фактически, через них можно было делать любой запрос. Например, получить личные сообщения, делать поиск по содержимому итд. На текущей ii-go личку сделал проще. Сообщения шлются в эху .private (вообще, эхи с . у меня считаются специальными) и дальше при заборе этой эхи учитывается, что именно можно отдавать юзеру. Решение делается на основе поля To. Там кажется можно даже групповую переписку организовывать, но я сейчас не помню. Но если написать в личку All, то услышат все (через личку). :) Естественно, забор . эх нужен авторизированный. Емнип, /u/point/ расширен для этого.

Но главный вопрос в другом. Как наладить хождение почты между узлами? И тут возникает масса интересных вопросов... Начиная от адресации, маршрутизации и заканчивая вопросами как долго хранить эту переписку транзитным узлам. Ну итд. И тогда я подумал, а так ли нужна эта фича? Мне вот достаточно лички в пределах моего ресурса.

> Естественно, забор . эх нужен авторизированный. Емнип, /u/point/ расширен для этого.

Ну, у меня ключевая идея была как раз в том, что если нам нужно авторизоваться для получения данных, то мы просто дописываем строку авторизации к идентификатору эхи (или сообщения) и не надо вводить никаких новых методов. Нет большой разницы, в плане наличия данных в запросе, обращаемся мы к специальному /u/private/myauth/secret.echo или к стандартному /u/e/myauth.secret.echo. Только с ограничением на имена эх промахнулся.

Без разницы, как это реализовано внутри - генерирует нода такие индексы динамически или честно форвардит входящие.

> ... если при внедрении расширений, наследие будет работать как и работало -- вообще
> замечательно. На своей ноде я вряд ли буду делать что-то дополнительное, но
> с интересом понаблюдаю за движухой.

Это самая правильная позиция :)

Главное не ломать совместимость со старыми версиями нодов/клиентов

> ii подмножество idec. Если речь про ii, то всё-ещё так. :)

ii более несуществует - есть только idec ;)

и он чуть более сложный...

А кстати небыло мыслей сделать специальный вызов в API, который возвращал бы uplinks?
Типа /fetches.txt

http://idec.spline-online.ml/;idec.talks/linux.14/lor-opennet.17/develop.16/plan.9/zx.spectrum;15
https://.....;something.something;60

Ну и было бы неплохо иметь возможность через API спросить у нода как он называется, а то я сейчас не вижу как по http://idec.spline-online.ml понять, что это tavern

И после этого можно будет строить топологию сети автоматически :)

Вот кстати здравая мысль. И фича полезная и ничего не ломает. Я - за.

Всех обитателей IDEC сети поздравляю с Новым 2022-м Годом! Желаю IDEC в новом году разростись до немыслимых размеров и подмять под себя ну скажем всех Спринтеристов (и даже частично Синклеристов), а если получится, то и ещё кого-нибудь в придачу ;)

ake> Добавил на своей ноде.

Это, безусловно, замечательно. А теперь как наладить отправку сообщения поинтом твоего узла поинту моего узла? :)

Внутри одного узла вообще не проблема личку сделать, но смысла в ней не очень много получается.

Не прошло и двух месяцев, как я собрал актуальный нодлист.

Лежит в таверне на публичных фреках. Налетай!

P.S.: Доступен через веб-интерфейс http://idec.spline-online.ml/ без регистрации и SMS.

Тогда спешу сообщить, что через пару дней станция tgi переезжает на домен tgistation.ru.

Не суть какое событие, но для порядка отписать обязан.

>> Реализация всё ещё пишется за несколько часов :)
shaos> Это далеко не так ;)

Ну если начинать наворачивать вебинтерфейс, то да. Но чисто обмен и хранение пишется часа за 4 +-. По крайней мере на ЯВУ :)

>> Да и не повод дальше усложнять.
shaos> Это небольшие инкрементальные улучшения, которые могут вывести IDEC на орбиту современных технологий ;)

Пока не понял как :)

>> Давай пойдём моим любимым путём: какие проблемы ты решаешь? :)
shaos> Ну для начала - добавляет бинарных данных в рассылки.

Какие проблемы решает добавление бинарных данных в рассылки? :)

>> С моей точки зрения этот false positive с такой высокой вероятностью ломает всю затею.
shaos> Ну почему? Есть разница 100% сообщений надо вычитать, чтобы отфильтровать из них бинарные объекты или 1.56%? ;)

А надо фильтровать?

>> А найти и прочитать сообщение в общем случае это O(1).
shaos> Скорее O(n)...

Сдаётся мне, что это зависит от реализации. Например, в цезии формат простой, заточенный на линейное чтение базы сообщений. Тут O(n), согласен. А если хотя бы по сообщению на файл, то уже всё таки O(1).

>> Есть ли смысл в таких аттачах? Тело сообщения не должно превышать 64КБ.
shaos> Есть смысл, если надо заслать что-то маленькое вместе с сообщением (бинарь программки например, или заархивированный исходник).

А есть такая необходимость? Ведь есть файлэхи :)

> Ну если начинать наворачивать вебинтерфейс, то да. Но чисто обмен и хранение пишется часа за 4 +-. По крайней мере на ЯВУ :)

Там мелочей всяких больше, чем на 4 часа, ну да ладно - не суть...

> Какие проблемы решает добавление бинарных данных в рассылки? :)

Ну сообщение становится самодостаточным (если приаттаченные файлы маленькие и влезают вместе с текстом сообщения в лимит)

> А есть такая необходимость? Ведь есть файлэхи :)

Не все узлы подписаны на все файлэхи и глобального поиска по идентификатору нет ;)

> А надо фильтровать?

Ну если будут сообщения разного типа, то да

Текстовый клиент, который не так давно отметил своё восьмилетие (первый из существующих клиентов) обновился до версии 0.9

* поддержка загрузки некоторых эх с других станций
* нумерация файлов в каталоге 0001.txt вместо 1.txt

Размер архива вырос на 55 байт :( и теперь составляет 3911 байт. Поддерживается python от 2.4 до 2.7.
(разные версии тестировались на первом пентиуме с Debian Sarge, Etch, и OpenBSD 4.2, 5.0 и др.)
(это сообщение создаётся на третьем пентиуме, правда с новейшей OpenBSD 7.1)

@base64: ii-txt-0.9.tar.gz
H4sICPqmcmICA2lpLXR4dC0wLjkudGFyAO0ca2/cxtGf+SvWdgSS8R3voZPkslVat3HioHWT
Ok6bQBEc6m55YsQjWZInnRwE8COuYySN66ABCrRoi37pp6KyY9nyS/4LvH/UmVk+705SmliK
7HBhmeTu7OzOc2d2ybOsajgIq3XtR0f2rdTrrfrczAxcqYxe6b7Rak63ZpqNRnMO6huNVn3m
yMyRAyj9IDR8GNJ33XA3uLVlzu0jL1yxUvnX6m4/3G/5N+Zm6vnruPxnsb7RbMzVD1b+/YD7
u8Pt3v5iyL+mtd2+Ez5bUuuNen221dpF/o1R+5+ea8weqZfy3/dSP1KWH3LJ27+3vu/r/97+
X9h/s95olf7/wOVf6/B9CAH28v+N6dkx+c/MzpX+/wDKW+/Ne+vhsutIpuuzVWY5rKm14G8G
/mbhb441pY4rWSb7QAC+tMqqv2XNVxgoy2rN6dv2B1K4zB0pRfXSqmRa0MnhpX99zuzftJyO
w9e0Z7oU7GH/YOytUfuHBaOM/w6iHGfVl6us7XYsp6uzfmhWT2KNJFk9z/VDbOHtoMJc+Gub
XUnqcJNBokBpgqLqEoNisXkWhL5iQZXrcUeRNa2YTsiq5nOjo6jqiYZKfXaAq8hrALvmWyFX
AK+A9XnY9x2WQk8FGlxkNsUsifwWN9Bxwfw0204mZQchTGthwBBggO1uoNlWEHYsnwaeChAD
N1QGzk0GrZcRaLBIvbGT2Qu6WAWYBEosAAdoBVu0lIipIEancKOC/dSKjMQQQ1PitcCzrdC2
HB4oaopxGdq4D0gB9YKO1gdGyAeKLKuLKRBM0YaxBKzK5udZM5sTlqW+ieRyY5GdQExpI7fH
+07v3nehobfwdkH+mc+90NUFbdhSX0xgWno2uzw7MuVAWWYsiGUqv+/I2oeu5SgwqsoyNoB0
fN5zV/kODFWl0lvvu//vrYTaM08D9or/mnNj8d90s9Us/f8h8P/BOjj+JSPgsy1cBIS7NdEr
Qotm+N1VcBaLwp2EA/Ai5APMxONRfZsaBBJtabbFHfQXCsLn1gIT/IqshW4QFBYB6BwDoX9w
jB5XzIp5QgaXIKul/T5j+wfHDox9xi5gr/hvrlkf3/8r7f/QxX+h1eMiAOwYIe8qnYoZx1px
gIYAGgSCJt6AmYqKbo8eMTjsqLCME4YLnuFfVHBdFxi8i+AiUPXGQqSeCy0dqx3Gz3E0411U
2U/YSZ0dB8/SYT0edNNQIp7OryEDjf1LiOi9ixC+iAEUuSYn6LW+h/QoYpCLlqcg/IKuNxcr
dNfAWzWJVdABWhcqDvpA7vR73MfOiszby64BXg+8F6KDC5Bj+m4P7oxOxxcVoQvXoL/0oayq
WRCGAbR14UQjrei5C86imLK1GM9zgXwe1mYxFLSf1BfVFIJGRhDkdlZRCKN7LnjxCTFsbPvg
DuRC5EYuv0cBtAAVgJOjWj2TmRBxYRToFod1vUnxcSpg6H90nuSX8ShAUlAVSPcy2iryVKc2
1atNrbOpM/rUWTkLKUVc28OFBTgGl5iJJJVFUa1gPSYv2EZyWlSxRWWihUaFZ/b62fPq+w6J
UGc5ZCDRxeIIJN64rjCunEXMZry8yRCNTwUQk+9QGDELuqfqhYiRsBg9DAAS0tq2G3Dl/4+R
R/y/FywfePzXqM9Oj8d/063S/x8C/9/3bdtaqmAYCEtAugPguUFoKkFs7mAjBhiagNXgEkd4
H8khar3OgorsGf1wGW4xSYc/8MQfC0M9/tGxX7iQ+zthNVz3+DGdHTM88ChtI7Rcpzaorq2t
VcEF9aop4s6xj6lrvzAouZgEfYPszwMfCd6MJljwgf0kPhXOzd4poA2TiLZnF0JaSHLROxMX
ACp1XFCvoUKFwZoVLpPDY+6KnHP1WZoLKKU0QSeEYO3YYcnqHpWzHp4PRDD59Llzb57T2Sr3
1xECV7zA6HKm2FbPCnU221pRj8rjGJHvjPu+6++M9NQ758+kfQO+E9jvzrz3U7lMw1/g+N/n
sGgH/ED3f5vg9sf2fxv16dL/H8L4P7cL3OXhhSQqUTAxj71c6K/ro6G4CP8QOo7/CH7HbVE+
aHMvHMMiy99/+vGc5BKw+u2VTeyaK+ydbuSyiZE9eJ9WYcO2uZEcEJjMcUNc+zwjXNb4wArC
oLgJX1ghe8YK71j+CIiY2DrMqKB6uIMP4y/EG/cTd+cpqyEsxdQmJ4ReUQi99d3ys4KOf+eM
Z5LKF3UPRTNfr8RaMC/LFVQDvJIexDd4QX2Aq/qC5k0TD14S6eJZAZ1DqdpF07JtpaVOPITA
k4dvl4lZE5IvgeTbJmCHa/1fM599+rfX+j9dn54Zy//qM+X7H4cn/2tmZwC0/J87/ZtfvXEW
fARINg0GTMVOVlORNZg8bC8z4f1sYSbgQNjbITR333iTxUMkz2KlEHVdWDrjVeb3fU4nufFM
tHOiRrHVPIAGLuiCOOFU5FNt9KVVShYBNSSAMiKUkx6B5zoBz+FMsscYWZrOJaCa5ZguBCpA
pSIn2erpBD0dqYoRMv+NHhSrtNfhv9csGwIS+M8F55zQq2To48VAnZCBIZ4ELr/ummkGu1cs
9t1isKQ3LK80UsA9xQYvy735Zj0eJT1h9w2ny5V6BTdobZWgcqvousXtDrMXBvrgBDbFGPuO
l+4kxINlZ0Xg7emsCLNmzzba4Ker4M9P0AoaV1yACgjBWMyLDl/qOx1gOK4GuRlSlBVM2K2k
pdbqVFbcDp7CJ1GdLlcauePp0eUcOuSOqZAI6K+OdsixG6YD2XjaAxDEy99on2SDtTIZmh0X
5BCQIHnNsFcucBvP3mOaOG7IyPKPQZvg5qOPi1ygbYqJfMBXITR6EcIpxiKE0ClW2fTKwHwS
eqVbD9zQJwBqhgfkdRSnED9yO95RwrxTAUOsGF6FJ55E7LOQc5GnAp68EyDAUnsBkDwHUlpF
SMrtnJjXCToAOx6NITMpdGx8TWTk5RFBw0JVuD59ETk1oKgWGhFtbm8X+nTElhIYi8BWadXV
IlOCHGG9PGEMlFmE2x1bzU2LplbQbUkSXMs2vXKdk7dh1Ep6JwL1fmUkUl+1kvA7FkLFqCwY
i+ULFz/A9z+C7rMf49u8/z1bb5bvfx+8/NEhHgr5z02X8v8e5B+HHvuW/33T7z+nW/gd4EHK
v/z+E+WP4cB+nv8mci/Y/0yrOSb/xlzzcMn/BbV/EHhyxInbaW3XMS0KJnd4aZlidV8xC/H5
wmIxvcBYtJkcolLBFwDNJPJPEo1BMSDGpCROEQaFFAEaxLi0pQyNhVxxkOZruqziuS+mMHBP
L3NTMs0Gonuub7whncKlaW4MCiFxHnYCXH5U0Sd79TyG8TGtkJ4b+z93+tSrZ09rfj842P2/
1iT7r2O8UK7/+16i/wyvRBts+OnwyvBq9BBuo6fDS9F2tDn8Q7Q1vASVm8MrzLJqVoe3q8PL
+Dj8nEVPsNcn0Ub0IHoE4HeGV4dfMGjeGl4GjJvR4+HVCovuwL9oK7obbTKqfUitCP7Z8Fqh
P4u2GFxvQ8P16Ak143RwdgTwNQJpkhT9EypuR9vUgFMD5BvRPRzgMhPfn9EXbIDxVb5kGQ47
jbuQgP1tw8fXJd45/1r1ZIV54EoCDqY7Pw9I/wzTBNLvA6qnQMllHJqIoGnCI/BkC5pgUB2z
di0glAE4K7gFQp/CXC4hWdEDfNiOHgGa6/EUEzqHnyFLkAHE4gesyogQ5PgGzODR8CbCazgf
uM8j2gSGb2HVE5DIPXxkxMhHw89hrtvI5s3odhXQ3AVkm8AL6LAND58Bz44ikwhhfrSHQEA1
QYjihG43hrcYiojmR9qwkU54C9mDWhFtVVA226KeBB89BnjEsp2f9FamKmJ+wElgBGoCzAq4
gmgfo5AJH0zlE8D+dbRBDN1OJoIKEW1Dh9zEqpMnJmUMELp6CQdGguGxSvKl5+Gn0OOL4Q3o
87ha69ek4R+H16KNkQuiAu6g6j0ooMMuuh5DSbUai24R1ltICc0cdHYTmA5CA80E/4dKtE36
fUPIEvXkDiMUmxqL/oozQYYJJQSdRmRA8U0Eo2OZWFX/TXIHOyHGwmhbyNWE02AkaLxM1INy
gGAqmZC3xTzu0wDU5U6uMXo8anObqe5WRM+7xIR7AHQjpeEyilaMiRqXSml4FTcpNSZFf8u0
YxPZyWiIh2TzSMR9ND+cj06fLknRP9LZg+oArdT+hbB2dDXXEr8C9OqS9HLstWLvUiRflxLr
BBw3R9SblBU7oP6hz5JStULgKiOVvR3dq0jUjbwfmSa6CSRjeBP6oA8CUwS1yjs6UHKdJoay
hRlIp2wbmfFV9F8WfRn9Bcz870Dsv1Bdh1ckQQiaFSrZFZ3tMnFI0qzOmFLBXGJzS81TsCNB
KjzSp8PPx+jMGFCgM0f+dayEXrdA0Ynub8aEUR7MTV+0f/7L/snZZsM4df7MzNsrZ1qSa3e8
tnSO6yzkAUR7SALSc50Mdvso8ganywSrYP4Fl0b8wj53Yx3YINquJxqPtKFGXCL7EJo/GOCx
MSow3IHWgYJfFSTEfivH7y2GJ9x6hcXH2Ki3d/IrmmAxLZlXRsbJmdcmaXbsHQrmm3j3TG3R
B24li7HwYTgP0u+v0aaH1wVD7kCHWyz16lu0JDwhq388anYF/y+oVJCjSHMyVjojhm8OqrFi
0BTv0qIVL3oS+iMW/QlU4ApoyAZQCRCMfNSXDL/TJPUcXqPhngxvov3GDg1dxsjSRwoM6z4t
5KNaDQ7yq3iWY350BNEWei7kIfJ3M3M0gkRRJQQNGltYtZDFm0JNY0cqBPjuu/i1Kb6YCTIX
DySa+8QTcri5yIHkj90SNj038X+W+x1s/F/Hd/1G4//per2M/w+gaNJyGHp6rbbc73LPcrpa
uILxUBB2tKQqAfGa2kwjhASxBukABkDgtTWvXR6ivBj7fyKt2Ycx0P532/9vNsb3/1vl778c
SDl+tLZkOTVczo+vzoMaSFK7w+qQbWhMw58Dkl5h8aGA9NJb78WZCN5lr4rTY/rlKPbXIPK1
TIrlWDVg2Zdl4pdibB4UKk2rPGr+/u0/DlgO3v4b4/t/zdlWuf93wPY/Yvdo1NnPAdGj+HUI
lvwMy8sYClOD+Gww14Cf8ceOoLSxspSlLGUpS1nKUpaylKUsZSlLWcpSlrKUpSxlKUtZylKW
spSlLGUpS1nKUpb9LP8D2f11hQB4AAA=

Восстановлена связь с сабжем. По техническим причинам в таверну не ходили сообщения с 9 апреля.

Сисопы, имеющие станцию Мира в аплинках, проверьте связь. Пока что она шлёт мусор на запросах несуществующих эх. У себя я обнаружил запрос несуществующих ifiction.15 и python.15.

+++ Caesium/0.4 RC1

Рад сообщить, что в таверне появился клуб эсперантистов. Заходите в eo.klubo -- поболтаем :)

+++ Caesium/0.4 RC1

У меня чото ни с сабжем, ни с idec.spline-online.ml связи нету :(
В живых вижу только 3 узла IDEC (ну кроме моего):
https://dynamic.lessmore.pw
https://club.hugeping.ru
https://tgistation.ru

на lessmore и ping каким-то чудом появляются мои сообщения отправленные с моего узла shaos :)

получается кто-то кроме spline-online.ml фетчит http://shaos.net:8085/ii-point.php?q=/

либо tavern сейчас живёт по другому адресу и продолжает меня фетчить и раздавать другим?...

Спешу сообщить, что мой заокеанский узел IDEC всё ещё существует!

Сегодня я добавил второй путь забирания эх через lessmore т.к. существующий адрес tavern не работает как минимум с 14 июля 2022 года (если пойти туда через браузер, то оно редиректит на какие-то списки ссылок). Несмотря на то, что старый адрес tavern не работает, он как будто-то бы продолжает забирать у меня сообщения по старому списку (я сегодня добавил у себя эху idec.test и её в том списке нет). Во всяком случае всё, написанное мной в idec.talks ушло в сеть и появилось как минимум на узлах lessmore и ping.

Список эх, которые я забираю извне:

	["idec.talks", "Сеть IDEC, её работоспособность и софт"],
	["idec.test", "Тестовые сообщения"],
	["lor-opennet.17", "RSS с сайтов linux.org.ru, opennet.ru"],
	["develop.16", "Программирование"],
	["linux.14", "Эха для линуксоидов"],
	["plan.9", "ОС Plan 9"],
	["zx.spectrum", "Speccy и совместимые компьютеры"],

Список локальных эх:

	["z80.coding", "Программирование процессора Z80"],
	["580.vm80a", "Программирование процессора КР580ВМ80А (i8080)"],
	["nedopc.1801", "Обсуждение компьютера nedoPC-1801"],
	["pdp.11", "Обсуждение архитектуры PDP-11 и совместимых машин"],
	["robby.lang", "Программирование на языке Robby"],
	["balanced.ternary", "Обсуждение троичной уравновешенной системы счисления"],
	["english.talks", "Speak English"],
	["silicon.valley.local", "Локальная конференция Кремниевой Долины"],
	["sprinter.computer", "Общие обсуждения компьютера Sprinter"],
	["sprinter.software", "Обсуждение программного обеспечения компьютера Sprinter"],
	["sprinter.hardware", "Обсуждение аппаратного обеспечения компьютера Sprinter"],
	["sprinternet.io", "Обсуждение сети для компьютера Sprinter"],
	["circuits.cc", "Эха про сайт circuits.cc"],
	["nedopc.org", "Эха про сайт nedopc.org"],
	["shaos.net", "Эха про сайт shaos.net"]

Короткий линк веб-интерфейса моего узла: http://idec.shaos.net

Могу взять благоразумных пойнтов - пишите на me@shaos.net ;)

Shaos

Ordos> Тогда спешу сообщить, что через пару дней станция tgi переезжает на домен tgistation.ru

Как обычно и бывает, вклинились обстоятельства. Поэтому процесс немного увеличился - вместо пары дней переезд занял полтора месяца.

Да. С таверной как-то всё грустно. Может ещё очнётся когда-нибудь. Пока отключил.

Сегодня подключил забирание с tgistation.ru эх idec.talks и zx.spectrum

shaos> на lessmore и ping каким-то чудом появляются мои сообщения отправленные с моего узла shaos :)
shaos> получается кто-то кроме spline-online.ml фетчит http://shaos.net:8085/ii-point.php?q=/
shaos> либо tavern сейчас живёт по другому адресу и продолжает меня фетчить и раздавать другим?...

this.

Я просрал домен, как всегда. Так что таверна живёт сейчас по адресу idec.spline-online.tk :)

+++ Caesium/0.4 RC1

shaos> Спешу сообщить, что мой заокеанский узел IDEC всё ещё существует!

И это ура! Я уж думал, что всё -- ты пропал с радаров, а мониторить состояние сети в данный момент времени не особо есть когда. Так что очень рад, что ты с нами.

+++ Caesium/0.4 RC1

Ordos> Да. С таверной как-то всё грустно. Может ещё очнётся когда-нибудь. Пока отключил.

Хех. Похоже, я отпал от основной сети. Надо Петра спрашивать :)

+++ Caesium/0.4 RC1

Я немного отовсюду пропал в последнее время - новая работа, много забот и очень мало времени. Надеюсь, скоро это всё устаканится. Пока же занимаюсь сабжем.

Итак, почти закончил godec (нехитрое название да) - библиотеки, реализующей протокол idec на go.

Следующим шагом будет создание нового фетчера на базе этой библиотеки, реализация хранилища (скорее всего на базе postgresql) сообщений, создание узла без веб-интерфейса и, собственно, завершающим шагом будет создание нового веб-интерфейса таверны.

После того, как начинка таверны будет полностью переписана, очень хочется переписать Цезий, но тут пока нет никаких заделов на будущее. Может, это будет более навороченный консольный клиент, а может и более-менее современный клиент с графическим интерфейсом.

После всей этой эпопеи планирую написать таки новый репозиторий instead-games.ru, но это уже для другой эхи и фиг знает когда будет :)

+++ Caesium/0.4 RC1

> Я просрал домен, как всегда. Так что таверна живёт сейчас по адресу idec.spline-online.tk :)

Привет - всё понятно теперь :)
Поправил настройки у себя, чтобы забирало по правильному адресу

Собственно сабж. Пару дней уже как.

Поторопился отписаться. Уже работает.

Изменения по tgistation.ru. Может кому интересно будет.

Поменялся дизайн web-морды в лютый минимализм без картинок, js и прочего. В результате сайт неплохо себя показывает даже в текстовых браузерах.

Прикручен сбор новостей с хабра. Не всех, в основном, низкоуровневое программирование, микроконтроллеры и т.п.

Открыта свободная автоматическая регистрация без почт и sms. Надеюсь спаммеры не заведутся :)

Идут раздумья по поводу реализации приватных бесед. Для начала хотя бы в пределах одной станции. Пока думаю использовать это для общения и взаимодействия с ботами. Мне кажется это сильно бы расширило полезность сети как таковой.

Проверил уменьшение окна браузера - прямоугольник с текстом масштабируется в соответствии с размером окошка и это очень хорошо! Значит будет работать в моём недобраузере на ретрокомпах без глюков (единственный глюк это убегание линейки минусов за пределы рамки, если окно браузера становится слишком узким) - можно заменить на тэг <hr>? Он должен работать в текстовых браузерах тоже :)

P.S. Feed показывает лишь 10 последних сообщений и листать никак - можно исправить? ;)

P.P.S. И содержимое эх не посмотреть - раньше вроде можно было не?

P.P.P.S. Надо настроить забирание bot.habr.rss себе :)

Настроил :)

http://shaos.net:8085/ii-web.php?echo=bot.habr.rss

По внешнему виду изменения будут, просто свободного времени не так много, как хотелось бы. Как дойдут руки - сделаю.

Хабр, конечно, давно уже не торт, как говорится. Тем не менее, я попробовал отобрать более-менее интересную тематику. Если это понравится кому-то - я только рад.

Касательно станции, наверно, не буду здесь спамить. Для этих целей есть локальная конференция, буду отписываться там.

https://idec.spline-online.tk/ опять помер - говорит EMPTY...

Ordos> Касательно станции, наверно, не буду здесь спамить. Для этих целей есть локальная конференция, буду отписываться там.

Эта эха как раз для такого общения. А IDEC для того, чтобы объединяться, а не дробиться. Так что лучше бы тут и писал :)

+++ Caesium/0.4 RC1

shaos> https://idec.spline-online.tk/ опять помер - говорит EMPTY...

У него это случается. Поднимаю как только могу :)

Пока нет времени дописать новую реализацию, но она всё равно будет. Теоретически она будет стабильнее и быстрее.

+++ Caesium/0.4 RC1

До нового года осталось всего несколько часов. Кто-то уже отмечает, кто-то только готовится, кто-то может быть даже работает. Некоторые так и вовсе не хотят ничего отмечать. И это тоже можно понять.

2022 год выдался на редкость паршивым. Может быть даже самым паршивым на моей памяти. Тем не менее, хочется надеяться, что следующий год будет лучше.

Поздравляю всех с наступающим Новым Годом! Пусть сбудутся все желания. И самое главное - пусть все будут живы и здоровы.




P.S. Не мастер говорить речи, просто хотелось высказаться.

С уже наступившим Новым Годом всех !!!

> Этот сайт НЕ использует cookie. Вообще не использует. Никак.
> Здесь нет рекламы, счетчиков посещений, аналитики и прочей подобной дряни.
> Совсем не используется JavaScript.
> И даже картинок здесь нет. Только текст.

Этот сайт использует ПРИНУДИТЕЛЬНЫЙ https, поэтому я нифига не могу зайти на него со своего Debian Etch. хоть с картинками, хоть без, хоть с js, хоть бе.

iiii> Этот сайт использует ПРИНУДИТЕЛЬНЫЙ https, поэтому я нифига не могу зайти на него со своего Debian Etch. хоть с картинками, хоть без, хоть с js, хоть бе.

Хм. Да, это так. Но разве https - это плохо? Первый раз слышу, чтобы были какие-то проблемы.

В любом случае - это всего лишь web-морда станции. И как таковой полезной нагрузки не несёт.

> Хм. Да, это так. Но разве https - это плохо? Первый раз слышу, чтобы были какие-то проблемы.

Да, есть проблемы. Несовместимость. Поэтому из старых ос на этот сайт не зайти в принципе. Хоть он трижды без javascript и всего остального.

> В любом случае - это всего лишь web-морда станции. И как таковой полезной нагрузки не несёт.

какая разница, всё остальное тоже работает по https, и нельзя приконнектиться. у меня вон, текстовый клиент гоняется на python 2.4 на debian etch :) к hugeping.tk я могу свободно подключаться, он http

iiii> какая разница, всё остальное тоже работает по https, и нельзя приконнектиться. у меня вон, текстовый клиент гоняется на python 2.4 на debian etch :) к hugeping.tk я могу свободно подключаться, он http

Вторая версия python уже года два как ушла в небытие. И, если я правильно помню, то последняя была 2.7, а никак не 2.4.

Принудительная настройка https, как мне думается - правильное решение. И если что-то совсем древнее, как естесственный отход жизнедеятельности предка слонов, не умеет с оным работать.. Ну что сказать - нет так нет, извиняйте. Могу предложить пользовать тот же hugeping. Кстати web-интерфейс там не в пример лучше. Да и функциональность намного функциональнее.

Debian Etch это извините на минуточку ОООЧЕНЬ старый дебиян :)

https://www.debian.org/releases/etch/index.ru.html

> Debian GNU/Linux 4.0r9 был выпущен 22 Мая 2010. Debian 4.0 изначально был выпущен 08 Апреля 2007.
> ...
> Предоставление обновлений безопасности было прекращено в конце февраля 2010 года.

Боюсь, что его у вас всяческие трояны, черви и вирусы пронизали вдоль и поперёк...

shaos> Debian Etch это извините на минуточку ОООЧЕНЬ старый дебиян :)

shaos> Боюсь, что его у вас всяческие трояны, черви и вирусы пронизали вдоль и поперёк...

О, Господи! Так и Plan 9 тогда пользоваться тоже нельзя? Там про обновления безопасности никто сроду ничего не слыхал. Да и ретрокомпьютинг - тоже. Как там насчёт эмуляторов C64 или амиги? Или калькуляторы TI? Тут прямо рядом эха со старым железом.

Конечно ожидать, что все будут этот антиквариат поддерживать - наивно. Но, учитывая специфику сети idec, вообще-то не так уж и глупо.

P.S. Извините, что влез не в своё дело, но слишком часто приходится видеть это "а зачем вам всё это надо?". Имеет каждый человек право на свои причуды и интересы. И отнестись к ним с сочувствием или хотя бы с пониманием - ничего ведь не отнимется. У меня самого в углу древний комп стоит, на который ничего новее 2005 года не установишь, а выкинуть жалко.

>> Вторая версия python уже года два как ушла в небытие. И, если я правильно помню, то последняя была 2.7, а никак не 2.4.

в debian sarge и etch - 2.4. и с idec-сайтами через http там нет никаких проблем

> Принудительная настройка https, как мне думается - правильное решение.

нет, принудительный https - это маразм. если человек хочет выбрать https - пусть выбирает https, а если http - значит, он хочет http

> И если что-то совсем древнее, как естесственный отход жизнедеятельности предка слонов, не умеет с оным работать.. Ну что сказать - нет так нет, извиняйте.

тогда к чему этот выпендрёж с "нет javascript, нет того, нет сего", если там принудительный https? со старых систем не зайти в принципе. а с новых - и что, что нет? я с новых могу зайти из links2 или dillo, и у меня тоже не будет ни javascript, ни остального. убрать для себя javascript я могу, выбрав нужный браузер. а убрать отсутствие https - нет, если автор его насильно приколотил. поэтому преимущество "плаин html" превращается в недостаток, ибо там, где оно наиболее уместно, а именно старые системы, до него не достучишься. а остальным оно особо и не надо, кому надо - тот и из links зайдёт.

> Боюсь, что его у вас всяческие трояны, черви и вирусы пронизали вдоль и поперёк...

я с ними на рыбалку хожу

> Конечно ожидать, что все будут этот антиквариат поддерживать - наивно. Но, учитывая специфику сети idec, вообще-то не так уж и глупо.

моя нода поддерживала python2.5, и работала на чистом http, нормально подключаясь. я пользовался веб-интерфейсом на windows 9.5 с ie4 и выше (ie3 не поддерживал utf-8).

оригинал php-ноды делался так, чтобы работать на php4.

я не вижу проблемы поддерживать старое, и при этом работать на самом новом.

у меня есть сонерик клавиатурник, весом в 100 грамм, который зайдёт на http-ноду, но не зайдёт на https. и софт там на свежий не обновишь.

1. перепись узлов - кто что гейтует? чё ща модно гейтовать

2. давайте сделаем новую межсетевую болталку - pipe.2033? новый год всё таки, а тянуть 3500+ сообщений 9-летней давности про болтание не стоит - лучше в архив :)

или std.hugeping тоже теперь болталка? :)

iiii> или std.hugeping тоже теперь болталка? :)

Судя по статистике с начала ноября, боюсь, что я тут самый болтливый. Это при том, что и сказать мне особо нечего :P

а где болтаем-то?

От создания контента - к его провайдингу.

http://ii.51t.ru

для старых компьютеров - ок. осталось забить контентом. функциональность "эхи как книги" надо будет вернуть, но переосмыслить под "архив эх". никакого https, никакого javascript и css. проверена работа на win 95 с ie4, на debian woody с netscape navigator и на всём остальном.

сейчас фетчатся эхи idec.talks и pipe.2033 (пока не существующая) с hugeping.tk, поллинг 5 минут

описание станции (точнее, софта эхи): http://ii.51t.ru/ii/html/about.html

iiii> а где болтаем-то?

У Петра, в основном. Вот здесь RSS всех сообщений по датам, где видна вся (не)активность: https://club.hugeping.tk/echo/all/rss

я про то, какие эхи гейтовать: std.hugeping это локальный блог или глобальный?

iiii> я про то, какие эхи гейтовать: std.hugeping это локальный блог или глобальный?

Честно говоря я не понимаю разницы. Если человек что-то публикует, то явно для того чтобы его читали и комментировали. Сомневаюсь, что имеет значение, кто и где именно это делает, тем более, что комментаторами там выступали и операторы других нод. Если же речь о том, кто должен там создавать новые темы, то, наверное, только он сам. Петру, конечно, виднее, но могу просто процитировать:

Peter> Я решил завести блог на IDEC, так как у меня есть много разрозненных
Peter> блогов. Но надо концентрировать сови усилия. IDEC - имеет прекрасный
Peter> формат для такого. Буду периодически высказываться на разные
Peter> темы. Что-то вроде текствого радио. Ну, просто потому, что надо что-то
Peter> делать!

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

Приветствую

> О, Господи! Так и Plan 9 тогда пользоваться тоже нельзя? Там про обновления безопасности никто сроду ничего не слыхал.

Ну новых планов не выпускают, а дебианы - выпускают. Какой смысл сидеть на старой версии если уже было выпущено много новых с обновлениями (в том числе секьюрными) и т.д.? Вот у меня есть старый повербук на G4 - там ничего новее MacOS X 10.4 не идёт ну я там и сижу в сафари который не обновлялся с 2007 года и тоже страдаю по недоступности многих сайтов https (хотя вот например некоторые летсэнкрипнутые сайты там открываются), но если есть стандартный ПЦ (страше 486), то что мешает поставить дебиян поновее? Религия? ;)

> Да и ретрокомпьютинг - тоже. Как там насчёт эмуляторов C64 или амиги? Или калькуляторы TI? Тут прямо рядом эха со старым железом.

Ретро это хорошо, но старый дебиан - это не ретро, а скорее дырявое корыто ;)

> но если есть стандартный ПЦ (страше 486), то что мешает поставить дебиян поновее? Религия? ;)

а что мешает использовать javascript, cookie, картинки? какой тогда смысл выпячивать "тут нет того и этого"?

iiii> а что мешает использовать javascript, cookie, картинки? какой тогда смысл выпячивать "тут нет того и этого"?

Разве кто-то что-то выпячивал? Просто констатация факта и не более того. Уж извините, но сделано так, как я посчитал нужным. В том числе и несчастный принудительный https. Где-то в стандартах указывается, что его нельзя использовать?

P. S. Ну хоть эха оживилась и то хорошо.

Я просто логики не вижу. Сделать сайт, лучше всего подходящий для старых систем и компьютеров, и запретить к нему доступ старым системам и компьютерам. И непонятно, к чему указывать, что у нас нет того, того и того, если основная целевая аудитория этого всё равно не увидит :)

Хотя я в любом случае ПРИНУДИТЕЛЬНЫЙ https считаю тупостью, лишающей пользователей выбора.

shaos> Ну новых планов не выпускают, а дебианы - выпускают. Какой смысл сидеть на старой версии если уже было выпущено много новых с обновлениями (в том числе секьюрными) и т.д.? Вот у меня есть старый повербук на G4 - там ничего новее MacOS X 10.4 не идёт ну я там и сижу в сафари который не обновлялся с 2007 года и тоже страдаю по недоступности многих сайтов https (хотя вот например некоторые летсэнкрипнутые сайты там открываются), но если есть стандартный ПЦ (страше 486), то что мешает поставить дебиян поновее? Религия? ;)

"Не корысти ради, а токмо..." ради верности фактам. Я дебианом никогда сам не пользовался, но вот федорой - много лет. И с 2019 года они интел 32-бит больше не поддерживают, от слова "совсем". Да и до этого минимальные требования памяти уже заметно превышали возможности старых компьютеров. Ну и, например, многие перестали поддерживать старые процессора ниже Pentium 4. Я с этим только вчера сталкивался, пытаясь установить android-x86 на старый комп (не ради любопытства, кстати).

Да если задуматься, то даже там, где оно ещё формально поддерживается, - количество багов зашкаливает. Помнится, что ещё в начале 2019 года у меня некоторые приложения в федоре (а может и не только, ведь это только дистрибутив часто стороннего софта) уже не работали, а разработчики такие баги просто тупо игнорировали.

P.S. А Plan 9 имеет несколько активных форков, но обновления там только для функциональности. В таких экзотических системах людей слишком мало, а работы - слишком много (хм, прямо Атос в исполнении Смехова: "можете не сомневаться, что я убью Вас" :)). А обновления безопасности - это только для больших, популярных ОС (Кстати, не самообман ли это на самом деле? Если сторонние приложения там никогда разработчиками на этот предмет даже не изучались?).

> с 2019 года они интел 32-бит больше не поддерживают, от слова "совсем".

Мимо - Debian 10 "buster" всё ещё поддерживает 32-битный интел и последнее обновление 10.13 вышло в сентябре 2022:

https://www.debian.org/releases/buster/

>> с 2019 года они интел 32-бит больше не поддерживают, от слова "совсем".
> Мимо - Debian 10 "buster" всё ещё поддерживает 32-битный интел и последнее обновление 10.13 вышло в сентябре 2022:
> https://www.debian.org/releases/buster/

интересно, это как надо так умудриться читать?

ps. Дебиан любой версии, вплоть до sid, поддерживает 32 бита

В кои-то веки -- оживление!

Мне тоже не нравится принудительный https, но тут каждый сам решает что на ноде крутить. Опять же, есть технические нюансы. Мне кажется, что заворот http на https это сейчас настройка по умолчанию много где. На моей ноде всё сделано руками, поэтому мне было не сложно оставить выбор.

P.S. gemini требует ssl и это для меня существенный минус. Выкидывает за борт всё ретро сразу. Хотя в остальном gemini мне очень нравится...

Пётр, я с тебя фетчу idec.talks и pipe.2033

1. сделай бекфетч с http://ii.51t.ru/ii/ :)
2. что думаешь о создании эхи pipe.2033 и отправке 2032 в архив
3. стоит ли гейтовать std.hugeping

у меня станция заточена под http и старые браузеры (проверено на win95 с ie4)

>> с 2019 года они интел 32-бит больше не поддерживают, от слова "совсем".

shaos> Мимо - Debian 10 "buster" всё ещё поддерживает 32-битный интел и последнее обновление 10.13 вышло в сентябре 2022:

Забавно. Я, вроде бы, совершенно ясно написал, что речь идёт вовсе не о дебиане, а о федоре и каких-то других ОС. Кроме того я упомянул и другие, не менее важные причины, почему современные ОС обычно не подходят для старых компьютеров. Как насчет них? Ссылаться только на официальные спецификации - не стоит, иначе остаётся впечатление, что спор идет только ради самого спора. Я не раз уже убеждался на личном опыте, что от задекларированных характеристик до реальности иногда дистанция огромного размера.

Задам тогда прямой и недвусмысленный вопрос: на каком именно старом компьютере кто-нибудь лично использовал последние версии каких-то ОС и какие остались впечатления? Какие именно ОС? Сколько было нужно памяти? Какие старые процессора работали, а какие - нет? Были ли проблемы с какими-то приложениями, которых не было на 64-битных компьютерах? Работали ли все устройства? Возможно ли было использовать готовые носители данных (CD, USB) для их установки без доработки напильником (речь о старых BIOS)?

P.S. Я вообще-то никогда не позволяю себе голословных домыслов. Все свои утверждения я проверял на реальных компьютерах. Могу назвать каждый и возникшие там конкретные проблемы. Результатом было то, что несмотря на моё сопротивление, спустя три года, я был вынужден перейти на 64-битную платформу с ОС, официально поддерживающей 32-бит до сих пор (не дебиан).

Прикольный дизайн прямо как в wap 2000

iiii> Пётр, я с тебя фетчу idec.talks и pipe.2033

iiii> 1. сделай бекфетч с http://ii.51t.ru/ii/ :)
iiii> 2. что думаешь о создании эхи pipe.2033 и отправке 2032 в архив
iiii> 3. стоит ли гейтовать std.hugeping

iiii> у меня станция заточена под http и старые браузеры (проверено на win95 с ie4)

У меня довольно утилитарное применение idec, я бы даже сказал - эгоистичное. По соображениям простоты я фетчу всё-то, что показываю. Так что фетч я взаимный поставил, но забираться будут только те эхи, которые присутствуют на станции.

Про pipe.2033 -- если создание эхи приведёт к тому что у нас будет две эхи, вместо одной, то я бы этого не хотел. Так что я не то чтобы инициативу не поддерживаю, я считаю что это нужно всем решать станциям.

Кроме того, твоя нода обычно появляется, потом пропадает. :) Ты создаёшь какие то эхи, потом забываешь. Поэтому я с осторожностью отношусь к идее. :)

> У меня довольно утилитарное применение idec, я бы даже сказал - эгоистичное. По соображениям простоты я фетчу всё-то, что показываю. Так что фетч я взаимный поставил, но забираться будут только те эхи, которые присутствуют на станции.

я так и не понял, гейтовать std.hugeping или нет?

и какие эхи ты фетчишь? вообще, какой-нибудь бонлист есть или нет, чтобы понимать, что куда ходит? я уже писал, что и откуда фетчу, надо чтобы все сисопы делились такой информацией.

> Про pipe.2033 -- если создание эхи приведёт к тому что у нас будет две эхи, вместо одной, то я бы этого не хотел. Так что я не то чтобы инициативу не поддерживаю, я считаю что это нужно всем решать станциям.

так я и выносил вопрос на все станции. все станции молчат. pipe.2032 давно не использовалась, а таскать 3500 сообщений туда-сюда из чатовой эхи смысла нет. именно поэтому изначально был обязательный постфикс, чтобы "освежать" эхи а старую инфу уводить в архив.

> Кроме того, твоя нода обычно появляется, потом пропадает. :) Ты создаёшь какие то эхи, потом забываешь. Поэтому я с осторожностью отношусь к идее. :)

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

из лайвовых эх чатилка (лучше 2033, чем 2032), idec.talks как нужная для обмена информацией по самой системе (нужен бонлист!), вопрос только в std.hugeping - там основная жизнь, но это всё-таки блог конкретной станции, конкретного автора. возможно, придётся режим read-only предусмотреть.

а, ты все свои эхи берёшь. тогда я, наверное, поставлю в обменник zx.spectrum и plan.9, в первой даже из 2022 есть сообщения. вдруг кто ходит и не знает, куда на zx.spectrum и plan.9 зайти

ii.51t.ru> и какие эхи ты фетчишь?

https://club.hugeping.ru/list.txt

ii.51t.ru> так я и выносил вопрос на все станции. все станции молчат. pipe.2032 давно не использовалась, а таскать 3500 сообщений туда-сюда из чатовой эхи смысла нет. именно поэтому изначально был обязательный постфикс, чтобы "освежать" эхи а старую инфу уводить в архив.

Сейчас фетч "поумнел" и он адаптивный, то-есть все 3500 сообщений фечнутся только один раз. На сеть нагрузки с моей стороны никакой. В общем, я пока забираю pipe2032.

> хотя у hugeping тоже нет https,

Он есть, просто не принудительный.

ii.51t.ru> вопрос только в std.hugeping - там основная жизнь, но это всё-таки блог конкретной станции, конкретного автора. возможно, придётся режим read-only предусмотреть.

Да, теперь понял. У меня скорее всего запрещено создание статей не от меня в этой эхе, но работает ли это если забор идёт через fetch, я не помню. Я посмотрю, чуть позже.

> Сейчас фетч "поумнел" и он адаптивный, то-есть все 3500 сообщений фечнутся только один раз. На сеть нагрузки с моей стороны никакой. В общем, я пока забираю pipe2032.

ну они всегда один раз забираются. я не понимаю просто смысла держать эху с сообщениями лет за 9, которая просто болталка. такие вещи надо держать в архиве.

просто у нас сейчас в таком случае болталкой стала idec.talks, сиё не очень хорошо :) ладно, буду искать линка на pipe.2033, 3500 сообщений, некоторые из которых мне вообще не нравятся, я хранить не хочу - хочу историю с чистого листа.

> Да, теперь понял. У меня скорее всего запрещено создание статей не от меня в этой эхе, но работает ли это если забор идёт через fetch, я не помню. Я посмотрю, чуть позже.

ясно. не буду гейтовать. буду pipe.2033 рекламировать :)

После некоторых размышлений таки убрал принудительный редирект на https. Теперь работает и так и так, по желанию. Мне не критично, а кому-то может и да.

Заодно зацепил к себе https://ii.51t.ru/ii/. Эхи idec.talks и zx.spectrum. Пусть будет.

>> Хм. Да, это так. Но разве https - это плохо? Первый раз слышу, чтобы были какие-то проблемы.
iiii> Да, есть проблемы. Несовместимость. Поэтому из старых ос на этот сайт не зайти в принципе. Хоть он трижды без javascript и всего остального.

Это, по идее, можно вылечить, обновив сертификаты, которые сто лет как стухли.

>> В любом случае - это всего лишь web-морда станции. И как таковой полезной нагрузки не несёт.
iiii> какая разница, всё остальное тоже работает по https, и нельзя приконнектиться. у меня вон, текстовый клиент гоняется на python 2.4 на debian etch :) к hugeping.tk я могу свободно подключаться, он http

Как будто что-то хорошее :)

+++ Caesium/0.4 RC1

shaos>> Debian Etch это извините на минуточку ОООЧЕНЬ старый дебиян :)
shaos>> Боюсь, что его у вас всяческие трояны, черви и вирусы пронизали вдоль и поперёк...
vvs> О, Господи! Так и Plan 9 тогда пользоваться тоже нельзя? Там про обновления безопасности никто сроду ничего не слыхал. Да и ретрокомпьютинг - тоже. Как там насчёт эмуляторов C64 или амиги? Или калькуляторы TI? Тут прямо рядом эха со старым железом.

Так никто оттуда и не намекает, что надо убирать SSL. Кому надо, те просто ставят проксирующий сервер своими силами и не жужжат.

vvs> Конечно ожидать, что все будут этот антиквариат поддерживать - наивно. Но, учитывая специфику сети idec, вообще-то не так уж и глупо.
vvs> P.S. Извините, что влез не в своё дело, но слишком часто приходится видеть это "а зачем вам всё это надо?". Имеет каждый человек право на свои причуды и интересы. И отнестись к ним с сочувствием или хотя бы с пониманием - ничего ведь не отнимется. У меня самого в углу древний комп стоит, на который ничего новее 2005 года не установишь, а выкинуть жалко

Смотря насколько древний. У меня валяется Compaq Evo N600c начала века. На него прекрасно ставится актуальный Debian. Конечно, работает он не очень шустро, на него бессмысленно ставить современный браузер, но в остальном машинка вполне юзабельная и я за ней периодически с удовольствием сижу. Хотя казалось бы: третий пентиум (ещё и М) да 256 МБ ОЗУ.

+++ Caesium/0.4 RC1

iiii> 1. перепись узлов - кто что гейтует? чё ща модно гейтовать

Ничего.

iiii> 2. давайте сделаем новую межсетевую болталку - pipe.2033? новый год всё таки, а тянуть 3500+ сообщений 9-летней давности про болтание не стоит - лучше в архив :)

А кто тебя заставляет их тянуть? Просто качай последние 100/10/5/1 сообщений и радуйся жизни.

+++ Caesium/0.4 RC1

iiii> или std.hugeping тоже теперь болталка? :)

А было иначе? Каждый волен делать у себя что хочет. Анархия.

+++ Caesium/0.4 RC1

iiii> а где болтаем-то?

В реале.

+++ Caesium/0.4 RC1

iiii> От создания контента - к его провайдингу.
iiii> http://ii.51t.ru
iiii> для старых компьютеров - ок. осталось забить контентом. функциональность "эхи как книги" надо будет вернуть, но переосмыслить под "архив эх". никакого https, никакого javascript и css. проверена работа на win 95 с ie4, на debian woody с netscape navigator и на всём остальном.
iiii> сейчас фетчатся эхи idec.talks и pipe.2033 (пока не существующая) с hugeping.tk, поллинг 5 минут
iiii> описание станции (точнее, софта эхи): http://ii.51t.ru/ii/html/about.html

На NCSA Mosaic 1 работает? Или оставишь жителей Windows 3.11 за бортом?

+++ Caesium/0.4 RC1

iiii> я про то, какие эхи гейтовать: std.hugeping это локальный блог или глобальный?

А в чём принципиальная разница?

+++ Caesium/0.4 RC1