Сделал

> curl -XGET https://sprinternet.io/iii/lim/3/u/e/retro.talks/english.talks
retro.talks
yceDK3BmBJnfAZQlktjd
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w

Сделал хак для поддержки /lim/N/u/e/...

> curl -XGET https://sprinternet.io/iii/lim/3/u/e/retro.talks/english.talks
retro.talks
yceDK3BmBJnfAZQlktjd
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w

работает также как и

> curl -XGET https://sprinternet.io/iii/u/e/lim/3/retro.talks/english.talks
retro.talks
yceDK3BmBJnfAZQlktjd
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w

ahamai> Да и пойнт тебе с u/e ничё не сделает.

Без фильтрации айдишников — ой как сделает.

> Так. Я могу задать срез последней, я могу задать каждой. А если я задам не каждой, а некоторым, что будет тогда?

Когда ты задаёшь "срез" в конце, то он распространяется на весь список

Если надо чтобы что-то из списка брало по своему, то там надо указать свой "срез" либо волшебное слово all либо волшебное слово last

типа /u/e/echo.1/echo.2/all/echo.3/last вернёт всё для echo.1 и echo.2, но только хеш последнего сообщения для echo.3

ну ещё lim можно воткнуть в середину - вот такая запись сделает тоже самое:

/u/e/echo.1/echo.2/lim/1/echo.3

короче полная гибкость и свобода выбора :)

ну конечно оно в каком-то смысле дублирует слайсы :)

короче с хаком теперь работает, но только применительно к /u/e т.е. например /lim/3/list.txt у меня не пройдёт ;)

Хак:

elseif (($opts[0] == 'u' and $opts[1] == 'e') ||
        ($opts[0] == 'lim' and $opts[2] == 'u' and $opts[3] == 'e')) {
	$work_options=array_slice($opts, 2);
	// lim/N/u/e hack
	if($opts[0] == 'lim') {
		$work_options[0] = 'lim';
		$work_options[1] = $opts[1];
	}

Жесть. Ты теперь обязан жениться на u/e

По ходу пьесы удалил около 500 строк отвечающих за файлэхи - это было порядка 20% всего кода ii-php (сейчас осталось чуть больше 2000 строк), а чтобы поддержать в /u/e/ слайсы где попало, lim/N, выдача по хешу, выдача по времени сохранения плюс хак /lim/N/e/u потребовалось добавить меньше 50 строк...

> сейчас осталось чуть больше 2000 строк

там ведь ещё есть неиспользуемый сейчас транспорт MySQL - я пока думаю стоит туда вообще залезать или остаться в рамках файлового представления

наверное надо пересаживаться на MySQL хотя бы для хранения метаданных типа цепочек тредов, таблиц поиска и т.д.

tuple> Очень желательно сделать на станции отличие одной страницы от другой в title вкладки. А то в истории браузера сохраняется просто как:

Посмотри сейчас, лучше стало? Правда наверное не все случаи предусмотрел.

hugeping> Посмотри сейчас, лучше стало? Правда наверное не все случаи предусмотрел.

Да, классно теперь. Только https://club.hugeping.ru/echo/all/ отображается как "club.hugeping.ru/echo/all".

hugeping>> Посмотри сейчас, лучше стало? Правда наверное не все случаи предусмотрел.

tuple> Да, классно теперь. Только https://club.hugeping.ru/echo/all/ отображается как "club.hugeping.ru/echo/all".

Ага, ещё несколько случаев добавил. Если что, пиши. Для меня web ii-go сейчас близок к идеалу. Но иногда что-то меняю по мелочи.

Зашёл на станцию hugeping а там уже будущее :)

Моё сообщение, написанное в 8:04 пришло туда в 8:38, чёт долго :)

Не могу понять, но от тебя периодически перестаёт ходить эха linux.14. Вот только эта эха. Проблему понять не могу

shaos> Если надо чтобы что-то из списка брало по своему, то там надо указать свой "срез" либо волшебное слово all либо волшебное слово last

Просто на всякий случай. В слайсах, установка limit в 0 означает безлимит.

https://hugeping.tk/u/e/idec.talks/0:0 - всё
https://hugeping.tk/u/e/idec.talks/-1:0 - последнее (ну или -1:1)

shaos> Ну вон я же вчера приводил замеры - каждый HTTPS запрос добавляет 3.5КБ к полезной нагрузке - будет 1000 запросов, будет лишних 3.5 мега...

Если в каждой эхе у нас новых сообщений от 128 до 256 штук, то для 1000 запросов, с учётом того, что запрашиваем по одной эхе, нужно запросить 125 эх. Это раз

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

Бандлы по 40 сообщений... Если мы возьмём те самые 125 эх, в которых у нас по 256 новых сообщений и начнём их выкачивать такими вот бандлами, у нас всё равно будет 800 запросов, что меньше заявленного тобой ужасного числа на 20%.

В реальности такой оверхед будет только для новых узлов и разово. Дальше, при фетчинге хотя бы пару раз в день, количество запросов будет от силы несколько десятков на сессию, что меньше 10% от заявленного.

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

1. я снял срезы. они почему-то вообще трафик не экономят, как был 2-4 мб так и остался, хотя x/h сильно его экономит. не понимаю, я же тяжёлые лор-опеннет и хабр.рсс тащу.

2. я создал эху spnet.uplink и поставил её фетч на тебя. поставь её фетч на меня, будем там решать проблемы нашей связи :), проблем, эх для гейтования и прочего, думаю здесь этому не место.

> Без фильтрации айдишников — ой как сделает.

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

1. у нас есть файл с такой эхой - отдаём этот файл
2. у нас нет файла с этой эхой, отдаём пустую эху

третьего не дано

> А потому что нефиг завязываться на точку было. Сделали бы 1) что-то в духе /u/l (в моём новом несовместимом протоколе будет /r/l вместо list.txt), 2) в выводе /u/e после каждой эхи (для отличия от msgid) ставить двоеточие. И всё, никаких коллизий.

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

Я после всех этих обсуждений засомневался, а может быть и правда нам нужны множественные слайсы в u/e? Может быть это нужно для адаптивного фетча? Поговорил с Андреем и стало понятно что вроде бы не нужны.

# Идея

Идея, на самом деле, простая. Мы сканируем последние сообщения станции но ровно до тех пор, пока сами не решим - хватит или нет. А решение принимаем на основе анализа полученных msgid (есть они в базе у нас или нет?). В этом отличие от просто фетча последних n сообщений.

# Алгоритм

1. Выбрали N=16, LIM=16
2. Выбрали набор эх elist: echo.1, echo.2, ... echo.i
3. Сделали запрос /u/e/echo.1...echo.i/-N:LIM
4. Для каждой эхи в ответе:
- Все отсутствующие msgid добавляем в список, который добавляем в голову msgids
- Если таких сообщений нет или ответ содержит меньше записей чем N (выгребли всё)
удаляем эху из набора elist
5. Набор elist пуст? Да! иди на 10
6. LIM=N, N = N * 2
7. N > 1024 ? Если да, бросаем это дело и начинаем полный фетч
8. Перейти на 3
10. Делаем запрос(ы) /u/m для всех id из списка msgids

Числа 16 и 1024 тоже эвристические. 1024 - просто способ закончить фетч если мы видим, что адаптивный фетч всё никак не дойдёт до "дна".

# Можно ли проще?

Моя станция работает по-другому. Основное отличие в том, что я делаю запросы -N:1 а не -N:LIM и просто проверяю -- а есть ли у меня это сообщение или нет? Если есть, потом я делаю фетч на -N:N.

1. Выбрали N=16
2. Выбрали эху
3. Сделали запрос /u/e/echo/-N:1
4. Сообщение есть? Или такое же как в прошлый раз? На 10
5. N = N*2
7. N > 1024 ? Если да, бросаем это дело и начинаем полный фетч
8. Перейти на 3
10. Делаем запрос /u/e/echo/-N:N
11. Делаем запрос /u/m для всех id из ответа пп.10 которых у нас нет

Это немного упрощает алгоритм и, возможно?, делает ситуацию безопасней, если во время сканирования добавились новые сообщения, но я работаю только с одной эхой. Если такую штуку делать со многими эхами сразу то:
a) понадобятся множественные slice
b) алгоритм станет сложнее, а не проще

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

1. Выбрали N=16
2. Выбрали набор эх elist: echo.1, echo.2, ... echo.i
3. Сделали запрос /u/e/echo.1...echo.i/-N:1
4. Для каждой эхи в ответе:
- Если сообщение есть или получили тот же id что в прошлый раз, удаляем эху из набора
5. Набор elist пуст? Да! иди на 10
6. N = N * 2
7. N > 1024 ? Если да, бросаем это дело и начинаем полный фетч
8. Перейти на 3
10. Делаем запрос(ы) /u/e/все эхи/-N:N
11. Делаем запрос(ы) /u/m для всех id из ответа пп10

Написал просто, чтобы не забыть.

Алгоритмы хорошо, но есть ли реальные замеры. Тестируй разные варианты на shaos, он подробную статистику ведёт :)

Да, ещё, чтобы не забыть.

Допустим, мы используем endpoint /lim/100 и всегда фетчим последние 100 сообщений. Чем это плохо? Плохо тем, что если за это время накопится 200 сообщений, то у нас старые сообщения придут когда-то потом, после того как админ заметит проблему и сделает полный фетч.

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

Адаптивный фетч пытается решить эту проблему. В самой частой ситуации он сработает как /lim, но если окажется что сообщений всё-таки накапало больше, сдвинется назад.

lim это не для фетча, это чисто для клиентов. а переполнение при постоянном фетче живых эх вообще практически 0. такое может быть, если где-то rss бот сломался а потом вдруг выдал всё (и то в rss по 100 сообщений обычно не отдают). ну и я в lor.gold вкидываю сразу всю серию, там может быть и 200. а в клиентских эхах, по своему опыту, если я в фидо давно не забирал почту и в какой-то эхе куча сообщений, я максимум прочту несколько десятков последних и потом помечу эху, как прочитанную.

ps. у меня такое ощущение, что с такой экономией копеечного на самом деле трафика вы скоро на аутбаунд перейдёте. :) который я считаю главным недостатком фидо, я ровно сегодня думал, что фидо даже с сегодняшней моделью ii и тогдашними модемами на 300 байт/с, вполне могло бы жить.

> Просто на всякий случай. В слайсах, установка limit в 0 означает безлимит.

0:0 у меня таки сработает как all
а вот -1:0 надо посмотреть...

> Моё сообщение, написанное в 8:04 пришло туда в 8:38, чёт долго :)

Я забираю раз в 30 минут с каждого, но моменты забирания размазаны вдоль часа - поэтому если с тебя никто кроме меня не забирает, то будет полчаса. А если все фетчат всех, то так или иначе теми или иными путями оно должно минут за 10 добраться...

2. сделал spnet.uplink

> Жесть. Ты теперь обязан жениться на u/e

Выходит что так :)

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

-1:0 не работает (точнее работает, но возвращает 0 хешей)
но я эту логику не трогал - видимо ii-php всегда так работал
исправлю

Проверил старый ii-point.php - он и по 0:0 возвращал 0 хешей :)
Так что я получается это уже частично исправил ;)
Осталось N:0 исправить...

shaos> Осталось N:0 исправить...

Я сегодня тоже баг в сплайсах у себя обнаружил. Не работали положительные индексы вообще :)
Но никто не использовал их в таком режиме. Исправил.

> Я сегодня тоже баг в сплайсах у себя обнаружил. Не работали положительные индексы вообще :)
> Но никто не использовал их в таком режиме. Исправил.

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

> Я забираю раз в 30 минут с каждого, но моменты забирания размазаны вдоль часа - поэтому если с тебя никто кроме меня не забирает, то будет полчаса. А если все фетчат всех, то так или иначе теми или иными путями оно должно минут за 10 добраться...

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

> 30 мин чё-то долго, я фетчу только тебя, но с интервалом 5 мин.

надо в iii-php фетчер под тебя подковырять, чтобы list.txt?h=1 спрашивал для понимания чего брать чего не брать - тогда буду почаще опрашивать

> Осталось N:0 исправить...

Исправил - заменяю количество 0 на 999999999 (один миллиард минус 1) т.к. вряд ли когда-нибудь в ii/IDEC будут эхи с количеством сообщений больше миллиарда - ограничение такое сделал ещё и из-за того, что у меня в /u/e/ теперь unixtime может пролетать и для простоты он у меня определяется как число >=1000000000 что соответствует Sun Sep 09 2001 01:46:40 GMT+0000 (не думаю, что в ii/IDEC когда-либо попадутся сообщения древнее сентября 2001 года)...

Заметил лишний пробел:

> Количество сообщений указывается от 0 до произвольного числа. Если количество равно нулю, индекс строится от смещения до конца. Если сумма смещения и количества превышает фактическу ю длину индекса на узле, отдаются все msgid от смещения до конца индекса.

фактическу_ю

Теоретически кто может сконвертить фидошные, с оригинальной датой. Лучше убрать один порядок :)

> Узел должен обеспечивать запрос 40 сообщений в одном запросе /u/m. Клиент может запрашивать меньше, но узел должен обеспечивать передачу именно 40 сообщений за запрос.

Может быть первое предложение подкорректировать?

Количество одновременно запрашиваемых сообщений в одном запросе /u/m не должно превышать 40. Клиент может запрашивать меньше, но узел должен обеспечивать передачу именно 40 сообщений за запрос.

Это не дата в заголовке сообщения, это дата когда сервер это сообщение принял либо по фетчу, либо по пушу, либо через поинтовый апи, либо путём копирования файлов извне (у меня сейчас - дата модификации файла сообщения). Ясно понятно, что 2001 год там быть не может. Да и в заголовке старая дата как бы не должна быть т.к. это timestamp проставляемый сервером при конвертировании ii сообщения из поинтового в сохранённое, чего никак не могло произойти раньше 2014 года...

И потом этот unixtime используется для отрезания сообщений в /u/e - типа дай мне всё что новее, а это обычно прям щас, не в прошлом

Тут ещё такой момент есть - ii-php со стародавних времён накладывает блеклистовый фильтр уже после того, как слайсы посчитаны и выходной список софрмирован, т.е. например если последнее сообщение в эхе заблеклисчено, то -1:1 вернёт ничего. По идее это решается административно путём принятия за правило никогда не блеклистить последнее сообщение в эхе - пусть оно немного "полежит" :)

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

а где попасть на сабж? ссылки на http в gopher у меня на том сайте не открываются :(

Да, хэши рулят. А вот срезы, на моё удивление, вообще трафика не снизили, до хэша было 12, с хэшем 2, поставил срезы, стало 4.5, потом 2.7, потом 2.5. убрал срезы, буду смотреть твою статистику за вчера и сегодня.

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

люблю оптимизм. :) будем ждать первую эху с миллиардом сообщений

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

Интересно. Мой вариант фетча с пробами по -N:1 вроде бы устойчив к такому поведению. Вот если сразу 16 заблеклистишь последних, тогда будут проблемы :)

ahamai> а где попасть на сабж? ссылки на http в gopher у меня на том сайте не открываются :(

https://git.luxferre.top/tii/file/README.html

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

ahamai> мне не нравится, когда все фетчат всех

Почему? Это ведь максимизирует надёжность доставки.

> Почему? Это ведь максимизирует надёжность доставки.

ну не знаю, не по фидошному это :) аплинк даёт тебе почту, его надо пивом поить. хотя мой аплинк в Калифорнии, а я во Владивостоке, сложна...

хотя когда я был в нодлисте, в 2000-м вроде году, моя нода по адресации была в Бельгии 550/13, а аплинк в Москве, 5020/52. Я думаю он даже не знал о моём существовании :)

прекольна. 12.8 без срезов. я вообще ничего не понимаю, без x/h примерно столько всегда и было. ладно, но срезы возвращать не буду :) смотрим что завтра будет

ahamai> прекольна. 12.8 без срезов. я вообще ничего не понимаю, без x/h примерно столько всегда и было. ладно, но срезы возвращать не буду :) смотрим что завтра будет

Это всё замечательно, но зачем всё это писать в теме, которая посвящена интерфейсу ii-go?

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

hugeping> Если идея ii в том, чтобы генерировать неструктурированный поток односложных сообщений, то мне такая сеть точно не нужна.

Я заблеклистил сообщения. Если оно и так дальше будет, я начну снимать эхи с фетча. Честно, достала меня такая помойка.

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

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

я про что всегда и говорил. малотрафиковый поток в формате форума, где кто-то пишет сообщения в рандомные темы, просто неудобен. это когда мне говорили, почему бы не взять форум. а в формате эхи эта вялая жизнь хоть как-то поддерживается. так что, в принципе, да, это основная идея. в сети из малого количества тем нет тем, есть сквозная тема, поэтому только формат эхи. если бы я это всё смотрел не эхой, а форумом, я бы это просто не увидел. всё это взято из фидо. ii это "социальная сеть малых сообществ". где всё структурировано и есть куча отдельных тем, там конечно форум интересен. но здесь основной формат - это эха, а не форум. потому что "настоящие фидошники сабжей не меняют" (c)(r)(tm)

кстати, спасибо, что напомнил, я это забыл записать в анонсе :)

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

Я тут "психанул" и заблеклистил часть сообщений в одном из топиков на своей станции. Типа, навёл порядок. И задумался.

ii часто сравнивают с Фидо, но Фидо была довольно структурированной и хорошо модерируемой... Ноды несли ответственность за поинтов. Ноды тоже несли ответственность ну и так далее... Были правила, формализованные способы наказания... никакой анонимности. В ii/idec всё по другому!

Надежда на самоорганизацию? Но .... когда у тебя бОльшая часть членов сети это авторы собственных нод. :) Не сработает.

ii очень простая. Предполагалось что эхи не живут вечно, перекатываются (архивируются)... И в целом, это действительно похоже просто на "соц-сеть". Некоторое "живое общение" - ленту. Формат сообщений - короткие реплики. Этому способствует в том числе - невозможность редактировать. Такой твиттер получается?

В Фидо же, нерегулярность обмена приводила к эффекту обычных писем. Люди часто писали развёрнуто, с ответами на конкретные тезисы и так далее. В ii/idec этого нет (и не будет).

Мне в ii/idec понравились:
- текстовость
- федеративность
- простота

Но это в большей степени относится к реализации. А вот КАК использовать ii? И вот есть ощущение, что я хочу от ii/idec то, для чего она в принципе никогда и не предназначалась...

- развёрнутые интересные тексты-статьи (хаха! без возможности редактирования?)
- тематическое общение (хаха! когда в стандарте "топик" это просто repto который никто (кроме ii-go) не использует для показа структуры)
- высокая культура общения, когда читаешь, понимаешь, думаешь и отвечаешь (ха ха! фетчим каждые 5 минут. отправил 1 сообщение, получил в ответ 10, ответил на каждое из 10 в ответ пришло 1000) - да это же хуже телеграмма!

Так для чего ii на самом деле? Рома писал в духе, что это для малых сообществ. Здорово. Но что эти сообщества там будут делать? Что делали бы условные радиолюбители? Чатились бы в режиме твиттера короткими сообщениями? Накапливали бы знания? ii может заменить форум? Или создаёт вал цепочных сообщений? Непонятно.

В общем, предлагаю высказаться. Мне кажется, нам самим хорошо бы понять "философию" сети. Что мы все от неё хотим?

> i часто сравнивают с Фидо, но Фидо была довольно структурированной и хорошо модерируемой... Ноды несли ответственность за поинтов. Ноды тоже несли ответственность ну и так далее... Были правила, формализованные способы наказания... никакой анонимности.

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

> Надежда на самоорганизацию? Но .... когда у тебя бОльшая часть членов сети это авторы собственных нод. :) Не сработает.

правила такие же, как в фидо. за косяки пойнта выносят нода. всё взято из фидо

> В Фидо же, нерегулярность обмена приводила к эффекту обычных писем. Люди часто писали развёрнуто, с ответами на конкретные тезисы и так далее. В ii/idec этого нет (и не будет).

серьёзно? пока до нода дозваниваешься, можно ещё несколько сообщений вдогонку накатать. а как же легендарное "ет" (Фарид) который вообще темплейтами ответы слал. Ответы из 1-2 строчек это самый обычный комментарий.

> - высокая культура общения, когда читаешь, понимаешь, думаешь и отвечаешь (ха ха! фетчим каждые 5 минут. отправил 1 сообщение, получил в ответ 10, ответил на каждое из 10 в ответ пришло 1000) - да это же хуже телеграмма!

это пики. конкретная тема взлетает в пик, её обсуждают. потом забывают и снова затишье. это тоже было нормально в фидо. я так, кстати, и не запомнил, взлетит он или не взлетит :)

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

> Так для чего ii на самом деле? Рома писал в духе, что это для малых сообществ. Здорово. Но что эти сообщества там будут делать?

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

> - развёрнутые интересные тексты-статьи (хаха! без возможности редактирования?)

изначально тут вообще textile был и эхи формата wiki.... но это не соответствовало концепту

> - тематическое общение (хаха! когда в стандарте "топик" это просто repto который никто (кроме ii-go) не использует для показа структуры)

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

> - высокая культура общения, когда читаешь, понимаешь, думаешь и отвечаешь (ха ха! фетчим каждые 5 минут. отправил 1 сообщение, получил в ответ 10, ответил на каждое из 10 в ответ пришло 1000) - да это же хуже телеграмма!

без контента сеть мертва. можно сколько угодно обсуждать непонятную крохоборскую экономию трафика, когда любая веб-страница жрёт больше, чем ii-клиент жрал в лучшие годы за день, но обсуждения создаёт привлечение к обсуждению. эха это группировка внимания, когда у тебя больше привлечения внимания к обсуждению. я решал проблемы форумов для малых сообществ, а не примкнул к ним :) качество общение это качество юзеров. а о чём мы, три с половиной сисопа ещё можем поговорить, и с кем ещё? я бы хотел обсуждать проблемы контента, проблемы новых пользователей, проблемы привлечения к написанию нового софта (как я называл это в 2014, любительское программирование). проблемы экономии 20% трафика меня мало интересуют, ну будет у 3.5 сисопов общение занимать не 5 мб в день, а 4, и что это изменит, в чём вообще суть сети?

Архивные записи удобнее читать в формате форума, свежие - подряд

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

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

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

Понятно. Ну, я должен подумать. И или принять или изолироваться. :)

P.S. Я отменил блеклист, так как рассинхронизация ещё хуже. Получилось две темы на ii-go, это ещё больше будет сбивать с толку.

Цитирую Рому:

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

> я про что всегда и говорил. малотрафиковый поток в формате форума, где кто-то пишет сообщения в рандомные темы, просто неудобен. это когда мне говорили, почему бы не взять форум. а в формате эхи эта вялая жизнь хоть как-то поддерживается. так что, в принципе, да, это основная идея. в сети из малого количества тем нет тем, есть сквозная тема, поэтому только формат эхи. если бы я это всё смотрел не эхой, а форумом, я бы это просто не увидел. всё это взято из фидо. ii это "социальная сеть малых сообществ". где всё структурировано и есть куча отдельных тем, там конечно форум интересен. но здесь основной формат - это эха, а не форум. потому что "настоящие фидошники сабжей не меняют" (c)(r)(tm)

> Архивные записи удобнее читать в формате форума, свежие - подряд

На самом деле в ii-go есть и эха, и форум. Но читать форум просто невозможно, именно потому, что тема топика никак не соответствует содержимому...

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

> Но читать форум просто невозможно, именно потому, что тема топика никак не соответствует содержимому...

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

(кстати, почему моё сообщение-то не по теме - мы экспериментируем с разным фетчем ноды и отслеживаем трафик, и что-то там очень странно, и это именно поведение ноды).

> Архивные записи удобнее читать в формате форума, свежие - подряд

да. поэтому для своих ретроспектив я доделываю к своей ноде разные возможности чтения тем. во-первых. у меня всегда был реверс, чтобы смотреть и от нового к старому и от старого к новому, во-вторых, думаю что сделать с цепочками тем (в elp были тэги, но прямо сейчас в ii их так не введёшь. хотя, кстати, почему не введёшь, поле тэгов которое и испольовалось в elp, как раз к этому и предназначено. наверное, надо идеи из elp взять)

>> Архивные записи удобнее читать в формате форума, свежие - подряд

ahamai> да. поэтому для своих ретроспектив я доделываю к своей ноде разные возможности чтения тем. во-первых. у меня всегда был реверс, чтобы смотреть и от нового к старому и от старого к новому, во-вторых, думаю что сделать с цепочками тем (в elp были тэги, но прямо сейчас в ii их так не введёшь. хотя, кстати, почему не введёшь, поле тэгов которое и испольовалось в elp, как раз к этому и предназначено. наверное, надо идеи из elp взять)

В ii-go тоже есть разные режимы показа. И реверс со всеми сообщениями. И вид эхи. И вид с топиками. И форум. И даже блог. Причём не все даже выведены в шаблоны. Но они частично бесполезны в режиме когда контент создаётся в виде "одного потока". Правда, мои собственные эхи я хотя бы контролирую.

Ладно, это всё так...

> В ii-go тоже есть разные режимы показа. И реверс со всеми сообщениями. И вид эхи. И вид с топиками. И форум. И даже блог. Причём не все даже выведены в шаблоны. Но они частично бесполезны в режиме когда контент создаётся в виде "одного потока". Правда, мои собственные эхи я хотя бы контролирую.

честно говоря, я этого не нашёл в интерфейсе.

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

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

но формат эхи для малочисленной группы был самым живучим, поэтому после elp-0.4 был выпущен ii-0.5, а скоро будет nastene-0.7 :)

ahamai> честно говоря, я этого не нашёл в интерфейсе.

Я думаю ты и не искал. :)

Форум: https://club.hugeping.ru/forum/
Блог: https://club.hugeping.ru/blog/std.hugeping
Эха: https://club.hugeping.ru/echo/std.hugeping
Топик: https://club.hugeping.ru/pgZZmWnIfm3dLZEAKc6W#pgZZmWnIfm3dLZEAKc6W
Новые сообщения в реверсе: https://club.hugeping.ru/echo/all/

Честно говоря, не особо понятнее стало. Я тыкал весь интерфейс, но кроме кнопки форум ничего не нашёл. Да и вообще не особо понял различий, как-то оно одинаково выглядит.

hugeping> Новые сообщения в реверсе: https://club.hugeping.ru/echo/all/

Текущая навигация ii-go.

Если на главной странице сверху нажать "Forum" - переходим в режим форума. Выйти из которого можно только нажав на logo (если из глубокого уровня вложенности, то несколько нажатий на logo)

Если на главной странице нажать на Subj сообщения - мы сразу попадём на это сообщение в режиме обычной эхи. С просмотром всех сообщений эхи рядом. Из режима просмотра всех сообщений можно попасть в конкретный топик нажав ">" рядом с сообщением.

Если на главной странице нажать на имя эхи (ярлык над сообщением) - попадаем в просмотр топиков эхи. В этом режиме можно выбрать другой режим: Echo :: Forum :: Blog

http://blcat.ru:15555/

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

Последний пункт написал doesnm

У меня статистика считается за сутки сразу после полуночи по тихоокеанскому времени - это 11 утра по Москве или 6 вечера по Владику, поэтому результат любого изменения лучше смотреть на следующий день.

И кстати у меня ведь теперь есть spnet.uplink где можно это обсуждать :)

shaos> Последний пункт написал doesnm

Да, не заметил с телефона. :)

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

Вот поэтому я и не хотел давать ссылку раньше времени. Но без мануалов с любым из моего софта (тем более написанного в первую очередь для себя) вообще делать нечего.

Вкратце — создаёшь stations.txt а-ля такого содержания:

https://sprinternet.io/iii 389
https://hugeping.tk 10000
#https://tgistation.ru 12
http://ii.blcat.ru 4238
http://idec.spline-online.ru 380

Запускаешь фетчер: ./tiifetch.tcl
Запускаешь GUI-клиент: ./tiix.tcl

В выпадающем списке эхи, справа фильтр по сообщениям (0 — читать все), ну а дальше, думаю, разберёшься.

revoltech> ну а дальше, думаю, разберёшься.

А, ну да, ещё auth.txt для постинга нужен. Формат тот же: на каждой строке урла станции и пароль через пробел.

В 19:57 у меня статистика обновляется

И я говорил это не в контексте проблемы, а в контексте работы срезов. Несколько десятков мб трафика в сутки между серверами это вообще не проблема. Да и для меня - стационарного инета у меня нет, на одном номере 26 гб в тарифе на другом 50. В конце месяца обычно на одном телефоне остаётся неиспользованными гигабайт 10, на другом 50 :)

ps. В последнее время думаю, что /u/e нафиг не нужна и только всё усложнила, проще было, действительно, опрашивать эхи по одной. Кроме того это ещё и DoS атака, когда с крупного узла запрашиваешь разом все эхи, он сильно задумывается, а ведь каждую эху можно засунуть в запрос несколько раз... если бы не старые клиенты, я бы отрезал её вообще, оставив только e. Но уже ничего не сделаешь, так исторически сложилось.

ahamai> без контента сеть мертва.

Ну дык инглиш, мазафака, ду ю спик ит? У меня, например, конента сколько угодно, но на более широкую аудиторию в основном за пределами чебурнетов. Внезапно даже мой гофер какую-то обратную связь даёт: со мной на днях связался какой-то пакистанец, нагугливший по совершенно неожиданному поисковому запросу веб-зеркало моего гоферного блога. И в итоге я от него получил материал (пару дампов), необходимый для успешного завершения одного из моих исследований. Сам в шоке до сих пор. Но я к тому, что через ii/IDEC в его нынешнем состоянии он бы на меня не вышел никогда даже с веб-зеркалами. Он только английский, урду и арабский знает.

ahamai> а о чём мы, три с половиной сисопа ещё можем поговорить, и с кем ещё?

Ну вот я с лора пришёл, можно ещё каких-то интересных личностей с 4PDA позвать, но опять же, глобальнее надо мылить, глобальнее (это мем, а не опечатка, если что).

ahamai> проблемы привлечения к написанию нового софта (как я называл это в 2014, любительское программирование)

А что, с этим есть какие-то проблемы? Ну, окромя того, что 95% населения даже тикль не хотят осиливать.

ahamai> когда с крупного узла запрашиваешь разом все эхи, он сильно задумывается

Раз Шаос тут свой монстрокод кидал, могу и я свой кинуть (правда, это ещё не окончательный вариант, а в репе этого файла пока вообще нет и ещё долго не будет) чисто по обработке /u/e со стандартным слайсингом:

            e {
              set erange [lrange $pathparts 3 end]
              if {[llength $erange] > 0} {
                set limit 0
                set offset 0
                set lastel [lindex $erange end]
                if {[string match *?:?* $lastel]} { # slice detected
                  set sparts [split $lastel :]
                  set offset [expr {int([lindex $sparts 0])}]
                  set limit [expr {int([lindex $sparts 1])}]
                  set erange [lrange $erange 0 end-1]
                }
                # validate the rest of the echo list
                set erange [lmap ename $erange {expr {
                  [validecho $ename] ? $ename : [continue]
                }}]
                if {[llength $erange] > 0} { # recheck length after validation
                  repdata $sock $ishttp [indexechos $dbfile $erange 1 $offset $limit]
                } else {
                  reperror $sock $ishttp "invalid request"
                }
              } else {
                reperror $sock $ishttp "invalid request"
              }
            }

Но это не самое интересное. Самое интересное — процедурка indexechos:

# echo indexer for /e and /u/e
proc indexechos {dbfile echolist includenames offset limit} {
  set rdata {}
  set oquery {ORDER BY `id`}
  if {$limit > 0} { # trigger limiting logic only with positive limit value
    if {$offset >= 0} { # normal limiting flow
      append oquery " ASC LIMIT $offset,$limit"
    } else {
      set reallimit [expr {-$offset}]
      set realoffset [expr {$reallimit - $limit}]
      if {$realoffset >= 0} {
        append oquery " DESC LIMIT $realoffset,$reallimit"
      } else { # invalid limit, falling back to full query
        append oquery " ASC"
      }
    }
  }
  set query {SELECT CONCAT(`echoname`, ':', GROUP_CONCAT(`msgid`,'|' ORDER BY `id`)) AS `rowcat` FROM (}
  foreach echo $echolist {
    append query "SELECT * FROM (SELECT `id`, `msgid`, `echoname` FROM `msg` WHERE `echoname` = '$echo' $oquery) UNION ALL "
  }
  append query {SELECT NULL,NULL,NULL) GROUP BY `echoname` ORDER BY `echoname` ASC;}
  sqlite3 db $dbfile -readonly true
  db eval $query echorow {
    if {$echorow(rowcat) ne ""} {
      set eparts [split $echorow(rowcat) :]
      set ename [lindex $eparts 0]
      if {$ename ne ""} {
        if {$includenames > 0} {
          append rdata $ename \n
        }
        append rdata [join [split [lindex $eparts 1] "|"] \n] \n
      }
    }
  }
  db close
  return $rdata
}

Вот и с чего бы такой обработчик долго задумывался, если он все эхи (после валидации) в один проход запрашивает?

Сегодня статистика без таверны, которая похоже опять прилегла...

Echoareas
────────────────────────
idec.talks...........518 ██████████████████████████████████████████████████▒▒▒▒▒▒▒▒▒▒
bot.slashdot.........127 ██████████████████████████████████████████████████▒▒
lor.gold..............89 ██████████████████████████████████████████████████▒
lor.opennet...........39 ███████████████████████████████████████
bot.habr.rss..........29 █████████████████████████████
linux.14..............15 ███████████████
spnet.stats............7 ███████
blcat.local............6 ██████
idec.test..............4 ████
std.game...............3 ███
std.rein...............3 ███
im.24..................3 ███
iii.nizya..............2 ██
bot.antropogenezru.rss.2 ██
std.hugeping.micro.....2 ██
english.talks..........1 █
crypto.talks...........1 █
ii.stat................1 █
spnet.uplink...........1 █
────────────────────────
Total                853

Ну тут у тебя SQLite по ходу? Это читерство ;)
Настоящие пацаны БД на текстовых файлах держат ;)

shaos> Ну тут у тебя SQLite по ходу? Это читерство ;)

Да, он самый, как и на клиенте. Меня групконкат спасал ещё на мускуле в бытность вебдевом (период моей жизни, в который я не хочу даже в воспоминаниях возвращаться), выручит и теперь. Очень мощная вещь. И из того же периода я вспомнил трюк с долбаными юнионами, кстати.

shaos> Настоящие пацаны БД на текстовых файлах держат ;)

Да кто против-то, только не жалуйтесь на тормоза при запросе кучи эх со слайсами.

> Вот и с чего бы такой обработчик долго задумывался, если он все эхи (после валидации) в один проход запрашивает?

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

> Ну дык инглиш, мазафака, ду ю спик ит? У меня, например, конента сколько угодно, но на более широкую аудиторию в основном за пределами чебурнетов.

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

и мне неинтересно болтать по английски. мне интересно по-фидошному :)

раньше хоть малое сообщество было, сейчас вообще сверхмалое

> А что, с этим есть какие-то проблемы? Ну, окромя того, что 95% населения даже тикль не хотят осиливать.

да, разумеется. клиентов сейчас нет. раньше все что-то делали, у меня был txt и http клиент, кто то делал клиент на dialog, был клиент на py-tk, на qt5, на android. MRD на java me пытался клиент набросать :) А сейчас только вечно живой цезий ну и твой клиент появился. Всё.

да, я буду писать про 0.7 новости на лоре и опеннете, делать что-то ещё.

но как, если тут и общения практически нет (надо хоть свою эхублог развивать активнее, ещё анекдотов хотя бы принести), и клиентов полторы калеки: нет инфраструктуры для заинтересовывания пользователей

> Да, он самый, как и на клиенте

Кстати SQLite расслабляет - лучше сразу на MySQL/MariaDB ориентироваться. Например в SQLite ключом можно чо угодно сделать (насколько я помню) и порядок записей всегда хронологический, а в MySQL если ты не сделал ORDER BY оно выльется как попало в зависимости от того как оно там внутри само заполнило дырки...

ahamai> причём здесь обработчик. я про нагрузку на сервер, когда с него опрашивают сразу все эхи разом.

Ну приведённый мной обработчик реагирует на запрос всех эх разом ровно так же, как и на запрос одной: формирует составной SQL-запрос с учётом срезов (если есть) и запрашивает инфу в базе. Откуда здесь дополнительная нагрузка на сам сервер возьмётся? Просто вложенных селектов будет больше, да. Но это уже проблема базы, хотя скулайт такие вещи обрабатывает крайне шустро. Не те объёмы, чтобы париться.

ahamai> и мне неинтересно болтать по английски.

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

ahamai> мне интересно по-фидошному :)

Что даёт фидошность? Широкие массы вот это понимают: есть проблема — есть исходящая из неё задача — есть решение. Здесь же какая задача для решения какой проблемы решается? Вот и донеси это до людей, если знаешь ответ на этот вопрос.

Для меня, например, ii/IDEC решает задачу цензуроустойчивости и распределённости при сохранении доступного и легковесного протокола. Поэтому я бы хотел его видеть вместо всяких форумов, мейлинглистов и прочих гуглогрупп как минимум. Везде. На всех языках. Хотя бы в нынешнем виде.

ahamai> раньше хоть малое сообщество было, сейчас вообще сверхмалое

Ну с таким подходом неудивительно.

ahamai> да, разумеется. клиентов сейчас нет.

Так это следствие мною указанного неосиляторства.

ahamai> нет инфраструктуры для заинтересовывания пользователей

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

> Ограничения по языку гораздо суровее отсекают аудиторию, чем ты можешь себе представить.

Я понимаю, но моя сеть не про это.

> Что даёт фидошность? Широкие массы вот это понимают: есть проблема — есть исходящая из неё задача — есть решение. Здесь же какая задача для решения какой проблемы решается? Вот и донеси это до людей, если знаешь ответ на этот вопрос.

фидо даёт душевность :) а идею я уже говорил в ii 0.1, построение малых сообществ и связь между ними

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

каждая станция это по сути своё малое сообщество, с какой-никакой тематикой. веб делать проще, да и пойнтам такое понятнее. но нужна и другая инфраструктура...

Это сообщение fiTy34vIAoqowA6GTpxX
пришло после этого d9fGfA6s7AVhMIQb0we9

Хотя хронологически они написаны в обратном порядке.
Я сфетчил их с ноды shaos. Там они тоже в обратном порядке. Хорошо бы разобраться, как такое происходит.
P.S. Edited: 2024-11-03 21:28:42

А почему они выводятся в обратном порядке? Я помню, давно, в клиенте для андроида часто такое было, и там специально делали, что бы они выводились в порядке "времени написания".

revoltech просто опрашивает все ноды своим клиентом, поэтому у него они появляются раньше, чем у shaos. потом он пишет ответ на станцию shaos, когда тот ещё меня не опросил. происходит потому что у shaos поллинг медленный, а у revoltech руки быстрые :)

btimofeev> А почему они выводятся в обратном порядке? Я помню, давно, в клиенте для андроида часто такое было, и там специально делали, что бы они выводились в порядке "времени написания".

Ну, я так понимаю выводятся в порядке в каком приняла её станция. Иначе возникают приколы, типа через 12 часов пришло сообщение и оно сразу затерялось -- его никто не увидит. Моя станция показывает так, как приняла. Станция shaos видимо тоже.

> Ну, я так понимаю выводятся в порядке в каком приняла её станция. Иначе возникают приколы, типа через 12 часов пришло сообщение и оно сразу затерялось -- его никто не увидит. Моя станция показывает так, как приняла. Станция shaos видимо тоже.

по идее, все так сейчас делают.

Дело не в том, что порядок другой. А в трм что сообщения информационно зависимы друг от друга. То есть на станцию shaos попал ответ на сообщение, которого не было на shaos. И видимо, не было на станции ahamai. А потом пришел сам ответ. Как это возможно?

hugeping> Как это возможно?

Вероятно, кто то отдает по фетчу не в том порядке..

жди моего ответа, когда хаос его польнет :)

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

hugeping>> Как это возможно?
hugeping> Вероятно, кто то отдает по фетчу не в том порядке..

Поясню ещё раз по другому.

Есть сообщение от ahamai fiTy34vIAoqowA6GTpxX (написано на станции blcat) 20:43:39
Есть сообщение-ответ d9fGfA6s7AVhMIQb0we9 от revoltech (написано на станции spnet) 20:51:24

Очевидно, что чтобы ответить на сообщение, сообщение ahamai сначала должно было быть получено станцией spnet. (Иначе, reply будет указывать на несуществующее сообщение.)

После этого, revoltech фетчит его и пишет ответ. Отправляет его на станцию spnet. И этот ответ НЕ МОЖЕТ встать РАНЬШЕ сообщения от ahamai. Но в индексе shaos он стоит РАНЬШЕ. Где-то есть проблема.

Надо разбираться.

Повторяю, меня не смущает сам факт нарушения порядка, но конкретно эта ситуация выглядит как невозможная. Кто то может меня разубедить?

я уже полдня назад ответ написал, только шаос медленный :)

http://ii.blcat.ru/rCu2q7hJ6T7vqKWjikjW

когда rt пишет свой ответ на shaos, моего сообщения там нет, физически

У меня появилась ГИПОТЕЗА.

1) revoltech фетчит себе куда-то локально эхи из разных мест
2) revoltech сфетчил сообщение ahamai с ноды blcat
3) revoltech формирует в своём клиенте ответ на сообщение и отправляет его spnet. reply указывает на сообщение с blcat
4) spnet НЕ ПРОВЕРЯЕТ reply вообще и берет это сообщение (считаю, должен был отбросить)
5) ЗАТЕМ spnet забирает сообщение на которое был ответ с blcat

Это всё объясняет. revoltech? shaos? я прав?

iiii> я уже полдня назад ответ написал, только шаос медленный :)
iiii> http://ii.blcat.ru/rCu2q7hJ6T7vqKWjikjW
iiii> когда rt пишет свой ответ на shaos, моего сообщения там нет, физически

Ага, я эту гипотезу и выдвинул тоже (см 5R0bd1lXAfHAJH9bFWvs )
Но spnet не должен был принимать сообщение с битым reply! В этом проблема. Это надо фиксить.