NIP-89
> Recommended Application Handlers
不明なkindのイベントを扱えるアプリケーションを発見するための仕組みを定義するNIP。
翻訳
理由
Nostrの発見可能性と透過的なイベントとのインタラクションは、Nostrの最も興味深く目新しい仕組みの一つである。このNIPはクライアントやイベント種別を跨いだインタラクションがスムーズであることを保証するために、クライアントが特定のイベント種別を持つイベントを発見するためのシンプルな方法を提供する。
登場人物
このワークフローでは3つの登場人物が登場する。
アプリケーション: 特定のイベントの種類を取り扱うことができる（アプリケーションは個別のエンティティである必要はなく、ユーザAと同じ公開鍵であってもよいことに注意）
kind:31990 を投稿する。どのようにそのアプリにリダイレクトすべきかを説明する。ユーザA: 特定のイベント種別を扱うことのできるアプリを推奨する。
kind:31989 を投稿する。ユーザB: 特定のイベント種別を扱うことのできるアプリの推奨を探す。
kind:31989 を問い合わせ、結果に基づいて kind:31990 を問い合わせするイベント
推奨イベント
_.json{
"kind": 31989,
"pubkey": <recommender-user-pubkey>,
"tags": [
[ "d", <supported-event-kind> ],
[ "a", "31990:app1-pubkey:<d-identifier>", "wss://relay1", "ios" ],
[ "a", "31990:app2-pubkey:<d-identifier>", "wss://relay2", "web" ]
]
} kind:31989 の d タグには、このイベントが推奨するサポートされているイベント種別を含める。ひとつの
kind:31989 に複数の a タグがあってもよい。タグの2つ目の値はリレーヒントであるべきである（SHOULD）。タグの3つ目の値はこの推奨が適用できるプラットフォームであるべきである（SHOULD）。
ハンドラー情報
_.json{
"kind": 31990,
"pubkey": <pubkey>,
"content": "<optional-kind:0-style-metadata>",
"tags": [
[ "d", <random-id> ],
[ "k", <supported-event-kind> ],
[ "web", "https://..../a/<bech32>", "nevent" ],
[ "web", "https://..../p/<bech32>", "nprofile" ],
[ "web", "https://..../e/<bech32>" ],
[ "ios", ".../<bech32>" ]
]
} content は、任意の（NIP-01で説明されている） set_metadata のような文字列化されたJSONオブジェクトである。このcontentは kind:31990 を作成する公開鍵がアプリケーションのものではない場合に便利である。もし content が空の場合には、pubkeyの kind:0 をアプリケーションの情報を表示するために使うべきである（例えば、name, picture, web, LUD16など）。