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

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

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

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

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

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

Я три недели назад уже всё посчитал 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 - будет покомпактнее чуток

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

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

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

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