Я тут подумал и понял, что не могу предложить никакого другого варианта фетчинга. Кроме того, что сделал в ii-go (на основе слайсов). Опишу варианты, которые рассматривал.

1) Вариант с запросом "дай мне все, что позже такого-то хеша" не сработает так как порядок сообщений в базе может быть разным;

2) Вариант с хешом эхи как индикатором изменений - не решает проблему забирать не всё, а только часть. Да и предполагает хранить на диске или в базе последний хеш;

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

4) Вариант возвращать список id в обратном порядке. Идея в том что если я получаю список в обратном порядке я могу закрыть соединение в тот момент когда мне уже больше не надо. :) Но, как-то на хак похоже. А как вам? Не знаю... Нет красоты.

Получается, ничего проще слайсов и не сделать? :)

hugeping> Я тут подумал и понял, что не могу предложить никакого другого варианта фетчинга. Кроме того, что сделал в ii-go (на основе слайсов). Опишу варианты, которые рассматривал.

hugeping> 1) Вариант с запросом "дай мне все, что позже такого-то хеша" не сработает так как порядок сообщений в базе может быть разным;

Хотя, сработает. Если брать с разумным "запасом" на самом деле... Правда опять вопросы с блеклистами и удалениями могут быть.

shaos>> И кстати зачем родили IDEC если ii был такой уютненький и самодостаточный? ;)
revoltech> Да вот не знаю, кстати, мне пока что только расширение с list.txt полезным показалось.

Это было в ii.

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

AL>> Удивительно. 9 лет у всех всё доходит, а у тебя нет. Может, надо что-то в фетчере поменять?
revoltech> Наверное, мы о разных вещах говорим.
revoltech> 1. Фетчер по server-side слайсу качает 100 последних сообщений вечером.
revoltech> 2. За ночь в эхе появляется 103 сообщения.
revoltech> 3. Фетчер по server-side слайсу качает 100 последних сообщений утром.
revoltech> Вопрос знатокам: увидит ли клиент те несчастные три сообщения?

Зачем брать сто, а не то, чего у тебя нет?

AL>> У тебя соединения платные или что?
revoltech> У меня идеология не тратить вычислительные ресурсы там, где их можно не тратить. Пермакомпьютинг так называемый.

Внимание! Вопрос: какая у тебя OS и какое окружение? Пользуешься веб-браузером?

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

>> Но вред файлэх в чём?
shaos> 1. Там передаётся нетекстовая информация т.е. через терминал уже не будет работать

Постоянно работаю с файлами в терминале.

shaos> 2. Функционально файл из файлэхи это просто забирание файла по HTTP - зачем городить лишние абстракции?

Транспорт может быть любым.

shaos> 3. Сейчас (на таверне) оно используется в основном только для раздачи порнухи и пиратских книг...

Не подписывайся. Вопрос был концептуальный, а не по конкретным фехам.

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

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

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

Продумать систему наказаний поинтов (накопление плюсиков, перевод в "только чтения", отключение от эхи) на уровне стандарта.

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

hugeping> P.S. Когда цезий возродишь? :)

Цезий ждёт похорон. Допилю ноду, продолжу пилить цезий+ :)

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

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

AL> Это было в ii.

А почему документация описывает это как IDEC-расширение?

AL> Внимание! Вопрос: какая у тебя OS и какое окружение? Пользуешься веб-браузером?

К сожалению, пользуюсь. К вопросу об ОС и окружении — Alpine Linux, X/Fluxbox.

а количество плюсиков не равно обратной карме? ;)

> Это было в ii.

А почему тогда list.txt и blacklist.txt перечисляется в /x/features?

curl -XGET http://idec.spline-online.ru/x/features
u/e
list.txt
blacklist.txt
x/file
x/small-echolist
x/caesium
x/c

О - кстати, а что такое x/small-echolist?

u/e тут тоже есть :)

собрал все сообщения всех станций. пока всё криво и косо :)

http://ii.blcat.ru:5000

кроме spline, до неё так и не достучался

AL> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики

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

1) получили счётчики
2) нарисовали пагинатор
3) по мере "листания" пользователя - проходим сообщения слайсами

Если убрать x/c то будет неполнота. Короче я за то, чтобы счётчики стали настоящими.

P.S. Хотя у нас есть list.txt где эти счётчики тоже присутствуют, но их надо парсить....

клиент, просматривающий сообщения онлайн, без слайсов и прочего

for n in `wget -q -O - http://ii.blcat.ru/e/idec.talks | tac`
do
wget -q -O - http://ii.blcat.ru/m/$n | less
done

переключаться клавишей q :)

ahamai> Зачем столько запросов? Это и лишняя нагрузка на сервер, и лишний трафик (хедеры, все дела).

Напиши конкретный алгоритм, я не понял твоё предложение.
Начинаю я с -16:1 - я там выше написал что лимит это параметр. В описании алгоритма я для понятности задал его в 1, но в быту мы начинаем не с 1. И обычно, если сообщений < 16 новых это единственный запрос. Если нет, будет -32:1, потом -64:1....

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

А что это значит, напомни?

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

Я и не фетчу (пока). Я тебе писал как к автору инициативы форвардить из теста в talks. :)

ahamai> открыл в lynx, попытался перейти в веб, пишет "ошибка документа"

А я хотел заценить твой гемини и... лежит... :(

а кто тогда фетчит idec.talks с меня? :)

http://ii.blcat.ru/list.txt?h=1

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

я даже не помнил, как сервер называется :) gmid оказывается, нашёл, включил

ну 16 норм, но потом бы я шаги увеличивал, там 64, потом 256 потом все сообщения. или вообще 16 если чё-то не хватает то забирать все. думаю, такие триггеры будут редко срабатывать.

стоп. -16:1 - это взять один хэш? а почему не -16:16? или я что-то не понял.

Мне нравится идея, что у каждого свой суверенный блеклист :)

Лучше когда все фетчат всех - и надежнее, и быстрее сообщения доходят :)

> Мне нравится идея, что у каждого свой суверенный блеклист :)

ну сейчас - да, и в принципе это норм

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

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

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

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

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

Мне идея хешей эх не нравится. Придётся хранить состояние последнее на диске при фетче. Теряется эстетика простоты. Кроме того, сплайсы и так решают эту проблему (но более элегантно). В общем я понял, стандарт лучше не трогать!

ahamai> я даже не помнил, как сервер называется :) gmid оказывается, нашёл, включил

Ну то есть это будет заброшено при первом же ребуте сервера? Ок, тогда не буду пока добавлять в ссылки на своей капсуле.

не, я сделал rcctl enable gmid, ща будет автостартовать :)

> Мне идея хешей эх не нравится.

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

> Придётся хранить состояние последнее на диске при фетче.

хранить предыдущий list.txt, только и всего. зато меньше лишних запросов, большинство эх перманентно мёртвые. я жду, когда shaos сделает ?h=1, чтобы под это фетчеры адаптировать и не гонять лишнее.

AL>> Это было в ii.
revoltech> А почему документация описывает это как IDEC-расширение?

Потому что документация описывает IDEC.

AL>> Внимание! Вопрос: какая у тебя OS и какое окружение? Пользуешься веб-браузером?
revoltech> К сожалению, пользуюсь. К вопросу об ОС и окружении — Alpine Linux, X/Fluxbox.

Слишком много оверхеда.

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

shaos> а количество плюсиков не равно обратной карме? ;)

Нет :)

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

ahamai> Андрей, а что с rss-гейтом? Мёртв с 16 числа.

Умер.

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

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

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

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

AL>> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики
hugeping> Я тут понял, что если счётчики будут настоящими счётчиками сообщений (без требования не расти вниз), то совместно с слайсами они дают возможность писать клиента который не скачивает сообщения в базу а просто просматривает их онлайн. То-есть:
hugeping> 1) получили счётчики
hugeping> 2) нарисовали пагинатор
hugeping> 3) по мере "листания" пользователя - проходим сообщения слайсами
hugeping> Если убрать x/c то будет неполнота. Короче я за то, чтобы счётчики стали настоящими.

Мысль интересная, но я бы за такие манипуляции со своей станцией карал :)

hugeping> P.S. Хотя у нас есть list.txt где эти счётчики тоже присутствуют, но их надо парсить....

Там они показывают фактическое количество сообщений. То есть могут иметь отрицательный рост :)

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

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

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

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

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

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

AL> Потому что документация описывает IDEC.

Возникает вопрос: её здесь вообще кто-нибудь ещё читал?

Первый же абзац в https://github.com/idec-net/new-docs/blob/master/extensions.md:

> Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii. Многие из них реализовывать совсем необязательно.

И далее чуть ниже пункт «Список эхоконференций», описывающий GET /list.txt.

То есть документация называет GET /list.txt одним из основных отличий IDEC от ii. А мне тут рассказывают, что «это было в ii». Ну так документацию тогда поправьте, если это было в ii, а не эксклюзив IDEC.

Я вот вместе с кодобазой tii начал вести свой ii-doc.txt, где описываю только реализованные в tii части протокола. И с пометкой IDEC extension у меня там только GET /x/features и один из вариантов /u/e, который со слайсами.

AL> Слишком много оверхеда.

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

ahamai> ну 16 норм, но потом бы я шаги увеличивал, там 64, потом 256 потом все сообщения. или вообще 16 если чё-то не хватает то забирать все. думаю, такие триггеры будут редко срабатывать.

Сделал у себя с шагом кратности 12 (потом 24, 48 и т.д.), чтобы в самом распространённом случае можно было даже с tgi и подобных за один запрос стянуть.

ahamai> стоп. -16:1 - это взять один хэш? а почему не -16:16? или я что-то не понял.

Ну в том алгоритме главная идея состоит в экономии трафика, полагаю. Сначала пробный запрос с -16:1, а потом, если в базе есть сообщение, то можно и -16:16.

revoltech> жирный HTTP

Почему жирный-то? Почти натуральный plaintext. Куда меньше?

tuple> Почему жирный-то? Почти натуральный plaintext. Куда меньше?

Потому что статусы и заголовки, например. См. как в гофере или нексе сделано: строка запроса — ответ, всё.

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

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

Отвечаю заранее на вопрос «а как же постить»? Как в NPS — на другой порт:

cat <<EOF | nc station.domain 1915
/u/point
[auth_string]
[base64_message]
.
EOF

Вот тут уж действительно меньше некуда.

tuple> Почему жирный-то? Почти натуральный plaintext. Куда меньше?

Потому что статусы и заголовки, например. См. как в гофере или нексе сделано: строка запроса — ответ, всё.

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

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

Отвечаю заранее на вопрос «а как же постить»? Как в NPS — на другой порт:

cat <<EOF | nc station.domain 1915
/u/point
[auth_string]
[base64_message]
.
EOF

Вот тут уж действительно меньше некуда.

P.S. Что-то не смог запостить на sprinternet, переслал на tgi.

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

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

Да не обязательно овер телнет, но да, суть в том, чтобы не относящихся непосредственно к ii метаданных меньше гонять. Здесь и так сообщения в base64 оборачиваются, что уже 4/3 от полезной нагрузки...

Думаю о создании станции lor2ii, которая будет медленно и печально собирать сообщения с текущих тем лора.

Без веб интерфейса, либо с веб интерфейсом только для пойнтов.

При этом пойнты могут комментировать эти сообщения и они будут доступны другим пойнтам. Получится этакий OverLor.

Сообщения с лора тэгировать чем-то типо lorlink/урл-на-сообщение.

Вернуть http-клиента и ориентировать на всё это.

Кому-нибудь такое интересно?

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

Го дропнем base64

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

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

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

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

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

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

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

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

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

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

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

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

iii.nizya

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

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

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

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

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

Поддерживаю

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

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

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

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