NIP-01

Basic protocol flow description

/icons/hr.icon

基本的なプロトコルの流れの説明

仕様について

イベントと署名

code:_.json

{

// シリアライズされたイベントデータのSHA-256(32バイト)を小文字の16進数で表記したもの

"id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,

// 公開鍵(32バイト)を小文字の16進数で表記したもの

"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,

// UNIXタイムスタンプ（秒単位）

"created_at": <unix timestamp in seconds>,

// イベントの種類

"kind": <integer>,

// タグ

"tags": [

... // 他の種類のタグが後に追加される可能性がある

],

// 任意の文字列

"content": <arbitrary string>,

// シリアライズされたイベントデータのSHA-256（IDフィールドと同じ）に対する署名を16進数で表記したもの

"sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>

}

訳注:

16進数表記すると1文字あたり4ビットで、32バイトのデータは64文字でエンコードされる。そう考えると辻褄が合う

後のフィルターの説明でも64文字という記述がある

シリアライズするには、次の構造を持つUTF-8のJSONシリアライズされた文字列（空白文字や改行文字を含まない）を生成する。

code:_.json

[

0,

<pubkey, as a (lowercase) hex string>,

<created_at, as a number>,

<kind, as a number>,

<tags, as an array of arrays of non-null strings>,

<content, as a string>

]

タグ

各タグは、いくつかの規約を持つ任意の長さの文字列の配列。以下に例を示す:

code:tags.json

{

...,

"tags": [

...

],

...

}

このNIPは、すべてのイベントの種類にわたって同じ意味を持つ、3つの標準タグを定義する。以下の通り:

Kind(イベントの種類)

{name: <username>, about: <string>, picture: <url, string>}

the content is set to the text content of a note (anything the user wants to say)

パースを必要とするコンテンツ（MarkdownやHTML）を使うべきでない。クライアントもコンテンツをそのようにパースすべきでない。

さらに、実験を容易にし、リレー実装に柔軟性をもたらす、kindの範囲に関する慣習がある:

リレーはこれらのイベントをすべて保存する

古いものは破棄する

リレーはこれらのイベントを保存しない

古いものは破棄する

以上は慣習にすぎず、実際のリレー実装は異なることがある。

クライアントとリレーの通信

WebSocket接続は各リレーにつき1つだけ

クライアントはそれぞれのリレーに対し、1つを超えるWebSocket接続を行うべきではない

1つの接続上で数に限りなく購読が行えるため、クライアントはそうすべき

WebSocketステータスコードの意味

リレーがWebsocketをステータスコード4000でクローズした場合、クライアントは再接続するべきではない。

注: WebSocketのcloseコード4000は「私的用途向け」として予約されている範囲の番号。

クライアントからリレー: イベントの送信と購読の作成

クライアントは、これらの3種類のメッセージを送信できる。これはJSON文字列でなければならない。

["EVENT", イベントの内容]

イベントを投稿するときに使う

["REQ", 購読ID, フィルターのJSON]

購読IDは空でない、最大64文字の任意の文字列

フィルターに一致するイベントを自身のデータベースからクライアントに返すべき(SHOULD)

REQ受信後に届いたイベントで、フィルターに一致するものをクライアントに転送すべき

同じ購読IDで新しくREQが送られた場合、過去の購読を上書きするべき

["CLOSE", 購読ID]

購読を停止したいときに使う

フィルターは、購読にどのようなイベントが送信されるかを定めるJSONオブジェクトである。次の属性を持つことができる。

code:filter.json

{

// イベントのID、もしくは先頭部分（プレフィクス）

"ids": <a list of event ids or prefixes>,

// 公開鍵、もしくは先頭部分。イベントの公開鍵はこれらのどれかでなければならない。

"authors": <a list of pubkeys or prefixes, the pubkey of an event must be one of these>,

// イベントの種類の数字のリスト

"kinds": <a list of a kind numbers>,

// "e"タグで参照されたイベントIDのリスト

"#e": <a list of event ids that are referenced in an "e" tag>,

// "p"タグで参照された公開鍵のリスト

"#p": <a list of pubkeys that are referenced in a "p" tag>,

// UNIXタイムスタンプ（秒単位の整数値）。通過するには、イベントの created_at がこの値以上でなければならない。

"since": <an integer unix timestamp in seconds. Events must have a created_at >= to this to pass>,

// UNIXタイムスタンプ（秒単位の整数値）。通過するには、イベントの created_at がこの値以下でなければならない。

"until": <an integer unix timestamp in seconds. Events must have a created_at <= to this to pass>,

// 初回の問い合わせで返されるイベントの個数の上限

"limit": <maximum number of events to be returned in the initial query>

}

一つ以上の値を含むJSONの配列として表現される

条件一致したと見なすには、イベントの属性が・・・

イベントに含まれる値が、リストに含まれていなければならない

イベントの値と条件のリストで、共通するものが少なくとも一つはなければならない

これらの属性で購読で返されるイベントの期間を指定できる。

フィルターの属性を複数指定する場合

フィルター自体を複数指定する場合

リレーからクライアントへの通信

リレーは、これらの3種類のメッセージを送信できる。これはJSON文字列でなければならない。

["EVENT", <購読ID>, <イベントのJSON>]

クライアントが要求したイベントを送るために使う

クライアントが(REQメッセージを使って)前もって開始した購読に関連する購読IDと共に送信しなければならない(MUST)

["OK", <イベントID>, <true|false>, <メッセージ>]

クライアントから送られてきたイベントの受理または拒否を表す

["EOSE", <subscription_id>]

新しくリアルタイムに受信されたイベントの始まりを意味する

["NOTICE", <message>]

human-readable(人が読める)なエラーメッセージなどをクライアントに送るために使う

このNIPでは NOTICEをどのように送信すべきで、どのように解釈されるべきかを定義しない