NIP-29
> Relay-based Group
クライアント
未定義
リレーの鍵をどうやって見つけるのか
kind:39000の鍵で分かる？
しかし、リレー管理者でない別の人がkind:39000をNIP-29に対応しないリレーに送る可能性がある
Proof of workとの相性 （NIP-13）
previous が衝突しやすい可能性翻訳
commit=c60ca88 リレーに基づくグループ
このNIPは閉じられたユーザのみが書き込めるグループのための標準を定義する。外部ユーザに読み込めるようにすることも、しないようにすることもできる。
グループはidとして提供される任意の長さを持つランダムな文字列によって識別される。
グループを作る手段は存在しない。実際に起きるのは（たいていユーザに依頼されたときに）リレーが特定のIDに関するルールを作ることであって、それでそのIDは実際のグループを提供し、それ以降のそのグループに送られるメッセージにはルールが課される。
（訳注: グループを「作る方法」というのは存在せず、リレーが特定のIDに対して（たいていユーザに依頼されたときに）ルールを設けることがグループの作成に相当する。ルールの作成後にグループに送られたメッセージにそのルールが課される。）
通常グループは本来は1つの特定のリレーに所属するが、コミュニティはグループを別のリレーに移したり、グループを分岐(fork)したりすることさえでき、異なるリレーの間で異なる形式（同じidを使ったまま）で存在する。
リレーの生成するイベント
リレーはグループのメタデータ（訳注:
kind:39000 (NIP-29#66968a251246d70000efcd88)）と管理者（訳注: kind:39001 NIP-29#66968dce1246d70000efcda0）を説明するイベントを生成することになっている。リレーの鍵ペアによって直接署名された、 d タグにグループのidを持つパラメータつき置換可能イベントである。（訳注：イベントの定義は下記のイベントの定義で説明される）
グループの識別子
グループは
<ホスト名>'<グループのID> という形式の文字列によって識別される。例えば、 wss://groups.nostr.com でホストされる abcdef というidを持つグループは groups.nostr.com'abcdef という文字列で識別される。h タグ
ユーザによってグループに送られるイベント（チャットメッセージ、テキスト投稿、モデレーションイベント等）は値としてグループidが設定された
h タグを持たなければならない。タイムライン参照
文脈(コンテキスト)外で使われることがないように、グループに送られるイベントは同じリレーからの前のイベントへの参照を
previous タグに含むかもしれない。どの前のイベントを選ぶのかというのはクライアントによる。参照は、リレーでユーザが見た最新50件のあらゆるイベント（自身によるものを除く）の最初の8文字(4バイト)によって作られることになっている。参照の数はどんな数であってもよい（ゼロも含む）が、クライアントは少なくとも3つを含め、リレーはこれを強制することが推奨される。これはメッセージが文脈外の分岐(fork)したグループを持つ外部のリレーにブロードキャストされることを防ぐためのハック(訳注:アイデア)である。リレーは自身のデータベースに見つからないイベントへのタイムライン参照を含むあらゆるイベントを拒否することが期待される。リレーが公正であることを維持するためにクライアントもこれらを確認するべきである。
公開の遅延
リレーは、別のリレーから分岐または移動されたグループを受け取るようにしていない限り、公開の遅延（今公開されたが、数日前や数時間前のタイムスタンプを持つメッセージ）を防ぐべきである。
イベントの定義
ルートテキスト投稿（text root note）（
kind:11 ）グループに送られる「マイクロブログ」のルートテキスト投稿(root text note)の基本単位である。
_.json "kind": 11,
"content": "hello my friends lovers of pizza",
"tags": [
["h", "<group-id>"],
["previous", "<event-id-first-chars>", "<event-id-first-chars>", ...]
]
...テキスト投稿のスレッド内返信（threaded text reply,
kind:12 ）グループに送られる「マイクロブログ」のリプライ（返信）投稿の基本単位である。常に他の投稿への返信（
kind:11 と kind:12 のいずれか）で使わなければならないという事実を除いて、基本的に kind:11 と同様である。 kind:12 イベントはNIP-10マーカーを使うべきである（リレーURLは空のままに）。 ["e", "<kind-11-root-id>", "", "root"] ["e", "<kind-12-event-id>", "", "reply"] チャットメッセージ（chat message,
kind:9 ）これはグループに投稿されるチャットメッセージの基本単位である。
_.json "kind": 9,
"content": "hello my friends lovers of pizza",
"tags": [
["h", "<group-id>"],
["previous", "<event-id-first-chars>", "<event-id-first-chars>", ...]
]
...チャットメッセージのスレッド内返信（chat message threaded reply
kind:10 ） kind:12 に似ていて、グループに送られるチャットメッセージの基本単位である。これは、デフォルトで非表示かもしれないチャット内スレッドで使われることを意図している。すべてのチャット内返信に kind:10 を使わなければならないわけではなく、チャットの通常の流れの一部でない、隠されたスレッドを作るために使われなければならない(MUST)（しかし、クライアントはデフォルトで表示してもよい）。参加リクエスト（join request,
kind:9021 ）あらゆるユーザは自動または手動でグループに追加してもらうためにこれらのイベントのひとつを送信できる。グループが
open ならば、リレーはユーザ追加の応答として kind:9000 を自動的に発行する。そうでない場合、グループの管理者がそれらの要求を問い合わせ、それに応じて対応をするかもしれない。_.json{
"kind": 9021,
"content": "optional reason",
"tags": [
["h", "<group-id>"]
]
}モデレーションイベント（
kind:9000-9020 ）（任意）クライアントはモデレーション操作を達成するためにこれらのイベントをリレーに送ってもよい。リレーはイベントの送信者の公開鍵がその操作を行う能力（権限）があるかを確認しなければならない。リレーは対応後にイベントを破棄してもよいし、モデレーションログとして残してもよい。
_.json{
"kind": 90xx,
"content": "optional reason",
"tags": [
["h", "<group-id>"],
["previous", ...]
]
}それぞれのモデレーション操作は異なるkindを使用し、（タグとして与えられる）異なる引数が必要である。これらは次のテーブルで定義される：
モデレーション操作の定義
| kind | name | tags |
| 9000 | `add-user` | `p` (16進数の公開鍵) |
| 9001 | `remove-user` | `p` (16進数の公開鍵) |
| 9002 | `edit-metadata` | `name`,`about`,`picture` (文字列) |
| 9003 | `add-permission` | `p` (公開鍵),`permission` (名前) |
| 9004 | `remove-permission` | `p` (公開鍵),`permission` (名前) |
| 9005 | `delete-event` | `e` (16進数のid) |
| 9006 | `edit-group-status` | `public`または`private`,`open`または`closed` |
| 9007 | `create-group` |
グループメタデータ（
kind:39000 ）（任意）このイベントはグループのメタデータ（基本的にクライアントがどのように表示するべきか）を定義する。これは見つかったリレーによって生成、署名されなければならない。別の人によって署名されていた場合、リレーはイベントを受理すべきでない。
もしグループが分岐して複数のリレーでホストされている場合には、このイベントの複数のバージョンがそれぞれの異なるリレーに存在するだろう。
_.json{
"kind": 39000,
"content": "",
"tags": [
["d", "<group-id>"],
["name", "Pizza Lovers"],
["picture", "https://pizza.com/pizza.png"],
["about", "a group for people who love pizza"],
["public"], // or ["private"]
["open"] // or ["closed"]
]
...
} name 、 picture および about は表示を目的とした基本的なメタデータである。 public はグループが誰からでも読めることを伝え、一方で private は認証（ AUTH ）済みのユーザのみが読めることを伝える。 open は誰でも参加をリクエストできることを伝え、一方で closed はメンバーは事前承認されていなければならないか、手動で参加リクエストが対応されるであろうことを示す。グループ管理者（
kind:39001 ）（任意）グループメタデータに似ていて、ホストをグループするリレーによって生成されることになっている。
それぞれの管理者は表示目的のためだけに使われるラベルと、管理者の権限のリスト（後に示す）を得る。これらの権限はUIを構築するクライアントに知らせるが、究極的にはリレーが有効となるようにリレーによって評価される。
以下が（今のところ）このNIPで定義される権限のリストである：
add-user edit-metadata delete-event remove-user add-permission remove-permission edit-group-status _.json{
"kind": 39001,
"content": "list of admins for the pizza lovers group",
"tags": [
["d", "<group-id>"],
["p", "<pubkey1-as-hex>", "ceo", "add-user", "edit-metadata", "delete-event", "remove-user"],
["p", "<pubkey2-as-hex>", "secretary", "add-user", "delete-event"]
]
...
}グループメンバー（
kind:39002 ）（任意）グループ管理者と似ていて、イベントはグループをホストするリレーによって生成されることになっている。
これはNIP-51風のグループメンバーの公開鍵リストである。リレーはこの情報を公開しないことにしても、取得ができる公開鍵を制限することにしてもよい。
_.json{
"kind": 39002,
"content": "list of members for the pizza lovers group",
"tags": [
["d", "<group-id>"],
["p", "<admin1>"],
["p", "<member-pubkey1>"],
["p", "<member-pubkey2>"],
]
}ユーザが所属するグループの一覧の保存
ユーザが所属を覚えてもらうことを望むグループの一覧をクライアントが保管できるようにするためのkind
10009 の定義はNIP-51に含められた。