NIP-29
Relay-based Group
未定義
リレーの鍵をどうやって見つけるのか
kind:39000の鍵で分かる?
しかし、リレー管理者でない別の人がkind:39000をNIP-29に対応しないリレーに送る可能性がある
previousが衝突しやすい可能性
/icons/hr.icon
翻訳 commit=c60ca88
リレーに基づくグループ
このNIPは閉じられたユーザのみが書き込めるグループのための標準を定義する。外部ユーザに読み込めるようにすることも、しないようにすることもできる。
グループはidとして提供される任意の長さを持つランダムな文字列によって識別される。
グループを作る手段は存在しない。実際に起きるのは(たいていユーザに依頼されたときに)リレーが特定のIDに関するルールを作ることであって、それでそのIDは実際のグループを提供し、それ以降のそのグループに送られるメッセージにはルールが課される。
(訳注: グループを「作る方法」というのは存在せず、リレーが特定のIDに対して(たいていユーザに依頼されたときに)ルールを設けることがグループの作成に相当する。ルールの作成後にグループに送られたメッセージにそのルールが課される。)
通常グループは本来は1つの特定のリレーに所属するが、コミュニティはグループを別のリレーに移したり、グループを分岐(fork)したりすることさえでき、異なるリレーの間で異なる形式(同じ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)の基本単位である。
code:_.json
"kind": 11,
"content": "hello my friends lovers of pizza",
"tags": [
]
...
テキスト投稿のスレッド内返信(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)
これはグループに投稿されるチャットメッセージの基本単位である。
code:_.json
"kind": 9,
"content": "hello my friends lovers of pizza",
"tags": [
]
...
チャットメッセージのスレッド内返信(chat message threaded reply kind:10)
kind:12に似ていて、グループに送られるチャットメッセージの基本単位である。これは、デフォルトで非表示かもしれないチャット内スレッドで使われることを意図している。すべてのチャット内返信にkind:10を使わなければならないわけではなく、チャットの通常の流れの一部でない、隠されたスレッドを作るために使われなければならない(MUST)(しかし、クライアントはデフォルトで表示してもよい)。
kind:10はNIP-10マーカーをkind:12と同様に使用すべきである(SHOULD)。 参加リクエスト(join request, kind:9021)
あらゆるユーザは自動または手動でグループに追加してもらうためにこれらのイベントのひとつを送信できる。グループがopenならば、リレーはユーザ追加の応答としてkind:9000を自動的に発行する。そうでない場合、グループの管理者がそれらの要求を問い合わせ、それに応じて対応をするかもしれない。
code:_.json
{
"kind": 9021,
"content": "optional reason",
"tags": [
]
}
モデレーションイベント(kind:9000-9020)(任意)
クライアントはモデレーション操作を達成するためにこれらのイベントをリレーに送ってもよい。リレーはイベントの送信者の公開鍵がその操作を行う能力(権限)があるかを確認しなければならない。リレーは対応後にイベントを破棄してもよいし、モデレーションログとして残してもよい。
code:_.json
{
"kind": 90xx,
"content": "optional reason",
"tags": [
]
}
それぞれのモデレーション操作は異なるkindを使用し、(タグとして与えられる)異なる引数が必要である。これらは次のテーブルで定義される:
table:モデレーション操作の定義
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)(任意)
このイベントはグループのメタデータ(基本的にクライアントがどのように表示するべきか)を定義する。これは見つかったリレーによって生成、署名されなければならない。別の人によって署名されていた場合、リレーはイベントを受理すべきでない。
もしグループが分岐して複数のリレーでホストされている場合には、このイベントの複数のバージョンがそれぞれの異なるリレーに存在するだろう。
code:_.json
{
"kind": 39000,
"content": "",
"tags": [
]
...
}
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
code:_.json
{
"kind": 39001,
"content": "list of admins for the pizza lovers group",
"tags": [
]
...
}
グループメンバー(kind:39002)(任意)
グループ管理者と似ていて、イベントはグループをホストするリレーによって生成されることになっている。
これはNIP-51風のグループメンバーの公開鍵リストである。リレーはこの情報を公開しないことにしても、取得ができる公開鍵を制限することにしてもよい。 code:_.json
{
"kind": 39002,
"content": "list of members for the pizza lovers group",
"tags": [
]
}
ユーザが所属するグループの一覧の保存
ユーザが所属を覚えてもらうことを望むグループの一覧をクライアントが保管できるようにするためのkind 10009の定義はNIP-51に含められた。