NIPs

NIPsは、Nostr Implementation Possibilitiesの略称である。

本文書は、Nostr互換のリレーおよびクライアントソフトウェアによって実装されうるものを文書化するために存在している。

仕様一覧
イベント種別(kind)
メッセージ型
- クライアントからリレーへ
- リレーからクライアントへ
標準化済みタグ
NIPsの受け入れ基準
このリポジトリは中央集権的な要素ではありませんか？
このリポジトリの仕組み
破壊的変更
ライセンス

仕様一覧

Event Kinds

kind	description	NIP
`0`	メタデータ	01
`1`	短文ノート	01
`2`	推奨リレー	01 (deprecated)
`3`	フォロー	02
`4`	暗号化されたダイレクトメッセージ	04
`5`	削除イベント	09
`6`	リポスト	18
`7`	リアクション	25
`8`	バッジ・表彰	58
`9`	Group Chat Message	29
`10`	Group Chat Threaded Reply	29
`11`	Group Thread	29
`12`	Group Thread Reply	29
`13`	Seal	59
`16`	汎用リポスト	18
`40`	チャンネル作成	28
`41`	チャンネルメタデータ	28
`42`	チャンネルメッセージ	28
`43`	チャンネル投稿ミュート	28
`44`	チャンネルユーザミュート	28
`1021`	Bid	15
`1022`	Bid confirmation	15
`1040`	OpenTimestamps	03
`1059`	Gift Wrap	59
`1063`	ファイルメタデータ	94
`1311`	ライブチャットメッセージ	53
`1617`	Patches	34
`1621`	Issues	34
`1622`	Replies	34
`1971`	問題トラッカー	nostrocket
`1984`	通報	56
`1985`	ラベル	32
`4550`	コミュニティ投稿の承認	72
`5000`-`5999`	ジョブ要求	90
`6000`-`6999`	ジョブ結果	90
`7000`	ジョブフィードバック	90
`9000`-`9030`	Group Control Events	29
`9041`	Zap Goal	75
`9734`	Zap要求	57
`9735`	Zap	57
`9802`	ハイライト	84
`10000`	ミュートリスト	51
`10001`	ピン留めリスト	51
`10002`	リレーリストメタデータ	65
`10003`	ブックマークリスト	51
`10004`	コミュニティリスト	51
`10005`	パブリックチャットリスト	51
`10006`	ブロック済みリレーリスト	51
`10007`	検索リレーリスト	51
`10009`	User groups	51, 29
`10015`	興味・関心リスト	51
`10030`	ユーザー絵文字リスト	51
`10096`	ファイルストレージサーバーリスト	96
`13194`	ウォレット情報	47
`21000`	Lightning Pub RPC	Lightning.Pub
`22242`	クライアント認証	42
`23194`	ウォレット要求	47
`23195`	ウォレット応答	47
`24133`	Nostr Connect	46
`27235`	HTTP認証	98
`30000`	フォローセット	51
`30001`	汎用リスト	51
`30002`	リレーセット	51
`30003`	ブックマークセット	51
`30004`	キュレーションセット	51
`30008`	プロフィールバッジ	58
`30009`	バッジ定義	58
`30015`	興味・関心セット	51
`30017`	Create or update a stall	15
`30018`	Create or update a product	15
`30019`	Marketplace UI/UX	15
`30020`	Product sold as an auction	15
`30023`	長文投稿	23
`30024`	長文投稿の下書き	23
`30030`	絵文字セット	51
`30063`	Release artifact sets	51
`30078`	アプリケーション固有データ	78
`30311`	ライブイベント	53
`30315`	ユーザーステータス	38
`30402`	Classified Listing	99
`30403`	Draft Classified Listing	99
`30617`	Repository announcements	34
`31922`	日付指定のカレンダーイベント	52
`31923`	時刻指定のカレンダーイベント	52
`31924`	カレンダー	52
`31925`	要返信のカレンダーイベント	52
`31989`	推奨ハンドラ	89
`31990`	ハンドラ情報	89
`34550`	Community Definition	72
`39000-9`	Group metadata events	29

メッセージ型

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

type	説明	NIP
`EVENT`	イベントの配信	01
`REQ`	イベントの要求と新規更新の購読	01
`CLOSE`	既存の購読の中止	01
`AUTH`	認証イベント	42
`COUNT`	イベント計数要求	45

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

type	description	NIP
`EOSE`	クライアントへのすべての保存済みイベントの送信完了通知	01
`EVENT`	クライアントから要求されたイベントの送信	01
`NOTICE`	クライアントへの人間可読なメッセージ	01
`OK`	クライアントへのイベント配信成功通知	01
`CLOSED`	クライアントへの購読終了とその理由の通知	01
`AUTH`	認証チャレンジの送信	42
`COUNT`	要求されたイベントの計数結果	45

新しいイベント種別(kind)を含むNIPsを提案する場合は、これらのリストも更新すること。

標準化済みタグ

タグ名	値	その他パラメータ	NIP
`e`	イベントID (hex)	relay URL, marker	01, 10
`p`	公開鍵 (hex)	relay URL, petname	01, 02
`a`	coordinates to an event	relay URL	01
`d`	識別子	--	01
`g`	ジオハッシュ	--	52
`i`	アイデンティティ	proof	39
`k`	種別(kind)番号 (string)	--	18, 25, 72
`l`	ラベル, ラベル名前空間	annotations	32
`L`	ラベル名前空間	--	32
`m`	MIME type	--	94
`q`	イベントID (hex)	relay URL	18
`r`	参照 (URL, etc)	petname
`r`	リレーURL	marker	65
`t`	ハッシュタグ	--
`alt`	概要	--	31
`amount`	文字列化されたミリサトシ	--	57
`bolt11`	`bolt11` invoice	--	57
`challenge`	チャレンジ文字列	--	42
`client`	名前, アドレス	relay URL	89
`clone`	git clone URL	--	34
`content-warning`	理由	--	36
`delegation`	公開鍵, 条件, 委任トークン	--	26
`description`	インボイス/バッジの説明	--	34, 57, 58
`emoji`	ショートコード, 画像 URL	--	30
`encrypted`	--	--	90
`expiration`	unix timestamp (string)	--	40
`goal`	イベントID (hex)	relay URL	75
`image`	画像URL	dimensions in pixels	23, 58
`imeta`	インラインメタデータ	--	92
`lnurl`	`bech32` encoded `lnurl`	--	57
`location`	場所文字列	--	52, 99
`name`	名前	--	34, 58
`nonce`	乱数	--	13
`preimage`	`bolt11` インボイスのハッシュ	--	57
`price`	値段	currency, frequency	99
`proxy`	外部ID	protocol	48
`published_at`	unix timestamp (string)	--	23
`relay`	リレーURL	--	42
`relays`	リレーリスト	--	57
`server`	ファイルストレージサーバーURL	--	96
`subject`	件名	--	14
`summary`	記事の要約	--	23
`thumb`	バッジサムネイル	dimensions in pixels	58
`title`	記事のタイトル	--	23
`web`	webpage URL	--	34
`zap`	公開鍵 (hex), リレー URL	weight	57

NIPsの受け入れ基準

(適用可能であれば)少なくとも2つのクライアントと1つのリレーが実装しているべきである。
理にかなっている必要がある。
任意に実装可能であり、後方互換性を有するべきである: 実装しないことを選択したクライアントやリレーが、実装することを選択したクライアントやリレーと通信した際に動作を停止しないよう厳に注意しなければならない。
同じことする方法が複数あってはならない。
その他のルールは必要に応じて作成する。

このリポジトリは中央集権的な要素ではありませんか？

To promote interoperability, we standards that everybody can follow, and we need them to define a single way of doing each thing without ever hurting backwards-compatibility, and for that purpose there is no way around getting everybody to agree on the same thing and keep a centralized index of these standards. However the fact that such index exists doesn't hurt the decentralization of Nostr. At any point the central index can be challenged if it is failing to fulfill the needs of the protocol and it can migrate to other places and be maintained by other people.

It can even fork into multiple and then some clients would go one way, others would go another way, and some clients would adhere to both competing standards. This would hurt the simplicity, openness and interoperability of Nostr a little, but everything would still work in the short term.

There is a list of notable Nostr software developers who have commit access to this repository, but that exists mostly for practical reasons, as by the nature of the thing we're dealing with the repository owner can revoke membership and rewrite history as they want -- and if these actions are unjustified or perceived as bad or evil the community must react.

このリポジトリの仕組み

Standards may emerge in two ways: the first way is that someone starts doing something, then others copy it; the second way is that someone has an idea of a new standard that could benefit multiple clients and the protocol in general without breaking backwards-compatibility and the principle of having a single way of doing things, then they write that idea and submit it to this repository, other interested parties read it and give their feedback, then once most people reasonably agree we codify that in a NIP which client and relay developers that are interested in the feature can proceed to implement.

These two ways of standardizing things are supported by this repository. Although the second is preferred, an effort will be made to codify standards emerged outside this repository into NIPs that can be later referenced and easily understood and implemented by others -- but obviously as in any human system discretion may be applied when standards are considered harmful.

破壊的変更

Breaking Changes

ライセンス

All NIPs are public domain.

Name		Name	Last commit message	Last commit date
Latest commit History 1,208 Commits
.github		.github
.husky		.husky
.gitignore		.gitignore
.textlintignore		.textlintignore
.textlintrc.json		.textlintrc.json
01.md		01.md
02.md		02.md
03.md		03.md
04.md		04.md
05.md		05.md
06.md		06.md
07.md		07.md
08.md		08.md
09.md		09.md
10.md		10.md
11.md		11.md
12.md		12.md
13.md		13.md
14.md		14.md
15.md		15.md
16.md		16.md
18.md		18.md
19.md		19.md
20.md		20.md
21.md		21.md
23.md		23.md
24.md		24.md
25.md		25.md
26.md		26.md
27.md		27.md
28.md		28.md
29.md		29.md
30.md		30.md
31.md		31.md
32.md		32.md
33.md		33.md
34.md		34.md
36.md		36.md
38.md		38.md
39.md		39.md
40.md		40.md
42.md		42.md
44.md		44.md
45.md		45.md
46.md		46.md
47.md		47.md
48.md		48.md
49.md		49.md
50.md		50.md
51.md		51.md
52.md		52.md
53.md		53.md
56.md		56.md
57.md		57.md
58.md		58.md
59.md		59.md
65.md		65.md
72.md		72.md
75.md		75.md
78.md		78.md
84.md		84.md
89.md		89.md
90.md		90.md
92.md		92.md
94.md		94.md
96.md		96.md
98.md		98.md
99.md		99.md
BREAKING.md		BREAKING.md
CONTRIBUTING.md		CONTRIBUTING.md
README.md		README.md
package-lock.json		package-lock.json
package.json		package.json

nostr-jp/nips-ja

Folders and files

Latest commit

History