NIP-72
#NIP
Moderated Communities (Reddit Style)
https://github.com/nostr-protocol/nips/blob/master/72.md
Redditのようなコミュニティを作ることができる仕様。
機能としての説明はコミュニティを参照
議論: https://github.com/nostr-protocol/nips/pull/602/files
/icons/hr.icon
原文: https://github.com/nostr-protocol/nips/blob/master/72.md
モデレーションつきコミュニティ(Redditスタイル)
このNIPの目的は、特定のトピックに関連するモデレータ承認つきのパブリックコミュニティを作ることである。コミュニティと現在のモデレータ・管理者リストを定める上書き可能イベント kind:34550を定義する。コミュニティに投稿したいユーザは、ただ任意のNostrイベントにコミュニティを指すaタグを付加するだけでよい。モデレータは、コミュニティと新規投稿を関連付ける承認イベントkind:4550を発行する。
コミュニティの定義
kind:34550(のイベント)はコミュニティとモデレータの集まりを定義するのに足るフィールドを含むべきである(SHOULD)。relayタグを(投稿)リクエストと承認(イベント)をダウンロードする優先リレーを指定するのに用いてよい(MAY)。
code:34550.json
{
"id": "<32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>",
"pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>",
"created_at": <Unix timestamp in seconds>,
"kind": 34550,
"tags": [
"d", "<コミュニティ名>",
"description", "<コミュニティの説明>",
"image", "<コミュニティ画像URL>", "<幅>x<高さ>",
//.. その他のコミュニティの定義に関連するタグ
// モデレータ
"p", "<32-bytes hex of a pubkey1>", "<推奨リレーURL(任意)>", "moderator",
"p", "<32-bytes hex of a pubkey2>", "<推奨リレーURL(任意)>", "moderator",
"p", "<32-bytes hex of a pubkey3>", "<推奨リレーURL(任意)>", "moderator",
// コミュニティが利用するリレー (マーカー(任意)つき)
"relay", "<投稿者のkind 0をホストするリレー>", "author",
"relay", "<リクエストを送受信するためのリレー>", "requests",
"relay", "<承認を送受信するためのリレー>", "approvals",
"relay", "<リクエストの送信先、承認を取得元のリレー>"
]
}
新規投稿リクエスト
任意のNostrイベントが投稿リクエストになりうる。クライアントは、投稿をモデレータに提示して承認してもらうために、コミュニティを指すaタグを新規投稿に追加しなければならない(MUST)。
code:post_request.json
{
"id": "<32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>",
"pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>",
"created_at": <Unix timestamp in seconds>,
"kind": 1,
"tags": [
"a", "34550:<コミュニティ作成者の公開鍵>:<コミュニティ識別子(dタグの値)>", "<リレーURL(任意)>",
],
"content": "<投稿内容>"
}
コミュニティを管理するクライアントはあるkind:34550のイベントに対するすべての言及をフィルタし、各投稿の承認をモデレータに要求してよい(MAY)。モデレータは、イベント削除(NIP-09を参照)によっていつでも承認を取り消してよい(MAY)。
モデレータによる投稿の承認
投稿承認イベントには、モデレータが参加(投稿)しているコミュニティ(1つまたはそれ以上)を指すaタグ、(承認する)投稿を指すeタグ、(承認する投稿の)投稿者を指すpタグ(承認通知用)を含めなければならない(MUST)。このイベントにはさらに、文字列化した投稿リクエストイベントをcontentに含め(NIP-18スタイル)、承認されたイベントをkindでフィルタリングできるようにするため元投稿のイベントkindを値にもつkタグを含めるべきである(SHOULD)。
code:4550.json
{
"id": "<32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>",
"pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>",
"created_at": <Unix timestamp in seconds>,
"kind": 4550,
"tags": [
"a", "34550:<コミュニティ作成者の公開鍵>:<コミュニティ識別子(dタグの値)>", "<リレーURL(任意)>",
"e", "<投稿リクエストのID>", "<リレーURL(任意)>",
"p", "<投稿リクエスト発行者のID>", "<リレーURL(任意)>",
"k", "<新規投稿リクエストのkind>",
],
"content": "<新規投稿リクエストのJSON>"
}
あるモデレータがコミュニティ所有者のリストから削除された際にコミュニティから投稿が削除されるのを避けるため、複数のモデレータが投稿を承認することが推奨される。全モデレータを入れ替えなければならない状況では、新しいモデレータたちに過去の投稿を改めて承認させるか、コミュニティを作り直す。コミュニティ所有者は、定期的に各モデレータによる承認イベントをコピー・再署名することで、投稿がモデレータとともに消失しないようにすることもできる。
上書き可能イベントの投稿承認は3つの方法でなされうる:
(1) 上書き可能イベントをeタグで参照する。モデレータがイベントの各々の変更について承認を行いたい場合。
(2) aタグで参照する。 イベントの発行者が追加の承認なしでイベントの変更を行えないように、モデレータが認可を行いたい場合。
(3) eタグとaタグの両方で参照する。この場合クライアントは、UIの適切な補足とともにイベントの元のバージョンと更新されたバージョンを表示できる。
リレーは上書き可能イベントの古いバージョンを削除することになっているので、eタグを用いた承認イベントのcontentにはその特定のバージョンのイベントを持たせなければならない(MUST)。さもなくば、クライアントはそのバージョンの内容を知ることができないだろう。
表示
コミュニティクライアントは、最低1人のモデレータかコミュニティ所有者によって承認済みのイベントを表示すべきである(SHOULD)。
次のフィルタを用いて、承認された投稿を表示できる。
code:承認済み投稿を取得するフィルタ.json
{
"authors": "<コミュニティ作成者の公開鍵>", "<モデレータ1の公開鍵>", "<モデレータ2の公開鍵>", "<モデレータ3の公開鍵>", ...,
"kinds": 4550,
"#a": "34550:<コミュニティ作成者の公開鍵>:<コミュニティ識別子(dタグの値)>",
}
クライアントは、ユーザの要求に応じてブロック済みモデレータによる承認を隠してもよい(MAY)。