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

Понял

В im.24 ответов нет. lor.gold я переконверчу под topicid. Новой эхой обновлённой сети будет naste.ne, и она тоже будет основой обновлённой сети с topicid. Ща главное доделать все свои планы.

А т.е. это не глобально включать? Только для отдельных эх?

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

а вдруг какие клиенты/ноды поперхнутся от лишних тегов?
я точно знаю, что idec.spline-online.ru будет норм, т.к. я проверил его через ii://idec.test, послав туда сообщение с вручную расширенными тегами какое-то время назад:

ii://P3r4mlQ5ynJf6VpmMn8j

tuple> Опять цыганские фокусы с бегом впереди паровоза :)
tuple> В общем "ленте" - https://club.hugeping.ru/echo/all :
tuple> - ii://TLSU6VMtvHxMzuCHvszE находится выше, хотя отправлено в 11:13
tuple> - ii://B2s0Ze9vgPVEz7hLae6o находится ниже, хотя отправлено в 11:28

А почему ты считаешь это неверным? Если сообщения будут не в порядке получения узлом, то как тогда фетчить, если не забором полного индекса? Вдруг там придёт сообщение в начало индекса, а у тебя фетч на срезах?

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

hugeping> Да. Но видишь, свобода принимать сообщения от поинта с repto на отсутствующее сообщение важнее. Так что или терпим или снимаем с фетча. Свобода, она такая :)

repto на отсутствующее сообщение имеет смысл.

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

hugeping>> Да. Но видишь, свобода принимать сообщения от поинта с repto на отсутствующее сообщение важнее. Так что или терпим или снимаем с фетча. Свобода, она такая :)
doesnm> А поменять местами уже на ноде можно?

А это бандитизм нацеленный на нарушение целостности эхи в сети.

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

shaos> Это значит мне надо опрашивать blcat чаще чем раз в 5 минут чтобы эстетическую красоту соблюсти :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

shaos>> Нельзя запрещать сообщения с неизвестным repto т.к. невозможно обеспечить 100% надёжную когерентность баз данных в этой сети - где-то всегда будут неувязки (какие-то временные, какие-то навсегда)
hugeping> Это относится к обменам между нодами. Я же говорю о проверке сообщений от поинтов. Это нормально. Единственная ситуация, и мы ее сейчас наблюдаем, когда поинт берет сообщения от одной ноды и потом пушит свое - другой. Это не норма. А обмен между нод я не предлагаю фильтровать. Но ощущение, что меня никто не читает (или нн понимает). :)

А почему поинт не может писать через тот узел, через который ему больше нравится? Какая причина у этого, кроме repto, который ни на что не влияет по факту?

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

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 в теле сообщения (которое на старых нодах просто будет показано первой строчкой в теле сообщения и это наверное ок), а то получится разрыв при показе, а исправлять пост-фактум уже нельзя т.к. хеш слетит (я всё ещё ратую за правильный хеш, по которому можно проверить целостность данных)...