No puedo encontrarlo en la documentación ahora, pero recuerdo una explicación en las siguientes líneas:
IPFS es un sistema de archivos y para los sistemas de archivos utiliza rutas en lugar de direcciones URL. Las URL pueden entenderse como una fealdad que representa una falla para unificar el acceso en su máquina local y en máquinas remotas. IPFS está evitando esta fealdad al tratar los archivos locales y remotos de la misma manera y el método para direccionar los archivos es una ruta estándar.

Puede ser útil imaginar montar todo el IPFS en /ipfs y luego acceder a los archivos como si fueran solo eso: archivos en su sistema de archivos.

Material de lectura adicional:

Larga discusión: https://github.com/ipfs/go-ipfs/issues/1678
Breve resumen del consenso actual: https://github.com/ipfs/go-ipfs/issues/1678#issuecomment -157478515

Además, se está trabajando para reconciliar las direcciones IPFS absolutas con la resolución de URL estándar y para abordar la identificación de orígenes con (¿o sin?) fs: paths .

Y https://github.com/ipfs/in-web-browsers/issues/28 con enlace a un borrador de especificación. cc @lgierth

:( Después de leer ipfs/go-ipfs#1678, ni siquiera estoy seguro de estar interesado en IPFS :( . Esa fue una terrible falta de discusión.

Realmente no quiero entrar en el cobertizo de bicicletas, pero esto

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.
no es una idea que me encienda. Me imagino de repente tener una raíz del sistema que se parece a
/btrfs/dev/sda1/.. /fat32/dev/sda2/.. /ext3/dev/sda3/boot/..

Ese no es un concepto que me atraiga. Estoy acostumbrado a organizar mi sistema como me gusta ya montar mis sistemas de archivos como yo elijo. Pero eso no es realmente lo que me está apagando. Eres libre de montar ipfs donde quieras. Me desanima el enfoque megalómano de "reinventemos todo". Vine a IPFS porque quería un CAS distribuido. Eso es todo lo que me interesaba. No me importa fusionar Unix con la web. Pero después de leer esa discusión, IPFS ya no parece un producto que me ayudará a obtener un CAS distribuido, parece un producto que dictará cómo uso y el espacio de nombres del sistema de archivos de mi computadora y una vez que los autores dictan una cosa, tal vez tendrán algunas otras ideas nuevas sobre cómo debe configurarse y organizarse mi computadora. No puedo predecir el futuro, pero no me gusta el enfoque.

Eso es una lástima, porque REALMENTE ME GUSTA la implementación CAS distribuida de IPFS. Llevo mucho tiempo soñando con tener un CAS distribuido :(. Así que tendré que volver al modo de investigación y ver otros CAS distribuidos...

@timthelion Veo que (al igual que yo) realmente se preocupa por CAS e IPFS.
Haré todo lo posible para aliviar sus preocupaciones.

Estoy bastante seguro de que puede usar IPFS como CAS sin montarlo en ningún lugar de su sistema, nunca.
La forma en que pienso sobre las rutas de /ipfs/Qm.. es que son solo un atajo mental que simplifica las conversaciones y los enlaces (al igual que las URL normales).

Personalmente, estoy de acuerdo en que la situación de los "controladores de protocolos" y la "semántica de direcciones canónicas" puede parecer un desastre para un espectador en este momento, pero las buenas personas están trabajando en soluciones pragmáticas que pueden funcionar en este momento (por ejemplo, https://github.com/ ipfs/in-web-browsers/issues/3, https://github.com/ipfs/in-web-browsers/issues/7).

Esta es una conversación continua y estas cosas toman tiempo.

La dirección general del proyecto (mi opinión personal) es _"crear herramientas útiles que reutilicen los estándares de la industria donde sea práctico hacerlo"_ ​​en lugar de _"reinventar todo sin importar nada"_.

No creo que debas preocuparte por el futuro. Las herramientas de IPFS siguen _"la forma de Unix"_, lo que significa que muchas herramientas, bibliotecas y comandos pequeños (similares a los subcomandos git ) que hacen una cosa pueden encadenarse para construir algo más grande.

Eres tú quien decide qué piezas se utilizan. ⚙️ 🔧

Espero que nadie se tome a mal mi último mensaje. No quiero decir "ustedes son todos unos gilipollas, me voy". Presumo que miles de personas han echado un vistazo a IPFS, han decidido que no les gusta algo y se han ido, sin siquiera escribir por qué... A menudo hago eso. Solo miro casualmente una tecnología y elijo una diferente en función de algún pequeño detalle que me molesta. Decidí no hacerlo porque no quería ser un miembro silencioso de una mayoría silenciosa, y también porque no tengo muchas otras opciones :D, pero parece que tendré que esperar ipfs para admitir fs: // o lo que elijan los jefes de proyecto antes de comenzar a usar ipfs en mi proyecto actual y solo podré comenzar a mirar IPFS hasta que existan algunas URL normales reales.

Me desanima el enfoque megalómano de "reinventemos todo".

Te estabas dejando llevar, nada de esto es 'megalomaníaco' o incluso una reinvención. Estamos hablando de rutas de archivo que se utilizan como siempre. El montaje en /ipfs fue solo un ejemplo para ilustrar las cosas, no la idea central.

Estoy acostumbrado a organizar mi sistema como me gusta ya montar mis sistemas de archivos como yo elijo.

Nadie lo obliga a montar IPFS como un sistema de archivos local @timthelion . Esta es una función que puede usar y puede decidir en qué rutas se monta. No me gusta una función deshabilitada de forma predeterminada, me parece una razón débil para descartar IPFS en su totalidad. Pero bueno, espero que cambies de opinión en el futuro y te unas a nosotros nuevamente.

No he visto un solo producto en el que a todos les gusten todas las funciones.

Vale la pena mencionar también que esto en realidad no está reinventando nada. Es "desinventar" algo.

Independientemente de nuestras diferentes opiniones, el controlador fs:// , que le brindará el soporte perfecto que desea, se está implementando en este momento, y ya puede usarlo con extensiones de navegador . También estamos trabajando en implementaciones de PoC para permitir que los navegadores lo usen de forma nativa. También puede implementar soporte para él en aplicaciones envueltas en electrones. Tal vez puedas contribuir a esos esfuerzos para que vayan más rápido.

"Te estabas dejando llevar, nada de esto es 'megalomaníaco' o incluso una reinvención".

Interpreto https://github.com/multiformats/multiaddr como magalomaníaco y reinventado. Es un formato diferente a una URL pero representa los mismos datos. Necesitas una muy buena razón para reinventar un estándar tan importante.

Seré un poco más detallado.

"Estamos hablando de rutas de archivo que se utilizan como siempre".

Creo que entiendo a donde ustedes van con esta idea. ¿El "error" que está tratando de corregir es el hecho de que no puede tratar los recursos web como archivos normales? Así no puedo hacer cat http://google.com/index.html ? Puedo estar de acuerdo contigo en que es triste que sea imposible. Si tuviera que escribir un sistema operativo, haría que la función open fuera capaz de abrir URL en archivos. Quizás tal cambio podría incluso hacerse en Linux. Su enfoque es diferente, está intentando insertar recursos web en la jerarquía de archivos POSIX. Si hay alguna otra razón por la que cree que las URL son un error, infórmeme.

Definitivamente puedo simpatizar con su objetivo de hacer que los recursos web actúen como archivos normales. Su método de corregir "el error", sin embargo, me parece una pendiente bastante resbaladiza. Si SÍ elijo montar los sistemas de archivos ipfs, entonces su punto de montaje es un comportamiento nuevo para mí. No puedo pensar en ningún otro programa de modo de usuario que pueda instalar en mi sistema, lo que crearía varios directorios directamente en mi directorio raíz.

Hoy, cuando hago ls / obtengo:

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

Con las rutas propuestas por multiaddr, en cambio, vería:

$ 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

Y antes de que me acuse de malinterpretar el estándar, le recordaré que lo estoy interpretando exactamente de la manera en que SIEMPRE se han interpretado las rutas de Unix.

Obviamente, no voy a querer ensuciar tanto mi directorio raíz. Por lo tanto, optaré por no montar estos caminos.

En mi caso, esta no es mi elección de todos modos, quiero escribir un software que use IPFS y no es mi decisión si el usuario monta esas rutas o no. Pero todavía quiero que mis usuarios puedan abrir un archivo compartido a través de IPFS tan fácilmente como pueden abrir un archivo en sus máquinas locales. Entonces, ¿cómo escribo ese código? Si ipfs usara direcciones URL estándar, simplemente reenviaría cualquier cosa que comenzara con ipfs:// a ipfs y todo sería simple.

Pero cuando mi programa mira una cadena que comienza con / , la interpreta como una ruta absoluta a un archivo o directorio en la máquina de alguien, generalmente la máquina en la que se ejecuta el código. Si se le indica que visite una ruta que comienza con / , DEFINITIVAMENTE la interpretará como una ruta absoluta a un archivo o directorio en la máquina local. Si /ipfs no existe en mi máquina, entonces el programa debería devolver un error de archivo no encontrado. No puedo pensar en otro ejemplo en el que una ruta absoluta que se le dice al programa que visite lleve a otro lugar que no sea un archivo o directorio en la máquina local. Entonces, para mí, como usuario/desarrollador de Linux desde hace mucho tiempo, este es un comportamiento nuevo.

Si mi aplicación intentara agregar soporte para multiaddr, entonces las cosas se pondrían difíciles bastante rápido. ¿Qué pasa si el usuario ejecuta:

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

y el usuario tiene un servidor web que almacena sus archivos html en /http . No del todo inaudito. ¿Debería mi programa resolver esto en una dirección multidirección o en el archivo local?

Ya escribí un código con soporte primitivo para abrir URL en python. Hacerlo fue bastante fácil. Pero, ¿cómo cambiaría mi código para que resuelva sin ambigüedades tanto las rutas multidirección como las rutas de archivos locales?

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

Realmente no creo que eso sea posible. Por lo tanto, me quedo sin implementar el soporte multidirección y solo admitiendo URL normales. Eso parece estar bien al principio, pero los usuarios de ipfs van a estar constantemente expuestos a direcciones multidireccionales para objetos ipfs, y mi programa, que anuncia la compatibilidad con IPFS, afirmará que esas rutas no existen. Así que no importa cómo implemente el soporte, mi programa se romperá. O se interrumpirá su compatibilidad con ipfs o se interrumpirá su compatibilidad con el sistema de archivos POSIX estándar.

Hay formas en que esto podría solucionarse, potencialmente. Una sería renunciar por completo a multiaddr. Otra sería cambiar multiaddr para que al menos limitara esas rutas a un solo subdirectorio. Entonces, en lugar de escribir /ipfs/hash/blah uno escribiría /webfs/ipfs/hash/blah . Y ls / devolvería:

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

Eso sería algo con lo que podría vivir, y tal vez incluso quedarme atrás. Pero la situación actual es que no conozco ninguna forma satisfactoria de implementar el soporte de ipfs.

Permítanme llegar a un ejemplo aún más CONCRETO. Imagina que estoy escribiendo un programa que convierte Markdown a PDF. Y quiero poder admitir la inclusión de imágenes de IPFS. Entonces el usuario escribe:

ático.md
````

Cosas que encontré en mi ático

Una vieja caja de rocas.

````

y corre

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

¿Cómo se supone que mi programa debe resolver esas rutas de imagen? ¿Se supone que debe asumir que el sistema /ipfs archivos /ipfs . ¿Debe el programa tratar /ipfs/ como un prefijo especial? Eso parece raro y roto. ¿Debería el programa admitir solo fs:// y devolver un error, no se encontró el archivo dadas esas rutas? eso parece razonable, pero confundirá a los usuarios que están acostumbrados al estándar multiaddr. ¡Simplemente no hay una forma correcta de salir de la bolsa! :/ :(

editado para aclarar

Gracias por proporcionar algunos casos de uso @timthelion. Es genial que la gente ofrezca ejemplos del mundo real para que podamos asegurarnos de que los protocolos funcionen para personas reales.

Aclarando el ejemplo de "montar todo en /"

Como señaló @lidel , la gente está trabajando actualmente en el diseño del esquema de direcciones, por lo que aún no hay documentación. Parece que el ejemplo de @jbenet de los montajes del sistema de archivos ha creado confusión. Es solo un ejemplo que pretende ayudar a las personas a pensar en el modelo conceptual detrás del esquema de dirección fs: o dweb: . No está proponiendo que obliguemos a todos a montar todos esos directorios en sus sistemas de archivos. Más bien, propone que deberíamos ser capaces de _identificar_ contenido con direcciones que se comporten como si el contenido estuviera montado en su sistema de archivos local, porque eso nos permitirá interactuar con contenido web/dweb usando herramientas unix/posix.

Cuando escribamos los documentos, tendremos que tener cuidado de dejar esto claro. Gracias por marcarlo.

En respuesta a tu ejemplo de 'cosas en el ático', creo que la idea es que usarías fs:/ en tus enlaces, así:

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)

Tener direcciones simples Y unificar los esquemas

Nota al margen: también está el problema de mantener las direcciones simples. En este comentario , @nicola propuso una forma inteligente de admitir direcciones ipfs:/ y ipns:/ sin romper el esquema de direcciones fs: / dweb: . La gimnasia de diseño de protocolo involucrada es (en mi humilde opinión) extrañamente confusa, pero al final le permitiría tener enlaces en su descuento como ipfs:/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV mientras que también permitiría a las personas abordar el mismo contenido como fs:/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV o solo /ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV en un contexto unix/posix.

Las rutas absolutas dependen del contexto

Con respecto a las rutas absolutas, dijiste:

Si se le indica que visite una ruta que comienza con /, DEFINITIVAMENTE la interpretará como una ruta absoluta a un archivo o directorio en la máquina local.

Tenga en cuenta que existe un amplio precedente de que las rutas absolutas son relativas a _context_ en lugar de relativas a la raíz del sistema de archivos. El ejemplo más común de esto son las rutas absolutas en HTML, que son relativas a la raíz del origin actual, no relativas a la raíz del sistema de archivos del servidor. Si tengo código que opera dentro de un contexto que asume que todas las rutas son fs: o dweb: , es completamente válido que ese código use direcciones que comienzan con /ipfs/ y hay muchas maneras para que ese código resuelva las rutas sin montar literalmente ipfs en /ipfs en su sistema de archivos.

Estos son mis 2 centavos:

• Cada archivo está bajo fs:/ , de la misma manera cada dominio está bajo http:/ .
• No / el sistema de nombres de dominio en / . En ambos sistemas el punto de referencia es / relativo al esquema ( http:/ , fs:/ ).

Creo que en la mayoría de sus ejemplos existe la noción de que cada sistema de archivos ha montado ipfs en / . Entonces, tener fs:/ no rompe el formato URI.

Más bien, propone que deberíamos ser capaces de identificar contenido con direcciones que se comporten como si el contenido estuviera montado en su sistema de archivos local, porque eso nos permitirá interactuar con contenido web/dweb usando herramientas unix/posix.

"Eso nos permitirá interactuar con contenido web/dweb usando herramientas unix/posix". ¿Puede darme un ejemplo concreto de un caso en el que la sintaxis prefijada no fs: se usaría con una herramienta de Unix? De alguna manera, todavía no lo estoy entendiendo.

He intentado encontrar un ejemplo yo mismo, pero no puedo pensar en ningún ejemplo en el que la sintaxis prefijada compatible con multidirección /ipfs tenga sentido.

Traté de hacer un scirpt de contenedor para la utilidad diff en bash que admitía ipfs usando el esquema multiaddr:

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

!/bin/bash

get_multiaddr_or_normal_file_getter(){
si [[ $1 == /ipfs/* ]] ;
entonces
file_getter="ipfs gato $1"
demás
file_getter="gato $1"
fi
echo $file_getter
}

archivo1= get_multiaddr_or_normal_file_getter $1
archivo2= get_multiaddr_or_normal_file_getter $2

diferencia <($archivo1) <($archivo2)
````

Funciona en el caso ingenuo tanto en archivos normales como en archivos ipfs:

````
timothy @yoga ~/c/ipfs-multiaddr>
./multiaddr-diff ../subuser/COPYING.LGPL /ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127a128,130

f) Sacrificar a su hijo primogénito al DIOS Laurath en el primer
luna llena del siguiente año par.

````

Pero cuando trato de usarlo para operar en un archivo real existente en un directorio /ipfs/ que he creado, aparece un error:

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 ....

No estoy seguro de cómo podría editar esa utilidad, de modo que pueda funcionar de manera confiable tanto con direcciones multidirección como con archivos Unix normales.

Por otro lado, no es más difícil crear un envoltorio de diferencias que admita solo la sintaxis de estilo de URL:

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

!/bin/bash

get_multiaddr_or_normal_file_getter(){
si [[ $1 == fs:* ]] ;
entonces
prefijo="fs:"
ruta_interna=${1#$prefijo}
file_getter="ipfs cat $ruta_interna"
demás
file_getter="gato $1"
fi
echo $file_getter
}

archivo1= get_multiaddr_or_normal_file_getter $1
archivo2= get_multiaddr_or_normal_file_getter $2
echo $archivo1
echo $archivo2
diferencia <($archivo1) <($archivo2)
````

Funciona igual de bien, y los 3 caracteres adicionales seguramente no hacen mucha diferencia cuando el hash ya tiene un billón y medio de caracteres.

````
timothy @yoga ~/c/ipfs-multiaddr>
./url-syntax-diff ../subuser/COPYING.LGPL fs:/ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
cat ../subusuario/COPIA.LGPL
gato de ipfs /ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127a128,130

f) Sacrificar a su hijo primogénito al DIOS Laurath en el primer
luna llena del siguiente año par.

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

Y en los casos extremos extraños, funciona admirablemente como cabría esperar de una utilidad POSIX bien pulida.

````
timothy @yoga ~/c/ipfs-multiaddr> echo "barra" >barra
timothy @yoga ~/c/ipfs-multiaddr> ./url-syntax-diff bar /ipfs/foo
barra de gato
gato /ipfs/foo
1c1

< barra

Foo
````

Dado que la discusión sobre fs: y dweb: parece no tener fin, todavía necesito alguna información sobre este pr: https://github.com/ipfs/specs/pull/139

Usando ipfs: mientras tanto resuelve muchos problemas, al menos para mí.

@pawal Suspiro, cuando vi tu comentario mi corazón se hundió, porque he estado esperando una respuesta a mis preocupaciones con bastante impaciencia.

Ping @jbenet

También estoy interesado en las respuestas a su publicación anterior, ya que destacó una perspectiva sobre el problema del que no estaba al tanto.

//editar: Es decir, todavía estoy siguiendo el problema y habría respondido si tuviera una respuesta satisfactoria para dar.

+1

Haga que 'ipfs://' funcione como estándar. Por favor.

(Para que todas nuestras aplicaciones puedan asumir que funciona en todas las plataformas, en todas partes -
en cualquier lugar y en tarjetas de visita)

Gracias.

Julián Smith
Blockfreight™

Las discusiones sobre ipfs: frente a fs: frente a dweb: son confusas y han estado ocurriendo desde antes de que me involucrara en este proyecto. Finalmente tuve un poco de tiempo para entenderlo durante el IPFS en navegadores web Sprint . Estoy escribiendo una explicación de la imagen completa, con un resumen de las diferentes opciones y argumentos, que enviaré como PR en ipfs/specs más tarde hoy. Incluiré ejemplos y referencias a las discusiones que conozco. Con suerte, eso brindará algo de claridad y nos permitirá avanzar por el camino más pragmático sin cometer errores que causen grandes problemas a largo plazo.

Hice un intento inicial para proporcionar antecedentes para estas discusiones aquí: https://github.com/ipfs/specs/pull/152 Actualice el PR con información inexacta, incompleta o que, en general, necesita mejoras.

Perdón por mi ignorancia, pero ¿cómo actualizo un PR?

@timthelion Puede hacerlo como @jbenet y agregar comentarios aquí o puede clonar el repositorio, verificar la rama, modificar, confirmar, enviar parche, etc.

@vasa-develop como su comentario en realidad no explica cómo el software mejora la situación, lo considero spam.

¿Qué hay de los URI DID? Como did:ipfs:QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp

Identificadores descentralizados (DID)

Los DID son identificadores de personas . Sin embargo, en el fondo, en realidad son URN (¿creo?), por lo que una mejor pregunta es: "¿por qué no URN?"

Realmente, la respuesta es que mientras que las URL nos brindan compatibilidad con el navegador, las rutas nos brindan compatibilidad con el sistema de archivos (entre otras cosas), pero las URN realmente no nos brindan mucho más que buena voluntad con algunos organismos de estándares.

Nota: De hecho, hemos cedido en la posición de la URL para obtener compatibilidad con el navegador. Es decir, el compañero de IPFS (complemento del navegador) admite ipfs://... y ipns://... . Queríamos usar dweb://ipfs/... etc., pero también necesitábamos soporte de origen de seguridad adecuado (lo que significa que necesitamos el hash en el primer componente).

Sin embargo, consideramos que ipfs://... es equivalente a /ipfs/... y usamos la sintaxis de ruta en cualquier otro lugar.

@Stebalien, ¿de dónde

No importa lo que consideres; si no se adhiere a los estándares existentes, no puede esperar la interoperabilidad y el soporte de la infraestructura existente.

¿De dónde sacas la idea de que los DID son para personas? "personas" no se menciona allí ni una sola vez en la especificación DID.

Los DID son para "identidad digital".

Los identificadores descentralizados (DID, por sus siglas en inglés) son un nuevo tipo de identificador para la identidad digital "auto-soberana" verificable.

¿Entonces? Todo puede tener _identidad_: personas, animales, edificios, organizaciones, cosas, ideas, documentos, etc. Esa es la belleza de las URI.
¿Has mirado realmente en la especificación DID? Repito, no hay nada específico a las personas.

Identificador descentralizado (DID)

Un identificador global único que no requiere una autoridad de registro centralizada porque está registrado con tecnología de contabilidad distribuida u otra forma de red descentralizada. El formato genérico de un DID se define en esta especificación. Un esquema DID específico se define en una especificación de método DID.