shaos>> Это значит мне надо опрашивать blcat чаще чем раз в 5 минут чтобы эстетическую красоту соблюсти :)
hugeping> Или проверять что поинт тебе шлёт сообщение с repto на отсутствующее сообщение. Не нода! Поинт.

Ну шлёт и шлёт. У поинта тоже может быть несколько аплинков.

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

>>> Или проверять что поинт тебе шлёт сообщение с repto на отсутствующее сообщение. Не нода! Поинт.
shaos>> И где я это отсутствующее сообщение буду искать? Ломиться всех опрашивать на всякий случай?
hugeping> Просто запрещать.
hugeping> Это заставит поинта не делать плохо. :) Потому что сейчас revoltech ведёт себя не как поинт, а как что то среднее между поинтом и нодой. Кстати, когда он сделает себе ноду и будет работать с ней, такая проблема уйдет. (Но, возможно, придут другие? :)))

Ущемлять поинтов только из-за нормальной работы сети? Может, тогда перетрясти стандарт.

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

hugeping> Ну, у нас федерация, я не настаиваю. Но как по мне - лучшее решение.

Лучшее потому что тогда не ломается одно из возможных визуальных представлений? Может, лучше просто как-то на стороне читалки эту проблему решать? Источником сообщений может быть что угодно. Целостность тредов при этом не гарантируется. Это прямо одна из основных идей была ещё в ii -- ты можешь взять сообщение хоть с какого-нибудь QR-кода в подъезде и оно упадёт в твою базу.

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

shaos>> У меня статистика считается за сутки сразу после полуночи по тихоокеанскому времени - это 11 утра по Москве или 6 вечера по Владику, поэтому результат любого изменения лучше смотреть на следующий день.
shaos>> И кстати у меня ведь теперь есть ii://spnet.uplink где можно это обсуждать :)
doesnm> Хотите сказать что это сообщение шло до станции 2 дня? или hugeping снимал фетч

Узел может снимать фетч с кого угодно и когда угодно на своё усмотрение.

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

shaos> Все существующие IDEC-клиенты позволяют забирать эхи из разных источников (даже там, где пользователь не является поинтом). Так что это не только не запрещено, а вовсе даже наоборот - приветствуется! Поэтому не надо выдумать бессмысленные ограничения и ненужные правила на пустом месте. Поинт это по сути уже «полунода» ;)

Поинт в IDEC может создавать эхи, писать любые сообщения. Единственное его отличие от ноды в том, что он не может отдавать бандлы.

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

shaos>> Поэтому не надо выдумать бессмысленные ограничения и ненужные правила на пустом месте. Поинт это по сути уже «полунода» ;)
hugeping> Не согласен, что ограничение бессмысленное. Но продолжать не буду, все скзано. :)

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

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

> А можно про эти самые "Квитки" поподробнее? Как предполагалось привязывать ключ к пользователю? Что если на какой-то левой станции появится другой ключ с привязкой к тому же имени пользователя?

это был эксперимент. использовался rsa. есть регцентры, которые кодируют имя, адрес, опции и цифровую подпись в base64 строку. это квиток. с этим квитком приходишь на любую станцию, где есть pubkey этого регцентра и тебя авторизует. вещь довольно бесполезная, но было интересно попробовать

> это был эксперимент. использовался rsa. есть регцентры, которые кодируют имя, адрес, опции и цифровую подпись в base64 строку. это квиток. с этим квитком приходишь на любую станцию, где есть pubkey этого регцентра и тебя авторизует. вещь довольно бесполезная, но было интересно попробовать

поянтно, спасибо

я хочу на е-мейл попробовать завязаться

> Сообщение с repto но без topicid мы не трогаем. Текущие цепочки без topicid не трогаем. Пока это опция

Есть одна неувязочка - берём тот же самый случай, когда юзер отвечает на какое-то локальное сообщение, которого ещё нет на узле - пользовательский клиент знает что там есть topicid, но по формату засылает сообщение c @repto но без topicid, а узел не может проверить есть ли у этого repto сообщения тэг topicid т.к. этого сообщения на узле нету. Выходит пользовательский клиент, зная этот самый topicid должен поставить его следом за @repto в отправке? Типа

@repto:fskjfskjfsdkjfds
@topicid:ksjdkjdgkdgkkj

???

Я писал же, что в 99.9% в случае ответа через веб интерфейс и в 98% случаев ответа через клиент это сообщение есть. Если нет, ничего не ставится

> Я писал же, что в 99.9% в случае ответа через веб интерфейс

Ну через веб-морду если отвечаешь, то понятно что repto-сообщение есть (иначе как бы ты на него отвечал? ;)

> и в 98% случаев ответа через клиент это сообщение есть. Если нет, ничего не ставится

А вот в случае с клиентом наверное надо предусмотреть такой вариант - клиент наверное должен перед посылкой торкнуться на ноду и если там repto-сообщения ещё нету, наверное таки должен присовокупить @topicid в теле сообщения (которое на старых нодах просто будет показано первой строчкой в теле сообщения и это наверное ок), а то получится разрыв при показе, а исправлять пост-фактум уже нельзя т.к. хеш слетит (я всё ещё ратую за правильный хеш, по которому можно проверить целостность данных)...