メディア欄の実装方法
X(Twitter)のようにユーザの投稿したメディア（写真や動画など）を一覧表示する機能を実装するにはどうするべきか。
課題
URLが添付されているkind:1をフィルターする簡単な方法がない
現実的に考えられる方法
kind:1をクライアントでフィルターして表示する
{ "kinds": [1], "authors": ["<pubkey>"], "limit": 50 }
利点
もっとも確実に投稿を見つけられる
欠点
転送量が大きくなる
読み込みが遅い
遡らないとメディア付き投稿を見つけられない
ローカルのキャッシュがあれば過去に取得した投稿をすぐに表示できる
が、最新情報は結局リレーに問い合わせる必要がある
採用しているクライアント：nostter、Iris
.pngや.jpg等で検索を行う
利点
転送量が少なくて済む
欠点
検索に対応するリレーは現状限られている（2024年現在）
検索では見つけられない投稿があるかもしれない
検索に対応するリレーは検索の元となる投稿を別のリレーから収集している
収集先リレーに対して投稿していないと、検索対象とならない
対応する拡張子ごとにfilterを書かなければならない（些細だが）
利用できない手段
rタグによるフィルター
NIP-12では活用の例としてURLを含むことができるrタグが考案されている（正式に用途が定められた仕様ではない） 一部のクライアントがkind:1に含めるようにしている
先頭一致の仕様の仕組みがあり、{ "#r": ["http"] } のようなREQを送ればURLを含む投稿を見つけられるはず ただし、#rのような1文字タグクエリに対して先頭一致が機能するかは明記されていない
利用できない理由
先頭一致の仕様は廃止されている
rタグは一部のクライアントしか対応していない
rタグ自体は活用例であって、正式な仕様ではないため
imetaタグによるフィルター
利用できない理由
1文字だけのタグがインデックスされるよう仕様が変更されたため
NIP-96に対応しないアップローダー上の画像はimetaに載らないかもしれない（実装による） 利用できない理由
投稿したファイル一覧を列挙するための仕様であり、本来ソーシャルクライアントがサポートすることは想定されていない
見つかった画像等のメディアのURLを含む kind:1 を見つけることが結局難しい
アイデア（仕様で定められているわけではない）
投稿にメディアを含むかどうか等のメタデータを持たせられるようにする
{ "tags": [ ["F", "has_image"], ["F", "has_link"] ] }
問い合わせするときは { "#F": ["has_image"] }
欠点
この仕様に対応した新しいイベントしか検索で見つけられない
メディアを含むかどうかなどの問い合わせにリレーを対応させる
{ "features": ["has_image", "has_link",] }
欠点
リレーの対応が必要となる
リレーはkind:1やkind:30023等の内容をパースしなければならず負荷が増える