спасибо за развёрнутый ответ
> Хитрость состоит в том, что в представлении Yggdrasil
> эти адреса являются отображением тех самых публичных ключей, принадлежащих тому или
> иному узлу сети. Адрес является одновременно и ключом
действительно очень хорошо сделано
> В чём-то действительно очень похоже на VPN, особенно по применяемым технологиям вроде
> TUN-интерфейса, но логически виртуальной приватной сетью это не является.
> Хотя бы потому, что задумано это всё как публичная, а не приватная сеть.
//оффтоп
имхо, публичный впн тоже бывает - всякие впн по обходу блокировок (слово "приватная" есть, а вход свободный однака...)
я понимаю впн не как "приватный нетворк", а как оверлейные туннели ака тор, создающие надсеть
> И работа в виртуальном оверлейном режиме рассматривается как такой прагматичный вспомогательный
> режим для узлов, не имеющих (пока) между собой прямых физических линков.
таких прямых линков между всеми узлами никогда не будет ибо роутеры у провайдера / a/v-dsl-модемы / 3-4-5g-модемы ни про какой yggdrasil-протокол никогда знать не будут (ток при коммунизме если)
> Однако возможность создания виртуальных приватных сетей также присутствует прямо внутри Yggdrasil.
> Доверенные узлы, явно обменявшиеся публичными ключами друг друга
а зачем ими обмениваться, если публичный==адрес ноды?
или речь об узнавании этого "псевдо-ipv6" адреса нужной ноды?
стандартными средствами yggdrasil можно сделать луковичную маршрутизацию? или защита анонимности не является целью yggdrasil ?
>> не понимаю смысла такого выделения
> будет создана программа, которая будет объявлять системе о
> поддержке схемы dweb:/ через себя и знать обо всех существующих пиринговых
> контентно-адресуемых сетях. Их разработчикам достаточно будет сходить в один репозиторий
> и внести туда параметры своего протокола.
я бы предпочёл, чтоб разработчики в своей системе реализовывали интерфейс http-proxy, который бы понимал обращение к "урлу" хэш/путь_после_хеша
хотя всё равно нужна программа/место, где будет записан стандартный порт прокси в эту систему
возможно http-proxy не очень как механизм взаимодействия с демоном системы, у меня просто перед глазами, что это из браузера должно работать
да и не знаю я протоколов управления "демоном" с работой по типу file open /dev/fs/ipfs/read/from512byte/to532byte/ipfs_hash_расшаренной_папки/путь_внутри
вроде бы реализация точки входа в виде http-proxy простая и многие её делают?
> Всё-таки dweb-протоколы резко отличаются от классических клиент-серверных
> тем, что для них необходим локальный демон на стороне каждого клиента.
а разве ftp: не требуется "демон", который умеет урл ftp://server/path превращать в биты запросов к серверу? в чём разница?
или речь о постоянно запущеном демоне для дистрибьютед-протокола? сегодня у меня трансмиссия, открыв файл торента, начала качать меньше чем за секунду фактически с холодного старта, вполне сравнимо с консольным ftp-клиентом
> А torrent: туда не включили хотя бы потому, что нет никакого torrent:,
> есть только magnet:. И возможности его более узкие, чем у IPFS.
> Например, не предполагается возможности обратиться через magnet: к отдельному файлу в
> раздаче. А без этого какой же это веб?
ничего не мешает сделать рабочим magnet://магнит/путь_внутри_файлов_описанных_в_торенте
и ничем от ipfs://хэш_папки/путь_внутри_расшаренной_папки отличаться не будет
