Não consigo encontrá-lo na documentação agora, mas lembro de uma explicação nas seguintes linhas:
O IPFS é um sistema de arquivos e, para sistemas de arquivos, você usa caminhos em vez de URLs. As URLs podem ser entendidas como uma feiúra que representa uma falha na unificação de acesso em sua máquina local e em máquinas remotas. O IPFS está evitando essa feiúra tratando os arquivos locais e remotos da mesma forma e o método para endereçar os arquivos é um caminho padrão.

Pode ajudar imaginar a montagem de todo o IPFS em /ipfs e, em seguida, acessar os arquivos como se fossem apenas isso: Arquivos em seu sistema de arquivos.

Material de leitura adicional:

Longa discussão: https://github.com/ipfs/go-ipfs/issues/1678
Breve resumo do consenso atual: https://github.com/ipfs/go-ipfs/issues/1678#issuecomment -157478515

Além disso, há um trabalho em andamento para reconciliar endereços absolutos IPFS com resolução de URL padrão e para lidar com a identificação de origens com (ou sem?) fs: caminhos .

E https://github.com/ipfs/in-web-browsers/issues/28 com link para uma especificação de rascunho. cc @lgierth

:( Depois de ler ipfs/go-ipfs#1678 eu nem tenho certeza se estou mais interessado em IPFS :( . Essa foi uma terrível não-discussão.

Eu realmente não quero entrar no galpão de bicicletas, mas isso

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.
não é uma ideia que me excita. Imagino de repente ter uma raiz do sistema que se parece com
/btrfs/dev/sda1/.. /fat32/dev/sda2/.. /ext3/dev/sda3/boot/..

Esse não é um conceito que me atrai. Estou acostumado a organizar meu sistema como eu gosto e montar meus sistemas de arquivos como eu escolho. Mas isso não é realmente o que está me desanimando. Você é livre para montar ipfs onde quiser. Estou desanimado com a abordagem megalomaníaca "vamos reinventar tudo". Eu vim para o IPFS porque queria um CAS distribuído. Isso é tudo que eu estava interessado. Eu não me importo em fundir unix com a web. Mas depois de ler essa discussão, o IPFS não parece mais um produto que me ajudará a obter um CAS distribuído, parece um produto que ditará como eu uso e espaço para nome o sistema de arquivos do meu computador e, uma vez que os autores estejam ditando uma coisa, talvez eles tenham algumas outras idéias novas sobre como meu computador deve ser configurado e organizado. Não posso prever o futuro, mas não gosto da abordagem.

Isso é muito ruim, porque EU GOSTO MUITO da implementação de CAS distribuído do IPFS. Há muito tempo que sonho em ter um CAS distribuído :(. Então vou ter que voltar ao modo de pesquisa e ver alguns outros CAS distribuídos...

@timthelion , vejo que você (assim como eu) realmente se importa com CAS e IPFS.
Farei o possível para aliviar suas preocupações.

Tenho certeza de que você pode usar o IPFS como um CAS sem montá-lo em qualquer lugar do seu sistema.
A maneira como eu penso sobre caminhos /ipfs/Qm.. é que eles são apenas um atalho mental que simplifica conversas e links (assim como URLs comuns).

Pessoalmente, concordo que a situação de "manipuladores de protocolo" e "semântica de endereço canônico" pode parecer uma bagunça para um espectador agora, mas boas pessoas estão trabalhando em soluções pragmáticas podem funcionar agora (por exemplo, https://github.com/ ipfs/in-web-browsers/issues/3, https://github.com/ipfs/in-web-browsers/issues/7).

Esta é uma conversa contínua e essas coisas levam tempo.

A direção geral do projeto (minha opinião pessoal) é _"criar ferramentas úteis que reutilizem os padrões da indústria onde for prático fazê-lo"_ em vez de _"reinventar tudo, não importa o quê"_.

Acho que você não deveria se preocupar com o futuro. As ferramentas IPFS seguem _"the unix way"_, significando que muitas pequenas ferramentas, bibliotecas e comandos (semelhantes aos subcomandos git ) que fazem uma coisa podem ser encadeados para construir algo maior.

Você é quem decide quais peças são usadas. ⚙️ 🔧

Espero que ninguém leve a mal meu último post. Eu não quero dizer "vocês todos são idiotas que eu estou deixando". Presumo que milhares de pessoas deram uma olhada no IPFS, decidiram que não gostam de algo e saíram, sem nunca escrever o porquê... Costumo fazer isso. Eu apenas olho casualmente para uma tecnologia e escolho uma diferente com base em algum pequeno detalhe que me incomoda. Decidi não fazer isso porque queria não ser um membro silencioso de uma maioria silenciosa, e também porque não tenho muitas outras opções :D, mas parece que vou ter que esperar ipfs para suportar fs:// ou o que os chefes do projeto escolherem antes de começar a usar o ipfs no meu projeto atual e só poderei começar a olhar para o IPFS até que existam algumas URLs normais reais.

estou desanimado com a abordagem megalomaníaca "vamos reinventar tudo".

Você estava se deixando levar, nada disso é 'megalomaníaco' ou mesmo uma reinvenção. Estamos falando sobre caminhos de arquivo sendo usados ​​como sempre são. A montagem em /ipfs foi apenas um exemplo para ilustrar as coisas, não a ideia central.

Estou acostumado a organizar meu sistema como eu gosto e montar meus sistemas de arquivos como eu escolho.

Ninguém está forçando você a montar o IPFS como um sistema de arquivos local @timthelion . Este é um recurso que você pode usar e pode decidir em quais caminhos ele monta. Não gostar de um recurso desabilitado por padrão me parece um motivo fraco para descartar o IPFS como um todo. Mas bem, eu espero que você mude de ideia no futuro e se junte a nós novamente.

Eu não vi um único produto onde todo mundo gosta de todos os recursos.

Vale a pena mencionar também que isso não está realmente reinventando nada. É "desinventar" algo.

Independentemente de nossas opiniões divergentes, o manipulador fs:// - que lhe dará o suporte perfeito que você deseja - está sendo implementado enquanto falamos, e você já pode usá-lo com extensões de navegador . Também estamos trabalhando em implementações de PoC para permitir que os navegadores o usem nativamente. Você também pode implementar suporte para ele em aplicativos encapsulados em elétrons. Talvez você possa contribuir com esses esforços para torná-los mais rápidos.

"Você estava se deixando levar, nada sobre isso é 'megalomaníaco' ou mesmo uma reinvenção."

Eu interpreto https://github.com/multiformats/multiaddr como sendo magalomaníaco e reinventando. É um formato diferente de um URL, mas representa os mesmos dados. Você precisa de uma boa razão para reinventar um padrão tão importante.

Vou ser um pouco mais detalhado.

"Estamos falando sobre caminhos de arquivo sendo usados ​​como sempre."

Acho que cheguei aonde vocês estão indo com essa ideia. O "erro" que você está tentando corrigir é o fato de não poder tratar os recursos da web como arquivos normais? Assim não posso fazer cat http://google.com/index.html ? Posso concordar com você que é triste que seja impossível. Se eu fosse escrever um sistema operacional, tornaria a função open capaz de abrir URLs para arquivos. Talvez essa mudança possa até ser feita no linux. Sua abordagem é diferente, você está tentando inserir recursos da Web na hierarquia de arquivos POSIX. Se houver algum outro motivo para você achar que os URLs são um erro, informe-me.

Definitivamente, posso simpatizar com seu objetivo de fazer com que os recursos da Web funcionem como arquivos normais. Seu método de corrigir "o erro", no entanto, parece-me ser uma ladeira escorregadia. Se eu optar por montar os sistemas de arquivos ipfs, seu ponto de montagem será um novo comportamento para mim. Não consigo pensar em nenhum outro programa de modo de usuário que eu possa instalar no meu sistema, o que criaria vários diretórios diretamente no meu diretório raiz.

Hoje, quando eu faço ls / eu recebo:

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

Com os caminhos propostos pelo multiaddr, eu veria:

$ 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

E antes que você me acuse de interpretar mal o padrão, vou lembrá-lo que estou interpretando da mesma maneira que os caminhos do unix SEMPRE foram interpretados.

Obviamente, não vou querer bagunçar tanto meu diretório raiz. Portanto, optarei por não montar esses caminhos.

No meu caso, essa não é minha escolha de qualquer maneira, eu quero escrever um software que use IPFS e não é minha decisão se o usuário monta esses caminhos ou não. Mas ainda quero que meus usuários possam abrir um arquivo compartilhado por IPFS com a mesma facilidade com que abrem um arquivo em suas máquinas locais. Então, como eu escrevo esse código? Se o ipfs usasse urls padrão, eu simplesmente encaminharia qualquer coisa que começasse com ipfs:// para ipfs e tudo seria simples.

Mas quando meu programa olha para uma string que começa com / , ele interpreta isso como um caminho absoluto para um arquivo ou diretório na máquina de alguém, normalmente a máquina em que o código está sendo executado. Se for solicitado a visitar um caminho começando com / , ele DEFINITIVAMENTE o interpretará como um caminho absoluto para um arquivo ou diretório na máquina local. Se /ipfs não existir na minha máquina, o programa deverá retornar um erro de arquivo não encontrado. Não consigo pensar em outro exemplo em que um caminho absoluto que o programa é instruído a visitar leva a outro lugar que não seja um arquivo ou diretório na máquina local. Então, para mim, como um usuário/desenvolvedor linux de longa data, esse é um novo comportamento.

Se meu aplicativo tentasse adicionar suporte para multiaddr, as coisas ficariam complicadas rapidamente. E se o usuário executar:

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

e o usuário tem um servidor web que armazena seus arquivos html em /http . Nada inédito. Meu programa deve resolver isso para um endereço multiaddr ou para o arquivo local?

Eu já escrevi algum código com suporte primitivo para abrir URLs em python. Fazer isso foi bem fácil. Mas como eu mudaria meu código para que ele resolva inequivocamente os caminhos multiaddr e os caminhos de arquivos locais?

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

Eu realmente não acho que isso seja possível. Portanto, não estou implementando o suporte multiaddr e apenas suportando URLs normais. Isso parece bom no começo, mas os usuários de ipfs serão constantemente expostos a endereços multiaddr para objetos ipfs, e meu programa, que anuncia suporte a IPFS, estará alegando que esses caminhos não existem. Portanto, não importa como eu implemente o suporte, meu programa será quebrado. Ou seu suporte para ipfs será quebrado, ou seu suporte para o sistema de arquivos POSIX padrão será quebrado.

Existem maneiras de corrigir isso, potencialmente. Uma seria desistir completamente do multiaddr. Outra seria alterar o multiaddr para que ele pelo menos limitasse esses caminhos a um único subdiretório. Então, ao invés de escrever /ipfs/hash/blah alguém escreveria /webfs/ipfs/hash/blah . E ls / retornaria:

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

Isso seria algo com o qual eu poderia viver, e talvez até ficar para trás. Mas a situação atual é que não conheço nenhuma maneira satisfatória de implementar o suporte ao ipfs.

Deixe-me chegar a um exemplo ainda mais CONCRETO. Imagine que estou escrevendo um programa que converte markdown em PDF. E quero ser capaz de suportar a inclusão de imagens do IPFS. Então o usuário escreve:

sótão.md
````

Coisas que encontrei no meu sótão

Uma velha caixa de pedras.

````

E corre

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

Como meu programa deve resolver esses caminhos de imagem? É suposto assumir que o sistema de arquivos /ipfs está montado? Já concordamos que os usuários não são forçados a montar /ipfs . O programa deve tratar /ipfs/ como um prefixo especial? Isso parece estranho e quebrado. O programa deve suportar apenas fs:// e retornar um erro, arquivo não encontrado com esses caminhos? isso parece razoável, mas vai confundir os usuários que estão acostumados com o padrão multiaddr. Simplesmente não há maneira certa de sair do saco! :/ :(

editado para esclarecimento

Obrigado por fornecer alguns casos de uso @timthelion. É ótimo ter pessoas oferecendo exemplos do mundo real para que possamos garantir que os protocolos funcionem para pessoas reais.

Esclarecendo o exemplo "montando tudo em /"

Como o @lidel apontou, as pessoas estão trabalhando no design do esquema de endereços, então ainda não há documentação. Parece que o exemplo de montagens do sistema de arquivos do @jbenet criou confusão. É apenas um exemplo destinado a ajudar as pessoas a pensar no modelo conceitual por trás do esquema de endereços fs: ou dweb: . Ele não está propondo que forcemos todos a montar todos esses diretórios em seus sistemas de arquivos. Em vez disso, ele está propondo que devemos ser capazes de _identificar_ conteúdo com endereços que se comportam como se o conteúdo estivesse montado em seu sistema de arquivos local, porque isso nos permitirá interagir com conteúdo web/dweb usando ferramentas unix/posix.

Quando escrevermos os documentos, teremos que ter o cuidado de deixar isso claro. Obrigado por sinalizar.

Em resposta ao seu exemplo de 'coisas no sótão', acho que a ideia é que você use fs:/ em seus links, assim:

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)

Ter endereços simples e unificar os esquemas

Nota lateral: Há também a questão de manter os endereços simples. Neste comentário @nicola propôs uma maneira inteligente de suportar endereços ipfs:/ e ipns:/ sem quebrar o esquema de endereços fs: / dweb: . A ginástica de design de protocolo envolvida é (IMHO) estranhamente confusa, mas no final permitiria que você tivesse links em sua marcação como ipfs:/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV , além de permitir que as pessoas abordassem o mesmo conteúdo como fs:/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV ou apenas /ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV em um contexto unix/posix.

Caminhos absolutos dependem do contexto

Em relação aos caminhos absolutos, você disse:

Se for solicitado a visitar um caminho começando com /, ele DEFINITIVAMENTE o interpretará como um caminho absoluto para um arquivo ou diretório na máquina local.

Tenha em mente que há amplo precedente para caminhos absolutos sendo relativos a _context_ em vez de relativos à raiz do sistema de arquivos. O exemplo mais comum disso são os caminhos absolutos em HTML, que são relativos à raiz do origin atual, não relativos à raiz do sistema de arquivos do servidor. Se eu tiver um código que está operando dentro de um contexto que assume que todos os caminhos são fs: ou dweb: , é completamente válido para esse código usar endereços que começam com /ipfs/ e existem muitas maneiras para esse código resolver os caminhos sem literalmente montar ipfs em /ipfs em seu sistema de arquivos.

Estes são meus 2 centavos:

• Cada arquivo está abaixo de fs:/ , da mesma forma que todo domínio está abaixo de http:/ .
• Eu não monto o sistema de nomes de domínio em / no meu sistema de arquivos, da mesma forma que não monto a totalidade do IPFS no meu / . Em ambos os sistemas o ponto de referência é / relativo ao esquema ( http:/ , fs:/ ).

Acho que na maioria dos seus exemplos existe essa noção de que todo sistema de arquivos montou ipfs em / . Portanto, ter fs:/ não quebra o formato URI.

Em vez disso, ele está propondo que devemos ser capazes de identificar conteúdo com endereços que se comportam como se o conteúdo estivesse montado em seu sistema de arquivos local, porque isso nos permitirá interagir com conteúdo web/dweb usando ferramentas unix/posix.

"Isso nos permitirá interagir com conteúdo web/dweb usando ferramentas unix/posix." Você pode me dar um exemplo concreto de um caso em que a sintaxe não prefixada fs: seria usada com uma ferramenta unix? De alguma forma, ainda não estou entendendo.

Eu mesmo tentei criar um exemplo, mas não consigo pensar em nenhum exemplo em que a sintaxe prefixada /ipfs compatível com multiaddr faça sentido.

Eu tentei fazer um wrapper scirpt para o utilitário diff no bash que suportava ipfs usando o esquema multiaddr:

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

!/bin/bash

get_multiaddr_or_normal_file_getter(){
if [[ $1 == /ipfs/* ]] ;
então
file_getter="ipfs cat $1"
senão
file_getter="cat $1"
fi
echo $file_getter
}

arquivo1= get_multiaddr_or_normal_file_getter $1
arquivo2= get_multiaddr_or_normal_file_getter $2

diff <($arquivo1) <($arquivo2)
````

Funciona no caso ingênuo em arquivos normais e arquivos ipfs:

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

f) Sacrifique seu filho primogênito ao DEUS Laurath no primeiro
lua cheia do ano par seguinte.

````

Mas quando tento usá-lo para operar em um arquivo real existente em um diretório /ipfs/ que criei, recebo um erro:

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

Não tenho certeza de como eu poderia editar esse utilitário, para que ele pudesse trabalhar de maneira confiável com endereços multiaddr e arquivos unix normais.

Por outro lado, criar um wrapper diff que suporte apenas o sytax estilo url não é mais difícil:

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

!/bin/bash

get_multiaddr_or_normal_file_getter(){
if [[ $1 == fs:* ]] ;
então
prefix="fs:"
internal_path=${1#$prefix}
file_getter="ipfs cat $internal_path"
senão
file_getter="cat $1"
fi
echo $file_getter
}

arquivo1= get_multiaddr_or_normal_file_getter $1
arquivo2= get_multiaddr_or_normal_file_getter $2
echo $arquivo1
echo $ arquivo2
diff <($arquivo1) <($arquivo2)
````

Funciona da mesma forma, e os 3 caracteres extras certamente não fazem muita diferença quando o hash já tem um zilhão e meio de caracteres.

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

f) Sacrifique seu filho primogênito ao DEUS Laurath no primeiro
lua cheia do ano par seguinte.

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

E nos casos de borda estranhos, ele se comporta admiravelmente como seria de esperar de um utilitário POSIX bem polido.

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

<barra

foo
````

Como a discussão sobre fs: e dweb: parece interminável, ainda preciso de algumas informações sobre este pr: https://github.com/ipfs/specs/pull/139

Usando ipfs: entretanto resolve muitos problemas, pelo menos para mim.

@pawal Suspiro, quando vi seu comentário meu coração afundou, porque eu estava esperando uma resposta às minhas preocupações com bastante impaciência.

Ping @jbenet

Também estou interessado em respostas ao seu post anterior, pois destacou uma perspectiva sobre o problema que eu não conhecia anteriormente.

//edit: Isso quer dizer que ainda estou acompanhando o problema e teria respondido se tivesse uma resposta satisfatória para dar.

+1

Faça 'ipfs://' funcionar - como padrão. Por favor.

(Assim, todos os nossos aplicativos podem assumir que funciona em todas as plataformas, em todos os lugares -
em qualquer lugar e em cartões de visita)

THX.

Julian Smith
Blockfreight™

As discussões em torno de ipfs: vs. fs: vs. dweb: são confusas e acontecem desde antes de eu me envolver neste projeto. Eu finalmente consegui um pouco de tempo para pensar nisso durante o

Fiz uma tentativa inicial de fornecer uma base para essas discussões aqui: https://github.com/ipfs/specs/pull/152 Atualize o PR com informações imprecisas, incompletas ou que geralmente precisam de melhorias.

Desculpe minha ignorância, mas como faço para atualizar um PR?

@timthelion Você pode fazer isso como @jbenet e adicionar comentários aqui ou você pode clonar o repositório, fazer check-out do branch, modificar, confirmar, enviar patch etc

@vasa-develop como seu comentário não explica realmente como o software melhora a situação, considero que é spam.

E quanto aos URIs DID? Como did:ipfs:QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp

Identificadores Descentralizados (DIDs)

DIDs são identificadores de pessoas . No entanto, em sua essência, eles são realmente URNs (eu acho?) então uma pergunta melhor é: "por que não URNs"?

Realmente, a resposta é que enquanto URLs nos dão compatibilidade com navegadores, caminhos nos dão compatibilidade com sistemas de arquivos (entre outras coisas), mas URNs realmente não nos dão muito além de alguma boa vontade com alguns órgãos de padrões.

Nota: Na verdade, cedemos na posição do URL para obter compatibilidade com o navegador. Ou seja, o complementar IPFS (complemento do navegador) suporta ipfs://... e ipns://... . Queríamos usar dweb://ipfs/... etc., mas também precisávamos de suporte de origem de segurança adequado (o que significa que precisamos do hash no primeiro componente).

No entanto, consideramos ipfs://... equivalente a /ipfs/... e usamos a sintaxe de caminho em todos os outros lugares.

@Stebalien de onde você tirou a ideia de que DIDs são para pessoas? "pessoas" não é mencionado uma única vez na especificação DID. Os identificadores de URI podem identificar qualquer recurso por definição.

Não importa o que você considere; se você não estiver aderindo aos padrões existentes, não poderá esperar interoperabilidade e suporte pela infraestrutura existente.

de onde você tirou a ideia de que DIDs são para pessoas? "pessoas" não é mencionado uma única vez na especificação DID.

DIDs são para "identidade digital".

Os Identificadores Descentralizados (DIDs) são um novo tipo de identificador para identidade digital verificável e "autossoberana".

Assim? Tudo pode ter _identidade_: pessoas, animais, prédios, organizações, coisas, ideias, documentos etc. Essa é a beleza dos URIs.
Você realmente olhou na especificação DID? Repito, não há nada específico para pessoas.

Identificador Descentralizado (DID)

Um identificador globalmente exclusivo que não requer uma autoridade de registro centralizado porque é registrado com tecnologia de contabilidade distribuída ou outra forma de rede descentralizada. O formato genérico de um DID é definido nesta especificação. Um esquema DID específico é definido em uma especificação de método DID.