Trusted Relay Assertionsは、relayについて署名付きの第三者評価をNostr上で公開し、clientがself-reported metadataだけではない文脈をもとにrelayを選べるようにする考え方です。現時点で標準化されているbuilding blockはNIP-85: Trusted Assertionsで、userがproviderをどう信頼し、providerが署名済み計算結果をどう公開するかを定義しています。

仕組み

relay選定には3つの層があります。NIP-11: Relay Information Documentはrelayが自分について何を言うかを扱います。NIP-66: Relay Discovery and Liveness Monitoringは可用性やlatencyのように観測できる値を扱います。Trusted Relay Assertionsは、その先にある「第三者がそのdataから何を結論づけるか」と「clientがその結論を信頼するか」を埋めようとするものです。

より広いNIP-85モデルでは、userがkind 10040 eventでtrusted providerを指定し、providerが署名済みのaddressable assertion eventを公開します。relay-scoring appを作るには、さらに2つの合意が必要です。relayをsubjectとしてどう識別するか、そしてscoreと裏付けをどのresult tagで表すかです。

ここで大事なのは、transportとtrust delegationは標準化されていても、relay固有のscoring modelはまだapplication patternだという点です。何をもってtrustworthy relayとみなすかについて、providerごとに正当な不一致があり得ます。

信頼モデル

relay trust scoreは客観的事実ではありません。あるproviderはuptimeとwrite throughputを重視し、別のproviderは法域、moderation policy、operator identityを重視し、さらに別のproviderは監視耐性を最優先するかもしれません。役に立つclientは、scoreそのものだけでなく、誰がそのscoreを出したかを示す必要があります。

ここでWeb of Trustも関わってきます。clientがすでに特定の人やserviceを信頼しているなら、そのsocial neighborhoodから来たrelay評価を優先できます。単一のglobal rankingがあるふりをしなくて済みます。

なぜ重要か

NIP-46 remote signer、wallet connection、未知のrelayを提示するappでは、第三者によるrelay評価がdefaultへの盲信を減らせます。NIP-65 relay listと組み合わせれば、clientは「どのrelayを使うか」と「どのrelayをこの用途で信頼するか」を分けて考えられます。

ただし正確さに関する注意点もあります。2026-01のnewsletterではrelay trust scoringが専用proposalのように扱われましたが、NIPs repositoryでmerge済みなのは、より広いNIP-85: Trusted Assertions formatです。relay scoringはその上に載るuse caseであり、独立した完成済みwire formatではありません。

主要ソース:

言及箇所:

関連項目: