リレーヒントの実装
リレーヒント
リポストやイベント参照に対象となるイベントやユーザを見つけられるリレーのURLを含める仕様のことをリレーヒントと言います。
他のユーザがイベントやユーザを見つけられるようにするために必要となります。
返信、引用
"e" タグや "a"タグに含める
nevent や naddr 、nprofile
任意のフィールドとして存在します
文献
どのリレーを選ぶか
イベントを受信したことのあるリレー（nostr-toolsやrx-nostrがサポート）
考慮すべきこと
認証が必要ならば、通常のユーザは閲覧ができないので除外するべきかもしれません。
判定方法
1. 最新1件だけ read して AUTH が流れてくるか
2. NIP-11の limitation.auth_requried を確認
置換可能イベントとパラメータ付き置換可能イベント
ユーザのwriteリレーに最新が載っているかもしれません。ユーザのwriteリレーを指定するのが良いかもしれません。
常に同じリレーを選ぶべきか？ランダムでよいのか？
リレーのスコアリングをするべきか？
リレーの安定性やこれまでのイベント数などに基づいて、リレーをスコアリングし、優秀なリレーをリレーヒントに含めることもできます。
リレーヒントの信頼度は高まる（イベントが見つかりやすくなる）が、リレーが分散されにくいという欠点もあります。
（参考までにgossipではリレーヒントにはスコアを使用していません。後述します。）
リレーヒントの利用
リレーヒントがあれば、イベントを見つけるときに利用できます。
通常のイベントの取得
リポスト等のイベントの参照時にだけ使う。
フォールバックとして使う。自分の普段利用しているリレーから見つからないときに問い合わせる。
置換可能イベント・パラメータ付き置換可能イベント
リポスト等のイベントの参照時に用いる
⚠️ただし、最新のユーザメタデータ(kind:0, いわゆるプロフィール)や最新の長文投稿を取得するなら、ユーザのwriteリレーを参照するのが確実かもしれません。 リレーヒントの限界
リレーヒントは常に信頼できる情報とは限りません。
リレーヒントで提示されたリレーが停止している恐れ（サービス停止、メンテナンス中など）
リレーヒントに認証付きリレーが選ばれてしまう恐れがある。
各クライアントの実装
※ SeenOn = クライアントがそのイベントを受信できたリレーのこと
gossip
Coracle
TBD
damus
TBD
amethyst
TBD
nostter
lumilumi
noshaiku
1. seenOnのうち、最初のOutbox modelのwriteに指定されているリレー
2. 存在しなければ、seenOnが存在すれば、seenOnの先頭
3. 存在しなければ、nevent1... のリレーヒントに含まれるものうち、writeに指定されているリレー
1. ユーザメタデータ(kind:0、いわゆるプロフィール)を取得する。そのseenOnのうち最初のOutbox modelのwriteに指定されてるリレー
2. 存在しなければ、seenOnが存在すれば、seenOnの先頭
3. 存在しなければ、nprofile...のリレーヒントに含まれるもののうち、writeに指定されているリレー