Я придумал p2p-аналог интернетов, который относительно не трудно реализовать. Сеть не нужно настраивать (zeroconf), и является юзерфрендли.

> Зачем?

На криптаче такие глупые вопросы не задают.

> Чем лучше аналогов?

У каждой скрытосети свои плюсы и минусы. Эта сеть - просто еще одна альтернатива.

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

Начнем рассматривать с самого высокого уровня сети - обычного пользователя сети (не программиста):
1. Юзер скачивает пакет.
2. Устанавливает.
3. Происходит магия.
4. Заходит в браузер.
5. Набирает hive:410/test.p2p
6. Заходит на сайт.

Когда заходит просто на hive:410 - открывает домашнюю страницу проекта с менеджером файлов и прочими настройками и интересностями.

Опускаемся ниже : уровень данных.

Как вообще выглядит Hive? Представьте себе кучу файлов имеющих фактический адрес (хеш). К любому файлу обраться по адресу hive:410/${hash}. Но для удобства использования сети, мы можем называть файлы человекочитаемыми именами. Делается это с помощью HNS (Hive NameSpace) - распределенной хештаблицы.
К примеру, программист создал html-файл, и создал в HNS запись что к данному файлу можно обратиться по "example.hive" и подписал запись.

Заметили? Здесь нет концепции "сайта" как некой папки с файлами. Все файлы сети находятся в куче и нет разделения между сайтами.
Программист создает папку с проектом и специальная утилита загружает все файлы проекта в "кучу" подписывая в HNS файлы как {"test.p2p/js/main.js": "==Hxkdhiei6473...", к примеру. Обращаться можно как публичному имени, так и по хешу. Хеш удобен в случае медиаконтента, публичное имя удобно в случае рабочих файлов проекта (скриптов, баз данных и тд).
Хеш публичного имени можно заменить.

Само API улия убийственно простое:
1. GET hive:410/${hash|pubname} - запросить файл по имени или хешу.
2. POST hive:410 - отправить файл в кучу.
3. PUT hive:410/${pubname} - обновить запись в HNS (доказав, что владелец записи). Либо создать запись.
4. DELETE hive:410/${hash|pubname} - в случае с публичным именем - удаляет запись. В случае хеша - удаляет файл в локальной куче пользователя.

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

Еще ниже, уровень пиров:
В Hive используется IPv6. Понятное дело, пользователей с IPv6 по пальцам пересчитать, потому используем костыль Miredo/Teredo, идущий как зависимость пакета. Miredo не требует к конфигурации, оно просто устанавливается вместе с пакетом и дает тебе IPv6 без какой-либо задней мысли.

На это уровне так же есть DHT включающий все пиры в сети.

Как получить Peer DHT если ты в первый раз зашел в сеть? Через публичные пиры, работающие на постоянной основе. Они либо будут прописаны в конфиге изначально, либо надо будет искать на Github список публичных пиров и прописывать их в конфиге ручками, как это надо делать с Yggdrasil.

hive:410 как вы уже поняли представляет собой локальный http-сервер.

Когда клиент запустился, он пытается обновить все свои DHT.

Когда юзер пытается получить файл, сервер смотрит в DHT и ищет там у кого можно этот файл взять, и обращается к ним. Файл скачивается, и юзер начинает раздавать его другим. Он отправляет всем другим юзерам весть о том, что этот файл можно найти у него.

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

Когда юзер обновляет запись в HNS он подписывает изменения и вещает об этом. Другие пользователи проверяют изменения и в случае мутной хуйни отклоняют изменения в локальной NHS.

Тоже самое происходит при удалении записи, правда, запись не пропадает бесследно, вместо нее появляется запись с тем же адресом, но вместо хеша - сообщение о том, что запись удалена подпись владельца(ов) записи.

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

И так немного по вопросам к реализации непосредственно опытным криптачерам:
Стоит ли писать сервер сразу на bash? Меньше зависимостей будет. Правда, теряется кроссплатформенность. Но над ней в принципе придется поработать в любом случае.

Как лучше всего поддвержать и проверять на законность тех или иных изменений в HNS?

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

Как лучше всего получать новые DHT при запуске клиента (особенно при первом)? Не доверять же первому встречному пиру.

Как лучше передавать файлы? Искать у случайного владельца файла и качать целиком, или скачивать у всех но порциями (как в торрентах)?

мимо ламер