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

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 и ставит фантазёров на место :)

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

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

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

Вот и повод написать ноду :)

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

AL>> FTN у нас уже есть.
doesnm> Сделать гейт в FTN

Смысла нет :)

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

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

Да. Не вижу проблемы. Разве что подключения платные и их приходится экономить :)

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

Ну тоже вариант. Но на нашей выборке не сработает, скорее всего. Делай как удобнее будет тебе и всего делов :)

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

AL>> Твой клиент не работает с твоей нодой?
revoltech> Моей ноды ещё не существует.

Повод написать :)

AL>> Что повышает надёжность передачи на нестабильном канале.
revoltech> Каким образом, если проверка целостности по msgid, как мы выяснили, идёт лесом, а проверка целостности самого списка в эхе сейчас вообще отсутствует?
revoltech> Ну то есть давай смоделируем ситуацию — обрыв соединения при фетче эхи. Этот обрыв может произойти во время:
revoltech> 1) скачивания списка айдишников в эхе (GET /u/e),
revoltech> 2) скачивания бандла (GET /u/m).
revoltech> В случае номер 1, если обрыв произошёл до последнего известного нам айдишника, мы не знаем, что там между ними (последним известным нам и тем, где произошёл обрыв), поэтому всё равно придётся запрашивать тот же список заново, независимо от размера.
revoltech> В случае номер 2, который на слабом канале критичнее, мы сравниваем список полученных сообщений со списком запрошенных и при несоответствии оных просто перекачиваем с последнего полученного (т.к. его тело могло быть выкачано не полностью). Изначальный размер бандла при этом значения также не имеет.

При этом, если вернулось не 200, то всё идёт лесом до следующего раза.

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

На нестабильном канале выкачать мелкие бандлы более вероятное событие, чем выкачать всё одним бандлом. По крайней мере так показала практика.

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

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

Можем обсуждать что угодно. Но все предпочитают обсуждать технологию :)

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

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

IDEC на 100% совместим с ii-0.3. Пользуйся и радуйся жизни.

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

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

Потому что все хотят менять стандарт или обвешивать его расширениями вместо того, чтобы просто пользоваться :)

Девять лет жили с текущим стандартом и тут все занемогли с него.

PS: Моё сообщение с темой "Стандарт" было на серьёзных щах, но всем пофиг. Только Петр откликнулся. Раз обсуждения нет, буду считать, что все согласны. Как появится свободное время, допилю новую ноду (тупо не хватает времени доделать некоторые мелочи) и релизну новый стандарт. И придётся с ним жить :)

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

hugeping>> Драматизировать тоже не стоит.
revoltech> А кто владелец репы idec-net? Он здесь есть? Он способен привести документацию в адекватный и недвузначно трактуемый вид?
revoltech> * Раз GET /list.txt всегда был в ii, надо его описать в базе, а не в расширениях.

Вообще не будет расширений. Будет один стандарт и всё. Расширения на совести людей, их реализующих останутся.

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

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

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

Это не важно. В новом стандарте счётчиков не будет.

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

Ну новый стандарт будет компактный и простой.

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

Жди и всё будет. У меня сейчас не очень простой период в жизни в плане свободного времени.

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

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

А по факту это всё ни на что не влияет и работает без проблем.

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

Вот ты дотошный без особого смысла :)

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

Переводы строк могут быть какими угодно. Символ возврата каретки ни на что не влияет.

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

Так, кажется я понял что выносит мне мозг.

Сообщение wCtCSY0AQJBPZgD7zwYS от revoltech с subj: Re: Стандарт
Поле repto указывает на: rgxK6d4FLFZpuzawHltM с subj: Re: Неожиданное наблюдение

Зачем так делать? :)

AL> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики, оставить только e/, m/, u/e (со слайсами), u/m, u/point, u/push, list.txt, blacklist.txt. Остальное выпилить нафиг.

А ты знаешь, подумал... Вообще, мне нравится. Без x/c можно жить, тем более если list.txt в базе будет.

hugeping> Зачем так делать? :)

А началось это кажется здесь: wCtCSY0AQJBPZgD7zwYS
И здесь: 0Lo8T5IAlUzzV0A2pgzy

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

AL> Повод написать :)

Напишу. С нексом и слайсами. :) Пока на стадии проектирования.

AL> При этом, если вернулось не 200, то всё идёт лесом до следующего раза.

Если вернулось не 200 (имеется в виду ведь хттпшный 200?), то мы в самом начале понимаем, что что-то не то, и размер бандла снова-таки значения не имеет.

AL> Переводы строк могут быть какими угодно. Символ возврата каретки ни на что не влияет.

У меня на клиенте не влияет, а у пинга (вроде) на ноде с ними были проблемы.
Но вообще если уж под старину подстраиваться (семибитные каналы и всё такое), то у всех подобных протоколов де-факто стандартом является CRLF.

AL> Ну новый стандарт будет компактный и простой.

Это хорошо. Ждём-с.

AL> Жди и всё будет. У меня сейчас не очень простой период в жизни в плане свободного времени.

Понимаю, сам вот только недавно из отпуска вышел.

hugeping> Зачем так делать? :)

Сам же просил все связанные со стандартом вещи начать тегировать как ответы на сабж «Стандарт». Или нет?

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

Этого пока ничего не надо делать. На днях рожу новый документ, от него и будем плясать.

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

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

Придётся. Раз уж мы тут шатаем то, что есть, то пошатаем и это. Бойтесь :)

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

Сейчас всё нормально. Так и оставим по сути.

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

Голословность как дух времени :)

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

Вообще, надо забыть что это хеш по своему происхождению и постараться вспомнить, что это msgid. Единственная его роль, единственное назначение.

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

revoltech> Сам же просил все связанные со стандартом вещи начать тегировать как ответы на сабж «Стандарт». Или нет?

Ага, теперь понял откуда это. Дело в том, что топики отслеживаются по цепочке repto, а не по subj. Ну, главное теперь я понял, что это не баг.

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

shaos>> дык у него ещё нету ноды - тока клиент :)
AL> Вот и повод написать ноду :)

Может и мне что нибудь написать. Хотя это скорее всего будет очередной проект в /projects который я подзаброшу из-за лени или какого-то затыка и когда-то давно вернусь

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

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 иногда не ловит ==== правильно и не отображает моноширинный текст - надо искать багу...

AL>> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики, оставить только e/, m/, u/e (со слайсами), u/m, u/point, u/push, list.txt, blacklist.txt. Остальное выпилить нафиг.
hugeping> А ты знаешь, подумал... Вообще, мне нравится. Без x/c можно жить, тем более если list.txt в базе будет.

В list.txt счётчик может убывать.

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

Ох уж эти боты. Зачем они в idec? Есть же RSS и его ридеры.

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

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

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

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

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

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

tuple> Ох уж эти боты. Зачем они в idec? Есть же RSS и его ридеры.

Ты так говоришь, как будто кто-то заставляет тебя подписываться или тянуть эти эхи к себе.

PS: А как в RSS-ридере обсудить с участниками сети что-то? :)

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

tuple> Ох уж эти боты. Зачем они в idec? Есть же RSS и его ридеры.

Ты так говоришь, как будто кто-то заставляет тебя подписываться или тянуть эти эхи к себе.

PS: А как в RSS-ридере обсудить с участниками сети что-то? :)

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

Накинул приблизительный черновик стандарта.

http://s.spline-online.ru/idec.html

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

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

tuple>> Ох уж эти боты. Зачем они в idec? Есть же RSS и его ридеры.
AL> Ты так говоришь, как будто кто-то заставляет тебя подписываться или тянуть эти эхи к себе.
AL> PS: А как в RSS-ридере обсудить с участниками сети что-то? :)

Похоже от тебя пришло 2 одинаковых сообщения: paG6r6FDOTURdMLwfObS и AFI7XFZL9kmtNGAUieKP

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

AL> Накинул приблизительный черновик стандарта.
AL> http://s.spline-online.ru/idec.html
AL> Просьба посмотреть на предмет неоднозначностей и непонятностей. Постарался учесть всё, что мы тут обсуждали.

Отличия от ii только в имени эх? Просто на глаз по памяти ничего другого не заметил

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

AL> Накинул приблизительный черновик стандарта.
AL>
AL> http://s.spline-online.ru/idec.html
AL>
AL> Просьба посмотреть на предмет неоднозначностей и непонятностей. Постарался учесть всё, что мы тут обсуждали.

Выглядит неплохо. Но несколько моментов:

1) было бы неплохо уточнить символ переноса строки;
2) было бы неплохо уточнить для непосвящённых, что такое аплинки и даунлинки;
3) в старом стандарте указано, что для постинга именно через GET /u/point поле tmsg должно быть закодировано не просто в Base64, а в Base64-urlsafe. В новом стандарте это требование убирается или как?

tuple>>> Ох уж эти боты. Зачем они в idec? Есть же RSS и его ридеры.
AL>> Ты так говоришь, как будто кто-то заставляет тебя подписываться или тянуть эти эхи к себе.
AL>> PS: А как в RSS-ридере обсудить с участниками сети что-то? :)
doesnm> Похоже от тебя пришло 2 одинаковых сообщения: paG6r6FDOTURdMLwfObS и AFI7XFZL9kmtNGAUieKP

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

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

AL>> Накинул приблизительный черновик стандарта.
AL>> http://s.spline-online.ru/idec.html
AL>> Просьба посмотреть на предмет неоднозначностей и непонятностей. Постарался учесть всё, что мы тут обсуждали.
doesnm> Отличия от ii только в имени эх? Просто на глаз по памяти ничего другого не заметил

Имена эх ничем не отличаются от ii-шных. Там ничем они не ограничивались фактически. Так что только слайсами отличается. Остальное шелуха :)

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

Прокинул на таверну std.rein и retro.talks

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

doesnm> Отличия от ii только в имени эх?

И в слайсах.

AL>> Накинул приблизительный черновик стандарта.
AL>>
AL>> http://s.spline-online.ru/idec.html
AL>>
AL>> Просьба посмотреть на предмет неоднозначностей и непонятностей. Постарался учесть всё, что мы тут обсуждали.
revoltech> Выглядит неплохо. Но несколько моментов:
revoltech> 1) было бы неплохо уточнить символ переноса строки;

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

revoltech> 2) было бы неплохо уточнить для непосвящённых, что такое аплинки и даунлинки;

Я думаю, что надо сделать словарик. Но не хочу пихать его непосредственно в стандарт.

revoltech> 3) в старом стандарте указано, что для постинга именно через GET /u/point поле tmsg должно быть закодировано не просто в Base64, а в Base64-urlsafe. В новом стандарте это требование убирается или как?

Безоговорочно принимается. Требование остаётся.

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

doesnm>> Отличия от ii только в имени эх?
revoltech> И в слайсах.

Может я слепой, но по ссылке не нашел упоминания слайсов

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

doesnm>>> Отличия от ii только в имени эх?
revoltech>> И в слайсах.
doesnm> Может я слепой, но по ссылке не нашел упоминания слайсов

2.3 /u/e/

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

AL> Всё ещё не считаю это задачей стандарта. Мы передаём текст. Любой. Хотя, если большинство согласится, что нам нужно это стандартизировать, соглашусь.

А как же интероперабельность? Вот, допустим, человек решил написать клиента под старый Макинтош. Очень старый, ещё на процессоре архитектуры 68k, где ещё MacTCP отдельным пакетом шёл. Знаешь, какой на тех макосях тогда был стандартный символ перевода строки? Не LF и даже не CRLF, а именно CR. И как, будет тот клиент работать с существующими нодами, если стандарт не уточнит этот момент?

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

AL>> Всё ещё не считаю это задачей стандарта. Мы передаём текст. Любой. Хотя, если большинство согласится, что нам нужно это стандартизировать, соглашусь.
revoltech> А как же интероперабельность? Вот, допустим, человек решил написать клиента под старый Макинтош. Очень старый, ещё на процессоре архитектуры 68k, где ещё MacTCP отдельным пакетом шёл. Знаешь, какой на тех макосях тогда был стандартный символ перевода строки? Не LF и даже не CRLF, а именно CR. И как, будет тот клиент работать с существующими нодами, если стандарт не уточнит этот момент?

Принимается. Укажу конкретный символ тогда.

+++ Caesium/0.4 RC1

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

Где?
Где?

+++ Caesium/0.4 RC1

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

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

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

Внёс правки по итогам замечаний и предложений. URL тот же: http://s.spline-online.ru/idec.html

Словарик будет отдельным документом.

Какие-либо ещё замечания и предложения будут?

PS: Перед окончательной публикацией дождусь реакции hugeping.

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

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

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

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

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

Ну то и значит, что валидация требует одни ресурсы, а конверсия — уже другие. Вот как раз нужно или не нужно делать конверсию — это уже дело конкретной станции. Например, с \r\n можно обрезать \r, а только с \r уже не принимать.

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

А где /x/features ?

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

Так

Ну теперь-то мея видо?

Пишу с самописного клиента tii

тест ответа

тест ответа 2

ВоÑ, теперь всё работает.
Интересное кинцо, однако...

--- Revoltech ---

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

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

видо-видо :)

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

revoltech> тест ответа

Привет! Для тестовых сообщений лучше пользоваться эхой idec.test.

+++ Caesium/0.4 RC1

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

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