AL> Потому что документация описывает IDEC.

Возникает вопрос: её здесь вообще кто-нибудь ещё читал?

Первый же абзац в https://github.com/idec-net/new-docs/blob/master/extensions.md:

> Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii. Многие из них реализовывать совсем необязательно.

И далее чуть ниже пункт «Список эхоконференций», описывающий GET /list.txt.

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

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

AL> Слишком много оверхеда.

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

ahamai> ну 16 норм, но потом бы я шаги увеличивал, там 64, потом 256 потом все сообщения. или вообще 16 если чё-то не хватает то забирать все. думаю, такие триггеры будут редко срабатывать.

Сделал у себя с шагом кратности 12 (потом 24, 48 и т.д.), чтобы в самом распространённом случае можно было даже с tgi и подобных за один запрос стянуть.

ahamai> стоп. -16:1 - это взять один хэш? а почему не -16:16? или я что-то не понял.

Ну в том алгоритме главная идея состоит в экономии трафика, полагаю. Сначала пробный запрос с -16:1, а потом, если в базе есть сообщение, то можно и -16:16.

revoltech> жирный HTTP

Почему жирный-то? Почти натуральный plaintext. Куда меньше?

tuple> Почему жирный-то? Почти натуральный plaintext. Куда меньше?

Потому что статусы и заголовки, например. См. как в гофере или нексе сделано: строка запроса — ответ, всё.

Пример запроса по Nex: echo /u/e/idec.talks | nc station.domain 1900

Ничего, кроме нетката, телнета или подобного, в основе не требуется.

Отвечаю заранее на вопрос «а как же постить»? Как в NPS — на другой порт:

cat <<EOF | nc station.domain 1915
/u/point
[auth_string]
[base64_message]
.
EOF

Вот тут уж действительно меньше некуда.

tuple> Почему жирный-то? Почти натуральный plaintext. Куда меньше?

Потому что статусы и заголовки, например. См. как в гофере или нексе сделано: строка запроса — ответ, всё.

Пример запроса по Nex: echo /u/e/idec.talks | nc station.domain 1900

Ничего, кроме нетката, телнета или подобного, в основе не требуется.

Отвечаю заранее на вопрос «а как же постить»? Как в NPS — на другой порт:

cat <<EOF | nc station.domain 1915
/u/point
[auth_string]
[base64_message]
.
EOF

Вот тут уж действительно меньше некуда.

P.S. Что-то не смог запостить на sprinternet, переслал на tgi.

Меньше это Gopher или Nex овер телнет :)

shaos> Меньше это Gopher или Nex овер телнет :)

Да не обязательно овер телнет, но да, суть в том, чтобы не относящихся непосредственно к ii метаданных меньше гонять. Здесь и так сообщения в base64 оборачиваются, что уже 4/3 от полезной нагрузки...

Думаю о создании станции lor2ii, которая будет медленно и печально собирать сообщения с текущих тем лора.

Без веб интерфейса, либо с веб интерфейсом только для пойнтов.

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

Сообщения с лора тэгировать чем-то типо lorlink/урл-на-сообщение.

Вернуть http-клиента и ориентировать на всё это.

Кому-нибудь такое интересно?

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

Го дропнем base64

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

> Пример запроса по Nex: echo /u/e/idec.talks | nc station.domain 1900

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

doesnm> Го дропнем base64

Для /u/m не получится без глубинного перелопачивания самого формата бандла, а вот для /u/point, в принципе, легко.

Кто-нибудь скажет, какие проблемы решает base64 именно при постинге, каких не решает тот же самый x-www-form-urlencoded, в который сообщение по итогу всё равно заворачивается?

> Кто-нибудь скажет, какие проблемы решает base64 именно при постинге, каких не решает тот же самый x-www-form-urlencoded, в который сообщение по итогу всё равно заворачивается?

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

ahamai> остаётся вопрос в том, как узнать, докачалось ли всё или оборвалось.

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

Для эх: сравнить количество айдишников с тем, которое мы запрашиваем, и удостовериться в том, что все скачанные айдишники имеют 20 символов.

> Для сообщений: посчитать хэш, преобразовать в айдишник по алгоритму и сравнить с тем айдишником, который в начале строки в бандле.
> Для эх: сравнить количество айдишников с тем, которое мы запрашиваем, и удостовериться в том, что все скачанные айдишники имеют 20 символов.

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

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

Ну вот, кстати, я начал просто отслеживать хэши сообщений вместе с айдишниками, и после перефетча (со всего, кроме spline-online) из 17614 сообщений 14067 оказались с корректными айдишниками (сравнивал по функции LOWER() в базе, так что нюансы с A-z не важны), а вот 3547 сообщений имеют айдишники, которые вообще описанному в доках хэшу не соответствуют. Вопрос: был/имеется ещё какой-то алгоритм хэширования или что за фигня там происходит? А потом коллизиям удивляются.

Статистика сообщений с левыми ID по эхам (не считая spline):

sqlite> SELECT DISTINCT `echoname`, COUNT(`id`) FROM `msg` WHERE LOWER(`msgid`) != LOWER(`content_id`) GROUP BY `echoname`;
blcat.local|1
develop.16|17
game.rogue.14|39
idec.talks|322
idec.test|13
ii.stat|7
linux.14|341
lit.14|4
lor-opennet.17|1
lor.gold|31
music.14|34
ping.local|4
pipe.2032|1123
plan.9|2
python.15|8
retro.talks|27
ru.humor.14|35
spnet.stats|1
std.club|1241
std.favorites|2
std.game|139
std.hugeping|68
std.hugeping.micro|2
std.prog|36
std.rein|1
std.tech|47
zx.spectrum|1

Я три недели назад уже всё посчитал TfXUY2nZ1vmjAsQhgfsK

Многие узлы допускают редактирование сообщений без изменения хеша и возможно какие-то изначально неправильно хеш реализовывали (т.к. в спеке небыло эталонных сообщений для сверки как это обычно принято) и потом некоторые ботоэхи с какого-то момента стали сломанные: 6kCluOlO0AG8aOvgvRPr

Основные stakeholders (текущий мейнтейнер стандарта с одной стороны и первоначальный создатель с другой) в один голос говорят, что сам алгоритм не важен - главное чтобы msgid был уникальным, поэтому я и отпочковал от ii/IDEC свой strengthened вариант iii т.к. мне для будущих экспериментов важно, чтобы хэш сходился всегда :)

iii.nizya

А вообще было бы сильно прикольнее, если бы история хеширования в ii пошла по другому пути ;)

vTYmGKHeCyvLZ3BV2NoP

Потому что как оказалось сам Создатель упоминал такой способ в комментах на лоре на этапе создания технологии ;)

[линк с пруфом пока не могут отыскать]

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

лор уже не торт...

ну оборвалось и оборвалось - в следующий раз дозаберётся, не?

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

> вот 3547 сообщений имеют айдишники, которые вообще описанному в доках хэшу не соответствуют. Вопрос: был/имеется ещё какой-то алгоритм хэширования или что за фигня там происходит? А потом коллизиям удивляются.

во всяких босфорах и улиссах длина хэша была где 8, где 12 символов, поэтому для гейтования в ii до 20 добавлялось что-то типа "bosforbosfor" (а в гейтованых месагах вроде где-то полный хэш был, не помню уже, как это всё между сетями летало, но летало успешно.

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

> лор уже не торт...

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

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

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

сейчас теневое "что-то" смысла имеет мало, потому что мало пользователей. нужна, наверное, новая инфраструктура и интересный контент, хотя бы r/o. по второму я продолжу голдификацию, как минимум :)

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

О - нашёл!!!

https://www.linux.org.ru/forum/talks/10258332?cid=10258568

> return base64.urlsafe_b64encode( hashlib.sha256(s).digest() ).replace('-',").replace('_',")[:20]
> мощно я задвинул? внушает? :)
> feofil (06.03.14 09:41:46 PST) автор топика

Мне интересно в какой момент в реплейсах появились 'A' и 'z'? ;)

Если верить гиту, то 1 апреля 2014 года (в момент создания репы):

a45cdfa3 (user 2014-04-01 19:19:03 +1100 16) def hsh(s):
a45cdfa3 (user 2014-04-01 19:19:03 +1100 17) return base64.urlsafe_b64encode( hashlib.sha256(s).digest() ).replace('-','A').replace('_','z')[:20]

Но я знаю, что первый релиз ii был в начале мерта 2014 года...

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

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

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 - если хеш не сошёлся, то мессага битая или подменянная - т.е. одновременно проверяем и целостоность данных, и подлинность, причём не добавляя никаких лишних сущностей!

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

ahamai> а вообще, у нас сейчас фанаты технологии, но нет фанатов распределённости и локального хранения.

Есть. Поэтому все подвижки в сторону «выкачивать не всё и не отовсюду» предлагаю отметать, как вредоносные.

В идеале — дайте мне возможность скачать все эхи одним файлом, а дальше уж разберусь локально, что с этим делать.

Если хочешь ознакомиться с процессом проектирования и реализации 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!) рядом с айдишником у таких сообщений.

Тут опять хаос с топиками. Я буду всегда отвечать в топике "Стандарт" для порядка. Появились такие мысли:

1) Хеши в list.txt мне не нравятся потому, что list.txt на данный момент не является обязательным и выглядит как просто информационный. Почему бы, если уж делать хеши эх, не сделать что-то вроде /u/h/ ? Использование хешей именно в list.txt да ещё и в позициях дескрипшена - выглядит как хак.

2) x/c считаю должен отражать реальный счётчик сообщений для просмотра "на лету" совместно со слайсами. Либо да, убирать и слайсы и x/c

3) Редактирование сообщений это не только "в последний момент" поменять что-то. Это вполне себе необходимая вещь, если мы рассматриваем idec не просто как болталку. Например, есть статья я её редактирую. Ссылка на статью должна быть постоянной... Для контента это важно.

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

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

Ну что то вроде: IIIIIIIIIIIIIIIIrrrr. I - хеш, rrrr - закодированный номер изменений. А может и не закодированный а прямо: 1t0CZs5lzqVxsoht0001

Да, хеш тут условный, это просто ID сообщения, не обязан совпадать при перерасчёте (он и не будет).

hugeping> Да, хеш тут условный, это просто ID сообщения, не обязан совпадать при перерасчёте (он и не будет).

Да, если это прям режет глаз. То можно делать не хеш сообщения. Любой алгоритм генерации uuid. Например, хеш от времени в мс + имя системы...

P.S. Edited: 2024-10-27 08:08:47

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

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

>> ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1
>> Что это должно делать?
shaos> Возвращать хеши эх вместо дескрипшина:
shaos> ====
shaos> idec.talks:1699:hsh/wHerzeypz8j1d8tviSRh
shaos> blcat.local:6:hsh/kAIYYMMc5DWK0FJhsW64
shaos> retro.talks:62:hsh/bahvlLwAzK2ArGHvXWat
shaos> bot.habr.rss:157:hsh/dwqigyrvKJQURxn88dwq
shaos> lor.opennet:127:hsh/12hqQwDfGoRXxD5ILIfj
shaos> ru.humor.14:817:hsh/4GxIyw2R69G75LlwnG0r
shaos> lor.gold:47:hsh/f4BQcuDnC7LTwzQHZ42k
shaos> linux.14:919:hsh/k8AiOJGrmMm1Q30W0Stz
shaos> ====

Какую проблему это решает?

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

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).

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

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

ahamai> что с лор.опеннетом делать будем?

Чинить. Займусь сегодня.

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

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

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

ahamai> Думаю о создании станции lor2ii, которая будет медленно и печально собирать сообщения с текущих тем лора.
ahamai> Без веб интерфейса, либо с веб интерфейсом только для пойнтов.
ahamai> При этом пойнты могут комментировать эти сообщения и они будут доступны другим пойнтам. Получится этакий OverLor.
ahamai> Сообщения с лора тэгировать чем-то типо lorlink/урл-на-сообщение.
ahamai> Вернуть http-клиента и ориентировать на всё это.
ahamai> Кому-нибудь такое интересно?

А чем текущая эха не устраивает? Зачем аж отдельная станция для отдельной эхи?

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

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

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

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

ahamai>> а вообще, у нас сейчас фанаты технологии, но нет фанатов распределённости и локального хранения.
revoltech> Есть. Поэтому все подвижки в сторону «выкачивать не всё и не отовсюду» предлагаю отметать, как вредоносные.
revoltech> В идеале — дайте мне возможность скачать все эхи одним файлом, а дальше уж разберусь локально, что с этим делать.

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

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

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

Почему?

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

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

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

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

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

тогда msgid будет решать только задачу идентификации сообщения уникальным образом и больше никакую другую, а в ii/IDEC с самого начала (и до сих пор) msgid потенциально пригоден для решения аж 3 задач:
- идентификация уникального сообщения (с высокой степенью защитой от коллизий);
- проверка целостности сообщения (что сообщение не повредилось при передаче от узла где сообщение было принято к узлу где оно читается);
- проверка подлинности сообщения (что зловредные индивиддуумы не подменили источник, приёмник, время, тему ну и до кучи тело сообщения на своё при передаче).

Проблему большого траффика когда тянется всё подряд без оглядки

shaos> тогда msgid будет решать только задачу идентификации сообщения уникальным образом и больше никакую другую

Собственно, для этого msgid и нужен. Если ты хочешь на него нагрузить что-то ещё "для красоты", то да, не будет работать редактирование, как минимум. Я понял, что у нас тут разные стремления. Но может быть лучше сделать базовую технологию обмена, а подлинность целостность - это отдельно? Без возможности редактирования сообщений мне ii-go бесполезен. Я ведь использую его для создания заметок. У меня даже резюме лежит на нём. :)

Починил сабж.

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

shaos> Проблему большого траффика когда тянется всё подряд без оглядки

Эту проблему прекрасно решают слайсы. Посмотри на трафик от Петра. Ну и не лучше ли вынести это в отдельный ендпоинт вместо хаченья list.txt?

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

Работает - получил кучу новых сообщений :)

> shaos> Проблему большого траффика когда тянется всё подряд без оглядки
> Эту проблему прекрасно решают слайсы.

Ну будут решать ещё лучше, когда необходимость дёргания будет решаться не по количеству сообщений в эхе, а по хешу т.к. например в ii-php количество сообщений это реальное количество сообщений в эхе и в /list.txt, и в /x/c (т.е. оно может не только расти, но и уменьшатся, и даже оставаться неизменным когда убавилось столько же сообщений сколько и добавилось, но этого никто не заметил т.к. сравнивают номера).

> Ну и не лучше ли вынести это в отдельный ендпоинт вместо хаченья list.txt?

Обычный /list.txt останется как был, а для хешей я пока делаю на выбор:
/list.txt?h=1
/listhsh.txt
и по аналогии с /x/c будет /x/h но вместо количества сообщений там будут хеши

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

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

shaos> А зачем отдельно, если оно уже есть - никаких новых полей ненадо т.к. всё уже прям тут - бери и используй как говорится :)

Я там выше сообщение написал про то как можно сделать редактирование. sZbskcy7huzEVJlsSDIF

То-есть, если считаем msgid настоящим хешем, так уже не сделать.

Мне интереснее, конечно, эту проблему решить.

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

Поддерживаю

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

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

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

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

shaos>> тогда msgid будет решать только задачу идентификации сообщения уникальным образом и больше никакую другую
hugeping> Собственно, для этого msgid и нужен. Если ты хочешь на него нагрузить что-то ещё "для красоты", то да, не будет работать редактирование, как минимум. Я понял, что у нас тут разные стремления. Но может быть лучше сделать базовую технологию обмена, а подлинность целостность - это отдельно? Без возможности редактирования сообщений мне ii-go бесполезен. Я ведь использую его для создания заметок. У меня даже резюме лежит на нём. :)

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

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

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

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

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

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

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

AL> Почему?

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

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

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

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

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

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

Да, я там сделал попытку предложить что-то (как мысленный эксперимент): sZbskcy7huzEVJlsSDIF

Вроде в таком варианте новые версии сообщения будут распространяться.

hugeping> Да, я там сделал попытку предложить что-то (как мысленный эксперимент): sZbskcy7huzEVJlsSDIF

hugeping> Вроде в таком варианте новые версии сообщения будут распространяться.

То-есть, основные мысли:
1) если видим что что-то на станции в этой эхе поменялось - всегда делаем полный фетч (адаптивный фетч в топку)
2) во время фетча учитываем не только id, но и ревизию сообщения. Всё это для простоты может быть частью msgid (но может и не быть)

>> shaos> Проблему большого траффика когда тянется всё подряд без оглядки
>> Эту проблему прекрасно решают слайсы.
shaos> Ну будут решать ещё лучше, когда необходимость дёргания будет решаться не по количеству сообщений в эхе, а по хешу т.к. например в ii-php количество сообщений это реальное количество сообщений в эхе и в /list.txt, и в /x/c (т.е. оно может не только расти, но и уменьшатся, и даже оставаться неизменным когда убавилось столько же сообщений сколько и добавилось, но этого никто не заметил т.к. сравнивают номера).

Для слайсов количество вообще не обязательно.

>> Ну и не лучше ли вынести это в отдельный ендпоинт вместо хаченья list.txt?
shaos> Обычный /list.txt останется как был, а для хешей я пока делаю на выбор:
shaos> /list.txt?h=1
shaos> /listhsh.txt
shaos> и по аналогии с /x/c будет /x/h но вместо количества сообщений там будут хеши

А какой смысл в этом многообразии?

+++ Caesium/0.4 RC1

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

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

> Не в первый и, думаю, не в последний раз, кого-то посещают мысли об нецелевом использовании идентификаторов.

И каждый раз приходит суровый Andrew Lobanov и ставит фантазёров на место :)

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

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

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

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

Вот и проверку подлинности можно поверх и сборку. :)

Кроме шуток, да, я думал о "сбоку". Но тогда, получается, мы должны сначала получить id сообщений эхи. А потом, ревизии но в полном соответствии с id. И тогда непонятно вообще зачем 1й вызов? Ну то-есть оно может быть сбоку, да, но ответ всё равно будет включать в себя и id и rev. Ну например:

JOHemYNZRC8Uo9QwAYQU:1

Мне кажется редактирование сообщений неплохо в "базе" иметь, всё-таки.

> т.к. оно будет нужно только для очень особенного типа сообщений

Понимаешь, у всех у нас своё "особенное" понимание. Я считаю что ii следует понимать просто как распространение текстовых сообщений. Что ИМЕННО в этих текстовых сообщениях - не наше дело. Кто-то считает, что это "мессенджер", кто-то - форум, а кто-то в блогах пишет....

hugeping> JOHemYNZRC8Uo9QwAYQU:1

Тогда такой вариант. Всё как было, но если сообщение отредактировано то в u/e/ придёт вот такая строка с доп ревизией (после :). Эту ревизию можно зашивать в теги самого сообщения и хранить в базе.

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

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

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

> Для слайсов количество вообще не обязательно.

т.е. ты предлагаешь каждый раз дёргать каждую эху с параметрами -1:1 чисто на всякий случай? ;)

> А какой смысл в этом многообразии?

эдакий A/B тест - кто что больше будет использовать, то прилипшим к стене и останется :)

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

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

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

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

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

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

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

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

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

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

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

cat <<EOF | nc station.domain 1915
/u/point
[auth_string]
[base64_message]
.
EOF

hugeping>> JOHemYNZRC8Uo9QwAYQU:1

hugeping> Тогда такой вариант. Всё как было, но если сообщение отредактировано то в u/e/ придёт вот такая строка с доп ревизией (после :). Эту ревизию можно зашивать в теги самого сообщения и хранить в базе.

Гм. На практике, редактирование сообщения - добавление новой записи в бд. Так что тут не все так просто.

hugeping>>> JOHemYNZRC8Uo9QwAYQU:1

hugeping>> Тогда такой вариант. Всё как было, но если сообщение отредактировано то в u/e/ придёт вот такая строка с доп ревизией (после :). Эту ревизию можно зашивать в теги самого сообщения и хранить в базе.

hugeping> Гм. На практике, редактирование сообщения - добавление новой записи в бд. Так что тут не все так просто.

Да нет, вроде нормально... Редактирование сообщения - это выпуск msgid с новым полем rev. Это на усмотрение ноды как именно отразить это в бд. В ii-go это дописывание новой инфы которая "перекрывает" старую. В sql это может быть тупо запись в бд. Требовать чтобы запись добавилась в конец запроса u/e наверное нецелесообразно.

Всё сделал - проверяй :)
/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 и забираем ответ

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

shaos> а почему бы и не добавлять также как в хттп?
shaos>
shaos> /u/point/pauth/tmsg
shaos>
shaos> \n и забираем ответ
shaos>
shaos> или там ограничение на длину запроса?...

Нет, как раз в нексе в спецификации ([1]) ограничения на запрос нет, можно и так и по тому же порту. По NPS ([2]) идиоматичнее просто.

Но, в принципе, да, можно и портом 1900 по предложенному тобой варианту обойтись, наверное.

[1]: https://nightfall.city/nex/info/specification.txt
[2]: https://nightfall.city/nps/info/form.txt

IDEC протокол нужен только для обсуждения IDEC-реализаций.

> Понимаешь, у всех у нас своё "особенное" понимание. Я считаю что ii следует понимать просто как распространение текстовых сообщений. Что ИМЕННО в этих текстовых сообщениях - не наше дело. Кто-то считает, что это "мессенджер", кто-то - форум, а кто-то в блогах пишет....

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

Всё сделал - проверяй :)

shaos> Ну вот поэтому все редакции "особых" сообщений должны идти как отдельные записи в списке хешей

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

tuple> IDEC протокол нужен только для обсуждения IDEC-реализаций.

Sad but true. Хотя мне, наверное, было бы достаточно корректно работающего ii. Просто по ходу дела выяснилось, что это ближе к мифу или оксюморону.

revoltech> Sad but true. Хотя мне, наверное, было бы достаточно корректно работающего ii. Просто по ходу дела выяснилось, что это ближе к мифу или оксюморону.

Драматизировать тоже не стоит. Я помню, когда делал для микроконтроллера клиента gemini тоже сталкивался с "разночтением" стандарта. Точно сейчас не помню, но кажется это было связано с относительными ссылками или что-то вроде того. Но это не мешает gemini быть живым.

Да, x/c похоже мало кто соблюдает в буквальном смысле. Но в остальном, я не вижу особых отклонений от стандарта. Ваши желания того, чтобы msgid совпадал с хешем сообщений -- никогда не было требованием. Как правильно тут писал Рома, иногда мы даже заполняли недостающую часть "заполнялками" итд. Хеш - это просто естественный способ создать уникальный идентификатор.

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

hugeping> Ну, хочется видеть idec другим -- никто не мешает разрабатывать свои варианты...

Жаль при этом происходит дробление сообществ на всё более мелкие части...

hugeping>> Ну, хочется видеть idec другим -- никто не мешает разрабатывать свои варианты...

tuple> Жаль при этом происходит дробление сообществ на всё более мелкие части...

Примерно как с gemini. Одному не понравился tls, второму -- отсутствие динамики... И понеслась. Тем не менее большая часть людей осталась на gemini. Я тоже на нём остался, и не жалею. Но тут как бы дело личное. С idec же "сообщество" -- слишком громко сказано. :) Но опять же, сомневаюсь что обмен по ii/idec кто-то из текущих нод будет выпиливать.

hugeping> Драматизировать тоже не стоит.

А кто владелец репы idec-net? Он здесь есть? Он способен привести документацию в адекватный и недвузначно трактуемый вид?

* Раз GET /list.txt всегда был в ii, надо его описать в базе, а не в расширениях.
* Раз айдишники в виде волшебного шопопало до сих пор проскакивают, надо указать, что алгоритм их генерации рекомендован. И указать правила замены на A-z, которые все ноды между собой понимали бы.
* Раз счётчики де-факто могут убывать, надо убрать ту приписку «Важно: параметр неубывающий».

Ну и так далее. В общем, привести теоретическую базу к тому, как оно всё на самом деле функционирует. Чтобы новые авторы клиентов (а тем более серверов) не путались в этих трёх соснах как минимум.

Я могу выложить свою (англоязычную) доку где-то здесь. Либо в english.talks, либо в какуюто новую эху. Там сейчас базовый ii без расширений по факту. Есть желание привлечь нексовских, гоферистов, джеминистов и прочих активистов смолнета к этой теме, но для начала неплохо было бы довести документацию до удобоваримого вида без разночтений.

revoltech> * Раз GET /list.txt всегда был в ii, надо его описать в базе, а не в расширениях.

В стандарте написано что это расширение. Значит - расширение. Было оно в ii или нет, не важно. Так как стандарт описывает idec. Сейчас ноды написаны так, что декларируют list.txt в расширениях. Для обмена list.txt не является обязательным. Так что не вижу причин переписывать стандарт.

revoltech> * Раз айдишники в виде волшебного шопопало до сих пор проскакивают, надо указать, что алгоритм их генерации рекомендован. И указать правила замены на A-z, которые все ноды между собой понимали бы.

Рекомендованный алгоритм описан в стандарте. Но проверять на его соответствие -- в стандарте такого нет. В стандарте указаны не A-z, а A-Z. Но, подумав, не могу сказать что это тоже требует изменения стандарта. Ну, алгоритм отличается немного от ii, и что?

revoltech> * Раз счётчики де-факто могут убывать, надо убрать ту приписку «Важно: параметр неубывающий».

С счётчиками я не знаю что делать. Возможно, надо признать что этот стандарт большинство не исполняет и всё.

revoltech> Ну и так далее.

А что ещё? Ну, переводы строк?

revoltech> А кто владелец репы idec-net? Он здесь есть? Он способен привести документацию в адекватный и недвузначно трактуемый вид?

Да, я уже предлагал: Z9zSZaq0u1HH47ud8PEz . В ответах предложили поднять на Github Pages на Jekyll, который там есть.

Странно отрабатывает сортировка в профиле https://club.hugeping.ru/from/btimofeev/7 . Если промотать вниз, то там видно два сообщения, которые написаны в 2020-м году, а выше идут из 2024-го.

...
zbWTwhBmxuHrWWhRnGRA 2024-10-07 10:46:58
А затем неожиданно:
0DUjGr0R7GbWZGgCXM8R
0MJApBaONSBNUIwlxcI9

hugeping> В стандарте написано что это расширение. Значит - расширение. Было оно в ii или нет, не важно.

В extensions.md: написано: «Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii.» — и там перечислен в том числе /list.txt. Это читается так, как будто IDEC от ii отличается в том числе /list.txt, т.е. в ii его не было.

hugeping> Рекомендованный алгоритм описан в стандарте. Но проверять на его соответствие -- в стандарте такого нет. В стандарте указаны не A-z, а A-Z. Но, подумав, не могу сказать что это тоже требует изменения стандарта. Ну, алгоритм отличается немного от ii, и что?

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

hugeping> С счётчиками я не знаю что делать. Возможно, надо признать что этот стандарт большинство не исполняет и всё.

Как и многое другое оттуда же.

hugeping> А что ещё? Ну, переводы строк?

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

revoltech> А кто владелец репы idec-net? Он здесь есть? Он способен привести документацию в адекватный и недвузначно трактуемый вид?

В организации значатся двое: difrex (у него была станция, сейчас её нет, давно не видно), btimofeev пару недель назад с ним общались в сети. Зовём его, пусть делает новый репозиторий для Github Pages, туда можно напосылать PR'ов с исправлениями. Но сначала просто полностью скопировать https://github.com/idec-net/new-docs , затем переделать его под Jekyll (чтобы github pages заработал), а только затем посылать всякие исправления и улучшения.

tuple> Странно отрабатывает сортировка в профиле https://club.hugeping.ru/from/btimofeev/7 . Если промотать вниз, то там видно два сообщения, которые написаны в 2020-м году, а выше идут из 2024-го.

Это следствие того, что эху retro.talks создали только что. Я удалил у себя oldpc и зафетчил retro.talks заново. В итоге, сообщения пришли как бы "только что". Для станции они - новые.

ii-go в данном случае показывает сообщения по мере их прихода на сервер, а не в соответствии с датой создания автором. Так что, получили то, что получили...