Я не могу найти его в документации сейчас, но я помню объяснение в следующих строках:
IPFS — это файловая система, и для файловых систем вы используете пути, а не URL-адреса. URL-адреса можно понимать как уродство, которое представляет собой неспособность унифицировать доступ на вашем локальном компьютере и на удаленных компьютерах. IPFS избегает этого уродства, обрабатывая локальные и удаленные файлы одинаково, а метод адресации файлов — стандартный путь.

Это может помочь представить монтирование всей IPFS в /ipfs, а затем доступ к файлам, как если бы они были просто файлами в вашей файловой системе.

Дополнительные материалы для чтения:

Длинное обсуждение: https://github.com/ipfs/go-ipfs/issues/1678 .
Краткое изложение текущего консенсуса: https://github.com/ipfs/go-ipfs/issues/1678#issuecomment -157478515

Кроме того, в настоящее время ведется работа по согласованию абсолютных адресов IPFS со стандартным разрешением URL и решению проблемы идентификации источников с помощью (или без?) fs: paths .

И https://github.com/ipfs/in-web-browsers/issues/28 со ссылкой на черновик спецификации. копия @lgierth

:( После прочтения ipfs/go-ipfs#1678 я даже не уверен, интересуюсь ли я больше IPFS :( . Это было ужасное отсутствие обсуждения.

Я действительно не хочу заходить в сарай для велосипедов, но это

It might help to imagine mounting the entire IPFS under /ipfs and then accessing the files like they are just that: Files in your file system.
это не идея, которая меня заводит. Я представляю себе, что у меня внезапно появился системный корень, который выглядит как
/btrfs/dev/sda1/.. /fat32/dev/sda2/.. /ext3/dev/sda3/boot/..

Это не та концепция, которая мне нравится. Я привык организовывать свою систему так, как мне нравится, и монтировать файловые системы по своему усмотрению. Но на самом деле меня отталкивает не это. Вы можете монтировать ipfs где угодно. Меня отталкивает маниакальный подход «давайте изобретем все заново». Я пришел в IPFS, потому что хотел распределенную CAS. Это все, что меня интересовало. Меня не волнует слияние unix с сетью. Но после прочтения этого обсуждения IPFS больше не кажется продуктом, который поможет мне получить распределенную CAS, он кажется продуктом, который будет диктовать, как я использую файловую систему моего компьютера и пространство имен, и как только авторы диктуют одну вещь, возможно, они будут иметь некоторые другие новые идеи о том, как мой компьютер должен быть настроен и организован. Я не могу предсказывать будущее, но мне не нравится такой подход.

Это очень плохо, потому что мне ОЧЕНЬ НРАВИТСЯ реализация распределенного CAS в IPFS. Я давно мечтал о распределенной CAS :(. Так что мне придется вернуться в режим исследования и посмотреть на некоторые другие распределенные CAS...

@timthelion Я вижу, вы (как и я) действительно заботитесь о CAS и IPFS.
Я сделаю все возможное, чтобы облегчить ваши заботы.

Я совершенно уверен, что вы можете использовать IPFS в качестве CAS, никогда не устанавливая его где-либо в вашей системе.
То, что я думаю о путях /ipfs/Qm.. заключается в том, что они являются просто мысленным ярлыком, который упрощает разговоры и ссылки (точно так же, как и обычные URL-адреса).

Лично я согласен с тем, что ситуация с «обработчиками протоколов» и «семантикой канонических адресов» может показаться сторонним наблюдателям беспорядком прямо сейчас, но хорошие люди работают над прагматичными решениями, которые могут работать прямо сейчас (например, https://github.com/ ipfs/in-web-browsers/issues/3, https://github.com/ipfs/in-web-browsers/issues/7).

Это непрерывный разговор, и эти вещи требуют времени.

Общее направление проекта (мое личное мнение) состоит в том, чтобы «создавать полезные инструменты, повторно использующие отраслевые стандарты там, где это целесообразно», а не «изобретать все заново, несмотря ни на что»_.

Я не думаю, что тебе следует беспокоиться о будущем. Инструменты IPFS следуют _"пути unix"_, а это означает, что многие небольшие инструменты, библиотеки и команды (похожие на подкоманды git ), которые выполняют одно действие, могут быть объединены в цепочку для создания чего-то большего.

Вы тот, кто решает, какие части использовать. ⚙️ 🔧

Я надеюсь, что никто не воспримет мой последний пост неправильно. Я не хочу сказать: «Вы все придурки, я ухожу». Я предполагаю, что тысячи людей посмотрели IPFS, решили, что им что-то не нравится, и ушли, даже не написав почему... Я часто так делаю. Я просто случайно смотрю на технологию и выбираю другую, основываясь на какой-то мелкой детали, которая меня раздражает. Я решил не делать этого, потому что не хотел быть молчаливым членом молчаливого большинства, а также потому, что у меня не так много других вариантов :D, но, похоже, мне придется подождать ipfs для поддержки fs:// или того, что выберут руководители проекта, прежде чем я начну использовать ipfs в своем текущем проекте, и я серьезно смогу начать смотреть на IPFS только до тех пор, пока не появятся какие-то реальные нормальные URL-адреса.

меня отталкивает маниакальный подход «давайте изобретаем все заново».

Вы увлеклись, в этом нет ничего «маниакального» или даже переизобретения. Мы говорим о том, что пути к файлам используются, как всегда. Монтирование на /ipfs было просто примером для иллюстрации, а не основной идеей.

Я привык организовывать свою систему так, как мне нравится, и монтировать файловые системы по своему усмотрению.

Никто не заставляет вас монтировать IPFS как локальную файловую систему @timthelion . Это функция, которую вы можете использовать, и вы можете решить, по каким путям она монтируется. Неприятие функции, отключенной по умолчанию, звучит для меня как слабая причина для отказа от IPFS в целом. Но что ж, я надеюсь, что в будущем вы передумаете и присоединитесь к нам снова.

Я не видел ни одного продукта, где бы всем нравилась каждая функция.

Стоит также отметить, что на самом деле это ничего не изобретает. Это что-то "неизобретать".

Несмотря на наши разные мнения, обработчик fs:// , который обеспечит вам необходимую поддержку, внедряется прямо сейчас, и вы уже можете использовать его с расширениями браузера . Мы также работаем над реализацией PoC, чтобы браузеры могли использовать его изначально. Вы также можете реализовать его поддержку в приложениях с электронной оболочкой. Может быть, вы можете внести свой вклад в эти усилия, чтобы заставить их работать быстрее.

«Вы увлеклись, в этом нет ничего «маниакального» или даже повторного изобретения».

Я интерпретирую https://github.com/multiformats/multiaddr как маниакальный и заново изобретающий. Это другой формат, чем URL, но он представляет те же данные. Вам нужна чертовски веская причина, чтобы заново изобрести такой важный стандарт.

Я буду немного более подробным.

«Мы говорим о том, что пути к файлам используются так, как всегда».

Думаю, я понял, к чему вы, ребята, клоните с этой идеей. Является ли «ошибкой», которую вы пытаетесь исправить, тот факт, что вы не можете обращаться с веб-ресурсами как с обычными файлами? Вот так я не могу сделать cat http://google.com/index.html ? Я могу согласиться с вами, что это грустно, что это невозможно. Если бы мне пришлось писать операционную систему, я бы сделал функцию open способной открывать URL-адреса файлов. Возможно, такое изменение можно было бы внести даже в Linux. Ваш подход отличается, вы пытаетесь вставить веб-ресурсы в файловую иерархию POSIX. Если есть какая-либо другая причина, по которой вы считаете, что URL-адреса являются ошибкой, сообщите мне.

Я определенно могу сочувствовать вашей цели заставить веб-ресурсы вести себя как обычные файлы. Ваш метод исправления "ошибки", однако, кажется мне довольно скользкой дорожкой. Если я ДЕЙСТВИТЕЛЬНО выберу монтирование файловых систем ipfs, то их точка монтирования станет для меня новым поведением. Я не могу придумать никакой другой программы пользовательского режима, которую я мог бы установить в своей системе, которая создала бы несколько каталогов непосредственно в моем корневом каталоге.

Сегодня, когда я делаю ls / , я получаю:

$ ls / bin/ dev/ home/ lib/ media/ opt/ root/ sbin/ sys/ usr/ vmlinuz@ boot/ etc/ initrd.img@ lib64/ mnt/ proc/ run/ srv/ tmp/ var/

С путями, предложенными multiaddr, я бы вместо этого увидел:

$ ls / bin/ bitcoin/ boot/ dev/ dns/ dns4/ dns6/ etc/ home/ http/ https/ initrd.img@ ipfs/ lib/ lib64/ libp2p-circuit-relay/ libp2p-webrtc-direct/ libp2p-webrtc-star/ media/ mnt/ onion/ opt/ p2p/ proc/ root/ run/ sbin/ sctp/ srv/ sys/ tmp/ udt/ unix/ usr/ utp/ var/ vmlinuz@
https://github.com/multiformats/multiaddr/blob/master/protocols.csv

И прежде чем вы обвините меня в неправильной интерпретации стандарта, я напомню вам, что я интерпретирую его точно так же, как пути unix ВСЕГДА интерпретировались.

Очевидно, я не собираюсь делать такой беспорядок в моем корневом каталоге. Поэтому я предпочитаю не монтировать эти пути.

В моем случае это все равно не мой выбор, я хочу написать программное обеспечение, использующее IPFS, и не мое решение, монтирует ли пользователь эти пути или нет. Но я по-прежнему хочу, чтобы мои пользователи могли открывать файл, к которому предоставлен общий доступ через IPFS, так же легко, как и файл на своих локальных компьютерах. Итак, как мне написать этот код? Если бы ipfs использовал стандартные URL-адреса, я бы просто пересылал все, что начинается с ipfs://, в ipfs, и все было бы просто.

Но когда моя программа просматривает строку, начинающуюся с / она интерпретирует ее как абсолютный путь к файлу или каталогу на чьем-то компьютере, обычно на компьютере, на котором выполняется код. Если ему будет предложено посетить путь, начинающийся с / , он ОПРЕДЕЛЕННО интерпретирует его как абсолютный путь к файлу или каталогу на локальном компьютере. Если /ipfs не существует на моей машине, программа должна вернуть ошибку «файл не найден». Я не могу придумать другого примера, где абсолютный путь, который программа должна посетить, ведет куда-то еще, кроме как к файлу или каталогу на локальном компьютере. Так что для меня, как давнего пользователя/разработчика Linux, это новое поведение.

Если бы мое приложение попыталось добавить поддержку multiaddr, все бы очень быстро зашло в тупик. Что, если пользователь запустит:

$tims-program-that-supports-normal-files-as-well-as-multiaddr /http/index.html
?

и у пользователя есть веб-сервер, который хранит свои html-файлы в /http . Совсем не неслыханно. Должна ли моя программа разрешать это в многоадресный адрес или в локальный файл?

Я уже написал код с примитивной поддержкой открытия URL-адресов в python. Сделать это было довольно легко. Но как мне изменить свой код, чтобы он однозначно разрешал как многоадресные пути, так и локальные пути к файлам?

if filename.startswith( "http://" ) or filename.startswith( "https://" ): import urllib.request try: with urllib.request.urlopen(filename) as webgraph: self.json = webgraph.read().decode("utf-8") except urllib.error.URLError as e: raise OSError(str(e)) else: try: with open(filename) as fd: self.json = fd.read() except FileNotFoundError: pass

Я действительно не думаю, что это возможно. Таким образом, я не реализую поддержку многоадресности и поддерживаю только обычные URL-адреса. Поначалу это кажется прекрасным, но пользователи ipfs будут постоянно получать многоадресные адреса для объектов ipfs, и моя программа, рекламирующая поддержку IPFS, будет утверждать, что таких путей не существует. Поэтому независимо от того, как я реализую поддержку, моя программа будет сломана. Либо его поддержка ipfs будет нарушена, либо его поддержка стандартной файловой системы POSIX будет нарушена.

Есть способы, как это можно исправить, потенциально. Можно было бы полностью отказаться от многоадресности. Другим было бы изменить multiaddr так, чтобы он, по крайней мере, ограничивал эти пути одним подкаталогом. Таким образом, вместо того, чтобы писать /ipfs/hash/blah , нужно было написать /webfs/ipfs/hash/blah . И ls / вернется:

$ ls / bin/ dev/ home/ lib/ media/ opt/ root/ sbin/ sys/ usr/ vmlinuz@ boot/ etc/ initrd.img@ lib64/ mnt/ proc/ run/ srv/ tmp/ var/ webfs/

Это было бы то, с чем я мог бы жить и, возможно, даже отстать. Но текущая ситуация такова, что я не знаю удовлетворительного способа реализовать поддержку ipfs вообще.

Позвольте мне перейти к еще более КОНКРЕТНОМУ примеру. Представьте, что я пишу программу, которая конвертирует уценку в PDF. И я хочу иметь возможность поддерживать включение изображений из IPFS. Итак, пользователь пишет:

чердак.мд
````

Вещи, которые я нашел на своем чердаке

Старый ящик камней.

````

И бежит

$ tims-md-to-pdf-with-ipfs-support attic.md > attic.pdf

Как моя программа должна разрешать эти пути к изображениям? Предполагается ли, что файловая система /ipfs смонтирована? Мы уже договорились, что пользователей не заставляют монтировать /ipfs . Должна ли программа рассматривать /ipfs/ как специальный префикс? Это кажется странным и сломанным. Должна ли программа поддерживать только fs:// и возвращать ошибку, файл не найден по этим путям? это кажется разумным, но смутит пользователей, привыкших к многоадресному стандарту. Просто нет правильного выхода из мешка! :/ :(

отредактировано для уточнения

Спасибо за предоставление некоторых вариантов использования @timthelion. Здорово, когда люди предлагают примеры из реальной жизни, чтобы мы могли убедиться, что протоколы работают для реальных людей.

Уточнение примера «монтирование всего в /»

Как отметил @lidel , в настоящее время люди работают над разработкой схемы адресов, поэтому документации пока нет. Похоже, что пример монтирования файловой системы @jbenet создал путаницу. Это всего лишь пример, призванный помочь людям обдумать концептуальную модель схемы адресов fs: или dweb: . Он не предлагает, чтобы мы заставляли всех монтировать все эти каталоги в своих файловых системах. Скорее, он предлагает, чтобы мы могли _идентифицировать_ контент с адресами, которые ведут себя так, как будто контент смонтирован в вашей локальной файловой системе, потому что это позволит нам взаимодействовать с контентом web/dweb с помощью инструментов unix/posix.

Когда мы будем писать документы, мы должны быть осторожны, чтобы сделать это ясным. Спасибо, что отметили это.

В ответ на ваш пример «вещи на чердаке», я думаю, идея состоит в том, чтобы вы использовали fs:/ в своих ссылках, например:

Stuff I found in my attic
----------------------------------

![An old box of rocks](fs:/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV)

An old box of rocks.

![A can of oil for water-proofing leather](fs:/ipfs/QmUPC5xbVtu6NxMwFBtmWVjrVM3XffuPtSMLpmDFGfTaKG)

Наличие простых адресов и унификация схем

Боковое примечание: существует также проблема сохранения простых адресов. В этом комментарии @nicola предложил умный способ поддержки адресов ipfs:/ и ipns:/ без нарушения адресной схемы fs: / dweb: . Используемая гимнастика при разработке протокола (ИМХО) ужасно сбивает с толку, но, в конце концов, это позволит вам иметь ссылки в вашей уценке, такие как ipfs:/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV , а также позволит людям обращаться к тому же контенту, как fs:/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV или всего /ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV в контексте unix/posix.

Абсолютные пути зависят от контекста

Что касается абсолютных путей, вы сказали:

Если ему будет предложено посетить путь, начинающийся с /, то он ОПРЕДЕЛЕННО интерпретирует его как абсолютный путь к файлу или каталогу на локальном компьютере.

Имейте в виду, что существует достаточно прецедентов для абсолютных путей относительно _context_, а не относительно корня файловой системы. Наиболее распространенным примером этого являются абсолютные пути в HTML, которые указываются относительно корня текущего origin , а не относительно корня файловой системы сервера. Если у меня есть код, работающий в контексте, который предполагает, что все пути равны fs: или dweb: , для этого кода вполне допустимо использовать адреса, начинающиеся с /ipfs/ , и есть у этого кода есть множество способов разрешить пути без буквального монтирования ipfs в /ipfs в вашей файловой системе.

Это мои 2 цента:

• Каждый файл находится под fs:/ , точно так же каждый домен находится под http:/ .
• Я не монтирую систему доменных имен на / в своей файловой системе точно так же, как я не монтирую всю IPFS на моем / . В обеих системах точкой отсчета является / относительно схемы ( http:/ , fs:/ ).

Я думаю, что в большинстве ваших примеров есть представление о том, что каждая файловая система смонтировала ipfs на / . Таким образом, наличие fs:/ не нарушает формат URI.

Скорее, он предлагает, чтобы мы могли идентифицировать контент с адресами, которые ведут себя так, как будто контент смонтирован в вашей локальной файловой системе, потому что это позволит нам взаимодействовать с контентом web/dweb с помощью инструментов unix/posix.

«Это позволит нам взаимодействовать с контентом web/dweb с помощью инструментов unix/posix». Не могли бы вы привести конкретный пример случая, когда синтаксис без префикса fs: будет использоваться с инструментом unix? Почему-то я до сих пор не понимаю.

Я пытался сам придумать пример, но не могу придумать ни одного примера, в котором синтаксис с префиксом /ipfs , совместимый с multiaddr, имеет смысл.

Я попытался сделать оболочку для утилиты diff в bash, которая поддерживала ipfs с использованием схемы multiaddr:

````
timothy @yoga ~/c/ipfs-multiaddr> cat multiaddr-diff

!/бин/баш

get_multiaddr_or_normal_file_getter(){
если [[ $1 == /ipfs/* ]] ;
тогда
file_getter="ipfs cat $1"
еще
file_getter="кот $1"
фи
эхо $file_getter
}

файл1= get_multiaddr_or_normal_file_getter $1
файл2= get_multiaddr_or_normal_file_getter $2

разница <($файл1) <($файл2)
````

Это работает в наивном случае как для обычных файлов, так и для файлов ipfs:

````
Тимоти @yoga ~/c/ipfs-multiaddr>
./multiaddr-diff ../subuser/COPYING.LGPL /ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127а128,130

е) Принесите своего первенца в жертву БОГУ Лаурату в первый же день.
полнолуние следующего четного года.

````

Но когда я пытаюсь использовать его для работы с реально существующим файлом в каталоге /ipfs/ , который я создал, я получаю сообщение об ошибке:

timothy<strong i="39">@yoga</strong> ~/c/ipfs-multiaddr> su Password: root<strong i="40">@yoga</strong>:/home/timothy/current/ipfs-multiaddr# mkdir /ipfs/ root<strong i="41">@yoga</strong>:/home/timothy/current/ipfs-multiaddr# echo "foo">/ipfs/foo root<strong i="42">@yoga</strong>:/home/timothy/current/ipfs-multiaddr# exit exit timothy<strong i="43">@yoga</strong> ~/c/ipfs-multiaddr> ./multiaddr-diff ../subuser/COPYING.LGPL /ipfs/foo Error: selected encoding not supported ....

Я не уверен, как я мог бы отредактировать эту утилиту, чтобы она могла надежно работать как с многоадресными адресами, так и с обычными файлами unix.

С другой стороны, создать оболочку diff, которая поддерживает только синтаксис стиля URL, не сложнее:

````
Тимоти @yoga ~/c/ipfs-multiaddr> cat url-syntax-diff

!/бин/баш

get_multiaddr_or_normal_file_getter(){
если [[ $1 == fs:* ]] ;
тогда
префикс = "фс:"
внутренний_путь=${1#$префикс}
file_getter="ipfs cat $internal_path"
еще
file_getter="кот $1"
фи
эхо $file_getter
}

файл1= get_multiaddr_or_normal_file_getter $1
файл2= get_multiaddr_or_normal_file_getter $2
эхо $file1
эхо $file2
разница <($файл1) <($файл2)
````

Это работает так же хорошо, и 3 дополнительных символа, безусловно, не имеют большого значения, когда хэш уже имеет длину в полтора миллиарда символов.

````
Тимоти @yoga ~/c/ipfs-multiaddr>
./url-syntax-diff ../subuser/COPYING.LGPL fs:/ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
кошка ../подпользователь/COPYING.LGPL
ipfs cat /ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127а128,130

е) Принесите своего первенца в жертву БОГУ Лаурату в первый же день.
полнолуние следующего четного года.

Тимоти @yoga ~/c/ipfs-multiaddr>
````

А в странных пограничных случаях он превосходно работает, как и следовало ожидать от хорошо отполированной утилиты POSIX.

````
Тимоти @yoga ~/c/ipfs-multiaddr> echo "bar" >bar
Тимоти @yoga ~/c/ipfs-multiaddr> ./url-syntax-diff bar /ipfs/foo
кошачий бар
кот /ipfs/foo
1с1

< бар

фу
````

Поскольку дискуссия о fs: и dweb: кажется бесконечной, мне все еще нужен какой-то вклад в этот pr: https://github.com/ipfs/specs/pull/139

Использование ipfs: тем временем решает много проблем, по крайней мере, для меня.

@pawal Вздох, когда я увидел ваш комментарий, мое сердце упало, потому что я с нетерпением ждал ответа на свои опасения.

Пинг @jbenet

Меня также интересуют ответы на ваш предыдущий пост, поскольку он освещает точку зрения на проблему, о которой я раньше не знал.

// редактировать: То есть я все еще слежу за проблемой, и я бы ответил, если бы у меня был удовлетворительный ответ.

+1

Заставьте работать 'ipfs://' - стандартно. Пожалуйста.

(Поэтому все наши приложения могут предполагать, что они работают на всех платформах и везде —
где угодно и на визитках)

Спасибо.

Джулиан Смит
Блокфрахт™

Дискуссии вокруг ipfs: fs: и dweb: ведутся сбивающим с толку еще до того, как я начал участвовать в этом проекте. Наконец-то у меня появилось немного времени, чтобы обдумать это во время IPFS в веб-браузерном спринте . Я пишу объяснение всей картины с изложением различных опций и аргументов, которые я представлю позже сегодня в качестве PR по ipfs/specs. Я буду включать примеры и ссылки на обсуждения, о которых я знаю. Надеюсь, это внесет некоторую ясность и позволит нам двигаться вперед по наиболее прагматичному пути, не совершая ошибок, которые в долгосрочной перспективе могут привести к большим проблемам.

Я предпринял первоначальную попытку предоставить основу для этих обсуждений здесь: https://github.com/ipfs/specs/pull/152 Пожалуйста, обновите PR с информацией, которая является неточной, неполной или вообще нуждается в улучшении.

Извините за мое невежество, но как мне обновить PR?

@timthelion Вы можете сделать это как @jbenet и добавить комментарии здесь, или вы можете клонировать репо, проверить ветку, изменить, зафиксировать, отправить патч и т. д.

@vasa-develop, поскольку ваш комментарий на самом деле не объясняет, как программное обеспечение улучшает ситуацию, я считаю это спамом.

Как насчет DID URI? Например, did:ipfs:QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp

Децентрализованные идентификаторы (DID)

DID — это идентификаторы людей . Однако по своей сути они на самом деле являются URN (я так думаю?), поэтому лучше спросить: «Почему не URN»?

На самом деле ответ заключается в том, что в то время как URL-адреса дают нам совместимость с браузером, пути обеспечивают совместимость с файловой системой (среди прочего), но URN на самом деле не дают нам ничего, кроме некоторой доброй воли с некоторыми органами по стандартизации.

Примечание. Мы фактически отказались от позиции URL, чтобы обеспечить совместимость с браузером. То есть компаньон IPFS (надстройка браузера) поддерживает ipfs://... и ipns://... . Мы хотели использовать dweb://ipfs/... и т. д., но нам также требовалась надлежащая поддержка источника безопасности (что означает, что нам нужен хэш в первом компоненте).

Однако мы считаем, что ipfs://... эквивалентно /ipfs/... и везде используем синтаксис пути.

@Stebalien , откуда вы взяли, что DID предназначены для людей? «люди» не упоминаются там ни разу в спецификации DID. Идентификаторы URI могут идентифицировать любой ресурс по определению.

Неважно, что вы считаете; если вы не придерживаетесь существующих стандартов, вы не можете рассчитывать на совместимость и поддержку существующей инфраструктуры.

откуда вы взяли, что DID для людей? «люди» не упоминаются там ни разу в спецификации DID.

DID предназначены для «цифровой идентификации».

Децентрализованные идентификаторы (DID) — это новый тип идентификатора для проверяемой «самостоятельной» цифровой идентификации.

Так? Все может иметь _идентичность_: люди, животные, здания, организации, вещи, идеи, документы и т. д. В этом прелесть URI.
Вы действительно смотрели в спецификации DID? Повторяю, нет ничего конкретного в лицах.

Децентрализованный идентификатор (DID)

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