> 4) spnet НЕ ПРОВЕРЯЕТ reply вообще и берет это сообщение (считаю, должен был отбросить)

почему он должен его отбросить-то? это абсолютно нормальная ситуация для распределённой сети, штатная, в фидо тоже такое было сплошь и рядом

почему оно битое-то? это абсолютно штатная ситуация и так было всегда

iiii> почему оно битое-то? это абсолютно штатная ситуация и так было всегда

Поинт шлет ноде сообщение с reply на несуществующее сообщение и это ок? Я не согласен. Я рублю и буду дальше это делать. Ну, главное что причина понятна.

> Поинт шлет ноде сообщение с reply на несуществующее сообщение и это ок?

Естественно. Что значит несуществующее, у тебя на ноде его нет не значит, что оно не существующее. В этапе фетчинга может сбойнуть фетчер или сервер, и у тебя сразу 40 сообщений могут вылететь из базы, и прийти только следующим фетчингом.

>> Поинт шлет ноде сообщение с reply на несуществующее сообщение и это ок?

iiii> Естественно. Что значит несуществующее, у тебя на ноде его нет не значит, что оно не существующее.

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

> Если поинт одновременно питается у нескольких нод - это ненормальная ситуация.

тут я согласен :) но в рамках распределённой сети ситуация вообще штатная

по мне так тут shaos-у надо почаще фетчить других :)

iiii> тут я согласен :) но в рамках распределённой сети ситуация вообще штатная

Я устал объяснять, почему эта ситуация не штатная. Конкретно эта, а не вообще некоторые абстрактные перемешивания. Выше все детально описано. Кому надо, разберутся.

iiii> по мне так тут shaos-у надо почаще фетчить других :)

Это не спасло бы от конкретно этой ситуации.

iiii>> по мне так тут shaos-у надо почаще фетчить других :)

hugeping> Это не спасло бы от конкретно этой ситуации.

Ладно, я реально устал. Пока перестаю читать idec.talks, а то напрягаюсь слишком.

> Я устал объяснять, почему эта ситуация не штатная.

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

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

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

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

> Это не спасло бы от конкретно этой ситуации.

это спасло бы от медленно ходящих сообщений по сети :) как будто реально голубями из США :)

> Если у меня его нет, то у поинта его тоже нет и ответить он на него не может

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

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

или у одного удалено, а у другого нет.

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

в аликорновских архивах почему-то для некоторых тем нет исходных сообщений.

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

я вот даже не вспомню, в фидо вообще хоть какой-то аналог repto был?

repto я прикрутил уже вообще в последний момент, поэтому он таким кривым видом прописывается, сначала его вообще не было как такового

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

> фидо было популярно только на русском языке. на остальных скорее мертво, чем живо

Да ну конечно - фидо в штатах же родилось и до сих пор как-то шевелится, хоть и по IP.
И левонеты кстати некоторые до сих пор существуют - я вопрос немного поизучал пару-тройку лет назад...

> жди моего ответа, когда хаос его польнет :)

шаос :)

это мой неизменный интернетовский ник с 1998 года...

Я говорю про популярность. Будучи уже нодой, я был подписан на разные мировые эхи и знаю, какой там был трафик. idec.test по сравнению с этим это твиттер.

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

Для подобных вещей в elp и bosfor был тэг topicid
http://blcat.ru:15555/m/53NZLKKTR2OS6NVZZP5W

.. который содержал исходный msgid и наследовался при каждом ответе. То есть, даже при выпадении сегмента, включая исходное сообщение, цепочку можно было восстановить. Я ОЧЕНЬ жалею, что не догадался вставить topicid в изначальный ii. Вообще, я очень долго думал и решал, и решил окончательно - в 0.7 я буду вставлять topicid в сообщения. Хоть это и будет касаться только сообщений, созданных на моей станции, ну хоть в чём-то археологи будущего будут мне благодарны. :)

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

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

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

В каком году это было? Всемирный пик фидо был в 1996 году, а потом пошёл спад

Я был немножко фидошником ещё когда жил в Екатеринбурге в 1997-1998 (всё как надо с модемом и т.д.)

Потом немножко левонетчиком (ZXNet в начале нулевых) - мне не понравилось т.к. там был трешак...

> В каком году это было? Всемирный пик фидо был в 1996 году, а потом пошёл спад

не помню, 2000 или 2001. не важно, суть в том, что и узлов, и контента у нас было суммарно больше, чем во всём остальном мире, вместе взятом

Это я в том смысле, что по ex-USSR оно с запозданием прошлось, когда во всём остальном мире уже был спад...

ну фидо в СССР ещё появилось. я про то, что суммарное количество узлов, трафика, популярности у нас и где-то ещё несравнимо. пни любого лоровца любого возраста и скажи FIDO и он поймёт о чём речь. А у вас в Калифорнии поймёт?

Ну в начале нулевых наверное

Ну так как FidoNet родилось в Сан-Франциско, то наверное в Калифорнии можно найти тех, кто помнит :)
Да даже тех кто до сих пор там сидит тоже можно найти ;)

> И кстати у меня ведь теперь есть spnet.uplink где можно это обсуждать :)

Чото похоже ты у меня не забираешь обратно spnet.uplink т.к. у тебя всё ещё там 2 сообщения...

Там "можно найти". А тут "пни любого лоровца", разная степень популярности.

hugeping> У меня появилась ГИПОТЕЗА.
hugeping>
hugeping> 1) revoltech фетчит себе куда-то локально эхи из разных мест
hugeping> 2) revoltech сфетчил сообщение ahamai с ноды blcat
hugeping> 3) revoltech формирует в своём клиенте ответ на сообщение и отправляет его spnet. reply указывает на сообщение с blcat
hugeping> 4) spnet НЕ ПРОВЕРЯЕТ reply вообще и берет это сообщение (считаю, должен был отбросить)
hugeping> 5) ЗАТЕМ spnet забирает сообщение на которое был ответ с blcat
hugeping>
hugeping> Это всё объясняет. revoltech? shaos? я прав?

Да, всё так. Но это не должно быть проблемой вообще, как по мне. Там же AL объяснял уже: как прилетают в базу, так и прилетают, а упорядочивать — это уже задача клиента. Так что я в своей ноде такую проверку тоже делать не буду.

ahamai>> да, разумеется. клиентов сейчас нет.
revoltech> Так это следствие мною указанного неосиляторства.

Ни один из существующих клиентов меня не устраивает (на тикле не пробовал, он же ещё не готов?). В планах есть попробовать написать клиент, аналогичный какому-нибудь aerc или newsboat, так как caesium на мой скромный зумерский вкус не очень. Не застал я FIDO, видел его только через webBBS - https://wfido.ru/ .

Однако чтобы такой клиент сделать нормально, нужно писать его на каком-нибудь C/Go/Rust и т.п. А я только python хорошо знаю, тыкался в C и Go только чуть-чуть. Поэтому планы остаются пока в мечтах.

Остаётся сидеть через веб ii-go.

tuple> Ни один из существующих клиентов меня не устраивает
tuple> Остаётся сидеть через веб ii-go.

С помощью ii-tool из состава ii-go ты можешь забирать и отправлять письма. И в принципе, даже смотреть. Так что остаётся только набрать сообщение в каком-то текстовом редакторе. Ну или написать обёртку - визуализатор всего этого дела.

Что то подобное представляет из себя mu4e например (надстройка над mu утилитой).

tuple>> Ни один из существующих клиентов меня не устраивает
tuple>> Остаётся сидеть через веб ii-go.
hugeping> С помощью ii-tool из состава ii-go ты можешь забирать и отправлять письма. И в принципе, даже смотреть. Так что остаётся только набрать сообщение в каком-то текстовом редакторе. Ну или написать обёртку - визуализатор всего этого дела.
hugeping> Что то подобное представляет из себя mu4e например (надстройка над mu утилитой).

Я планировал так сделать. Поэтому хочу написать конвертер для всех форматов в которых только можно хранить эху (txt, aio, ait, Maildir и т.д). Лучше пока написать PoC на питоне или сделать как практику для изучения C++?

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

doesnm> Я планировал так сделать. Поэтому хочу написать конвертер для всех форматов в которых только можно хранить эху (txt, aio, ait, Maildir и т.д). Лучше пока написать PoC на питоне или сделать как практику для изучения C++?

Вскрылась проблема: в mat сообщения разделяются новой строкой, а само сообщение символом 15. Но походу содержимое сообщений содержит новую строку и скрипт сходит с ума. Как это решить?

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

А что с таверной? Лежит уже дня 3:

Service Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

Apache/2.4.62 (Debian) Server at idec.spline-online.ru Port 80

У нас нет клиентов

У нас нет инфрастуктуры

У нас нет заинтересованности писать клиенты

Сейчас не 2014

shaos>> Настоящие пацаны БД на текстовых файлах держат ;)
revoltech> Да кто против-то, только не жалуйтесь на тормоза при запросе кучи эх со слайсами.

У нас столько эх нет, чтобы оно тормозило.

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

Нода почти готова (на первое время будет с регистрацией вручную), но /u/push пока решил не реализовывать. У меня вообще нода от клиента структурно отличается только парой новых таблиц в скулайте, которые на клиенте не используются — для авторизации и публичного списка эх.

Существуют ли какие-то реальные юзкейсы у /u/push?

AL> У нас столько эх нет, чтобы оно тормозило.

«Нет? Будут!» © Операция Ы/Напарник

Другое дело, что при запросе именно большого количества эх в /u/e можно опять уткнуться в тот же лимит на GET-запросы, что и в /u/m. Надо бы подумать, что с этим делать. Теоретически длина имени в эхе может быть и 120 символов, дык что, максимум |8000/121| = 66 эх за раз запрашивать?

Юпуш вообще для закидывание на 10 бесплатных хостингов и резервирования на них

Но я у себя вчера для постинга в lor.gold впервые реализовал юпуш

ahamai> Юпуш вообще для закидывание на 10 бесплатных хостингов и резервирования на них

А что, по старинке скрипт + файлик с базой закидывать — уже не вариант, обязательно нужно какое-то хитровыдуманное апи для этого?

Нет, я правда не понимаю, какие реальные задачи это решает.

AL> revoltech> Существуют ли какие-то реальные юзкейсы у /u/push?
AL>
AL> Да.

Борода. Какие, например?

И что должно произойти, если не у всех сообщений в бандле будет то же самое имя эхи, что и в поле echoarea? Зачем там это поле вообще нужно?

revoltech> Существуют ли какие-то реальные юзкейсы у /u/push?

Да.

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

AL> Например, узел в изолированной сети без внешнего адреса.

Если сеть действительно изолирована, оттуда и пуш не пройдёт. В противном случае gsocket, zerotier и прочее решают.

AL> А где в бандле имя эхи, если не в поле сообщений?

В каждом сообщении в одном из полей (строчка номер два) есть имя эхи. Что произойдёт, если в поле echoarea в POST /u/push будет указана не та эха, что в теле сообщения в бандле? Что должно произойти?

1) Такое сообщение отбросится?
2) Содержимое поля echoarea в POST-запросе проигнорируется?
3) Сообщение перепостится и туда, и туда?

AL>> revoltech> Существуют ли какие-то реальные юзкейсы у /u/push?
AL>> Да.
revoltech> Борода.

Не хами. Какой вопрос, такой ответ.

revoltech> Какие, например?

Например, узел в изолированной сети без внешнего адреса.

revoltech> И что должно произойти, если не у всех сообщений в бандле будет то же самое имя эхи, что и в поле echoarea? Зачем там это поле вообще нужно?

А где в бандле имя эхи, если не в поле сообщений?

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

doesnm> 4. В эхе указанной в push будут сообщения как будто из другой эхи

Ни хрена в этом случае не понял. Связь msgid и эхи однозначна. Что значит «как будто из другой эхи»? Это либо перепост с новым айдишником (пункт 3), либо дублирование айдишника, что ломает вообще всю логику ноды.

AL>> Например, узел в изолированной сети без внешнего адреса.
revoltech> Если сеть действительно изолирована, оттуда и пуш не пройдёт. В противном случае gsocket, zerotier и прочее решают.
AL>> А где в бандле имя эхи, если не в поле сообщений?
revoltech> В каждом сообщении в одном из полей (строчка номер два) есть имя эхи. Что произойдёт, если в поле echoarea в POST /u/push будет указана не та эха, что в теле сообщения в бандле? Что должно произойти?
revoltech> 1) Такое сообщение отбросится?
revoltech> 2) Содержимое поля echoarea в POST-запросе проигнорируется?
revoltech> 3) Сообщение перепостится и туда, и туда?

4. В эхе указанной в push будут сообщения как будто из другой эхи

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

doesnm>> 4. В эхе указанной в push будут сообщения как будто из другой эхи

revoltech> Ни хрена в этом случае не понял. Связь msgid и эхи однозначна. Что значит «как будто из другой эхи»? Это либо перепост с новым айдишником (пункт 3), либо дублирование айдишника, что ломает вообще всю логику ноды.

Согласен. Непонятно и мутно. Ну я такие сообщения буду дропать. Если echoarea в сообщении не соответствует тому что в запросе. Хотя предложил бы вообще не вводить echoarea в push.

P.S. Есть гипотеза почему это так. ii-go всегда когда принимает бандл - распаковывает его и перепроверяет. Иногда даже меняет (вырезает \r). Вероятно, создатели считали что бандл "кушается" как есть...
P.S. Edited: 2024-11-05 14:03:54

Опять цыганские фокусы с бегом впереди паровоза :)

В общем "ленте" - https://club.hugeping.ru/echo/all :
- TLSU6VMtvHxMzuCHvszE находится выше, хотя отправлено в 11:13
- B2s0Ze9vgPVEz7hLae6o находится ниже, хотя отправлено в 11:28

В этой "теме/ветке" тоже сбит порядок этими сообщениями - https://club.hugeping.ru/B2s0Ze9vgPVEz7hLae6o

   __---~~~~--__                      __--~~~~---__
  `\---~~~~~~~~\\                    //~~~~~~~~---/'
    \/~~~~~~~~~\||                  ||/~~~~~~~~~\/
                `\\                //'
                  `\\            //'
                    ||          ||
          ______--~~~~~~~~~~~~~~~~~~--______
     ___ // _-~                        ~-_ \\ ___
    `\__)\/~                              ~\/(__/'
     _--`-___                            ___-'--_
   /~     `\ ~~~~~~~~------------~~~~~~~~ /'     ~\
  /|        `\                          /'        |\
 | `\   ______`\_         DMC        _/'______   /' |
 |   `\_~-_____\ ~-________________-~ /_____-~_/'   |
 `.     ~-__________________________________-~     .'
  `.      [_______/------|~~|------\_______]      .'
   `\--___((____)(________\/________)(____))___--/'
    |>>>>>>||                            ||<<<<<<|
    `\<<<<</'                            `\>>>>>/'

      ┏┓ ┏━┓┏━╸╻┏    ╺┳╸┏━┓   ┏━╸╻ ╻╺┳╸╻ ╻┏━┓┏━╸
      ┣┻┓┣━┫┃  ┣┻┓    ┃ ┃ ┃   ┣╸ ┃ ┃ ┃ ┃ ┃┣┳┛┣╸
      ┗━┛╹ ╹┗━╸╹ ╹    ╹ ┗━┛   ╹  ┗━┛ ╹ ┗━┛╹┗╸┗━╸

P.S. арт отсюда - https://gist.github.com/sottam/8786a280f7ab0cf184915cea3ea2c55a

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

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

А поменять местами уже на ноде можно?

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

doesnm> А поменять местами уже на ноде можно?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FvAoTezksrljZy6PtSQ2

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

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

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

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

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

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

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

shaos> У меня статистика считается за сутки сразу после полуночи по тихоокеанскому времени - это 11 утра по Москве или 6 вечера по Владику, поэтому результат любого изменения лучше смотреть на следующий день.
shaos> И кстати у меня ведь теперь есть 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. Я думал она тут чисто как архив

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

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

А idec.local чья?

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

shaos> А idec.local чья?

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

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

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

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

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

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

лучше

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какой блядь файлик? Какая блять база? Я для лор.голд так и делал, закидывал файлики с базой, потом добавлял эти msgid в эхи. В итоге это надоело, и я сделал юпуш, чтобы через него постить в lor.gold напрямую.

Юпуш ровно для одной ситуации, когда конкретный человек постит на конкретную ноду с конкретной целью. Раскидать по 10 бесплатным хостингам, где максимум есть кривой ftp, и синхать базу на них.

К тому же в pipe.2032 в этом 2024 году было ровно одно сообщение

P.S. Извини, братан, но твоё следующее сообщение я заблеклистю из-за мата ибо сюда в том числе и дети ходют…

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

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

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

Я подумал, действительно в текущем виде моя нода не вписывается в то, чем является сейчас idec.

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

Фетч на данный момент со всех станций снят. Регистрация закрыта.
P.S. Edited: 2024-11-05 22:06:45

Вот что бывает, когда слишком часто опрашиваешь другие ноды - у меня это сообщение исчезло через пару минут после того как появилось…

Как щас матерятся дети, не матерюсь даже я :)

А вообще, после 10 лет затухания и деградации сеть нужно развивать. Не с полтора сисопами калеками, которые воюют за чремерный трафик, которого никогда не будет, а нормально развивать. Ты за новаторство, предлагаю начать с введения topicid и постепенного перехода в эхи, где topicid есть везде. Изначально проект был идеальным, но не стоило делать u/e, проще было запрашивать e/ за раз, и надо было делать topicid

Сорян, пришлось подредактировать…

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

А topicid это msgid самого первого сообщения? С одной стороны его всегда можно вычислить по цепочке, однако если у нас появятся длинные темы на тысячи вхождений, то тогда по цепочке будет долго и потом цепочка может внезапно оборваться. Ну и с другой стороны чему оно может помешать? Так, что я могу поддержать у себя - да :)

P.S. Мои дети не матерятся (ни по русски, ни по американски), а им идёт уже 15-й и 20-й годок…

у меня детям 20, 19, 14 и 4 :) они не матерятся, наверное ;)

topicid

если у сообщения нет repto и topicid - ставим topicd этого сообщения
если у сообщения есть repto и topicid - наследуем этот topicid
во всех остальных случаях игнор

не, марине не 14 а 15

> ставим topicd этого сообщения

Не - само на себя сообщение не может указывать - мы же по контенту хеш считаем уже после того как заголовки готовы :)

> Не - само на себя сообщение не может указывать - мы же по контенту хеш считаем уже после того как заголовки готовы :)

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

на первом уровне цепи repto совпадает с topicid, но если отвечают на ответ, repto новое а topicid просто наследуется

> у меня детям 20, 19, 14 и 4 :) они не матерятся, наверное ;)

А они ii-эхи читают? ;)

я не общаюсь ни с бывшими женами не с детьми

Ну т.е. первое сообщение всегда без repto и topicid, следующее с одинаковыми repto и topicid, указывающими на предыдущее, а далее уже с тем же самым topicid, но меняющимися repto, так? А старые цепочки не трогаем?

Если отвечают на сообщение где только repto, ну или с «классической» IDEC-ноды оно пришло?

Ну так как я это себе и представлял

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

Понял

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

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