Децентрализованная сеть хранения контента

Пользователь Aksion уже несколько раз высказывал идеи о распределённом аналоге Webа с децентрализованным хранением контента. Этой ночью я задумался, как это вообще можно было бы реализовать технически, и решил изложить здесь некоторые соображения и ключевые понятия. Пока что идея в процессе обдумывания, поэтому получится достаточно сумбурно.
Итак, отправное понятие — это хост, то есть компьютер, на котором запущено некоторое программное обеспечение, которое реализует весь обмен данными. Хосты могут быть активными (с белым IP, к которым можно подключиться напрямую) и пассивными (которым можно передать данные только через те активные хосты, к которым они подключены). Алгоритм, по которому они находят друг друга и взаимодействуют, можно позаимствовать из Yggdrasil, там это достаточно хорошо реализовано.
Второе важное понятие — агент. В самом общем случае агент — тот, кто может создавать контент. У агента есть пара приватный-публичный ключ, а также подписанный приватным ключом  файл типа vCard (или какой-нибудь LD-JSON), где хранится человекопонятное название и описание агента, а также его тип: человек (person), организация, бот и сообщество/группа (community). При этом у каждого хоста есть список локальных агентов (то есть тех, чьи приватные ключи есть на данном хосте) и известных. При этом агент идентифицируется двумя способами: публичным ключом — для хостов, и человеко-понятным описанием — для пользователей. Также предполагается, что есть защита от дублей, то есть при создании нового агента делается рассылка по хостам, где проверяется, нет ли агента со слишком сходными параметрами (имя + описание + аватар). Агент не является однозначно привязанным к хосту. Чтобы агент считался локальным, достаточно, чтобы у хоста был его приватный ключ.
Следующее ключевое понятие — это контент или произведение. Ключевой момент, до которого я доходил достаточно долго: контент представляет собой не отдельный файл, а папку, где сохраняется всё, касающееся этого произведения. Во-первых, файл с мета-информацией: названием, аннотацией и данными автора. Во-вторых, собственно само произведение (статья, картинка, и т.п.). В третьих, цифровые подписи, сделанные для каждого файла приватным ключом автора. В четвертых, отметки других хостов, подтверждающие создание/копирование контента. Важно: контент всегда привязан к автору! Кроме этого, контент хранится с версионированием (аналогично тому, как это сделано в git).
И ещё одно понятие я бы назвал «реакцией». Это может быть лайк, комментарий, ответ на опрос или уведомление о создании контента-ответа, а также жалоба. Он подписывается ключом среагировавшего агента, но хранится не как самостоятельная единица, а в папке с произведением. (В качестве основы можно взять формат из ActivityPub.)

Как строится взаимодействие между узлами:
1. Новый хост подключается к какому-либо известному хосту сети (начальный список узлов придётся задавать в конфиге, как у yggdrasil), получает от него некоторое количество других известных хостов
2. Новый хост подключается к каждому из этих хостов и обменивается с ними следующей информацией:
а) локальные агенты,
б) известные агенты
в) метаинформация о хранящемся на хосте контенте
3. Если пользователь (точнее, в общем случае, агент) создаёт контент, он сохраняется на его хосте.
4. Если у какого-либо хоста обнаруживается более новая информация по уже хранимому контенту (например, реакции на него других пользователей или более новые версии), она в обязательном порядке копируется, если проходит проверку корректности цифровой подписи.
5. Хосты могут обмениваться контентом известных агентов, либо полностью, либо на уровне метаинформации, когда пересылается только название/описание контента и данные о хостах, где он лежит. По сути, главная проблема такой децентрализованной сети — это как определить, чем именно обмениваться, не имея полной информации о том, сколько копий контента вообще есть в системе. С одной стороны, очевидно, что нужно сохранять наиболее востребованный контент (что можно отследить по реакциям), с другой — наоборот, редкий, для которого сществует мало копий, чтобы не допустить его исчезновение. Возможно, тут поможет вот эта моя идея.
6. Раз в несколько минут каждый хост случайно выбирает какой-либо из известных ему, и обменивается с ним информацией об известных агентах и мета-информацией об их контенте.
7. Периодически хосты могут проводить верификацию — выбирать произвольный фрагмент хранящегося у них контента, считать его хеш, и посылать запрос на расчёт аналогичного хеша другим хостам, у которых есть этот контент.
8. Для каждого известного узла хранится репутация, которая считается на основе того, сколько контента хранит данный хост, как активно участвует в верификациях, а также на основе востребованности контента, созданного локальными агентами хоста. Она необходима для соблюдения принципа «сначала сделай что-то для сети, чтобы сеть сделала что-то для тебя» и для того, чтобы защититься от DDoS-атак, когда злоумышленник сгенерирует огромное количество случайного контента, чтобы занять всё отведённое на хостах место для хранения. Для её расчёта можно использовать предложенный мной когда-то алгоритм социального доверия.

Создание и отображение контента можно делать через Web-интерфейс в обычном броузере, который будет подключаться на localhost по какому-то известному порту. Там будет интерфейс, где будет показываться список уже созданного пользователем контента, полученные реакции, список локально хранимого контента, возможно, уведомления о новом (с возможностью настройки)  и интерфейс поиска.

Ещё важный момент: для известных пользователей хранится (и распространяется) информация о том, на каком хосте в последний раз пользователь был замечен как активный. Это поможет ускорить сбор реакций на контент (а также доставку личных сообщений, если таковые будут).
Реализовывать такое, думаю, лучше всего на Go как языке, сочетающем в себе компилируемость, кроссплатформенность и хорошие возможности по распараллеливанию задач.
Основной риск такой сети — это вброс злонамеренным пользователем какого-либо нелегального контента, который потом разойдётся по хостам остальных участников, о чём они даже не будут знать, но могут получить с этогопроблемы.

Ох уж эти белые IP адреса. (и узлы) - всё это слабые места любой децентрализации. Белый IP это то, что легко отбирается административно.
Мне кажется именно по этой причине не вводят который год IPv6. 
Тут как то подняли вопрос о устойчивости сети криптовалюты (несколько видов криптовалют) на форумах разработчиков, так им пришлось даже эти темы закрыть, потому в ходе анализа и дискуссии нескольких сообществ крипты оказалось, что любую криптовалюту можно убить просто отобрав белые IP у держателей нод и блокчейна (белоIPишных майнеров и пулов). А ведь долгие годы главным аргументом всех разработчиков крипты о неубиваемости криптовалют было то, что криптовалюту нельзя уничтожить потому что придется уничтожить весь интернет типа а на это власти типа не могут пойти. Ан нет...оказалось, что для нужд государств и бизнеса вполне достаточен интернет пользователей (обывателей как бы сказал Про) за NATом на серых динамичных IP. 
Поэтому надо что то на основе DHT или еще что то лучше поверх серого интернета.
Кстати в тот день когда несколько разрабов криптовалют просто закрыли темы на коференциях про зависимость крипты от белых IP узлов и полностью затыкали несколько дней рты многим прозревшим даже околоразрабам , - многие поняли, что крипта полностью подконтрольна (а скорее всего и создавалась) на уровне властей и государств и полностью регулируема. Об этом говорит и то что именно тогда резко затух бум крипты в целом по миру, и вообще в информационном пространстве. Можно сказать это был день начала смерти крипты

А тут уже ничего не поделаешь, такова сама природа протокола TCP, что хотя бы два узла должны иметь публичные адреса (неважно, IPv6 или IPv4, если программная реализация сделана так, что умеет работать с обоими протоколами). То же верно и для Torrentов, и для yggdrasil (с некоторыми оговорками) и для прочих децентрализованных систем. Разве что изобретать что-то, что может коннектиться через WebRTC, который умеет обходить NAT. Но и то там агенты как-то должны узнать о существовании друг друга.
Другой вопрос, что запретить арендовать VDS с белым IP для такого узла где-нибудь достаточно сложно: так или иначе обходные пути будут находиться.

мне вот интересно, а как я вот тогда по DHT передаю через торрент файлы раздачу с одного компа с серым IP за NAT на другой комп с серым IP за NAT без указания трекера какого либо при создании торрент файла (и саму раздачу и торрент создаю на компе с серым IP).
Я много раз проверил что трекеры не участвуют, на разных раздачах. При этом и других сидов и пиров не подключается. Хотя даже в спецификации DHT написано, что один из участников должен быть с белым IP. Может что то уже доработали?


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

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

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

Любопытно: пару недель назад думал, что хорошей идеей было бы реализовать всё это на смартфоне, и попалась статья на Хабре на ту же тему https://habr.com/ru/companies/ruvds/articles/766518/habr.com

Имхо, как и для распределённой системы хранения файлов, нужна простенькая двутабличная распределённая БД. Что-то вроде моих тривьюшек или твоей будущей MLFW.

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

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


--




Ранее, сам же пишешь:

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

Как правило, точных копий вебстраничек не требуется. Достаточно применений Firefox-плагина Scrapbook X (или Scrapbook Web того же автора). Примеры нужны? — у меня так хранятся множество форумных страничек, которые жалко было терять - это прообраз статичных виртуальных тем - тоже очень полезная штука...