現在、ドキュメントで見つけることができませんが、次の行に沿った説明を覚えています。
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：パスを使用して（または使用せずに）発信元を特定するための作業が進行中です。

また、 https：//github.com/ipfs/in-web-browsers/issues/28とドラフト仕様へのリンクがあります。 cc @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はどこにでも自由にマウントできます。 私は、巨大な「すべてを再発明しよう」というアプローチに気を失っています。 分散CASが欲しかったのでIPFSに来ました。 私が興味を持ったのはそれだけです。UNIXをWebにマージすることは気にしません。 しかし、その議論を読んだ後、IPFSは分散CASを取得するのに役立つ製品のようには見えなくなり、コンピューターのファイルシステムの使用方法と名前空間を決定する製品のように見えます。私のコンピュータをどのように構成し、整理するかについての他のいくつかの新しいアイデア。 将来を予測することはできませんが、そのアプローチは好きではありません。

私はIPFSの分散CAS実装が本当に好きなので、それは残念です。 私は長い間分散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方法" _に従います。つまり、1つのことを実行する多くの小さなツール、ライブラリ、およびコマンド（ gitサブコマンドに類似）をチェーン化して、より大きなものを構築できます。

どのピースを使用するかを決めるのはあなたです。 ⚙️🔧

誰も私の最後の投稿を間違った方法で受け取らないことを願っています。 「あなたはみんな私が残しているお尻の穴だ」と言うつもりはありません。 何千人もの人々がIPFSを見て、何かが好きではないと判断し、理由を書かずに去ったと思います...私はよくそうします。 私はただ何気なくテクノロジーを見て、間違った方法で私をこすりつけるいくつかの小さな詳細に基づいて別のテクノロジーを選択します。 サイレントマジョリティのサイレントメンバーになりたくなかったので、また、他に選択肢があまりないので、そうしないことにしました：D、しかし、私は待たなければならないようです現在のプロジェクトでipfsを使い始める前に、fs：//またはプロジェクトヘッドが選択するものをサポートするipfsを使用すると、実際の通常のURLがいくつか存在するまで、IPFSを真剣に検討し始めることができます。

メガロマニア的な「すべてを再発明しよう」というアプローチによってオフになっています。

あなたは夢中になっていた、これについては何も「メガロマニア」または再発明でさえありません。 いつものように使用されているファイルパスについて話しています。 / ipfsへのマウントは、物事を説明するための単なる例であり、コアアイデアではありません。

私は自分のシステムを好きなように整理し、選択したとおりにファイルシステムをマウントすることに慣れています。

IPFSをローカルファイルシステム@timthelionとしてマウントするように強制する人は誰もいません。 これは使用できる機能であり、マウントするパスを決定できます。 デフォルトで無効になっている機能を嫌うのは、IPFS全体を却下する弱い理由のように思えます。 でも、将来は気が変わってまた参加していただければ幸いです。

誰もがすべての機能を気に入っている製品は1つも見たことがありません。

これは実際には何も再発明していないことにも言及する価値があります。 それは何かを「発明しない」ことです。

私たちの意見の違いに関係なく、 fs://ハンドラー（必要なシームレスなサポートを提供します）は、私たちが話しているように実装されており、既にブラウザー拡張機能で使用できます。 また、ブラウザがネイティブに使用できるようにするためのPoC実装にも取り組んでいます。 電子ラップされたアプリケーションでそれのサポートを実装することもできます。 たぶん、あなたはそれらをより速くするためのそれらの努力に貢献することができます。

「あなたは夢中になっていた。これについては「メガロマニア」であり、再発明でさえない。」

私はhttps://github.com/multiformats/multiaddrをmagalomaniacalであり、再発明していると解釈し

もう少し詳しく説明します。

「ファイルパスがいつものように使用されていることについて話しています。」

私はあなたたちがこのアイデアでどこに向かっているのかを理解していると思います。 Webリソースを通常のファイルのように扱うことができないという事実を修正しようとしている「間違い」はありますか？ そのように私はcat http://google.com/index.html行うことはできませんか？ 不可能なのは悲しいことだと私はあなたに同意することができます。 OSを作成する場合は、 open関数でファイルへのURLを開くことができるようにします。 おそらく、そのような変更はLinuxにも行われる可能性があります。 アプローチは異なります。POSIXファイル階層にWebリソースを挿入しようとしています。 URLが間違っていると思われる理由が他にある場合は、お知らせください。

Webリソースを通常のファイルのように動作させるというあなたの目標には間違いなく共感できます。 しかし、あなたの「間違い」を修正する方法は、私にはかなり滑りやすい坂道のようです。 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が私のマシンに存在しない場合、プログラムはfile-not-foundエラーを返すはずです。 プログラムがアクセスするように指示された絶対パスが、ローカルマシン上のファイルまたはディレクトリ以外の場所につながる別の例を考えることはできません。 ですから、私にとって、長年のLinuxユーザー/開発者として、これは新しい振る舞いです。

私のアプリケーションがmultiaddrのサポートを追加しようとした場合、物事はかなり早く毛むくじゃらになります。 ユーザーが実行した場合：

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

そして、ユーザーはたまたまそのhtmlファイルを/httpに保存するWebサーバーを持っています。 まったく前代未聞ではありません。 私のプログラムはこれをマルチアドレスアドレスまたはローカルファイルに解決する必要がありますか？

PythonでURLを開くための基本的なサポートを備えたコードをすでに作成しました。 そうすることは非常に簡単でした。 しかし、マルチアドレスパスとローカルファイルパスの両方を明確に解決するようにコードを変更するにはどうすればよいですか？

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

私はそれが可能だとは本当に思いません。 したがって、multiaddrサポートを実装せず、通常のURLのみをサポートすることになります。 最初は問題ないように見えますが、ipfsのユーザーは常にipfsオブジェクトへのマルチアドレスアドレスにさらされることになり、IPFSサポートをアドバタイズする私のプログラムはそれらのパスが存在しないと主張します。 したがって、どのようにサポートを実装しても、私のプログラムは壊れてしまいます。 ipfsのサポートが壊れるか、標準のPOSIXファイルシステムのサポートが壊れます。

これを修正できる可能性のある方法がいくつかあります。 1つは、multiaddrを完全に放棄することです。 もう1つは、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からの画像の包含をサポートできるようにしたいと思います。 したがって、ユーザーは次のように書き込みます。

attic.md
`` ``

屋根裏部屋で見つけたもの

岩の古い箱。

`` ``

そして実行します

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

私のプログラムはこれらの画像パスをどのように解決することになっていますか？ /ipfsファイルシステムがマウントされていると想定されていますか？ ユーザーが/ipfsをマウントすることを強制されないことにすでに同意しました。 プログラム/ipfs/を特別なプレフィックスとして扱う必要がありますか？ それは奇妙で壊れているようです。 プログラムはfs://のみをサポートし、エラーを返す必要がありますか？これらのパスでファイルが見つかりませんか？ これは理にかなっているように見えますが、multiaddr標準に慣れているユーザーを混乱させるでしょう。 バッグから抜け出す正しい方法はありません！ ：/ :(

明確にするために編集

@timthelionでいくつかのユースケースを提供していただきありがとうございます。 プロトコルが実際の人々のために機能することを確認できるように、人々に実際の例を提供してもらうのは素晴らしいことです。

「すべてを/にマウントする」の例を明確にする

@lidelが指摘したように、人々は現在アドレススキームの設計に取り組んでいるため、まだドキュメントはありません。 @jbenetのファイルシステムマウントの例が混乱を引き起こしているようです。 これは、 fs:またはdweb:アドレススキームの背後にある概念モデルについて人々が考えるのに役立つことを目的とした単なる例です。 彼は、すべてのディレクトリを実際にファイルシステムにマウントするように強制することを提案していません。 むしろ、彼は、コンテンツがローカルファイルシステムにマウントされているように動作するアドレスでコンテンツを_識別_できるようにすることを提案しています。これにより、unix / posixツールを使用してweb / dwebコンテンツと対話できるようになります。

ドキュメントを作成するときは、これを明確にするように注意する必要があります。 フラグを立てていただきありがとうございます。

'屋根裏部屋の'の例に答えると、次のように、リンクで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は、 fs: / dweb:アドレススキームから逸脱することなく、 ipfs:/およびipns:/アドレスをサポートする賢い方法を提案しました。 関係するプロトコル設計の体操は（IMHO）ひどく混乱しますが、最終的にはipfs:/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPVのようなリンクをマークダウンに含めることができ、同時に人々がfs:/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPVまたはunix / posixコンテキストでは/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPVだけです。

絶対パスはコンテキストに依存します

絶対パスに関して、あなたは言いました：

/で始まるパスにアクセスするように指示された場合、ローカルマシン上のファイルまたはディレクトリへの絶対パスとして確実に解釈されます。

絶対パスがファイルシステムのルートではなく_context_に相対的であるという前例が十分にあることに注意してください。 この最も一般的な例は、サーバーのファイルシステムのルートではなく、現在のoriginのルートに相対的なHTMLの絶対パスです。 すべてのパスがfs:またはdweb:であると想定するコンテキスト内で動作しているコードがある場合、そのコードが/ipfs/で始まるアドレスを使用することは完全に有効です。ファイルシステムの/ipfsにipfsを文字通りマウントせずに、そのコードがパスを解決するための多くの方法。

これらは私の2セントです：

• すべてのファイルがfs:/下にあり、同じようにすべてのドメインがhttp:/ます。
• ドメインネームシステムをファイルシステムの/にマウントしません。同じように、IPFS全体を/マウントしません。 どちらのシステムでも、参照ポイントはスキームに対して/です（ http:/ 、 fs:/ ）。

ほとんどの例では、すべてのファイルシステムが/ ipfsをマウントしているという概念があると思います。 したがって、 fs:/があってもURI形式は壊れません。

むしろ、彼は、コンテンツがローカルファイルシステムにマウントされているように動作するアドレスを持つコンテンツを識別できるようにすることを提案しています。これにより、unix / posixツールを使用してweb / dwebコンテンツを操作できるようになります。

「これにより、unix / posixツールを使用してweb / dwebコンテンツを操作できるようになります。」 fs:プレフィックス付き構文がUNIXツールで使用される場合の具体例を教えてください。 どういうわけか、私はまだそれを取得していません。

私は自分で例を考え出そうとしましたが、multiaddr準拠の/ipfsプレフィックス付き構文が意味をなす例は考えられません。

multiaddrスキームを使用してipfsをサポートするbashのdiffユーティリティへのラッパーscirptを作成しようとしました。

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

！/ bin / bash

get_multiaddr_or_normal_file_getter（）{
if [[$ 1 == / ipfs / *]];
それから
file_getter = "ipfs cat $ 1"
それ以外
file_getter = "cat $ 1"
fi
エコー$ file_getter
}

file1 = get_multiaddr_or_normal_file_getter $1
file2 = get_multiaddr_or_normal_file_getter $2

diff <（$ file1）<（$ file2）
`` ``

これは、通常のファイルとipfsファイルの両方で単純な場合に機能します。

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

f）最初に生まれた子供を神のローラスに生け贄に捧げる
次の偶数年の満月。

`` ``

しかし、それを使用して、作成した/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ファイルの両方で確実に機能できるように、そのユーティリティをどのように編集できるかわかりません。

一方、urlスタイルのsytaxのみをサポートするdiffラッパーを作成することは難しくありません。

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

！/ bin / bash

get_multiaddr_or_normal_file_getter（）{
if [[$ 1 == fs：*]];
それから
prefix = "fs："
internal_path = $ {1＃$ prefix}
file_getter = "ipfs cat $ internal_path"
それ以外
file_getter = "cat $ 1"
fi
エコー$ file_getter
}

file1 = get_multiaddr_or_normal_file_getter $1
file2 = get_multiaddr_or_normal_file_getter $2
エコー$ file1
エコー$ file2
diff <（$ file1）<（$ file2）
`` ``

それも同様に機能し、ハッシュがすでに数十億文字の長さである場合、3つの余分な文字は確かに大きな違いはありません。

`` ``
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）最初に生まれた子供を神のローラスに生け贄に捧げる
次の偶数年の満月。

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

そして、奇妙なエッジの場合、それは、よく洗練されたPOSIXユーティリティから期待されるように見事に実行されます。

`` ``
timothy @ yoga〜 / c / ipfs-multiaddr> echo "bar"> bar
timothy @ yoga〜 / c / ipfs-multiaddr> ./url-syntax-diff bar / ipfs / foo
キャットバー
cat / ipfs / foo
1c1

<バー

foo
`` ``

fs：とdweb：に関する議論は終わりがないように思われるので、私はまだこのprにsom入力が必要です： https ：

ipfsの使用：それまでの間、少なくとも私にとっては多くの問題を解決します。

@pawalため息、あなたのコメントを見たとき、私の心は沈みました。なぜなら、私は私の懸念への応答を非常に待ち焦がれていたからです。

Ping @jbenet

以前の投稿への回答にも興味があります。以前は気づかなかった問題についての見方が浮き彫りになったからです。

//編集：つまり、私はまだ問題をフォローしており、満足のいく答えがあれば応答したでしょう。

+1

'ipfs：//'を標準として機能させます。 お願いします。

（したがって、すべてのアプリは、すべてのプラットフォームで、どこでも動作すると想定できます-
どこでも、名刺で）

どうも。

ジュリアン・スミス
Blockfreight™

ipfs: vs. fs: vs. dweb:に関する議論は、私がこのプロジェクトに参加する前から続いている混乱した議論です。 Web Browsers SprintでのIPFS中に、ようやく頭を悩ませる時間が少しありました。 さまざまなオプションと議論の概要とともに、全体像の説明を書いています。これは、今日の後半にipfs / specsのPRとして提出します。 私が知っている議論の例と参照を含めます。 うまくいけば、それはある程度の明確さを提供し、長期的に大きな問題を引き起こす間違いを犯すことなく、最も実用的な道に沿って前進することを可能にするでしょう。

私はここでこれらの議論の背景を提供することに最初の努力をしました： https ：

無知で申し訳ありませんが、PRを更新するにはどうすればよいですか？

@timthelion @jbenetのように実行してここにコメントを追加

@ vasa-あなたのコメントはソフトウェアがどのように状況を改善するかを実際に説明していないので開発してください、私はそれをスパムだと思います。

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は「デジタルID」用です。

分散型識別子（DID）は、検証可能な「自己主権」デジタルIDの新しいタイプの識別子です。

そう？ 人、動物、建物、組織、物、アイデア、ドキュメントなど、すべてが_アイデンティティ_を持つことができます。それがURIの美しさです。
実際にDID仕様を調べましたか？ 繰り返しますが、人に固有のものは何もありません。

分散型識別子（DID）

分散型台帳技術または他の形式の分散型ネットワークで登録されているため、集中型登録機関を必要としないグローバル一意識別子。 DIDの一般的な形式は、この仕様で定義されています。 特定のDIDスキームは、DIDメソッド仕様で定義されています。