イベントの削除要請

投稿の削除を実現するための仕様

翻訳

特別のイベントの種類 (kind)が 5 のイベントは「削除要請」を意味し、 e タグまたは a タグのリストに、イベントの著者が削除を要請しているイベントのIDを一つ以上指定することで削除を表現する。削除を要請するイベントのkindを削除要請の k タグに含めるべきである(SHOULD)。

(訳註) kタグを含めるようになった経緯

詳細は https://github.com/nostr-protocol/nips/issues/669#issuecomment-2024025600

フォロータイムラインの表示では、テキスト投稿( kind:1 )だけに対する削除イベントを取得したいユースケースが考えられる

互換性の考慮

2024/7/29以前の削除要請( kind:5 )イベントには基本的に k タグが含まれない

古い時間のタイムラインを実装しようとするクライアントはこの方法に頼らずに取得するようにするべき

2024-08-19時点で対応しているのは、Coracle、NDK、Amethyst、nostk、nostter。

タグの個々の要素は、削除を意図する「e」イベントID、NIP-33の a タグを含まなければならない

削除イベントの content には削除理由を説明するテキストを含めてもよい(MAY)。

リレーは、削除リクエストと同じ公開鍵( pubkey )を持つすべての参照されたイベントを削除または公開停止すべきである(SHOULD)。

クライアントは、参照されたイベントを隠すか、あるいは参照されたイベントが削除状態であることを示すべきである(SHOULD)。

削除されることを意図されたイベントをクライアントが既に保有している可能性があるため、リレーは削除のイベントを無期限に公開・共有し続けるべきである(SHOULD)

加えて、クライアントは削除イベントを持たないリレーに削除イベントを公表すべきである(SHOULD)

クライアントは、正当な削除イベントが指すすべてのイベントを完全に削除してよい(MAY)。テキスト投稿、ダイレクトメッセージ、その他今後定義されるであろう(すべての)種類のイベントが削除対象となる。代わりに、クライアントはイベントの横に投稿者がそのイベントから「縁を切った」ことを示すアイコンなどを表示してもよい(MAY)。(削除イベントの) content フィールドで削除されたイベントのコンテンツを置き換えてもよいが、それが削除理由であって、元のコンテンツではないということを明確に表すようなUIとすべきである。

クライアントは、イベントを隠したり削除する前に、削除リクエストの e タグが指す各イベントの pubkey が削除リクエストの pubkey に一致することを検証しなければならない(MUST)。一般にリレーはこの検証を行わない。リレーを信頼できるものとして扱うべきではない。

リレーは、削除イベントがそれ自体と同じ pubkey を持つイベントだけを指しているかどうか検証してもよい(MAY)が、必須ではない。これは、リレーが参照されている全イベントの情報を持たない可能性があるためである。

削除イベントに対して削除イベントを発行しても効果はない。クライアントとリレーに「削除取り消し」機能をサポートする義務はない。