В сеть попали некорректные сообщения в эху oldpc.51t.ru. Моё расследование показало, что эта эха есть только у hugeping и shaos.

Проблем тут две. Почти всегда в сети была станция, которая содержала в себе весь архив ii с 2014 года, сначала у меня, потом alicorn, потом lessmore.pw (у него, кстати, можно базу взять?). И сообщение, принадлежащее двум эхам, может сорвать им крышу, в любом случае не будет ничего хорошего.

Вторая: эха в самом сообщении должна совпадать с фактической, а тут в сообщении будет одна, а текущих - две. Тоже проблема.

Надо снять эху с фетча и вычистить некорректные сообщения. Либо грохнуть у обоих и восстановить из актуального архива, в неё давно не писали.

А какая сейчас вообще схема роутинга, кто кого фетчит?

И есть ли у кого архивы, кроме аликорновского? В нём 46 тыщ сообщений, а у меня много лет назад в архиве было уже 87 тыщ. Откуда вообще взялась old.pc, в аликорновской базе такого нет.

На huheping всё чисто - он из новых мессаг создал новую эху old.pc, а старая oldpc.51t.ru как содержала 32 сообщения так и содержит

Для разрешения проблемы надо просто убить old.pc на hugeping и всего делов: https://hugeping.tk/old.pc/

old.pc взялась с веб-архива странички http://p2.51t.ru и её нигде больше нет - только у меня...

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

> Вторая: эха в самом сообщении должна совпадать с фактической

если всё настолько серьёзно, то незамедлительно нужно сделать 2 вещи:
1) чётко прописать алогритм хеша (конверсия небуквенных символов в A и z без всяких "например" и "лишь бы было уникально");
2) запретить редактирование сообщений если они уже приняты сервером (ибо это сломает сходимость хеша);
из вышесказанного вытекает ещё одно требование к узлам - проверять все входящие сообщения на совпадение хеша (по чётко прописанному в стандарте алгоритму) для отбрасывания всего, что не сходится (а оно не сойдётся если имя эхи не то или получателя/отправителя исправили или текст покоцался)

https://hugeping.tk/u/e/oldpc.51t.ru

oldpc.51t.ru
73zlBKu8621aATH5SkH4
y7DFYDMApBrme9nhehVX
2XvYZ97i4I4mh1CQAU3G
6xlVJD05JIWxAc9DFdGa
O0nLmhAwM7ue2cUhUWMG
J9L2ZQFWRn9EO1PBopYK
oDqUfLHkbgx4nGE6cp4y
qD3xqOMALnhxXKiFkhi6
oW3z5qndxnIvySKBNCBs
OVPnZYUf9PYuFI2QESvT
fA0gfNf3o2IlHeLDg5Gt
vKLfirFV6cHKKcJH32rM
JwrRKyFrGau1TUj6dVI2
6z8ZvS6BiSD55Ik0uK6W
INM8dh0b9QWYolnOfFQx
YK72VF2WFxjbEuAbtDA0
c9sgQ8wLlmG6T1uK2kA8
VuQd1IXcVIVqb3ITifXZ
oEzDIsA5hy8Enxc0ZI3f
bkawVubpvKvz6debphFg
c74ii0Y4GynI6ZKmX9tE
fTlZz38CgMzhTp3er0or
Oiu4QOAAGuyF07nZOLc3
AbCUUHla1UlxpsP3oQAg
FlAbPqmSDcpzpdVqdIha
dp9LwyLJWBjnWQLN0lL2
pIegZwE3tUMlzP1YNe9x
VFDBu0HLrcREUWm9qfq7
AXCXyAwUTLec0PqhdmKU
AibFl1PPdBh2GJW9WDSi
64Sv1pXU8iZey6xKvPJG
2YxOzvz1QGJZFwDMTNk6

всё как было - ничего нового
так что ненадо разводить панику...

интересно, каким образом он её создал, по какому принципу?

тогда всё проще

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

поскольку у меня её тоже больше нет, она действительно есть только у тебя :)

ок, заберу, почищу ненужное, прокомментирую/исправлю устаревшее и сконвертирую всё в retro.talks. а свою old.pc убью. в общем, никто не пострадал, но непонятно, почему станция Петра поместила их в old.pc, если ты проставил там новую эху внутри

зачитался, сижу восстанавливаю games.utf по исходнику инсталлера. восстановил :)

а ещё есть какие-нибудь архивы?

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

> интересно, каким образом он её создал, по какому принципу?

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

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

ну на самом деле одно другому не противоречит - надо просто ввести понятие draft для сообщений которые только что приняты сервером - их надо просто попридержать какое-то время (5 минут?) прежде чем флаг draft снимется и сообщение станет доступно для фетчинга с других узлов и если юзер вдруг решил исправить draft, то надо УБИТЬ старое сообщение и СОЗДАТЬ новое с ДРУГИМ msgid !!! т.к. старое сообщение ещё не ушло, то о такой подмене никто не узнает, а если сообщение уже ушло (т.е. флаг draft снялся), то всё - исправлять это сообщение уже больше нельзя иначе в системе будут циркулировать сообщения с одним и тем же msgid, но разным содержимым - поэтому и надо сверять хэши при фетче (хотя бы чтобы защититься от коррапнутых при хранении или передаче сообщений)

P.S. тот же механизм можно использовать для модерирования сообщений от новых поинтов - они будут в сосотянии draft пока модератор узла их не одобрит...

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

ну почему? если перекодировать сообщения в хронологическом порядке, то можно и repto подменить т.к. repto будут ссылаться на msgid который заведомо уже был и уже сконверчен - т.е. просто подменяем и всё

> а ещё есть какие-нибудь архивы?

я в декабре 2021 года качнул database.tar.xz с alicorn и сейчас поднял на локальном узле потихоньку вытаскивая оттуда полезное (например python.15 уже вытащил)

ii.stat почему то был только на spline-online.ru, а в архиве alicorn его небыло - тоже стянул...

> но непонятно, почему станция Петра поместила их в old.pc, если ты проставил там новую эху внутри

на тот момент когда он фечнул в этих сообщениях в качестве эхи стояла именно old.pc - я потом пробовал ставить oldpc.51t.ru, а потом обратно всё откатил, но это всё уже никуда не попало...

Мне лень так конвертить :)

Я сконвертил но не выложил так как ушёл, приду выложу проверишь

А ну тогда вообще ничего не страшно, это валидная эха old.pc

Там нет многих эх которые я даже на память помню.

У кого-то он в любом случае есть, надо только найти его...

> А ну тогда вообще ничего не страшно, это валидная эха old.pc

ну просто эти сообщения для old.pc пришли на запрос эхи oldpc.51t.ru и я уже понял, что это было нехорошо...

>> А ну тогда вообще ничего не страшно, это валидная эха old.pc

shaos> ну просто эти сообщения для old.pc пришли на запрос эхи oldpc.51t.ru и я уже понял, что это было нехорошо...

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

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

Хотя сделать это, не так-то просто. Ведь когда я формирую список id он уже отвязан от эх... Мнда... Ладно, подумаю на досуге.

Насчёт запретить редактировать.

Я этого делать не буду, моя нода служит мне чисто утилитарно для моего проекта. Мне важно уметь редактировать сообщения. При этом не создаётся много сообщений, ID остаётся тем-же самым, но база хранит всю историю сообщений (но не отдаёт их наружу, всегда только последнее). Так же есть личные сообщения, но они тоже локализованы моей нодой.

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

Если это кого-то напрягает, снимайте фетч. Ну и я сам могу снять по просьбе.

Это к вопросу о важности тэгов. Вообще обычно фетчеры ориентируются на то, какую эху забирают, но фетчер Петра, видимо, ориентируется на тэг. Поэтому получилась совершенно валидная эха old.pc, такая же, как оригинальная.

> Я этого делать не буду, моя нода служит мне чисто утилитарно для моего проекта. Мне важно уметь редактировать сообщения. При этом не создаётся много сообщений, ID остаётся тем-же самым, но база хранит всю историю сообщений (но не отдаёт их наружу, всегда только последнее). Так же есть личные сообщения, но они тоже локализованы моей нодой.

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

iiii> Это к вопросу о важности тэгов. Вообще обычно фетчеры ориентируются на то, какую эху забирают, но фетчер Петра, видимо, ориентируется на тэг. Поэтому получилась совершенно валидная эха old.pc, такая же, как оригинальная.

Не совсем понимаю, что за тег? Я просто забираю список id по всем эхам а потом забираю эти сообщения. Распаковываю и помещаю их в соответствии с содержимым в базу.

я для того и формат такой делал, чтобы было какие сообщения к какой эхе, а не все скопом :)

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

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

Я тоже считаю, что проблемы особой нет. А стандартов - чем меньше, тем лучше :)

shaos, проверь с меня эху retro.talks.test

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

вообще надо как-нибудь ревизию сети провести на предмет эх, где эха не совпадает с тэгом

я, если соберу все сообщения со всех текущих станций, проверю

> shaos, проверь с меня эху retro.talks.test

Вроде ок выглядит - Re сообщения ссылаются куда надо

Правда в одном сообщении в тексте осталась ссылка на несуществуюзщий msgid ( см. http://ii.blcat.ru/AVLUW1VuKb0T81PYx9rM )

И вот тут http://ii.blcat.ru/Iis8J50kYDLEJN0LMyRf наверное надо заменить линк на несуществующий club.syscall.ru (сейчас это club.hugeping.ru) - но это наверное мелочи, если гнаться за исторической аутентичностью, то наверное пусть остаётся как есть...

я себе пишу всякие такие проверялки на сях

лежат на гитлабе

https://gitlab.com/shaos/iii-php/-/tree/master/native-utils?ref_type=heads

например с помощью iii-check я проверял корректность эх ii://python.15 и ii://ii.stat прежде чем себе перетащить (там в итоге надо было переставить кое-какие сообщения, чтобы всё было в хронологическом порядке) - корректность тэга оно тоже проверяет...

> Правда в одном сообщении в тексте осталась ссылка на несуществуюзщий msgid ( см. http://ii.blcat.ru/AVLUW1VuKb0T81PYx9rM )

Всё понятно - этот несуществующий msgid существует на hugeping в эхе std.hugeping https://hugeping.tk/TF9RuFRon9u7ps9Owka3 и текст был перепостчен в oldpc.51t.ru как ii://FlAbPqmSDcpzpdVqdIha

P.S. Я гляжу беседа там в oldpc.51t.ru продолжается и я её продолжаю себе затягивать ;)
https://sprinternet.io/iii-web.php?echo=oldpc.51t.ru

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

msgid ведёт на обзор план9, но в эхе std.hugeping. я её потом перекопировал, можно изменить ссылку и на него. сейчас мы заморозим oldpc51, потому что она снова ожила, и я там поправлю, games.utf тоже перевыложу и ссылку на неё поправлю

кроме того у меня есть идея собирать все msgid со всех станций, и если там есть такое сообщение, то перенаправлять на них (а если будет архив, то сразу на него)

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

> я там потом чёнить причешу, чёнить поудаляю и скорее всего просто в лоб переименую в retro.talks и смержу с текущей

а что будешь делать с ii://oldpc.51t.ru которая продолжает жить своей жизнью на hugeping.tk и соответственно у меня?

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

свои запланированные сообщения про sarge я точно буду пулять в retro.talks

nastene-retro я буду выпускать уже с полным архивом retro.talks

ИМХО болталка это зло ибо болталка ни о чём очень быстро превращается в болталку о чём-нибудь конкретном, на что у людей есть разные взгляды, что может триггернуть кого-нибудь и затем начинается взаимные метания какашками, обзывания, мат, а также обещание найти и покалечить собеседника (я знаю о чём говорю т.к. админю phpBB форум более двух десятков лет)...

всегда была такая болталка, там im.1407, im.1408, потом pipe.2032, и она всегда генерила трафик

ну последние годы это не так - если посмотреть внутрь pipe.2032, то можно обнаружить, что в 2024 году там ничего небыло, а в 2023 было 4 чтоли темы - и всё...

так эха никуда и ни с кем не ходила, надо возрождать. но нужны новые пойнты, с лора пока никто не пришёл, надо продолжать движуху

> кроме того у меня есть идея собирать все msgid со всех станций, и если там есть такое сообщение, то перенаправлять на них (а если будет архив, то сразу на него)

А небыло мыслей про распределённое хранилище объектов, чтобы небыло замыкания на один узел - держатель архива? Я это озвучивал как идею развития ii/IDEC в декабре 2021:

ii://xDT61Ukip7E064VjCjt4

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

По тем пунктам:

1. Цель остаётся максимально простая реализация на любом языке программирования. Поэтому к версии 0.3 я отказался от zlib, если что пусть лучше сервер использует gzip-сжатие. Поэтому и замена символов в base64 вместо base58 - base64 есть везде.

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

5. Изначально в ii были и бинарные файлы, и файлы с разметкой textile, я от всего этого отказался ради простоты.

6. ЮЮКи в фидо. Я об этом думал, но это вообще лишнее, лишний трафик в простой сети, всё это должно реализовываться внешними средствами а не ходить по эхам.

7. В принципе, для чего-то подобного и резервировалось поле addr. У меня даже были реализации, где оно как-то так использовалось. Но особо это не нужно, разве что, в случае роста сети, делать там идентификатор для реализации NETMAIL (как я изначально и планировал, если потребуется), но пока там просто отпечаток станции.

8. Для этого изначально была система колец. Идеи все фетчатся со всеми не было (кстати, кто-нибудь всё таки скажет схему роутинга?). Сначала базовое кольцо, большие станции, далее кольца поменьше. Просто сеть никогда не разрасталась до таких масштабов, чтобы это использовать, но всё подобное было заложено изначально, расписано в доках. :)

shaos> ИМХО болталка это зло ибо болталка ни о чём очень быстро превращается в болталку о чём-нибудь конкретном, на что у людей есть разные взгляды, что может триггернуть кого-нибудь и затем начинается взаимные метания какашками, обзывания, мат, а также обещание найти и покалечить собеседника (я знаю о чём говорю т.к. админю phpBB форум более двух десятков лет)...

на tgi я могу писать только сюда и вроде бы в эху по zx spectrum

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

> на tgi я могу писать только сюда и вроде бы в эху по zx spectrum

ну idec.talks не совсем болталка, а очень тематическая эха про обсуждение деталей функционирования ii/IDEC сети :)

болталка нужна

а ещё никто так и не сказал, можно ли связаться с Difrex, чтобы получить архивы

и ещё никто так и не сказал, кто сейчас кого фетчит, какой роутинг. я фетчу idec.talks с hugeping и habr.rss и lopennet.rss с spnet, но эхи инконсистентные

Идея хорошая, но нам тут всё таки ближе plaintext (изначально ii вообще был на json, но я перевёл в plaintext). Если в какой-то plaintext перенести, будет интересно, я такое расширение даже поддержу.

Ну за себя я сказал - см. мой node.json :)

bot.habr.rss изначально идёт с tgistation.ru а lor.opennet с idec.spline-online.ru - так что логичнее их из источников брать, а с меня можешь иногда обратно фетчить retro.talks если вдруг кто с моей ноды туда чо напишет ;)

P.S. У меня в веб интерфейсе в строке статуса есть инфа кто с меня фетчил (точнее дёргал апи поинта) за последние сутки и сколько раз в час - см. https://sprinternet.io/iii-web.php или http://sprinternet.io:8085/iii-web.php

Ну изначально формат описателя ноды в JSON предложил Лобанов ( см. ii://WxnDvQ31oreCIUc6p0K7 ) - я подумал, что идея здравая и решил туда же добавить инфу по конкретике фетча (урлы и список забираемых эх для каждой ноды) - просто там данные разношёрстные (и древовидные) и в plaintext будет как-то некрасиво (я пробовал) и потом в работе самой станции оно как бы не участвует (ну разве что если фетчи будут настраиваться по этому описателю) и по сути оно нужно лишь для выкачивания внешней программой, которая периодически будет строить актуальную топологию сети...

Новейшая статистика по тем, кто фетчит с меня, за последние сутки построенная по логам апача (на веб-страничке может обновляться не сразу):

tavern 16.6MB (2/hr), Google 12.4MB, tgi 5.0MB (3/hr), ping 3.4MB (6/hr), blcat 3.0MB (2/hr)

Ну пусть бкдет json. Вопрос только в таймингах, они произвольные, что писать?

iiii> С исторической ценностью ничего не случится, потому что оригинальные сообщения никуда не денутся. Вообще, смысл цифровых эх был в том, что они периодически отправляются в архив. А проблема в том, что сейчас такого архива нет.

Когда были цифровой постфикс эх, такого архива тоже не было. Циферки не влияют на наличие архива.

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

iiii> ещё неплохо бы возродить идею перекатываемых болталок ни о чём, а то сейчас только idec.talks живая. я у себя на станции потом сделаю talks.24

Зачем их перекатывать? Чтобы что?

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

shaos> ИМХО болталка это зло ибо болталка ни о чём очень быстро превращается в болталку о чём-нибудь конкретном, на что у людей есть разные взгляды, что может триггернуть кого-нибудь и затем начинается взаимные метания какашками, обзывания, мат, а также обещание найти и покалечить собеседника (я знаю о чём говорю т.к. админю phpBB форум более двух десятков лет)...

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

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

shaos> ну последние годы это не так - если посмотреть внутрь pipe.2032, то можно обнаружить, что в 2024 году там ничего небыло, а в 2023 было 4 чтоли темы - и всё...

По сравнению с другим эхами это был трафик.

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

Чтобы не было больших эх. Im.14@@ каждый месяц по несколько тысяч сообщений собирали.

Был, у меня, он ведь был задуман изначально, что эхи в архив переезжают.

Потом был публично открыт

shaos> Понятно - спасибо за развёрнутый ответ! :)
shaos> В официальных доках нету ничего ни про кольца, ни про zlib, но я встречал обрывки обсуждений в архивных эхах - надо будет всё перечитать.

Потому что не было никаких колец никогда. Ну и zlib тоже использовался, видимо, где-то на заре до 2014 года.

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

shaos> Ну изначально формат описателя ноды в JSON предложил Лобанов ( см. ii://WxnDvQ31oreCIUc6p0K7 ) - я подумал, что идея здравая и решил туда же добавить инфу по конкретике фетча (урлы и список забираемых эх для каждой ноды) - просто там данные разношёрстные (и древовидные) и в plaintext будет как-то некрасиво (я пробовал) и потом в работе самой станции оно как бы не участвует (ну разве что если фетчи будут настраиваться по этому описателю) и по сути оно нужно лишь для выкачивания внешней программой, которая периодически будет строить актуальную топологию сети...

Я просто сделал такой формат, который проще преобразовать в граф. Но делать это частью стандарта не вижу смысла. А делать расширение стандарта и подавно. Превратимся в XMPP на минималках :)

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

Тайминги в виде “30m” это значит с какой периодичностью идут запросы - в данном случае один раз в 30 минут (что равно 2 раза в час)

А если нет тайминга что писать

Есть темы, которые триггерят много людей в 100% случаев - это секс, религия, политика и национальные вопросы. Если речь идёт просто о предпочтениях в выборе языка программирования или ОС, то тут выбор больше и накала меньше - например никто не поедет тебя искать с целью переломать ноги, если ты всё ещё кодишь на перле…

Ну если не по крону, а вручную фетчишь как попало то например оставляй пустым “” :)

Я с вашего позволения ваеду флаг inc, показывающий что эха инконсистннтная

Многие проблемы сети удалось избежать благодаря малой распостранённости :)

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

А что касательно архивов - в этом и был изначальный смысл. Все пользователи рабоют с одной версией эхи, с актуальной. Чтобы юзер при подключении не тянул архив за много лет. Чтобы тематическая станция тоже не тянула такой архив. Я вот стянул 2000 с лишним сообщений idec.talks, но они мне не нужны. Инконсистетные эхи мне не нравятся, у всех она разная, а потом выяснится что полной нет вообще ни у кого :) Изначальная задумка, что все работают с одной и той же версией эхи, и у всех она одинаковая, поэтому не должна быть большой. Хочет юзер архив, пусть выкачивает архив, хоть частично, хоть весь. Эха должна быть целостная, и у всех, и у нодов и у пойнтов одинаковая, пусть может быть разный порядок сообщений. И все работают только с актуальной версией.

Вот я не хочу тянуть несколько тысяч сообщений pipe.2032. Это архивные сообщения и их место в архиве. Я создам im.24, а там кто хочет, пусть её забирает.

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

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

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

полторы тыщи сообщений в idec.talks, не 2, но не суть :)

> Я с вашего позволения ваеду флаг inc, показывающий что эха инконсистннтная

И что это значит?

> Инконсистетные эхи мне не нравятся, у всех она разная, а потом выяснится что полной нет вообще ни у кого :)

Ну любая большая эха будет разная на разных нодах ибо сисопы блеклистят разные сообщения :)

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

А что в этом плохого? ;)

Если тебе нравится раз в 5 лет бегать за каждым сисопом и вручную собирать с них JSON-ы, то пусть, а я пока включил node.json в свой /x/features как фичу :)

Iiii> Чтобы не было больших эх. Im.14@@ каждый месяц по несколько тысяч сообщений собирали.

Размер эхи влияет ни на что.

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

Iiii> Был, у меня, он ведь был задуман изначально, что эхи в архив переезжают.

Это быль костыль, потерявший актуальность ещё в 15-м году.

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

iiii> Многие проблемы сети удалось избежать благодаря малой распостранённости :)

Некоторые удалось решить, когда начали править стандарт.

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

Формально, тогда просто выпал один узел. Колец всё ещё не было.

iiii> А что касательно архивов - в этом и был изначальный смысл. Все пользователи рабоют с одной версией эхи, с актуальной.

И каждый сидит и правит конфиги ради ничего.

iiii> Чтобы юзер при подключении не тянул архив за много лет. Чтобы тематическая станция тоже не тянула такой архив.

Он и сейчас может тянуть хоть одно последнее сообщение и начинать общение с этого.

iiii> Я вот стянул 2000 с лишним сообщений idec.talks, но они мне не нужны.

Если не нужны, то зачем ты их стянул?

iiii> Инконсистетные эхи мне не нравятся, у всех она разная, а потом выяснится что полной нет вообще ни у кого :)

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

iiii> Изначальная задумка, что все работают с одной и той же версией эхи

То есть то, к чему мы в итоге и пришли.

iiii> и у всех она одинаковая, поэтому не должна быть большой.

Смысла в этом мало.

iiii> Хочет юзер архив, пусть выкачивает архив, хоть частично, хоть весь.

Всё как сейчас.

iiii> Эха должна быть целостная, и у всех, и у нодов и у пойнтов одинаковая, пусть может быть разный порядок сообщений.

Кому должна? По какой причине?

iiii> И все работают только с актуальной версией.

То, что мы имеем сейчас.

iiii> Вот я не хочу тянуть несколько тысяч сообщений pipe.2032.

Тебя никто не заставляет.

iiii> Это архивные сообщения и их место в архиве.

Архивные эхи - это пережиток прошлого.

iiii> Я создам im.24, а там кто хочет, пусть её забирает.

Каждый раз, когда Рома вспоминает про нас, он создаёт новые эхи, которые успешно бросает, как и сеть. Смысл в этих обрезках эх никакого.

iiii> Проблема в том, что юзеров мало и архивов тоже мало и они все успели поисчезать.

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

iiii> Вообще, сеть имеет потенциал, и чем больше в мире блокировок, тем больший, если появится популярность, то надо использовать дробление эх, нормальное их архивирование

Чтобы уж точно никто никогда ничего не нашёл среди сотен одинаковых эх с разным контентом.

iiii> и нормальный доступ к контенту.

Он уже есть.

iiii> Для малотрафиковых эх это всё, конечно, не нужно, и для сети с 5 пользователями - тоже :)

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

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

AL> У всех разные архивы эх, а потом выяснится, что полного архива нет вообще ни у кого. Та же фигня, но в профиль.
А можно брать часть сообщений с одной ноды, а часть с другой?

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

AL>> У всех разные архивы эх, а потом выяснится, что полного архива нет вообще ни у кого. Та же фигня, но в профиль.
doesnm> А можно брать часть сообщений с одной ноды, а часть с другой?

Можно.

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

AL>>> У всех разные архивы эх, а потом выяснится, что полного архива нет вообще ни у кого. Та же фигня, но в профиль.
doesnm>> А можно брать часть сообщений с одной ноды, а часть с другой?
AL> Можно.
Тогда по идее не должно быть проблемы что на некоторых нодах заблочены сообщения

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

Iiii>> Чтобы не было больших эх. Im.14@@ каждый месяц по несколько тысяч сообщений собирали.

AL> Размер эхи влияет ни на что.

При использовании idec расширений. Если же говорить об ii, то придётся всегда синкать все сообщения. Так что тут смысл есть.

Ну и в теории, если реализация простенькая - большой размер базы может сильно нагружать. Но вот после введения расширений idec которые позволяют сделать адаптивный фетч (как я сделал в ii-go), вопрос по поводу "текучести" эх как часть стандарта - уже не так очевиден.

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

Так то и ii-txt берёт только последние 100 сообщений, и я беру с rss эх только последние 100 сообщений, но это из-за разросшести эх.

> И каждый сидит и правит конфиги ради ничего.

это можно автоматизировать. но я говорю, что такая была изначальная идея.

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

подожди, почему у всех разные архивы эх?

> То есть то, к чему мы в итоге и пришли.

нет, сейчас нет версий, есть только эха, которая может и 10 лет тянуться. одна эха на все времена.

> Всё как сейчас.

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

> Архивные эхи - это пережиток прошлого.

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

> Стопятьсот болталок, из которых живая одна, не решает эту проблему. Не усугубляет, но и не решает.

так и должно быть - одна болталка живая, остальные архивные.

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

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

Iiii>>> Чтобы не было больших эх. Im.14@@ каждый месяц по несколько тысяч сообщений собирали.
AL>> Размер эхи влияет ни на что.
hugeping> При использовании idec расширений. Если же говорить об ii, то придётся всегда синкать все сообщения. Так что тут смысл есть.

У нас эхотаг какой? Не ii.talks, а idec.talks же.

hugeping> Ну и в теории, если реализация простенькая - большой размер базы может сильно нагружать. Но вот после введения расширений idec которые позволяют сделать адаптивный фетч (как я сделал в ii-go), вопрос по поводу "текучести" эх как часть стандарта - уже не так очевиден.

Забирай что хочешь откуда хочешь и как хочешь. Никаких ограничений нет.

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

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

Изначально был ii. Ты прямым текстом писал, что возможно на основе ii будет другая технология с другим названием. Мы находимся здесь.

>> У всех разные архивы эх, а потом выяснится, что полного архива нет вообще ни у кого. Та же фигня, но в профиль.
iiii> подожди, почему у всех разные архивы эх?

Потому же, почему ты не хочешь тянуть большие эхи. Зачем мне тянуть старые сообщения, если я не хочу? Да и просто могу в любой момент грохнуть архивные эхи, чтобы почистить место.

>> То есть то, к чему мы в итоге и пришли.
iiii> нет, сейчас нет версий, есть только эха, которая может и 10 лет тянуться. одна эха на все времена.

Версии не решают озвученных проблем. Расширенный u/e решает.

>> Всё как сейчас.
iiii> не совсем. во-первых, по дефолту качается всё, во вторых эха становится инконсистентной. в эхах с годами всё чётко, за какие года хочешь выкачивать, за такие и выкачивай, там всё понятно и однозначно.

По умолчанию мой фетчер качает далеко не всё. Чтобы цезий клонировал эху, надо конкретно указать ему, что клонировать. Инконсистентность эхи будет и в твоём случае. Захочу и засуну половину сообщений в blacklist и прощай консистентность.

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

Зачем качать архивные эхи? Чем это отличается от выкачивания большой эхи?

>> Стопятьсот болталок, из которых живая одна, не решает эту проблему. Не усугубляет, но и не решает.
iiii> так и должно быть - одна болталка живая, остальные архивные.

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

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

Мы к нему не придём. Ты хочешь костыли, мы хотим спокойного общения.

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

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

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

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

В пнрвом случае 9 эх в архиве. Все нужны мало кому

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

Маленькие станции и пойнты - да. Но архив в любом случае должен быть. Вон кто то архив old.pc спас

> Вон кто то архив old.pc спас

Я его не спас - я его восстановил :)

Сохранил HTML из веб-архива (пока он ещё живой был) сайта p2.51t.ru и оттуда вбил все тексты в текстовые файлы с изначальными msgid и примерными временами (с точностью до минут - ну может таймзоной ошибся)...

А в 2022 году я не знал о существовании этого самого p2.51t.ru хоть и читаю idec.talks с августа 2021 года (видимо оно тут не пролетало)

С ума сойти :) не, надо Difrex а ловить вдруг у него архив остался

На днях скачал архив ru.humor.14 и пару дней перечитывал. Архивы рулят

iiii> В пнрвом случае 9 эх в архиве. Все нужны мало кому

Во втором случае из одной эхи можно скачать 1000 сообщений. Вся эха мало кому нужна.

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

>> Ну и выходит, что имеет смысл хранить только последнюю, а архивные удалять за ненадобностью.
iiii> Маленькие станции и пойнты - да. Но архив в любом случае должен быть. Вон кто то архив old.pc спас

Маленькие станции и поинты могут хранить лишь часть одной эхи. От этого ничего не меняется.

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

iiii> В пнрвом случае 9 эх в архиве. Все нужны мало кому

Ты знаешь, мне нравится простота первоначальной ii и мне понятно то, что ты говоришь.

Да, идея была простая. Без расширений. Просто сливать сообщения. Причём отделить динамические текущие эхи от архива - это красиво.

Но сейчас живые ноды -- это idec и там проблема ограниченного фетча решена. Я бы даже не побоялся сказать, что idec потерял в простоте и элегантности. Я даже думал о том, что именно можно было бы сделать в ii чтобы решить эту проблему без расширений? Ну например, отдавать список msgid в реверсном порядке. Хотя тоже тут изящность уходит и становится хаком....

Так вот, я это понимаю, но возврат на схему с эхами с датами мне кажется невозможен главным образом из-за орг вопросов. Ну, например. Одна нода сделала idec.talks.24, а прошлый talks убрала в архив. А остальные этого не сделали... Начинается разброд и шатание. То-есть, вся эта штука предполагает некую централизацию организации работы нод. Добиться этого, по-моему, утопия. Причём это было бы утопией даже в ситуации когда все ноды были бы на ii.

В idec, с другой стороны, проще и анархичней. Действительно все обмениваются так как им удобно и всё.

Но я вот ещё что хочу добавить. Технически сейчас можно обмениваться с idec нодами и по ii. Причём по современным меркам, если обмен делать пару раз в день, даже для больших индексов - это копейки. И главное не idec это или ii. Главное, что придя с работы я снова могу почитать нашу сеть! Пусть даже большинство сообщений о технической стороне работы нашей сети. Это здорово! Давайте просто не забрасывать сеть! А возврат к корням ii ты можешь сделать на своей ноде с новой эхой, и вполне возможно что я буду подтягивать её и подчиняться правилам которые ты определишь для этой эхи. Просто не бросай свою ноду. Мне кстати web интерфейс её в эстетическом смысле очень нравится.