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

архив всегда был. последний архив был у difrex. только сейчас его нет.

> Так это живая эха. Не архивная.

она только на одной станции и туда давно ничего не писалось, похожа на архивную :) хотя у меня она тоже живая :)

> Но тебе нравится, что на ноде не все эхи. Я правильно понимаю?

на маленьких и тематических нодах - да, только активные

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

>> Челобитных непонятно кому ради регистрации точно писать не буду.

> Ну это такая игра в которую можно играть вдвоём - почему кто-либо должен непонятно кого пускать в свою сеть? ;)

изначально был чисто фидошный принцип - пойнт пишет ноду, и там просит пойнта.

Работает

ээээ я живой вычё

Ссылки кривые, ничо не понял

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

А, это bosfor. С более развитым ip и прозрачным гейтом в ii, эхи там определялись не по точке, а по символу : спереди.

Не помню, был ли там список эх, но там была команда discover, показывающая все эхи на станции, скрытых эх нету. У меня, кстати, в gemini транслируются тоже все эхи, в том числе скрытые :)

Расширения idec я не поддерживаю, но конкретно в моей реализации есть две минифичи, естественно это никакой не стандарт:

при запросе list.txt с ключом ?h=1, он вместо описаний эх показывает хэши файлов эх, чтобы можно было забирать только изменившиеся эхи.

при запросе /u/e/ с ключом ?sf=хэш он при запросе будет выдавать только хэши после указанного (если указанного в списке нет, выдаст все). но запрашивать так можно по одной эхе. это нигде и никогда не использовалась, но такая возможность в моей реализации есть, каждая заняла по 2 строчки кода в коде сервера, поэтому добавил.

ещё раньше была возможность задавать количество скачаного с помощью url, типа запрос /lim/200/u/e вместо /u/e отдавал только последние 200 хэшей из эхи - то есть, вообще не надо менять клиентский софт или фетчеры, просто менять строку в конфиге. в следующей версии nastene, когда я перепишу её на picnic, я её верну

> Да вот не знаю, кстати, мне пока что только расширение с list.txt полезным показалось.

а что за расширение list.txt? не слышал. щас у себя посмотрел, el поддерживает ключи ?h=, ?n=, и ?el= :) сидел соображал. что к чему. не сообразил.

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

А lim совместим со всем, хоть с ii txt 0.1, меняется только строка в конфиге.

Точнее наоборот, сообразил :)

Тока оно неверно работает, надо поменять

Ага, это Оля. Просто я когда возобновлял станцию, взял первую попавшуюся версию, а она с Олей, я и оставил. При переезде на picnic тоже оставлю.

Я думал, ты про аватарки девочек, которые были в 2014 году. Надо попробовать их на py3 портировать.

http://ii.blcat.ru/idec.talks

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

здесь всё про nastene 0.6 и про данную станцию

Забираю с spnet readonly эху bot.habr.rss, но не всю, сейчас взял последние 100 сообщений

то же с эхой lor.opennet

стянул со spline архив эхи ii://game.rogue.14 но в общий список не выношу

https://infostart.ru/1c/articles/2208631/

Конкурент fheroes

ii/idec - это распределённая система сообщений, сильно упрощённое фидо. Общение идёт в эхах. Есть станции, они постоянно скачивают друг с друга по своему роутингу сообщения друг с друга. И есть пойнты, которые пишут сообщения в конкретную эху на конкретной станции.

По сути, любая станция знает только две команды:
* Отдай мне такие-то сообщения по такому-то критерию
* Прими сообщение от пойнта в эху

Nastene 0.6 и есть такая станция. Написана на python3 и работает на текстовых файлах.

Есть lite-интерфейс (поддерживает, например win95/ie4+), создана эха retro.talks: http://ii.blcat.ru/lite/retro.talks

Изначальная цель проекта - ведение маленьких, но дружных сообществ. Минифорум. Или минитвитер. Но распределённый. Проекту более 10 лет, но до сих пор сохранилось много сообщений многолетней давности с сайтов, которых уже давным давно нет. Что написано в ii, не вырубишь топором :).

До сих пор живые станции:

http://hugeping.tk
https://sprinternet.io/iii-web.php
http://idec.spline-online.ru/ (старейшая станция, с 2014 года)
https://tgistation.ru/

Пользователи могут как пользоваться веб-интерфейсом, так и скачивать и отправлять сообщения с помощью клиентов.

Относительно живые клиенты:

Caesium Golded-like

ii-txt 0.9 просто текстовые файлы : работает на python 2.4-2.7, хорош для первых пентиумов и какого-нибудь debian sarge на них

Архив проектов: https://github.com/idec-net

Скачать: http://ii.blcat.ru/s/nastene-0.6.tar.gz

Nastene Retro 98 : версия сервера для старых систем. Для python 2.5-2.7, только lite интерфейс, вырезано всё, что можно.

Идеальный вариант для ваших серверов с Debian Etch (или в Etch максимум 2.4? тогда ничего не поделаешь, придётся обновиться до Lenny)

В комплекте архив эхи retro.talks, будет что почитать долгой зимней ночью. И на станции уже сразу есть контент. К сожалению, заметки о Debian Sarge туда не попали в связи с их ненаписанностью, но будут доступны позже в эхе.

http://ii.blcat.ru/s/nastene-retro-98.tar.gz

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

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

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

http://ii.blcat.ru/rCu2q7hJ6T7vqKWjikjW

когда rt пишет свой ответ на shaos, моего сообщения там нет, физически

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://www.opennet.ru/opennews/art.shtml?num=62106

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

Я правильно понял, что если хорошо попросят, то могут просто удалить все копирайты этих участников, подтёршись всеми жепеелями, шмепеелями и так далее?

ps. shaos, фетчь с меня эху linux.14