Difrex> В тему про чатики, форумы, и.т.д
Difrex> А кто пользуется сабжем? Я вот завел себе аккаунт, думаю бота натравить туда и постить статистику
Difrex> по IDEC. Да и вообще репостить туда из IDEC. Жаль только, что это твиттероподобное нечто...

Я пользуюсь.
Но это больше соц. сеть, разговоры ориентированы вокруг людей, а не тем.

В тему подумалось, что форумы похожи на BBS.
Только вот BBS объединились эволюционировав в Fidonet и т.п.
А вот интернет форумы ничего не делают.
И их давно обошли соц. сети. Некоторые из которых добавили группы, что по функционалу похоже на форумы.
Вот такой круговорот.

+++ Caesium/0.4 RC1

mirage>> Продолжу тут тоже.
mirage>> У этой схемы нашел один минус - кто угодно может напушить что угодно на ноду. Нужна аутентификация нод.
Difrex> У нас есть уже в стандарте авторизация для ноды. Можно её и использовать.
Difrex> Смотри тут https://ii-net.tk/idec-doc/?p=extensions про push.

То есть каждая нода для каждой должна выдать по паролю? Это же не масштабируется.

G2I>> Мне кажется для netmail лучше push модель.
G2I>> point1 ---push---> node1 ---push---> node2 ---pull---> poin2
G2I>> Тогда письмо будут видеть только src и dst ноды. Но нужен будет nodelist с адресами нод.
AL> Я тут отвечу пока. Вообще, доля здравого смысла в этом есть. Плюсы очевидны. Опять таки, если оглядываться на фидонет, то там нетмейл тоже сбоку от эхомейла. И даже маршруты прохождения почты разные зачастую. Может, попробуем такой вариант? Хотя, сейчас мне надо iing уже выкинуть на свалку и на базе idec (который моя реализация) запилить новую таверну. А там уже можно и экспериментировать.
AL> Лично мне определённо нравится что не надо ничего сбоку прикручивать типа того же PGP, что нет необходимости прохождения нетмейла по лишним нодам. Заодно будет повод актуализировать нодлист :)

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

Хотя есть еще более простой способ.
srcnode делает запрос на dstnode со списком msgid для dstnode. dstnode запрашивает в обратном запросе по нодлистовому адресу srcnode эти msgid и получает сообщения.

Сабж.

+++ Caesium/0.4 RC1

AL>>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage>> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
AL> Ещё проще так, как есть. Потому что оно уже есть и оно простое.
AL> Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.

Этот x/c нужен же для u/e?
Смотрю в описание u/e: смещение указывается одно для всех эх в запросе?
Получается не оптимально. Ведь в разных эхах разное количество апдейтов.
А вот например эхаA:idA/эхаB:idB/.... будет оптимальнее.

+++ Caesium/0.4 RC1

AL>>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage>> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
AL> Ещё проще так, как есть. Потому что оно уже есть и оно простое.
AL> Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.

Решаемая задача: скачать обновление индекса.
Предложеное решение: запросить все что после конкретного ID.
Я не понял зачем ты спросил в этом случае про слайсы, они тут не нужны.
Я подумал слайсы нужны что бы скачивать обновление индекса по частям, если например есть опасения в слишком большом обновлении индекса.
Получается, если надо качать все обновление индекса за раз, то один запрос.

+++ Caesium/0.4 RC1

AL> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.

По нетмайлу готов proposal. Просто чтобы внимание не распылять по одной теме пишу :)

+++ Caesium/0.4 RC1

>>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Peter>> Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.
AL> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.

Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах
и время обработки запроса. С ID проще, строже.

+++ Caesium/0.4 RC1

AL>>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage>> Несколько десятков ID и получит. Только новое.
AL> Каким образом фетчер узнает по одному ID сколько ему сообщений зпрашивать в слайсе? Вот он запомнил, что поледним получил сообщение mzu2V8Iz3VIAVeDg0TOi. Как он узнает сколько именно тянуть?

Фетчер знает сколько ему надо максимум запросить чтобы не подавиться, по каким-либо причинам.
Допустим это 100 idшников.
Он запрашивает 100 записей от последнего id. В итоге будет 2 случая:
1. Придет меньше 100 id - запоминаем последний, конец.
2. Придет 100 id - запоминаем последний и запрашиваем снова 100 от него.

mirage>> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage>> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage>> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage>> И получает ID4 ID5 ID6 и запоминает ID6.
mirage>> Весь индекс тянуть заново не надо.
AL> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.

Это было предложение на вопрос в дискуссии о не совсем ясном числе в ответе API. Ну и это может быть расширением.

+++ Caesium/0.4 RC1

Peter>> Фехи не поддерживаются этой нодой (syscall) :)
mirage> Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/

Кажется я доменом ошибся. В одной доке .tk в другой .ml
В итоге в клиенте одно, в браузере другое :)

+++ Caesium/0.4 RC1

AL>>>> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
mirage>>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>>> Только возникнет проблема если это сообщение будет удалено.
AL>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage> Несколько десятков ID и получит. Только новое.
mirage> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage> И получает ID4 ID5 ID6 и запоминает ID6.
mirage> Весь индекс тянуть заново не надо.

Ну и можно тоже тянуть слайсами. Просить N ids от последнего id. Последний запомнить и опять N от последнего.

+++ Caesium/0.4 RC1

AL>>> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
mirage>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>> Только возникнет проблема если это сообщение будет удалено.
AL> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.

Несколько десятков ID и получит. Только новое.

Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
На ноду еще приходят сообщения: ID4 ID5 ID6.
В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
И получает ID4 ID5 ID6 и запоминает ID6.
Весь индекс тянуть заново не надо.

+++ Caesium/0.4 RC1

Peter> Фехи не поддерживаются этой нодой (syscall) :)

Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/

+++ Caesium/0.4 RC1

mirage>>>> | GET /x/с/<параметры>
mirage>>>> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage>>>> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
vit01>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage>> Тогда это уже не количество сообщений будет, а что-то другое.
AL> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.

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

Другой вариант при запросе методом инкрементного листинга нода может записывать в файл эхи метку вида ">node_name"
и при следующем запросе отдавать список от этой метки и двигать ее в конец.

Я больше склоняюсь к первому варианту, он более гибкий, простой и стабильный.
Надо только продумать удаление, без удаления id сообщения из списка.

+++ Caesium/0.4 RC1

mirage>> В коде нашел fecho, но без авторизации похоже не работает. Хотя вручную API без авторизации все отдает.
AL> Это баг в цезии, который я всё никак не поправлю. Просто времени сейчас нет особо. Попробуй вбить произвольную строку авторизации в конфиг и получить файлы.

Пробовал. Не фетчит.

+++ Caesium/0.4 RC1

Сабж как? В документации нет.
В коде нашел fecho, но без авторизации похоже не работает. Хотя вручную API без авторизации все отдает.

+++ Caesium/0.4 RC1

mirage>> | GET /x/с/<параметры>
mirage>> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage>> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
vit01> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.

Тогда это уже не количество сообщений будет, а что-то другое.

vit01> // удалять сообщения может только держатель ноды, и это в будущем так и останется
mirage>> | /u/m/msgid/msgid/msgid
mirage>> Количество msgid лимитировано длиной GET запроса на сервере.
mirage>> Почему вместо этого не передавать msgid в POST?
vit01> С точки зрения масштабируемости протокола это хорошая идея, но на практике ещё никому не пригождалось скачивать сообщения очень большими порциями.
vit01> Скорее всего, Рома просто забыл про такой вариант, а после него об этом никто не задумывался.

Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.


+++ Caesium/0.4 RC1

Читаю про сабж и не понимаю.

| GET /x/с/<параметры>
| Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.

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


| /u/m/msgid/msgid/msgid

Количество msgid лимитировано длиной GET запроса на сервере.
Почему вместо этого не передавать msgid в POST?

+++ Caesium/0.4 RC1

| Esc - выход из режима чтения в режим выбора эхоконференции

Зачем выбран Esc для этой функции? Он в ncurses тормозит.

| F10 - выход из клиента

Лучше не использовать функциональные клавиши. F10 например у меня - меню терминала.


+++ Caesium/0.4 RC1

Hi All!

Из документации:
"Берёт своё начало от "Клуба хороших людей" (2014) и работает на распределённом протоколе IDEC
(ii-like Data Exchange Convention), форкнутом от ii (всё от того же "Клуба")."

Что за клуб и что за ii?
Попытки найти источник не были успешными.

+++ Caesium/0.4 RC1