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

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

> Они не посвящены никакой теме.

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

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

> Я на gopher://hoi.st обитаю, если что.

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

других gopher клиентов я не помню, бомбадила вроде умеет, но он вроде веб не умеет

Капец там запросов, оверхед.

x/features вообще должна кешироваться, сервер не меняет серверное по каждый день, чтобы это постоянно запрашивать

2 и 3 вообще должны быть одним запросом, типа дай мне сообщения, начинающиеся с такого-то.

Зачем столько запросов? Это и лишняя нагрузка на сервер, и лишний трафик (хедеры, все дела). Почему не делать шаги типа 1, 16, ещё чёнить, всё, то есть более частые юзкейсы. или даже сразу начинать с 16. запрос вообще вещь дорогая, и их лучше минимизировать

> Конечно, сейчас хочется сказать - а давайте вернёмся и придумаем что-то более простое и надёжное и сделаем что-то среднее между ii и idec... Но боюсь, лишние потрясения нам не к чему.

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

> Идея с счётчиками работает ТОЛЬКО в условиях ii. Когда все базы одинаковы.

у меня изначально было понимание что базы будут разные, и блеклист появился чуть ли не сразу

> Там ещё идея с подменой (amend) сообщений выглядит интересной - идеологически верная альиернатива редактированию старых мессаг...

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

у меня фетчер, оказывается, вообще без поддержки blacklist :)

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

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

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

http://ii.blcat.ru:5000

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

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

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

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

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

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

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

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

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

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

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 :)

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

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

а кто тогда фетчит 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 от полезной нагрузки...

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

Го дропнем base64

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

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

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

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

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

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

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

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

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

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

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

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