NIP-28
Public Chat
/icons/hr.icon
パブリックチャットのチャンネル、チャンネルメッセージ、基本的なクライアントサイドでのモデレーション用の新しいイベントの種類 (kind)を定義する。 今すぐ使うものとして5つのkind(40-44)を、将来的に使うものとしてもう5つのkind(45-49)を予約する。
40: チャンネル作成
41: チャンネルメタデータ
42: チャンネルメッセージ
43: メッセージ非表示化(Hide message)
44: ユーザのミュート
クライアント中心のモデレーションにより、どんな種類のコンテンツを許すかに関する裁量はクライアント開発者に委ねられることになり、リレーには追加の要求を課さずに済む。
Kind 40: チャンネル作成
パブリックチャットのチャンネルを作成する。
contentフィールドには、基本的なチャンネルのメタデータ(name, about, picture, relays)を含めるべき(SHOULD)。
Kind 41: チャンネルメタデータ設定
チャンネルの公開メタデータを更新する。
クライアントとリレーはkind 41のイベントをkind 0のイベントと同様に扱うべき(SHOULD)。
同じ公開鍵を持つ同じkindのイベントがあったら、新しい方だけを採用せよ、ということ
クライアントは、チャンネルを作成したpubkey以外からのkind 41イベントを無視すべき(SHOULD)。
クライアントは、以下に挙げる基本的なメタデータフィールドをサポートすべき(SHOULD)。他のメタデータを追加してもよい(MAY)。
name (string): チャンネル名
about (string): チャンネルの説明
picture (string): チャンネル画像のURL
クライアントは、推奨リレーの指定にNIP-10のmarked e タグを使うべき(SHOULD)。 と書いてあるが、eタグにリレーURLを含める仕様を定義しているのはNIP-01では? jiftechnify.icon Kind 42: チャンネルメッセージの作成
チャンネルにテキストメッセージを送信する。
クライアントは、推奨リレーと、リプライかルートメッセージかの指定にNIP-10のmarked eタグを使うべき(SHOULD)。 クライアントは、リプライメッセージにNIP-10のpタグを追加すべき(SHOULD)。 code:ルートメッセージの例.json
{
"content": <string>,
"tags": "e", <kind_40_event_id>, <relay-url>, "root",
...
}
code: リプライメッセージの例.json
{
"content": <string>,
"tags": [
...
],
...
}
Kind43: メッセージ非表示化
特定のメッセージをユーザの目から隠す。
contentにはreasonのようなメタデータを含めてもよい(任意)。
クライアントは、ユーザが発行した非表示イベントによって指定されたIDに一致するメッセージ(kind 42)を非表示にすべき(SHOULD)。
クライアントは、他のユーザが送信した非表示イベントによって指定されたメッセージを非表示にしてもよい(MAY)。
例えば、3人のユーザがあるメッセージを「ポルノ」という単語を含む理由で非表示にしたら、iOSアプリのnostrクライアントは全クライアントからそのメッセージを隠す選択をしてもよい
Kind 44: ユーザのミュート
特定のユーザからのメッセージを隠す。
contentにはreasonのようなメタデータを含めてもよい(任意)。
クライアントは、ユーザが発行したミュートイベントによって指定された公開鍵に対応するユーザからのメッセージ(kind 42)を非表示にすべき(SHOULD)。
クライアントは、他のユーザのミュートイベントに基づきメッセージを非表示にしてもよい(MAY)。
NIP-10 リレー推薦(relay recommendations)について
クライアントは、基本的には元の(最古の)チャンネル作成イベントが送信されたリレーを使うべき(SHOULD)。
クライアントは任意のリレーURLを推奨してよい(MAY)。例えば、元のチャンネル作成イベントの送信先リレーが落ちたら、バックアップリレー・クライアントが元のリレー以上に信頼を置いているリレーなどからチャンネルデータを取得することができる。
他のリレーの推薦をkind 41のeタグを使ってやる、という理解でいい?jiftechnify.icon
将来の拡張
kind 45-49を、新しい種類のメディア(画像・動画)、モデレーション、プライベートまたはグループメッセージングのサポートなどのチャット関係の追加イベント用に予約している。
動機
ソーシャルメディアのために検閲耐性を持つコミュニケーション手段を作るという問題を解決しようとするのであれば、同じ問題をTelegram式のメッセージングのために解決しようとしてもいいはず。
グローバルな会話を、壁に囲まれた庭から全ての人に開かれた真にパブリックな広場に持ち込めるはずだ。