> Зачем?
На криптаче такие глупые вопросы не задают.
> Чем лучше аналогов?
У каждой скрытосети свои плюсы и минусы. Эта сеть - просто еще одна альтернатива.
Предлагаю обсудить проект, и может присоединиться к его разработке.
Начнем рассматривать с самого высокого уровня сети - обычного пользователя сети (не программиста):
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 при запуске клиента (особенно при первом)? Не доверять же первому встречному пиру.
Как лучше передавать файлы? Искать у случайного владельца файла и качать целиком, или скачивать у всех но порциями (как в торрентах)?
мимо ламер
Hive можно сравнить с некой круглой площадью вместе с людьми.
Те люди, что находятся на краю круга - публичные пиры. Когда новый человек желает войти в круг (сеть), они дают ему всю необходимую информацию для функционирования в круге, а так же сообщают всем членам площади, что пришло пополнение.
У каждого члена круга есть папочка с файлами, который он готов хранить и распространять. Так же есть несколько книжек:
1. Книжка о том, кто какие файлы хранит.
2. Книжка человекочитаемых названий некоторых файлов.
3. Книжка с именами всех посетителей круга.
Люди постоянно обновляют записи и проверяют друг друга на мухлеж.
Надеюсь, объяснил понятным образом.
У этой сети есть какие-то преимущества перед ZeroNet и другими p2p хостингами? Пока что кажется, что тут ничего нового нет.
> У этой сети есть какие-то преимущества перед ZeroNet и другими p2p хостингами?
Таки есть. DNS over DHT. Напомню в других скрытосетях DNS либо нет, либо они анальные.
Ну, Hive вдохновлен многими уже существующими сетями. "Куча файлов" - из IPFS, IPv6 - из Yggdrasil (отсюда - высокая скорость сети, по сравнению другими сетями, сравнимая с Yggdrasil).
Как гарантировать консистентность данных? Возможное решение - сделать транзакции в базу на блокчейне, в таком случае необходим свой транслятор для генерации конечного файла БД из цепочки, а чтение и запись можно делать напрямую в JS, но плохо, что появится задержка появления данных равная времени генерации блока, хотя можно сделать время генерации от одной минуты до бесконечности, чтобы не было пустых блоков без транзакций. Может, есть и другой вариант?
И второе: судя по ОП-посту в сети анонимность на уровне торрентов, то есть любой пир будет видеть, что ты на себе хостишь, а прикручивание слоёв очень сильно замедлит сеть, сужу по своему опыту с I2PSnark.
> Допустим, я хочу не просто захостить статичную страницу, а сделать в данной сети некий сайт с динамичными данными, например, борду. Соответственно, должна быть некая БД, в которой хранятся посты.
Я предлагаю использовать уже встроенные в систему броадкастинг. Мы отправляем ивент совладельцам сайта, они решают добавлять данные в БД или нет. Так я делал распределенные DB по WebRTC. Тема рабочая и проверенная.
> И второе: судя по ОП-посту в сети анонимность на уровне торрентов
"Анонимность не являются принципиальной задачей для нас. Нужна анонимность - заходите в сеть через Tor."
Yggdrasil, ZeroNet ©
Постим также, зачем создавать велосипед.
Кто является совладельцем сайта? Скорее всего изначально тебя не понял, думал, что по аналогии с битторрентом любой пользователь для посещения сайта должен его скачать и встать на раздачу.
И по аналогии додумал следующее: так как я могу создать торрент-файл, встать на раздачу, дать другим людям его скачать, а затем уйти, файл останется доступен, значит то же самое я должен иметь возможность делать с сайтом. Единственное, что имеет только создатель - редактирование DNS записей.
> Кто является совладельцем сайта?
Фактически, любой кто зашел на сайт.
> битторрентом любой пользователь для посещения сайта должен его скачать и встать на раздачу.
Да, ты понял верно.
> Единственное, что имеет только создатель - редактирование DNS записей.
Да, здесь имеется разный уровень прав.
Понял. Только что будет представлять из себя проверка на корректность данных? В БД можно только писать, а вот удалять и изменять нельзя?
Есть какие-либо наработки, помимо написанного в треде?
Хотел бы помочь с реализацией в свободное время, правда с p2p сетями никогда не работал.
> В БД можно только писать, а вот удалять и изменять нельзя?
Это зависит от разработчика сайта полностью. Hive дает только канал для общения пиров.
> Есть какие-либо наработки, помимо написанного в треде?
Я работал с WebRTC. Написать собственный p2p-сайт можно и без создания целого протокола. Правда, все данные сайта будут храниться непосредственно в браузере - как только юзер кеш почистит, дб стереться. Неудобно.
> Это зависит от разработчика сайта полностью. Hive дает только канал для общения пиров.
Не вижу смысла каждому разрабу писать/копипастить один и тот же код каждый раз, когда необходима БД, вместо того чтобы добавить синхронизацию БД в протокол. Появляется неудобство использования одной из ключевых кмк фич сети.
Да и к тому же не представляю как это реализовать. Вот есть у тебя страница, есть на ней кнопка, после нажатия на которую в итоге должна добавиться запись в БД. Для этого тебе надо использовать Hive API. Куда и какой запрос будешь слать? Твой API работает только с файлами и позволяет редактирование только создателю.
> Написать собственный p2p-сайт можно и без создания целого протокола.
> как только юзер кеш почистит, дб стереться
Это-то понятно, для этого нужен локальный веб-сервер, который всем рулит, ну ты это и так знаешь. Исходники i2pd глядел, можно всё абсолютно так же сделать, за исключением чесночной маршрутизации.
> Вот есть у тебя страница, есть на ней кнопка, после нажатия на которую в итоге должна добавиться запись в БД.
Нажал кнопку, отредактировал локальную дб, отправил интент остальным пирам. Всё через REST API локального сервера.
> отредактировал локальную дб
Т.е. получил от веб-сервера файл БД, открыл его в контексте браузера, там же отредактировал и отправил обратно? Это целиком БД в оперативке висеть будет.
> отправил интент остальным пирам
Каким методом происходит обновление и в какой момент должна быть проверка на корректность данных?
Проверка обязана быть на стороне веб-сервера, так как в случае некорректности входных данных необходимо отклонить изменения. По крайней мере должен вызываться какой-то "прикреплённый" к файлу JS-код, который принимает на вход обе версии файла и возвращает true/false в зависимости от корректности данных.