ハンドルアンチを名乗っている割にあんまり具体的な話をしていなかった気がするので、ハンドルという機能が持つ課題を一旦まとめておく。正直に言えば、一時期カスタムハンドルがアカウントの検証手段として過剰に期待されていたことに対する逆張りの気持ちも大いにあるが、それは別として現状のハンドルに対する問題意識を明文化したい。
念の為書いておくと、atprotoの現状理解を整理する一貫として書いているのであって、これらの問題を解決するような仕様変更を求めるつもりはない。
あると嬉しいし、PDS的にもあまりコストがかからないのではないかと思うが、必須にはしたくないという話。
PDSが初期ハンドルも提供してくれるのは助かる一方で、ハンドルがPDSに依存することになる。PDSを変える際にはおそらくハンドルを捨てることになるため、折角のアカウント可搬性に対して負のモチベーションになりかねない。
これはハンドルがオプション機能になれば解決する。つまり、アカウント作成時にはハンドルは割り当てられず、欲しければ所有するドメインなり外部サービスなりを使ってハンドルを取得すればよい。ハンドルを持たないアカウントの識別のためにDIDを表示したりするようになれば、個人的には敢えてハンドルを取得しない選択肢も十分ありえる。
フォロー対象などの参照は内部的にはDIDを使うはず(そうでないとハンドル変更時に追跡できない)なので、機能上はさほど問題にならない。アカウントを探すにしても、bskyの場合は独自のアカウント検索機能を備えているのだから、単独で解決できるハンドルでなくても、表示名で検索すれば済む[1]。
例えば名刺にハンドルを記載したり、ウェブサイトにアカウントへのリンクを張っていたとして、そこにアクセスされる時にまだそのハンドルを使い続けているかは分からない。単にアカウントにアクセスできないだけならまだしも、最悪の場合ハンドル変更後になりすましがスクワッティングしているかもしれず、古いハンドルであることに気付くことすらできないかもしれない[2]。
これはハンドルを変更不可にすれば解決するものではあるが、その場合はハンドルの提供者と運命を共にする必要があることに注意すること。特にPDSが提供するハンドルは注意が必要で、一度bsky.socialでハンドルを取ったら、他PDSに移動してもハンドルはそのままになる。当然bsky.socialが停止したらハンドルも機能しない。Skynameのようにハンドルを提供するサービスの場合も同様。
他の対策としては、ハンドルにDID由来の短いハッシュを連結することで一意のIDを作る、かつてのdiscordのような方式も考えられる。この場合、古いハンドルからアカウントを見つけることはできないが、これも発見は表示名の検索などに任せて、同定はDID(のハッシュ)部分を使えばいい。
余談だが、bsky.appのアカウントや投稿のパーマリンクは以下のようにDIDでも表すことができる。URLを載せる際はこちらの方が望ましい……と思っているが、いちいちDIDを調べないといけないのが面倒なところ[3]。
atprotoではdid:webを利用することができる[4]。この識別子はハンドルと同様にドメイン名を用いるが、ハンドルとDIDは独立に管理されているため、同じドメイン名を使っているからといって同じアカウントとは限らない。例えば、@example.comというハンドルが指すアカウントとdid:web:example.comが指すアカウントは必ずしも一致しない。
ユーザーにDIDの存在を意識させなければ混乱も生じないので解決、と言われればそれまでなのだが、先述の通りDIDを完全に隠すのもそれはそれで望ましくない。
解決は難しいが、例えばハンドルの代わりにサブDIDもしくは表示用DIDのようなものを定義してやることで、did:web自体をハンドルとして使うという手はありえる。それだけだとサーバ必須になるため、現状のハンドルと同様の使い勝手にするにはdid:dnsも使うことになりそう。結局似たようなDIDが2つ作れるようにはなってしまうが、メソッド名が表に出ているだけマシに感じる。
前述の通りdid:webはハンドルとほぼ同じ値が使えるので、DIDは必ずしも可読性が悪いわけではない。なので、did:plcなどという可読性の悪いメソッドをデフォルトにしているのが悪い……と主張していたこともあったが、どうやらこれは筋が悪いらしい。
DIDにはhuman-friendlyであることを良しとする価値観はあまり無いようで、むしろセキュリティの観点から無意味な文字列である方が望ましいとされている。
一般論としてDIDをそのまま扱うのが辛いというのは反論の余地が無さそう。