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 настоящим хешем, так уже не сделать.

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

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

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

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

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

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

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

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

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

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

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

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

AL> Почему?

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

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

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

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

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

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

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

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

hugeping> Да, я там сделал попытку предложить что-то (как мысленный эксперимент): ii://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? Он здесь есть? Он способен привести документацию в адекватный и недвузначно трактуемый вид?

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

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

...
ii://zbWTwhBmxuHrWWhRnGRA 2024-10-07 10:46:58
А затем неожиданно:
ii://0DUjGr0R7GbWZGgCXM8R
ii://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 в данном случае показывает сообщения по мере их прихода на сервер, а не в соответствии с датой создания автором. Так что, получили то, что получили...

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

В ii не было просто самого механизма расширений. В любом случае, смысл менять стандарт я не вижу. Иначе придётся требовать наличия list.txt как обязательного компонента.

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

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

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

Что именно? x/c - да. msgid - нет, нет такого требования. Хеши и не должны совпадать. Но ты пишешь "многое другое". Где пруфы?

Мне кажется ты совсем не читаешь то, что я тебе пишу. Прекращаю это бессмысленное занятие. :)

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

На самом деле с переводами тоже не все просто. Я когда написал фильтр получил ещё несколько сообщений с \r где-то в теле. Я стал их резать при записи в БД. Кстати, ещё один источник того, что хеш может отличаться. В общем, idec и ii не требуют совпадений при пересчёте хеша. Пересчёт вообще не должен нигде проводиться.

>> Не в первый и, думаю, не в последний раз, кого-то посещают мысли об нецелевом использовании идентификаторов.
shaos> И каждый раз приходит суровый Andrew Lobanov и ставит фантазёров на место :)

Да я что? Я ничего. Так, погулять вышел. Просто надо сильно всех загонять в рамки и часть узлов просто отвалится.

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