Даже пример реализации пролетал :)

https://github.com/gk11-ru/ii-elp/blob/master/run.py#L24

Сегодня-завтра попробую у себя добавить

Плюс listhsh.txt как алиас того же самого плюс /x/h который как /x/c но вместо номеров - хеши хешей

>ahamai> предлагаю включить в стандарт возможность исполнения list.txt?h=1

>Что это должно делать?

Возвращать хеши эх вместо дескрипшина:

idec.talks:1699:hsh/wHerzeypz8j1d8tviSRh
blcat.local:6:hsh/kAIYYMMc5DWK0FJhsW64
retro.talks:62:hsh/bahvlLwAzK2ArGHvXWat
bot.habr.rss:157:hsh/dwqigyrvKJQURxn88dwq
lor.opennet:127:hsh/12hqQwDfGoRXxD5ILIfj
ru.humor.14:817:hsh/4GxIyw2R69G75LlwnG0r
lor.gold:47:hsh/f4BQcuDnC7LTwzQHZ42k
linux.14:919:hsh/k8AiOJGrmMm1Q30W0Stz

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

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

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

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

ii://iii.nizya

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

ii://vTYmGKHeCyvLZ3BV2NoP

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

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

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

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

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

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

О - нашёл!!!

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

Если хочешь ознакомиться с процессом проектирования и реализации 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. Возможность пользоваться разными транспортами это большой плюс - даже если речь идёт о текстовых терминалах или дискетах - кто знает на каком железе нам придётся работать в постапокалиптическом мире...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Echoareas
────────────────────────
idec.talks...........468 ██████████████████████████████████████████████████▒▒▒▒▒▒▒▒▒
bot.slashdot.........146 ██████████████████████████████████████████████████▒▒
lor.opennet...........61 ██████████████████████████████████████████████████▒
lor.gold..............47 ███████████████████████████████████████████████
idec.test.............35 ███████████████████████████████████
bot.habr.rss..........25 █████████████████████████
linux.14..............18 ██████████████████
bash.rss..............11 ███████████
spnet.stats............7 ███████
ifhub.club.............4 ████
iii.nizya..............2 ██
ii.stat................1 █
bot.antropogenezru.rss.1 █
────────────────────────
Total                826

Почему-то ii-php иногда не ловит ==== правильно и не отображает моноширинный текст - надо искать багу...

Да, ботов тут дофига :)

idec.talks...........468

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

Полуневдимые эхи :)

Я только вчера заметил, что пропустил букву в первом слове сабжа ;)

Полуневидимые имелось ввиду конечно же :)

Сообщения раздваиваются
Сообщения раздваиваются

Ну можно написать, что принимаем любой текст, но сохраняем только с \n (и сервер считает хеш уже по сконверченному тексту)

Проехали
Проехали

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

Что значит усложнит? Валидацию входящего в любом случае надо делать - вот вместе с валидацией и делать конверсию если надо

Это всё делается в одной функции

А где /x/features ?

Может их в виде /features.txt организовать? Всё равно это по сути статический текст…

Это ты у меня второй после гугла получился за предыдущие сутки? ;)

TOP10 VISITORS:

[1] Google point=10 web=1096 up=43.2MB (32%) <--- Google
[2] 145.224.100.x point=116 web=10 up=41.8MB (31%) <--- 145.224.100.x (5/hr) <<<<<<<<<<<<<<
[3] 176.109.111.x point=47 web=0 up=16.3MB (12%) <--- tavern (2/hr)
[4] 217.197.116.x point=142 web=0 up=12.0MB (9%) <--- blackcat (6/hr)
[5] Facebook point=0 web=401 up=7.6MB (5%)
[6] 92.63.98.x point=69 web=0 up=4.9MB (3%) <--- tgi (3/hr)
[7] 95.165.9.x point=125 web=2 up=3.1MB (2%) <--- ping (5/hr)
[8] 24.130.121.x point=37 web=9 up=3.0MB (2%) <--- spnet (2/hr)
[9] DataForSeoBot point=1 web=16 up=0.4MB (<1%) <--- DataForSeoBot
[10] 104.128.67.x point=0 web=3 up=0.1MB (<1%)

TOTAL TRAFFIC: 133MB

Нода на Tcl? ;)

...
145.224.100.164 - - [21/Oct/2024:05:27:24 -0700] "GET /iii/u/m/HaYwRbvCz0HDMhN2IrOU HTTP/1.1" 200 225 "-" "Mozilla/5.0 (Unix; U; Linux 6.6.56-0-rpi) http/2.9.8 Tcl/8.6.15"
145.224.100.164 - - [21/Oct/2024:05:27:24 -0700] "GET /iii/u/m/ymc21433dohplAzblytS HTTP/1.1" 200 225 "-" "Mozilla/5.0 (Unix; U; Linux 6.6.56-0-rpi) http/2.9.8 Tcl/8.6.15"
145.224.100.164 - - [21/Oct/2024:05:27:25 -0700] "GET /iii/u/m/bGF8asq7me3B7nMzrKRq HTTP/1.1" 200 225 "-" "Mozilla/5.0 (Unix; U; Linux 6.6.56-0-rpi) http/2.9.8 Tcl/8.6.15"
145.224.100.164 - - [21/Oct/2024:05:27:25 -0700] "GET /iii/u/m/XrdTe37AHd3m1aY3Oaw6 HTTP/1.1" 200 225 "-" "Mozilla/5.0 (Unix; U; Linux 6.6.56-0-rpi) http/2.9.8 Tcl/8.6.15"
145.224.100.164 - - [21/Oct/2024:05:27:25 -0700] "GET /iii/u/m/AhS5Q6mYGHzZzNdx9Lf3 HTTP/1.1" 200 225 "-" "Mozilla/5.0 (Unix; U; Linux 6.6.56-0-rpi) http/2.9.8 Tcl/8.6.15"
...

видо-видо :)

Надо наверное ii://idec.test в обязательном порядке протянуть на все ноды, чтобы народ тестовые сообщения в ii://idec.talks не слал...

> Для тестовых сообщений лучше пользоваться эхой ii://idec.test.

Она не везде есть - на ping и tgi например её нету...

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

Надо будет себе пометку на полях сделать...

> Пардон за трафик, тестировал туда-сюда.

Ну гугл тебе обогнать всё равно не удалось, так что ок ;)

Кстати формат ответа неправильный:

ii/ok/repto/test
idec.talks
1729606618
revoltech
tgi,15
All
test

тест ответа

тут вместо repto/test надо писать repto/msgid где msgid является идентификатором сообщения на которое отвечаем...

Первоначальное сообщение было вот это: ii://xXufIMsKzDC1FFJ0Dh1g

Второй тест ответа вроде ок

А как тогда проверить, что оно нормально фетчится между нодами? ;)