На http://ii.blcat.ru/idec.talks правильный порядок - значит blcat берёт сообщения с меня чаще, чеми я с него, а revoltech по-видимому читает сразу всех и часто - я просто вижу его ответы раньше т.к. он мой поинт и отвечает через меня...

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

Такое, кстати, является вполне штатной ситуацией. Сообщения в индексе располагаются в порядке получения нодой. Все ноды получают сообщения в разном порядке.

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

doesnm>> Отдачу сделать по CGI (читерство), а вместо nc взять /dev/tcp (фича баша)
revoltech> Да что ж везде одни теоретики... /dev/tcp только для клиентских соединений работает. Сервер сугубо на нём не сделаешь.

Перечитай на что отвечаешь. Серверная часть на CGI, клиентская на /dev/tcp. Как раз то, что ты пишешь, и выходит. Ну блин.

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

shaos> Возможно revoltech берёт сообщения Ромы прямо с blcat.ru и отвечает на них через меня

Я сейчас опрашиваю ноды в таком порядке: 1) https://sprinternet.io/iii, 2) https://hugeping.tk, 3) http://ii.blcat.ru, 4) http://idec.spline-online.ru. Соответственно, если его ответов на твоей и у пинга нет, то они выкачиваются и добавляются в локальную базу с ii.blcat.ru.

shaos> а revoltech по-видимому читает сразу всех и часто

Не так уж и часто. У меня фетч чисто в ручном режиме по кнопке на данный момент. Но порядок чтения уже написал.

Рома, не нервничай. У меня 3й день подряд мигрень, но я решил немного пояснить ситуацию, не влезая в детали. Как ты предложил. Но по существу! Мой ответ частично обращён к твоим другим сообщениям.

# Про дизайн и простоту ii

Я прекрасно понимаю твои доводы о простоте и сам практикую решения проблем "не в лоб". Это действительно круто, когда проблему можно "обойти" не решая её вообще. Plan9, кстати, отличный пример этого подхода. Я пришёл к этому не сразу, но когда так понял - сразу начал с радостью практиковать. На работе и в быту. И про питон + падения некорректных данных я тоже нормально отношусь. Мы пишем "чистые (сейчас не в терминах ФП)" функции при этом. А контролируемое падение питона (да ещё в рамках веб-фреймворка, например) это, обычно, не является проблемой безопасности.

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

# Проблемы "базового" ii

Собственно это и есть краеугольный момент. Либо мы воспринимаем особенности ii проблемами либо нет. Я согласен, можно проявить аскетичность, смирение и "вложить" себя в базовый ii который предполагает:

- полный фетч;
- архивирование и "бегучесть" эх.

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

# Обсуждаемые изменения стандарта idec

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

# Новый стандарт

Вот. А теперь самое интересное. Есть чистый стол. Есть ii. Есть упрощённый idec. И дальше развилка.

1) мне достаточно ii
2) мне достаточно idec
3) я могу сделать лучше

Ты можешь мне сказать где ты? Вроде бы ты на пп1, но при этом я вижу в твоих сообщения обсуждения решений тогоже sf, h которые вроде бы демонстрируют что то из пп3.

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

Я лично могу сформулировать несколько вариантов:

1) ii с полным фетчем но с надёжным механизмом проверки изменений в эхах узла (это то, что у тебя hash эх
2) ii с возможностью забирать n последних сообщений (это твой lim и/или sf)
3) ii с отдачей списка msgid в обратном порядке (моя идея)

Каждая из них мне не нравится по своим причинам:

1) Необходимостью хранить счетчики/хеши/что угодно - мой шкурный интерес. Я тоже иногда люблю экстремальную простоту. Приемлемо, но не прекрасно.

2) Невозможно "чётко" подобрать лимит такого захлёста. Сколько надо ставить чтобы и разброс порядка не влиял и интенсивность чата? 100? А если сисоп уехал в круиз а за пол года его отсутствия пришло 10000 пользователей? Нет, не надёжно.

3) Вроде всё четко технически (читаем и обрываем связь когда считаем нужным) но.. Есть элемент хака.

Текущий idec в терминах простоты мне тоже НЕ НРАВИТСЯ, но! Я НЕ МОГУ придумать лучше и так, чтобы были решены те недостатки, о которых я говорю. И вот слайсы, достаточно просты и их таки решают! И этот адаптивный фетч который ты называешь оверинженирингом, для меня это вынужденный шаг. Другого пути я просто не вижу. Если хочу избавиться от полного фетча и при этом иметь надёжность которая позволила бы мне бросить ноду и не следить за ней год (хотя бы и гипотетически)

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

Подумал тут ещё... Хочу добавить. Может какой-то мозговой штурм начнётся. Но это все в рамках некоторого "потенциально нового" ii-подобного протокола. idec3 :)

Адаптивный фетч тоже не 100% надёжен. Но ненадёжен по-другому. Речь о той точке алгоритма, когда мы останавливаемся. Когда видим что такое сообщение у нас есть и начинаем фетч. Это лучше чем жёсткий лимит, но всё-ещё не абсолютно надёжно.

Поэтому мне кажется, что в "идеальном" протоколе нужно выбрать что-то принципиально иное.

1) Либо полный sync если хоть что то поменялось (но тогда стоит вернуться и к перекатыванию эх, потому что в этом решении нет масштабировании при бесконечном росте эхи. Короче - это "принятие" ii)

2) Выборка, основанная на времени.

Вроде бы Рома делал такое когда-то, может ошибаюсь. Запрос вида: дай мне сообщения которые пришли с такого-то времени (время - ну пусть секунды эпохи unix в utc).

Да, тогда мы немного завязаны на время, но это вроде бы окончательно решает всё. Или нет?

Что думаете?

hugeping> Но это все в рамках некоторого "потенциально нового" ii-подобного протокола. idec3 :)

Стоило прийти в idec, как его уже хоронят :)

tuple> Стоило прийти в idec, как его уже хоронят :)

Не надо вбросов! Давай по существу.

P.S. Ipv4 тоже хоронят давно, но что-то никак. :)

hugeping> Что думаете?

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

Так что sf=hash так же надёжна как и время, если мы после каждого фетча успешного записываем hash последнего взятого сообщения для этой ноды.

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

Если сохранять хеш последнего принятого сообщения для КАЖДОЙ опрашиваемой ноды, то тогда да - имеет право на жизнь. По идее оно может собой заменить хеш списка сообщений для эхи (мой /x/h или /list.txt?h=1) т.к. список не может расти изнутри - только с конца...

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

shaos> Если сохранять хеш последнего принятого сообщения для КАЖДОЙ опрашиваемой ноды, то тогда да - имеет право на жизнь. По идее оно может собой заменить хеш списка сообщений для эхи (мой /x/h или /list.txt?h=1) т.к. список не может расти изнутри - только с конца...

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

shaos> Время ненадёжно т.к. сообщения приходят так как приходят из-за особенностей роутинга и последовательности фетчинга, а вовсе не в хронологическом порядке, и старое сообщение вполне может внезапно "всплыть" выше по списку чем более новые ответы на него (см. беседу revoltech с Ромой).

Я имел в виду время принятия сообщения нодой, а не время создания сообщения, конечно.

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

А ну это сейчас вообще никем не фиксируется

shaos> А ну это сейчас вообще никем не фиксируется

Гм. Действительно, как-то я не подумал об этом. :)

Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять, а если только в файлах, то по времени создания файла? Можно попробовать - всё равно ведь не всё перебирать надо, а только последние сообщения в эхе пока не найдём «прошлое»…

shaos> Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять, а если только в файлах, то по времени создания файла? Можно попробовать - всё равно ведь не всё перебирать надо, а только последние сообщения в эхе пока не найдём «прошлое»…

Да не, ерунда это всё. Не могу я, в общем, ничего принципиально иного придумать. Ну, а о реверсной выдачи ID что думаешь?

Реверсная выдача это когда клиент качает список в обратном порядке пока не дойдёт до знакомых хешей? Это может работать только для отдельных эх (типа /e но в обратном порядке).

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

echo.1:msgid999
echo.2:msgid998
echo.1:msgid997
…

> Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять

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

> Он не то чтобы его заменяет, а решает бОльшую задачу - sync только новых сообщений. При этом /x/h не нужен, так как решена более общая задача. Но хеши надо хранить для всех эх всех нод с которых мы фетчим...

x/h единственный валидный триггер. он бывает в двух состояниях "эха изменилась" и "эха не изменилась". всё остальное не даёт полных гарантий.

> Собственно это и есть краеугольный момент. Либо мы воспринимаем особенности ii проблемами либо нет. Я согласен, можно проявить аскетичность, смирение и "вложить" себя в базовый ii который предполагает:

Это не проблема. Это основа. Хотел вчера ответить revoltech, но отвечу сразу здесь.

ii это социальная сеть малых сообществ. Так она всегда и называлась. Она не про технологии, она про любительское программирование, радиолюбительство, клуб юного техника и прочие порождения Дворца Пионеров. Чтобы каждый мог собрать свою ноду и общаться со своим хомячком. Потому что это просто. Весь протокол постоянно упрощался. Какие вообще слайсы?

Ещё мне там понравилось, что второй человек уже указывает, что в выводе /u/e может быть мусор. Они походу вообще не понимают сути. Ты синкаешься с доверенным узлом по предельно формализированному и простому формату. Единственный вариант, когда там может быть мусор - это СБОЙ. И как можно в этой ситуации поступать "ну давайте что-нибудь попробуем вычленить". Да ты можешь получить 800 дублей или ещё чего похуже. Вся история и фидо, и ii, говорят об этом.

> Ты можешь мне сказать где ты? Вроде бы ты на пп1, но при этом я вижу в твоих сообщения обсуждения решений тогоже sf, h которые вроде бы демонстрируют что то из пп3.

меня не интересует стандарт. ВООБЩЕ. у меня есть /u/e, который проживёт ещё 100 лет и переживёт всех модернизаторов.

я просто напоминал о 2014 году, когда делали стандарт. сейчас 2024 год и опять делают стандарт. на этом всё. умному - достаточно.

Мне, старому фидошнику, непонятно, зачем фетчить сразу несколько станций. :) лично я качаю только с shaos

> 2) Невозможно "чётко" подобрать лимит такого захлёста. Сколько надо ставить чтобы и разброс порядка не влиял и интенсивность чата? 100? А если сисоп уехал в круиз а за пол года его отсутствия пришло 10000 пользователей? Нет, не надёжно.

полный фетч периодически необходим. и он решает все вопросы. вопросы "уехал в круиз на полгода" тоже решает полный фетч. а лимиты, как и любой другой k/v, можно легко добавить вообще не ломая совместимость с любой версией ii, просто меняя endpoint (что было заложено изначально, когда схема /z менялась на схему /u)

но вообще причина не особо понятна. я опрашиваю shaos каждые 5 минут, сейчас слайсами раньше полным фетчем. до h/x и с полным фетчем это 12 мб в сутки (при этом я тяну rss-эхи). после h/x и с полным фетчем 2-4 мб в сутки. (со слайсами, кстати, трафик почему-то нифига не уменьшился). в http есть gzip, который тоже экономит трафик.

По мне проблемы ровно три: отсутствие контента, отсутствие клиентов, отсутствие юзеров. Проблему внезапного лишнего трафика решает элементарное внедрение хэширования эх - оно сокращает трафик, и в отличие от адаптивных и ?sf даёт полную гарантию синхронности эх.

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

shaos> Для минимизации количества запросов можно все эхи разом опросить - для этого придётся городить новый вызов и новый формат ответа

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

ahamai> Чтобы каждый мог собрать свою ноду и общаться со своим хомячком. Потому что это просто. Весь протокол постоянно упрощался. Какие вообще слайсы?

Дык я и начинаю собирать свою ноду. Слайсы мне в этом вообще не помешают. А ещё у меня там будет автопереключение транспортов — по одному и тому же порту можно будет запрашивать как HTTP, так и Nex/Gopher. И потом ещё после стандартной реализации IDEC будет сбоку приделан совсем несовместимый с ним протокол, ещё более простой и при этом решающий ровно те же задачи, но куда более красиво, компактно и всего пятью эндпоинтами.

ahamai> Ещё мне там понравилось, что второй человек уже указывает, что в выводе /u/e может быть мусор.

Не в выводе, а на входе. Это существенная разница.

ahamai> Они походу вообще не понимают сути. Ты синкаешься с доверенным узлом по предельно формализированному и простому формату.

А ты уверен, что ты сам-то суть понимаешь? Это не про доверенные узлы вообще. Для запроса /u/e пароль не нужен, тебе запрос с дичью вместо эхонеймов может прислать вообще кто угодно, когда угодно и в каком угодно количестве.

ahamai> Единственный вариант, когда там может быть мусор - это СБОЙ.

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