🤔
Nostrのアカウントまわり(鍵云々)をOAuthで例えてみる
ritou です。
うまく説明しにくいなって思ってたやつの話です。
Nostr is ...
詳しい人がたくさんいます。
Nostrにはログインという概念はありません。セッションもありません。(有料リレーを使うための認証を除く)
情報の署名を行うための秘密鍵を持っているか、居ないか、それだけです。
署名が必要なのは、送信と暗号化DMの読み取りだけです。
ので、公開された情報(公開鍵がわかっている情報)を読むためには特に何も要りません。
そのため、秘密鍵の所有が、アカウントの所有に相当することになります。
OAuthで説明していく
今回はアカウントが云々の部分だけにフォーカスします。
いきなりまとめると、
- Nostrにおける鍵ペア : OAuth 2.0のClient Credentials
- NostrにおけるClient : OAuth 2.0のリクエストを送れるライブラリやプロダクト
- Nostrにおけるユーザーのプロフィール : OAuth 2.0のClient Metadata
- OAuth 2.0のServer : 一つに定まらず、リレーと呼ばれる人たちが相当
これぐらいかなと思います。
一連の流れを見ていきましょう。
Nostr Clientへの秘密鍵入力 or 鍵ペア生成
- Nostr Clientで鍵ペア生成 : OAUth 2.0でDynamic Client RegistrationしてClient Credentialsを取得
- Nostr Clientへの秘密鍵入力 : 自分の使いたいOAuthライブラリにClient Credentialsを設定
Nostr Clientでプロフィール設定
- Client AuthenticationつきのリクエストでClientのmetadataを更新
write系の処理
- Client Authenticationつきのリクエストで利用できるAPIを利用
read系の処理
- Client IDのみ指定してデータが引ける
偽Damusに秘密鍵を入力
- Client Secretを第３者の管理化にあるプロダクトなどに登録してしまった！
- Client Secretだけを更新する仕組みがない！こうなったらもうこのClientは捨てて再度Dynamic Client Registrationからやり直しだ！
という感じの説明はどうでしょう。
上に書いたとおりアカウントのあたりに注目して整理したものなので、リレーまで考慮するとまた違った整理ができる気もします。
ではまた。
Discussion