>> А ну тогда вообще ничего не страшно, это валидная эха 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 я проверял корректность эх python.15 и ii.stat прежде чем себе перетащить (там в итоге надо было переставить кое-какие сообщения, чтобы всё было в хронологическом порядке) - корректность тэга оно тоже проверяет...

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

Всё понятно - этот несуществующий msgid существует на hugeping в эхе std.hugeping https://hugeping.tk/TF9RuFRon9u7ps9Owka3 и текст был перепостчен в oldpc.51t.ru как 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 и смержу с текущей

а что будешь делать с 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 чтоли темы - и всё...

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

Сделал мерж всех старых эх в retro.talks. Shaos, можешь забирать :)

и на форуме своём рекламить, можно всю эху можно отдельные статьи.

oldpс51 походу надо фризить, а то мне потом опять придётся сообщения переносить :)

> Сделал мерж всех старых эх в retro.talks. Shaos, можешь забирать :)

Забрал :)

https://sprinternet.io/iii-web.php?echo=retro.talks

Только переставил 4 верхних сообщения ниже перед 4 последними, чтобы было в хронологическом порядке, а то ii-php их криво показывает

olldpc.51t.ru удаляю и снимаю с фетча у hugeping

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

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

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, но эхи инконсистентные

Понятно - спасибо за развёрнутый ответ! :)

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

Для автоматического построения схемы роутинга я предлагал расширение стандарта при котором каждая станция имеет у себя файл node.json с описанием станции и что откуда фетчится - если каждый узел будет иметь такой файл (мой имеет), то автоматическое построение топологии сети становится тривиальной задачей:

https://sprinternet.io/iii/node.json

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

Идея хорошая, но нам тут всё таки ближе 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 предложил Лобанов ( см. 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 предложил Лобанов ( см. 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 как фичу :)

Планирую сегодня-завтра поменять домашний маршрутизатор со старого на новый и в процессе сего моя нода sprinternet.io может на какое-то время приуныть :)

Вобчем не теряйте меня - я обязательно вернусь ;)

Таверна через веб вот так теперь открывается:

http://idec.spline-online.ru/echolist

А если идти напрямую, то там Gitea, где например есть описание IDEC в одну страницу :)

https://idec.spline-online.ru/spline/idec-doc/src/branch/master/main.org

Маршрутизатор поменян, порты зафорвардены по старому - вроде всё работает :)

Теперешние характеристики гигабитного кабеля:
927 Mbps up
353 Mbps down

т.е. всё наоборот конечно же :)
927 Mbps down
353 Mbps up
это для внешнего мира мой up будет down ;)

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), вопрос по поводу "текучести" эх как часть стандарта - уже не так очевиден.

А фетчить обратно кто будет? ;)
Хотя бы с ping-a, а лучше и оттуда, и от меня,
а то там люди уже ответы пишут :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а эту эху с меня кто-нить фетчит? сейчас и проверим :)

кстати, можешь тянуть с меня idec.talks

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 сообщений ничем не отличается. Либо мы выпиливаем и не гоняем архив, либо гоняем всё. Ты уже озвучил, что гонять надо в любом случае всё.

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

> кстати, можешь тянуть с меня idec.talks

ага - ок
готово :)

ну дык если фетч уже и так бегает чего бы туда экспериментально не добавить ещё одну эху то? ;)

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

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

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

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

ну я :)

Ну круто :)

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

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

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

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

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

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

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

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

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

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

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

shaos>> Это к Andrew Lobanov
shaos> Andrew Lobanov>Чего это?
shaos> Ну как к держателю стандарта IDEC по видимому ;)

Вот так новости!

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

Держателю и оберегателю :)

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

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

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

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

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

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

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

Мне не нравится, что потерялась изначальная идея - что написанные сообщения никуда не пропадают. Да, часть архива удалось восстановить, но некоторые эхи я бы ещё почитал - случайно заметил что ru.humor.14 сохранился.

Смысл был маленькие эхи и глобальные дублирующиеся архивы - щас нет ни того ни другого.

Идея что на ноде не полная эха мне не нравится - хотя у меня у самого rss-эхи урезанные, но содержимое оттуда потерять не жалко :)

iiii> Мне не нравится, что потерялась изначальная идея - что написанные сообщения никуда не пропадают. Да, часть архива удалось восстановить, но некоторые эхи я бы ещё почитал - случайно заметил что ru.humor.14 сохранился.
iiii> Смысл был маленькие эхи и глобальные дублирующиеся архивы - щас нет ни того ни другого.
iiii> Идея что на ноде не полная эха мне не нравится - хотя у меня у самого rss-эхи урезанные, но содержимое оттуда потерять не жалко :)

А сколько весят полные архивы? У моего одноплатника сдкарта на 64гб
+могу запрячь ссд на 512гб по нативному сата
Поместится?
+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

> А сколько весят полные архивы?
То что есть старого в развёрнутом виде весит около 200 МБ (это 46 тысяч сообщений).
Говорят раньше было до 80 тысяч и современных собщений ещё порядка 22 тысяч имеется (90 мегов).
т.е. в пределе порядка полугигабайта ii/IDEC-наследия с 2014 года набирается (но у меня на руках есть только 300 МБ - 200 старых и 90+ новых)

>> А сколько весят полные архивы?
shaos> То что есть старого в развёрнутом виде весит около 200 МБ (это 46 тысяч сообщений).
shaos> Говорят раньше было до 80 тысяч и современных собщений ещё порядка 22 тысяч имеется (90 мегов).
shaos> т.е. в пределе порядка полугигабайта ii/IDEC-наследия с 2014 года набирается (но у меня на руках есть только 300 МБ - 200 старых и 90+ новых)

Пф, маловато звучит
Это и у меня на телефоне поместится

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

Таверна по ходу IP-адрес сменила - вчера 2 разных записи в статистике получилось - со старым и с новым адресом:

[1] Amazon point=0 web=768 up=20.3MB (25%)
[2] Google point=9 web=1378 up=18.7MB (23%) <--- Google
[3] 217.197.116.x point=140 web=0 up=11.9MB (15%) <--- blackcat (6/hr)
[4] 176.109.111.x point=26 web=0 up=9.0MB (11%) <--- tavern (1/hr)
[5] 62.109.31.x point=20 web=0 up=6.9MB (8%) <--- tavern
[6] 92.63.98.x point=71 web=0 up=5.0MB (6%) <--- tgi (3/hr)
[7] 95.165.9.x point=142 web=0 up=3.6MB (4%) <--- ping (6/hr)
[8] Facebook point=0 web=174 up=1.7MB (2%)
[9] 24.130.121.x point=8 web=36 up=1.5MB (1%) <--- spnet
[10] 46.119.3.x point=0 web=4 up=30KB

Надо наверное адаптивным способом IP-адреса нодов выявлять при парсинге апачи логов - беря имена серверов из моего node.json

shaos> Держателю и оберегателю :)

Да какое там. Я уже давно не занимаюсь ничем. Даже таверну в порядок привести времени и сил нет.

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