> не понял: в Yggdrasil адреса, выглядящие как ipv6, могут получить соединение как
> через ipv6-протокол через yggdrasil-vpn, так и через некий yggdrasil-протокол, поддерживающий
> единое адресное пространство с ipv6-протоколом?Адресное пространство у Yggdrasil и обычного IPv6 действительно общее, но для отделения одного от другого применяется обычное локальное правило маршрутизации. Со стороны пользователя это выглядит как дополнительный сетевой интерфейс, на который назначен адрес из ipv6-подсети 0200::/7, которая смаршрутизирована через этот же интерфейс. Адреса из этой сети и применяются в качестве адресов Yggdrasil. Сама эта подсеть заброшена и никому особо не нужна, так что вероятность коллизий с уже задействованными где-то адресами, как это однажды было с Hamachi, минимальна. (В cjdns для этой же цели использовался диапазон для приватных адресов fc00::/8, который что-то вроде 192.168.0.0/16. Но это было менее удачным решением.) Благодаря правилу маршрутизации, все пакеты для новоявленных Yggdrasil-адресов отправляются в этот интерфейс, и далее попадают к демону, который шифрует их публичным ключом узла, соответствующего адресу назначения, и отправляет его дальше в соответствии со своими внутренними правилами. Хитрость состоит в том, что в представлении Yggdrasil эти адреса являются отображением тех самых публичных ключей, принадлежащих тому или иному узлу сети. Адрес является одновременно и ключом, что очень удобно и избавляет от необходимости дополнительных слоёв шифрования, удостоверяющих центров и всего такого прочего.
В чём-то действительно очень похоже на VPN, особенно по применяемым технологиям вроде TUN-интерфейса, но логически виртуальной приватной сетью это не является. Хотя бы потому, что задумано это всё как публичная, а не приватная сеть. И работа в виртуальном оверлейном режиме рассматривается как такой прагматичный вспомогательный режим для узлов, не имеющих (пока) между собой прямых физических линков. Однако возможность создания виртуальных приватных сетей также присутствует прямо внутри Yggdrasil. Доверенные узлы, явно обменявшиеся публичными ключами друг друга, могут туннелировать между собой обычный IP-трафик примерно так же, как это можно сделать с помощью OpenVPN или Wireguard. Главное отличие состоит в том, что двум узлам для этого необязательно быть напрямую подключённым друг к другу. При наличии маршрута трафик между ними может прозрачно проходить и через промежуточные узлы.
Ну и сделано вот это отображение ключей в адреса для того, чтобы аккуратно и без помех встроиться в существующий сетевой стек. Напрямую добавлять в каждую операционную систему нескучную PKI-адресацию сетевого уровня было бы уж слишком накладно.
> не понимаю смысла такого выделения
Рассмотрим это с практической стороны. Предполагается, что в будущем будет создана отдельная компактная программа, возможно кроссплатформенная, которая будет объявлять системе о поддержке схемы dweb:/ через себя и знать обо всех существующих пиринговых контентно-адресуемых сетях. Их разработчикам достаточно будет сходить в один репозиторий и внести туда параметры своего протокола. (На практике скорее всего в два, потому что помимо общесистемной скорее всего будет ещё и отдельный браузерный аддон. Но это не точно.) Тогда, при попытке открытия адреса вида dweb:/shinynewp2p/<...> и отсутствии в системе обработчика для shinynewp2p:/ эта компактная программа будет выдавать окно с текстом вида "Вы попытались открыть адрес протокола Shiny New P2P. Но в вашей системе не установлен демон, который её реализует. Установите и запустите пакет shiny-new-p2p для открытия таких адресов". И так для каждого из них. Или даже предупреждать, что о таком протоколе ей неизвестно (пока ещё), но скорее всего это тоже пиринговый dweb-протокол. (Последнее, понятное дело, сработает только в том случае, когда разработчики новых p2p-систем тоже будут оставлять ссылки в таком формате.) Без применения "надпротокола" собирать их все вместе будет довольно-таки неудбно. А так - кто объявляет себя dweb-системой, тот скорее всего ей и является. Всё-таки dweb-протоколы резко отличаются от классических клиент-серверных тем, что для них необходим локальный демон на стороне каждого клиента. Эту вот разницу и призвана, вероятно, подчёркивать общая схема, и время ответа тут особенно не при чём.
А torrent: туда не включили хотя бы потому, что нет никакого torrent:, есть только magnet:. И возможности его более узкие, чем у IPFS. Например, не предполагается возможности обратиться через magnet: к отдельному файлу в раздаче. А без этого какой же это веб?
Пока что весь этот dweb: находится только на стадии обсуждения и ранних экспериментов, несмотря на регистрацию в IANA. Может быть, и что-нибудь другое в итоге будет придумано.
