Nastene 0.7 — простая распределённая система сообщений

я видел программки для незаметного размещения текста в картинках с котиками.

Сколько можно поместить в EXIF-метаданные кстати?

Ещё есть rarjpeg.

Сколько можно поместить в EXIF-метаданные кстати?

Обратите внимание,что фотоаппараты нередко в основной jpeg файл запихивают еще и preview низкого разрешения размером в пару десятков килобайтов. Попробовать запихать вместо preview полноразмерную картинку я не пробовал. Или вовсе не картинку.

А в файлах mp3 попадаются встроенные фотографии обложек альбомов,которые приходится удалять чтобы побольше музыки влезало в память всяких портативных плейеров.

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

А еще есть оверлейные сети (yggdrasil,cjdns) которые имеют настолько продвинутые средства автоконфигурации что позволяют поднять прямо IP-канал между двумя компами,находящимися за NAT сотового оператора. Причем у yggdrasil уже вроде бы есть даже клиент под андроид. Также для cjdns заявлена работа прямо поверх «голых» кадров ethernet. Я проверял - оно работает. Значит можно заставить работать поверх любого линка,имитирующего ethernet в смысле передачи кадров,пусть даже и медленной. Надо лишь написать модуль-драйвер в ядро,который со стороны софта будет выглядеть как драйвер сетевой карты. Возможно что и yggdrasil так сможет - я не пробовал.

Кстати,внутри сети yggdrasil вполне себе есть и люди и ресурсы. Только об этом мало знают и говорят,в отличие от tor. Для желающих попробовать и имеющих под рукой Дебиан - пакет лежит тут:

deb http://neilalexander.s3.dualstack.eu-west-.amazonaws.com/deb/ debian yggdrasil

В установке безобиден.

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

С ним не нужно тягаться. Будет лучше если все они останутся, как есть. А рядом свободное и не привлекающее внимание общение для тех, кто «наелся».

Не очень понимаю такое отвращение к бинарным форматам. Есть какие-то аргументы или это чисто личные предпочтения?

Принцип KISS и идеология пермакомпьютинга. Как отмечал даже автор топика, клиент или даже просто фетчер ii можно изготовить, не имея под рукой компилятора и вообще ничего, кроме busybox. Этот протокол будет работать везде, где работает голый TCP. На любой древнятине или мобиле с J2ME или хоть какими-нибудь приложениями. Я вон даже HTTP оверхедом считаю, поэтому в своей ноде и клиенте встроил поддержку фетчинга по Nex/Gopher (по факту в данном контексте запросы там одинаково выглядят).

Вообще разговор в какое-то не то русло пошёл. Стеганография, иггдрасили и прочие AX.25 — это вообще не про эту сеть.

Времена халявных толстых каналов - заканчиваются.

У вас — может быть. Я вне чебурнета. Но объём трафика в ii даже с учётом перегонки бандлов в base64 настолько незначителен, что и GPRS для обмена вполне хватает.

Как вот это должно поджечь пукан цукербергу?

А с чего бы оно вообще должно кому-то поджигать пукан-то?

Чтобы болталка была успешной - она должна реально угрожать пейсбуку.

Каковы критерии «успеха»? Ламерьё плейнтекст всё равно не признаёт, но нужно ли оно здесь?

Так, я не понял одного. Как вот это должно поджечь пукан цукербергу?

опыта тягаться с цукербергом

Откуда взялась пресуппозиция, что такая задача не то что ставится, а вообще кому-то из авторов в голову приходила? По тексту новости этого сказать нельзя, по комментам тоже, по тому, что я вижу в сети про эту ii — тоже. Это же просто очередное типа-фидо для уютненького чатинга между своими. На мой взгляд со странными решениями местами, но почему бы и не быть и такой штуке…

http://ii.blcat.ru/qq/lor.opennet/24ZrIxeup1gAOARJICWz — красота какая… И я так понимаю, оно там так и будет висеть теперь всегда, верно?

Вот поэтому я blcat и не фетчу, только spnet и foxears.

клиент или даже просто фетчер ii можно изготовить, не имея под рукой компилятора и вообще ничего, кроме busybox

А в реальной жизни эта возможность точно будет востребована?

Стеганография, иггдрасили и прочие AX.25 — это вообще не про эту сеть.

Это про отвязку верхнего уровня доставки сообщений от транспорта. Полную отвязку. Поэтому и были упомянуты другие виды транспорта с их особенностями.

Этот протокол будет работать везде, где работает голый TCP.

Вот только TCP умирает на линках где всего лишь процентов 10 пакетов теряются. От того регулярно появляются альтернативы,работающие прямо поверх пакетной(packet switching) сети. Смотрим например на Гугл с его QUIC(RFC9000).

Я вне чебурнета.

Усиление контроля над передачей данных по сетям связи - это общемировое явление. И кстати на первом месте в этом деле - мировой экономический лидер Китай. Попробуйте зайти на какой-нибудь «внутрикитайский» сайт,посмотрите на скорость.Другие развитые страны тоже постепенно подтягиваются. Поэтому разрабатывая средства обмена текстовыми сообщениями это явление надо учитывать. Вон в США принцип сетевой нейтральности был отменен еще в 2017 году. Ну вот провайдер и выделит большую часть канала какому-нибудь CNN или кто там у них является аналогом газеты «Правда»,остальное поделит между гуглами и фейсбуками которые ему заплатят,а для «нецелевого» использования оставит какие-то крохи,да еще и с большой потерей пакетов из-за плохо работающего шейпинга. В том же 17 году в Евросоюзе был принят закон о защите потребителей (Consumer Protection Cooperation),позволяющий блокировать сайты без судебного решения «в целях защиты потребителей». И уже блокируют (например про Каталонию,Косово).

объём трафика в ii даже с учётом перегонки бандлов в base64 настолько незначителен

Я не понимаю с технической точки зрения зачем специально увеличивать объем данных если можно уменьшать? Да, иногда это требуется вынужденно для совместимости с древними протоколами типа как пересылка юникода (который таки бинарный) через электронную почту которая гарантированно пропускает только base64 набор символов,а остальное как повезет. Да, в древние времена упаковка/распаковка была «дорогим» процессом,но те времена уже лет тридцать как прошли.

GPRS для обмена вполне хватает.

GPRS это еще вполне быстро. У меня тут года до 12 только оно и было так что хорошо знаком. А вот если сотовому оператору захочется закрутить шейпер на якобы 64К из-за того что на «безлимитном» 4G-тарифе лимит кончился - то обычно получается такое через что ничего толком не работает. И не из-за скорости,а из-за потерь пакетов и произвольно прыгающей величины задержки. А так-то да, ничуть не соврали - тариф безлимитный,вас не отключили. Но и качать ничего не дают.

Вопрос автору. Или очень плохо смотрели или не нашел. С какой периодичность и как вообще реализована периодичность синхронизации нод? Фоновое задание, которое фетчит ноды по списку раз в N-минут или каким образом?

Как вот это должно поджечь пукан цукербергу?

А зачем? Мы - сами по себе,цукерберг - сам по себе. Вон в IRC люди сидят и никак с цукербергом не пересекаются. В Фидо кстати тоже.

Чтобы болталка была успешной

Сначала надо договориться о критериях оценки успешности. Например предлагаю такой критерий - успешная фильтрация пользователей по IQ и недопущение в сеть личностей у кого он на уровне плинтуса. Наличие входного барьера в виде необходимости осилить чтение документации и сделать как написано - это хорошо,а не плохо. Смотрим на LOR - здесь собрались пользователи Линукса,который этот порог входа имеет. И присутствующим нравится общаться друг с другом потому что у них сходный и достаточно высокий интеллектуальный уровень. И нет, именно программистом для соответствия вышеозначенному критерию быть абсолютно не обязательно. Умение читать и следовать инструкциям - достаточно универсально для самых разных областей деятельности.

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

Ламерьё плейнтекст всё равно не признаёт

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

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

На снрвере есть gzip сжатие. А на диске данные текстовые, а не сквиш или джам какой нибудь

Я мог бы заблеклистить но не буду. На других станциях это заблекличено

Фоновое задание, которое фетчит ноды по списку раз в N-минут

Да

Для экономии трафика на стене 0.7 есть следующие ступеньки, это не часть стандарта но для своего фетчера это можно использовать:

/list.txt?h=1 выдаёт вместо описаний хеши эх. можно хранить этот хэш, и если эха не изменилась, не запрашивать её

/u/e/эха/эха/эха?sf=хэш/хэш/хэш - если один из хэшей найден в любой из эх, то выдаётся список только из хэшей, которые за ним. то есть, берём последний хэш из каждой фетчимой эхи и запрашиаем

прописка в клиенте вместо server/u/ урла server/lim/200/u/ запрашивает только последние 200 сообщений вместо всех, в любом случае. при фетче раз в день 200 это разумное число, но можно по статистической эхе, которая пишет статистику раз в неделю, подобрать себе своё.

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

У тебя /x/features не реализован?

Нет

Так его ж уже выкинули из стандарта. Из нового только слайсы оставили.

Это нестандарт. Стандарт — ты знаешь, какой.

Интересно почему, удобно же когда нода сразу сообщает что умеет.

Потому что в новой версии стандарта нет расширений как таковых.

Надо бы и себе прикрутить. Или не надо. Пока думаю. Сейчас отдача по HTTP и голому TCP почти идентична. А так придётся Accept-Encoding находить и анализировать.

Ну и правильно сказал мели-оратор выше: гзипить то, что до этого расширяется в base64… так себе удовольствие.

Да, в древние времена упаковка/распаковка была «дорогим» процессом,но те времена уже лет тридцать как прошли.

Кому как. Мне важно, чтобы и железо 30-летней давности в строю оставалось, например.

Не имеется, объясни что ты ответил, какая была мысль.

Ну это довольно большие тексты. Но да, я у себя на ноде сделал сжатие. Причём мог его сделать на уровне Traefik, но решил автономно в самом tiid.

Каким образом бинарные форматы типа squish или jam в фидо что-то экономило? А бандлы для посылания - они тоже все были zip-ом пожато. Ну так и сейчас есть gzip сжатие в http.

На сервере есть gzip сжатие.

Вот это хорошо и правильно. Потому что текстовые данные хорошо поддаются упаковке.

на диске данные текстовые, а не сквиш или джам какой нибудь

При хранении нынче упаковка действительно не особо нужна - место на дисках большое и дешевое. А вот для повышения эффективности обработки вместо сквиша и джама надо бы задействовать какую-нибудь лёгкую СУБД. Желательно такую,которая позволяет хранить записи переменной длины без добивания их пробелами до единожы установленного максимума как древние «реляционные» СУДБ из времен доса. Текстовые сообщения по определению имеют разную длину.

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

выкинули из стандарта.

А можно полюбопытствовать - кто/где пишет сам стандарт протокола? Есть какой-то комитет/рабочая группа/ответственный координатор?

удобно же когда нода сразу сообщает что умеет.

Полностью согласен! Это есть даже в весьма древнем протоколе POP3. Странно почему нет здесь. Кстати,в Фидо у мэйлеров были некие «флаги» которые передавались при хэндшейке и публиковались в нодлистах. На практике обычно использовались для предотвращения файлового (не почтового) трафика так как он сильно забивал каналы.

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

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

гзипить то, что до этого расширяется в base64… так себе удовольствие.

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

придётся Accept-Encoding находить и анализировать.

Accept-Encoding это хорошо и правильно,а «находить и анализировать» сейчас не ресурсозатратно,не на 286 процессорах работаем. Зато явное указание кодировки позволит не пихать юникод тогда, когда он не нужен,например при переписке на языках имеющих общепринятые однобайные кодировки, и не увеличивать чуть ли не вдвое объем передаваемых данных.

Go, Traefik, ...

Тянет вас на смузи прям. Не лучше ли сделать протокол файловый? Что бы можно было запустить апач, натравить на директорию, и стандартизировать пути по которым хранятся данные. Для ReadOnly достаточно будет иметь сервер который умеет отдавать файлы, все.

Тогда останется только описать куда можно загружать файлы, и откуда получать. И это автоматически перестанет зависеть от HTTP, потому что передавать и получать файлы можно по ftp, sftp, http.

А тут накрутили сложные ID, какие то base64, парсинг путей в url. То что в распределенной сети какая то нода может своими хешами все сломать это вообще рофл.

HTTP кстати и так умеет отдавать данные со смещением, или например указывать дату, в текущем протоколе многое дублируется ... софтверно? Не знаю как назвать. Не хватило ему человека, который бы сел, подумал, изучил бы то на чем он строится основательно, и сделал реально минималистичный дизайн. Хотя возможно была задумка в том, что бы сделать его похожим на текущие ограниченные из за легаси протоколы, не совсем красивые, тогда удалось.

/list.txt?h=1 выдаёт вместо описаний хеши эх. можно хранить этот хэш, и если эха не изменилась, не запрашивать её

В HTTP можно обозначить дату изменения контента, это еще один пример каких то странных ... действий. Это вообще хорошая практика что бы заново браузер не перекачивал ресурсы.

Мне важно, чтобы и железо 30-летней давности в строю оставалось, например.

Идейно согласен с вами насчет поддержки всякого разного в том числе и маломощного железа. Но в моем случае не потому что железо древнее,а потому что всякое «одноплатное» и даже микроконтроллерное,мало электричества кушающее.

Вот для этого и нужны в стандарте и features и accept-encoding тоже. В софте,работающем на железе 30-летней давности вы и модный нынче юникод без ухищрений не отобразите на экране и не введете с клавиатуры. У мелких экранов,использующихся с микроконтроллерами - тоже в абсолютном большинстве случаев один байт== один символ,и возможность загрузить некоторое количество битмапов для тех символов которых во встроенном знакогенераторе нет. При этом стандарт не будет жестко ограничивать тех кто имеет доступ к толстому каналу и мощному железу - они смогут создать например конференцию для общения иероглифами на китайском.

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

Поэтому в features должно быть указано поддерживается ли упаковка(и какая),а в accept-encoding - указано в какой кодировке созданы сообщения.

По сути каждый щас делает свою ii. И у каждого свой стандарт. У меня моя базовая реализация. Но пока всё это более менее совместимо.

Каким образом бинарные форматы типа squish или jam в фидо что-то экономило?

Это были самодельные аналоги СУБД. Они экономили время обработки на узле. Навалите в один каталог несколько тысяч мелких текстовых файлов и посмотрите как это будет подтормаживать даже сейчас в линуксе. А в те времена в досе оно вообще колом вставало уже при нескольких сотнях файлов. Соответственно,сортировка хранящихся таким образом сообщений становилась невозможной. Вот бинарные форматы хранения и придумали потому что свободно доступных готовых СУБД в то время мне не попадалось. Они появились позже (например dbVista).

Кстати, такой формат хранения сообщений в фидошном софте «исторически» поддерживался - в виде каталога с файлами *.msg. Иногда использовался для обработки личной почты(напускания на нее скриптов),которой по определению намного меньше чем сообщений в конференциях.

Ну так и сейчас есть gzip сжатие в http.

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

Но я считаю нужно сразу полноценную прикручивать

Тогда надо сначала определиться с критериями «полноценности». Вот один из критериев я указал - хранение строковых данных в виде записей переменной длины,без добивания пробелами до предустановленного при создании базы максимума. Второй назвали вы - хранение двоичных данных(и тоже переменного размера). Надо подумать что еще нужно от базы. Я например могу упомянуть поддержку отношения один-к-многим на уровне формата СУБД.. Для этого в продвинутых коммерческих базах (например MDBS/Titanium) хранятся внутренние указатели,создаваемые в момент помещения объекта в базу. А при запросе нет как такового чтения подряд и сравнения данных,выдается то на что указывают уже существующие указатели. В качестве примера - в базе создаем набор «календарь»,куда каждый день помещаем новый элемент,содержащий дату. И при помещении сообщений в этот день - привязываем их к этому элементу. Потом когда нужно их выбрать за этот день - уже ничего искать не надо,они вытаскиваются по созданным указателям. В качестве аналогии - висящие на гвоздиках связки ключей вместо кучи ключей с бирками,в которой надо рыться,бирки читать и сравнивать прочитенное с искомым. По-научному это называется network-model database (к сетям связи слово network тут отношения не имеет). Доступную в исходниках одну такую базу знаю - называлась «db.star»,даже с ней работал,но это было пару десятков лет назад,причем исходники были еще более старые. Видел еще FramerD такого же типа но не щупал. А вообще на тему всяких разных базоданных есть такой сайт https://dbdb.io - там их очень много перечисленно очень разных.

для нормального поиска хотя бы.

В текстовой почте «нормальный поиск» - это по словам/сочетаниям в тексте сообщения. Создать какой-то индекс заранее тут не получится. Проиндексировать можно только служебные поля подчиняющиеся определенным правилам.

Более того, для текстов полезен «нечеткий» поиск например по алгоритму Левенштейна. Это особенно актуально для языков типа русского где есть многочисленные формы одного и того же слова.

Не лучше ли сделать протокол файловый?

Так html-страница это тоже вобщем-то файл,даже если сгенерирована на стороне сервера скриптом «на лету». Это я к тому,что понятие «файловый протокол» в нынешних условиях слишком неопределенно и отделение контента от среды распространения не так просто как сходу кажется. Хотя с тем что контент должен быть максимально отвязан от способов его передачи - я безусловно согласен. Как и с тем что должна быть возможность передачи простым копированием файлов(даже не через сеть) если такая надобность где-то когда-то возникнет.

Рассуждения на эту тему полезно почитать у Vitus Wagner применительно к проекту Cheshirenet,он в Живом Журнале немало про это написал. Там он не один, над этим думали люди куда умнее и опытнее чем я.

накрутили сложные ID

Уникальный идентификатор у сообщения в любом случае должен быть чтобы можно было выполнять дедупликацию на узлах при наличии более чем одного пути от узла к узлу. Что кстати плохо умело Фидо.

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

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

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

Изначально всё и было файловым (но через http), без base64, были только /e и /m. Но на практике оказалось, что брать сообщения по одному это медленно и печально, поэтому и появились бандлы. base64 хорош тем, что это просто одна строка, и есть однозначный разделитель сообщений - это новая строка. Всё это вырабатывалось практикой.

В HTTP можно обозначить дату изменения контента

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

Кстати, реализации всяких протоколов взаимодействия чего-то с чем-то удобно делать на основе теории «конечных автоматов»(finite state machine) c использование вот этого инструмента: https://imatix-legacy.github.io/libero/lrdoc.htm Под линуксом собирается и работает,лично проверено. Делает экономичный код и помогает избегать ошибок в логике работы автомата.

В HTTP можно обозначить дату изменения контента, это еще один пример каких то странных ... действий. Это вообще хорошая практика что бы заново браузер не перекачивал ресурсы.

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

Спустя более 10 лет я смотрю и думаю, что всё сделал грамотно.

Вы лично разрабатывали дизайн? Это где-то обсуждалось? Если да - можно ли где-то почитать те обсуждения? Увы, по слову «ii» ничего нагуглить невозможно в виду неудачно выбранного названия/аббревиатуры именно с точки зрения поиска.