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

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

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

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

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

AL> Почему?

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

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

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

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

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

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

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

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

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

Поддерживаю

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему?

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

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

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

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

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

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

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

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

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

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

Предлагаю отказаться от HTTP, base64, списков и переделать всё на актбаунды.

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

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

Ну так пиши транспорт какой тебе больше нравится. Стандарт не завязан на HTTP как таковой. Был опыт обмена и по FTP. Просто HTTP всех устраивает, так как дёшево и просто с точки зрения использования и уже так сложилось.

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

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

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

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

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> предлагаю включить в стандарт возможность исполнения 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> ====

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

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

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

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

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

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

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

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

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 сообщения, не обязан совпадать при перерасчёте (он и не будет).

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

Ну я у себя теперь просто делаю приписку (ID hash mismatch!) рядом с айдишником у таких сообщений.

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

А на такие платформы уже портировали Tcl 8.6, sqlite3 и прочее? Я же конкретно насчёт своего клиента/фетчера говорю. Там-то понятное дело, что другие подходы ко всему нужны.

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

Да я не против того, чтобы в стандарте они оставались.

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

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

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

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

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

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

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

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