shaos> Многие узлы допускают редактирование сообщений без изменения хеша

Что есть маразм by design. Хэш — он на то и хэш, чтобы отражать изменения в содержимом, иначе на... зачем он нужен?

shaos> base64 нужен т.к. позволяет ii транспорту работать в том числе и по последовательным 7-битным каналам - через COM порт там или прямо в тексте е-мейлов без mime кодирования (которое также в текст по сути)

Интересно девки пляшут. То у нас без HTTP(S) никуда, то семибитные каналы через ком. Надо бы уж определиться.

В почте это сделано просто ради кучи легаси-софта из 1980-х, а первая версия ii появилась в 2014 году, когда весь нормальный мир давно перешёл на UTF-8. Для реальных семибитных каналов есть вполне себе другие решения, которые любой восьмибитный трафик через себя туннелируют. Но для 99% населения, умеющего и желающего общаться только по TCP/IP, это реальный оверхед.

И да, ранее описанный подход мог бы применяться и к POST /u/point:

POST /u/point
Content-Type: text/plain; charset=utf-8

[auth_str]
[message]
.

shaos> Я для себя хочу попробовать новый вызов /u/n с ascii85+ вместо base64 - будет покомпактнее чуток

Вот это уж точно не упростит жизнь никому. Всем придётся пилить свою реализацию этого.

shaos> > мощно я задвинул? внушает? :)

Спасибо, с изначальным подходом к проектированию ii всё ясно.

shaos> в старой "болталке с девочками" hc.51 почти все хеши вида 7lwguohJulissiiuliss и mPJSJAI3ulissiiuliss а в других местах видимо просто отредактированные сообщения без изменения msgid...

И с реализациями тоже.

shaos> вот поэтому и нужны железобетонные хеши в качестве msgid - если хеш не сошёлся, то мессага битая или подменянная - т.е. одновременно проверяем и целостоность данных, и подлинность, причём не добавляя никаких лишних сущностей!

Полностью согласен.

Если хочешь ознакомиться с процессом проектирования и реализации ii в более широком смысле, то можно прочитать следующие статьи на лоре (и комментарии к ним):

- https://www.linux.org.ru/forum/general/10247460
- https://www.linux.org.ru/forum/talks/10258332
- https://www.linux.org.ru/forum/talks/10267735
- https://www.linux.org.ru/news/opensource/10319264
- https://www.linux.org.ru/news/opensource/10534550
- https://www.linux.org.ru/forum/general/10532800

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

P.S. Возможность пользоваться разными транспортами это большой плюс - даже если речь идёт о текстовых терминалах или дискетах - кто знает на каком железе нам придётся работать в постапокалиптическом мире...

ahamai> как отличить "конец передачи" от "оборвалось", чтобы не запарсить что не то

В том же гофере (как минимум при выдаче гофермапов) наши деды решили это гениальным способом: точкой на конце. Просто точка без ничего на отдельной строке после текста (CRLF . CRLF). Здесь в спецификации я вижу, что содержимое эхи заканчивается пустой строкой (LF LF). Но такое может возникнуть и в результате преждевременного закрытия соединения. А вот точка там не возникнет сама по себе никогда.

> Что есть маразм by design. Хэш — он на то и хэш

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

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

P.S. хеш с подменой двух небуквоциферных символов в хеше на A и z по идее можно и оставить как рудимент прошлого т.к. оно даёт возможность по статистическому анализу букв используемых среди N хешей со 100% уверенностью сказать, что они пришли из ii/IDEC-сетей ;)

В сухом остатке _на данный момент_ имеем следующее:

* айдишник сообщения не может использоваться для проверки целостности, поскольку битые есть даже среди относительно новых (за 2024);
* длина файла с айдишниками эхи не настолько велика, чтобы заморачиваться со слайсами, а локально накладные расходы они увеличивают существенно (наверное, откачу логику tiifetch до простого выкачивания эх);
* на данный момент докачанность списка айдишников можно проверять наличием \n\n в конце, но в теории можно придумать сценарий, в котором это не сработает, пусть и крайне маловероятный.

> айдишник сообщения не может использоваться для проверки целостности, поскольку битые есть даже среди относительно новых (за 2024);

ну почему не может? может

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

а на старых "классических" эхах несходящиеся сообщения можно продолжать показывать помечая специальным символом...

> длина файла с айдишниками эхи не настолько велика

не будем забывать про слабые ретроплатформы где память 64КБ и меньше

например список хешей lor-openned.17 весит 299КБ и они точно не влезут в память ретрокомпьютера целиком

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

shaos> не будем забывать про слабые ретроплатформы где память 64КБ и меньше

А на такие платформы уже портировали Tcl 8.6, sqlite3 и прочее? Я же конкретно насчёт своего клиента/фетчера говорю. Там-то понятное дело, что другие подходы ко всему нужны.

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

Да я не против того, чтобы в стандарте они оставались.

shaos> а на старых "классических" эхах несходящиеся сообщения можно продолжать показывать помечая специальным символом...

Ну я у себя теперь просто делаю приписку (ID hash mismatch!) рядом с айдишником у таких сообщений.

А ну если ты только про своего клиента, то ок

Главное если надумаешь делать свой узел, чтобы он умел слайсы ;)

AL>> Потому что документация описывает IDEC.
revoltech> Возникает вопрос: её здесь вообще кто-нибудь ещё читал?

И даже писал.

revoltech> Первый же абзац в https://github.com/idec-net/new-docs/blob/master/extensions.md:
>> Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii. Многие из них реализовывать совсем необязательно.
revoltech> И далее чуть ниже пункт «Список эхоконференций», описывающий GET /list.txt.

Бывает.

revoltech> То есть документация называет GET /list.txt одним из основных отличий IDEC от ii. А мне тут рассказывают, что «это было в ii». Ну так документацию тогда поправьте, если это было в ii, а не эксклюзив IDEC.

Зачем?

revoltech> Я вот вместе с кодобазой tii начал вести свой ii-doc.txt, где описываю только реализованные в tii части протокола. И с пометкой IDEC extension у меня там только GET /x/features и один из вариантов /u/e, который со слайсами.

Молодец.

AL>> Слишком много оверхеда.
revoltech> Слишком много сарказма. Если уж позиционируем протокол как альтернативу щитвебу и если уж спецификация не обязывает именно к HTTP(S)-транспорту (опять гитхаб процитировать?), то вполне логично принимать и предложения по более легковесным протоколам вместо упора в жирный HTTP(S).

Ну то, как Вы позиционируете протокол, мы узнали только что. Сидим вот, думаем что дальше с этим делать.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

tuple>> Почему жирный-то? Почти натуральный plaintext. Куда меньше?
revoltech> Потому что статусы и заголовки, например. См. как в гофере или нексе сделано: строка запроса — ответ, всё.
revoltech> Пример запроса по Nex: echo /u/e/idec.talks | nc station.domain 1900
revoltech> Ничего, кроме нетката, телнета или подобного, в основе не требуется.
revoltech> Отвечаю заранее на вопрос «а как же постить»? Как в NPS — на другой порт:
revoltech> cat < revoltech> /u/point
revoltech> [auth_string]
revoltech> [base64_message]
revoltech> .
revoltech> EOF
revoltech> Вот тут уж действительно меньше некуда.

Ну так пиши транспорт какой тебе больше нравится. Стандарт не завязан на HTTP как таковой. Был опыт обмена и по FTP. Просто HTTP всех устраивает, так как дёшево и просто с точки зрения использования и уже так сложилось.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos>>> Меньше это Gopher или Nex овер телнет :)
revoltech>> Да не обязательно овер телнет, но да, суть в том, чтобы не относящихся непосредственно к ii метаданных меньше гонять. Здесь и так сообщения в base64 оборачиваются, что уже 4/3 от полезной нагрузки...
doesnm> Го дропнем base64

Предлагаю отказаться от HTTP, base64, списков и переделать всё на актбаунды.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos>> base64 нужен т.к. позволяет ii транспорту работать в том числе и по последовательным 7-битным каналам - через COM порт там или прямо в тексте е-мейлов без mime кодирования (которое также в текст по сути)
revoltech> Интересно девки пляшут. То у нас без HTTP(S) никуда, то семибитные каналы через ком. Надо бы уж определиться.

Мы и определились и отказались от максимализма.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

ahamai>> как отличить "конец передачи" от "оборвалось", чтобы не запарсить что не то
revoltech> В том же гофере (как минимум при выдаче гофермапов) наши деды решили это гениальным способом: точкой на конце. Просто точка без ничего на отдельной строке после текста (CRLF . CRLF). Здесь в спецификации я вижу, что содержимое эхи заканчивается пустой строкой (LF LF). Но такое может возникнуть и в результате преждевременного закрытия соединения. А вот точка там не возникнет сама по себе никогда.

Почему?

revoltech> * длина файла с айдишниками эхи не настолько велика, чтобы заморачиваться со слайсами, а локально накладные расходы они увеличивают существенно (наверное, откачу логику tiifetch до простого выкачивания эх);

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

revoltech> * на данный момент докачанность списка айдишников можно проверять наличием \n\n в конце, но в теории можно придумать сценарий, в котором это не сработает, пусть и крайне маловероятный.

Просто сделай новый транспорт. Там уже можно считать хоть точку в конце, хоть любую другую метку как частью протокола транспортного уровня, а не ii/idec.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos>>>> Меньше это Gopher или Nex овер телнет :)
revoltech>>> Да не обязательно овер телнет, но да, суть в том, чтобы не относящихся непосредственно к ii метаданных меньше гонять. Здесь и так сообщения в base64 оборачиваются, что уже 4/3 от полезной нагрузки...
doesnm>> Го дропнем base64
AL> Предлагаю отказаться от HTTP, base64, списков и переделать всё на актбаунды.

Поддерживаю

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

AL> Ты бы хоть иногда из крупных городов куда-то выезжал. Слайсы позволяют мне использовать IDEC в деревне, где интернет настолько нестабилен, что без слайсов можно просто забить на эти ваши эхи и общение в них.

У моего мобильного оператора бывают такие потери что даже к ирке не подключается
об HTTP и даже IDEC речи уже не идет

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

AL> Ты бы хоть иногда из крупных городов куда-то выезжал. Слайсы позволяют мне использовать IDEC в деревне, где интернет настолько нестабилен, что без слайсов можно просто забить на эти ваши эхи и общение в них.

Внезапно, я сам в селе. Интернет спутниковый.

По поводу слайсов на своём клиенте пока окончательно не решил. В принципе, для тестирования симулировать медленный трафик довольно легко: достаточно делать фетч через torsocks.

AL> Просто сделай новый транспорт. Там уже можно считать хоть точку в конце, хоть любую другую метку как частью протокола транспортного уровня, а не ii/idec.

Сделаю. Клиент tii (а конкретнее — компонент tiifetch), собственно, уже поддерживает выкачивание по гоферу, нексу, спартану и джемини. Не на чем только это всё потестить покамест.

AL> Почему?

А кто её передаст, точку эту?

AL> Для этого вообще никакой протокол не нужен. Просто паковать всю станцию в бандл и сразу отдавать клиенту. Ну и что что там несколько сотен мегабайт? Зато всё и клиент сам разберётся что ему надо, а что нет.

Вот для первого выкачивания такая опция не помешала бы. Иначе ему придётся качать те же несколько сотен мегабайт, но маленькими фрагментами.

AL> Мы и определились и отказались от максимализма.

Вместе с минимализмом.

AL>> Ты бы хоть иногда из крупных городов куда-то выезжал. Слайсы позволяют мне использовать IDEC в деревне, где интернет настолько нестабилен, что без слайсов можно просто забить на эти ваши эхи и общение в них.
revoltech> Внезапно, я сам в селе. Интернет спутниковый.

Это что-то на богатом.

AL>> Просто сделай новый транспорт. Там уже можно считать хоть точку в конце, хоть любую другую метку как частью протокола транспортного уровня, а не ii/idec.
revoltech> Сделаю. Клиент tii (а конкретнее — компонент tiifetch), собственно, уже поддерживает выкачивание по гоферу, нексу, спартану и джемини. Не на чем только это всё потестить покамест.

Твой клиент не работает с твоей нодой?

AL>> Почему?
revoltech> А кто её передаст, точку эту?

Твоя нода на новом транспорте?

AL>> Для этого вообще никакой протокол не нужен. Просто паковать всю станцию в бандл и сразу отдавать клиенту. Ну и что что там несколько сотен мегабайт? Зато всё и клиент сам разберётся что ему надо, а что нет.
revoltech> Вот для первого выкачивания такая опция не помешала бы. Иначе ему придётся качать те же несколько сотен мегабайт, но маленькими фрагментами.

Что повышает надёжность передачи на нестабильном канале.

AL>> Мы и определились и отказались от максимализма.
revoltech> Вместе с минимализмом.

Всё так. От крайностей одни неприятности.

+++ Caesium/0.4 RC1

doesnm>>> Го дропнем base64
AL>> Предлагаю отказаться от HTTP, base64, списков и переделать всё на актбаунды.
doesnm> Поддерживаю

FTN у нас уже есть.

+++ Caesium/0.4 RC1

опиши подробнее как по нексу планиуешь работать - я подниму сервачок :)

Да чо уж там - давайте распечатывать эхи на листах A4 и рассылать бумажной почтой...

дык у него ещё нету ноды - тока клиент :)

AL> FTN у нас уже есть.

Сделать гейт в FTN

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

AL> Твой клиент не работает с твоей нодой?

Моей ноды ещё не существует.

AL> Что повышает надёжность передачи на нестабильном канале.

Каким образом, если проверка целостности по msgid, как мы выяснили, идёт лесом, а проверка целостности самого списка в эхе сейчас вообще отсутствует?

Ну то есть давай смоделируем ситуацию — обрыв соединения при фетче эхи. Этот обрыв может произойти во время:

1) скачивания списка айдишников в эхе (GET /u/e),
2) скачивания бандла (GET /u/m).

В случае номер 1, если обрыв произошёл до последнего известного нам айдишника, мы не знаем, что там между ними (последним известным нам и тем, где произошёл обрыв), поэтому всё равно придётся запрашивать тот же список заново, независимо от размера.

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

И это ещё с допущением, что само соединение установлено успешно. А чем нестабильнее канал, тем дольше устанавливается соединение. И накладные расходы на кучу мелких запросов в этом случае ещё сильнее влияют.

shaos> опиши подробнее как по нексу планиуешь работать - я подниму сервачок :)

Ну геты с порта 1900 точно так же, как в хттп (просто путь в сокет, \n и забираем ответ), а посты по порту 1915 — каноничная NPS-форма такова:

cat < /u/point
[auth_string]
[base64_message]
.
EOF

Всё сделал - проверяй :)
/list.txt остался как был
/list.txt?h=1 подставляет hsh/хэш вместо дескрипшинов и имеет "алиас" /listhsh.txt
ну и /x/h/echo.1/echo.2 по аналогии с /x/c/echo.1/echo.2 сдедал, например

> curl https://sprinternet.io/iii/x/h/retro.talks/idec.talks
retro.talks:mWbHlTgoAaE1IaEoubCR
idec.talks:4dBW6db3TdOmYzbdZAg5

тут без префикса hsh/

> ну и /x/h/echo.1/echo.2 по аналогии с /x/c/echo.1/echo.2 сдедал, например
> ====
> > curl https://sprinternet.io/iii/x/h/retro.talks/idec.talks
> retro.talks:mWbHlTgoAaE1IaEoubCR
> idec.talks:4dBW6db3TdOmYzbdZAg5
> ====

После того как предыдущее сообщение добавилось стало так :)

retro.talks:mWbHlTgoAaE1IaEoubCR
idec.talks:KCAVqaCJCot0ByQVlWg5

а почему бы и не добавлять также как в хттп?

/u/point/pauth/tmsg

\n и забираем ответ

или там ограничение на длину запроса?...