doesnm>> А поменять местами уже на ноде можно?
hugeping> Не уверен, что хорошая идея так как запись сообщений в бд не буферизируется. Разве что вручную. Но я бы просто фетч снял если честно. :) Тебе эта эха нужна?

А что кроме этой эхи читать? Разве что в linux эхе иногда сообщения появляются

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

hugeping>> Не уверен, что хорошая идея так как запись сообщений в бд не буферизируется. Разве что вручную. Но я бы просто фетч снял если честно. :) Тебе эта эха нужна?

doesnm> А что кроме этой эхи читать? Разве что в linux эхе иногда сообщения появляются

Вот и я терплю. :) Пока.

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

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

Или проверять что поинт тебе шлёт сообщение с repto на отсутствующее сообщение. Не нода! Поинт.

> Или проверять что поинт тебе шлёт сообщение с repto на отсутствующее сообщение. Не нода! Поинт.

И где я это отсутствующее сообщение буду искать? Ломиться всех опрашивать на всякий случай?

Вобщем покa сделал забирание blcat каждые 10 минут - 3,13,23,33,43,53

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

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

>> Или проверять что поинт тебе шлёт сообщение с repto на отсутствующее сообщение. Не нода! Поинт.

shaos> И где я это отсутствующее сообщение буду искать? Ломиться всех опрашивать на всякий случай?

Просто запрещать.
Это заставит поинта не делать плохо. :) Потому что сейчас revoltech ведёт себя не как поинт, а как что то среднее между поинтом и нодой. Кстати, когда он сделает себе ноду и будет работать с ней, такая проблема уйдет. (Но, возможно, придут другие? :)))

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

Вот я тут в декабре 2021 года свои мысли излагал применительно к IDEC

ii://FvAoTezksrljZy6PtSQ2

doesnm>>> А поменять местами уже на ноде можно?
hugeping>> Не уверен, что хорошая идея так как запись сообщений в бд не буферизируется. Разве что вручную. Но я бы просто фетч снял если честно. :) Тебе эта эха нужна?
doesnm> А что кроме этой эхи читать? Разве что в linux эхе иногда сообщения появляются

Кстати посоветуйте эхи которые почитать можно. Подписан на idec.talks, develop.16, linux.14, retro.talks, idec.local

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

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

Хотите сказать что это сообщение шло до станции 2 дня? или hugeping снимал фетч

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

doesnm> Кстати посоветуйте эхи которые почитать можно. Подписан на idec.talks, develop.16, linux.14, retro.talks, idec.local

Весь набор собран. Хотя... А где же pipe.2032 - Болталка?

doesnm>> Кстати посоветуйте эхи которые почитать можно. Подписан на idec.talks, develop.16, linux.14, retro.talks, idec.local
tuple> Весь набор собран. Хотя... А где же pipe.2032 - Болталка?

На tgi она в read-only. Я думал она тут чисто как архив

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

А idec.local чья?

Да кто его знает - опять наверное психанул? ;)

shaos> А idec.local чья?

local небось на то и local, что только на одной станции работает.

shaos>> А idec.local чья?
tuple> local небось на то и local, что только на одной станции работает.

Лучше: эта эха есть только на моем телефоне. Сейчас она пустая. Создал для экспериментов, но руки не дошли, да и конвертер написать не выходит. Мб лучше её назвать doesnm.local?

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

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

Это относится к обменам между нодами. Я же говорю о проверке сообщений от поинтов. Это нормально. Единственная ситуация, и мы ее сейчас наблюдаем, когда поинт берет сообщения от одной ноды и потом пушит свое - другой. Это не норма. А обмен между нод я не предлагаю фильтровать. Но ощущение, что меня никто не читает (или нн понимает). :)

лучше

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

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

Не согласен, что ограничение бессмысленное. Но продолжать не буду, все скзано. :)

> Поинт это по сути уже «полунода» ;)

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

а новонод не обязан выкачивать все 2000+ сообщений из idec.talks, он их просто читать не будет

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

> и мы ее сейчас наблюдаем, когда поинт берет сообщения от одной ноды и потом пушит свое - другой

это штатная ситуация. via нода эха у меня была в первых клиентах. по-моему, сети надо перейти на topicid, а потом и на новые эхи

Подписывайся у меня на lor.gold и im.24, там есть/будет трафик и сообщения можно слать в любом порядке :) поднимать pipe.2032 не вижу смысла, потому что нет смысла гонять несколько тысяч архивных сообщений, не нужных никому, ибо это просто болталка

> Не согласен, что ограничение бессмысленное.

есть на лоре XXXX модераторы. кто-то кидает вброс, но потом на этом месте разворачивается вполне нормальная и вполне интересная дискуссия. может пройти несколько дней, очень интересная тема, все вовлечены. и потом приходит модератор XXXX и режет исходное сообщение. И ВМЕСТЕ С ЭТИМ, XXX, РЕЖЕТ ВСЮ ВЕТКУ. там нельзя вырезать только исходное, только всю ветку. XXXX вся история ii это против этого (я Dimez-а за такое хотел убить, просто и конкретно, это XXXX в степени XXXX, ЭТО УБИЙСТВО КОНТЕНТА). поэтому в моей сети я полностью против этого, контент первичнее правил и он должен жить. только деструктивный контент должен страдать, а не обсуждение после него.

ОТМОДЕРИРОВАН МАТ

> Это заставит поинта не делать плохо. :)

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

Худший вариант создания сообщества - отдать это программистам. Я говорил это в 2003, говорю и в 2024. Какая кочевряжная грусть, из такого потенциала сделать ЭТО.

>> Не согласен, что ограничение бессмысленное.

ahamai> есть на лоре XXXX модераторы. кто-то кидает вброс, но потом на этом месте разворачивается вполне нормальная и вполне интересная дискуссия. может пройти несколько дней, очень интересная тема, все вовлечены. и потом приходит модератор XXXX и режет исходное сообщение. И ВМЕСТЕ С ЭТИМ, XXX, РЕЖЕТ ВСЮ ВЕТКУ. там нельзя вырезать только исходное, только всю ветку. XXX вся история ii это против этого (я Dimez-а за такое хотел убить, просто и конкретно, это XXXX в степени XXXX, ЭТО УБИЙСТВО КОНТЕНТА). поэтому в моей сети я полностью против этого, контент первичнее правил и он должен жить. только деструктивный контент должен страдать, а не обсуждение после него.

Я снимаю idec.talks с фетча.
Моё участие в сети idec я ещё обдумаю, но не сейчас. Сейчас буду спать.