Skip to content

erechorse/nips-ja

BranchesTags
 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1,134 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
 
 
30.md
30.md
 
 
31.md
31.md
 
 
32.md
32.md
 
 
33.md
33.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
 
 
CONTRIBUTING.md
CONTRIBUTING.md
 
 
README.md
README.md
 
 
package-lock.json
package-lock.json
 
 
package.json
package.json
 
 

Repository files navigation

NIPs

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

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

仕様一覧

イベント種別(kind)

kind 説明 NIP
0 メタデータ 01
1 短文ノート 01
2 推奨リレー 01 (廃止)
3 フォロー 02
4 暗号化されたダイレクトメッセージ 04
5 削除イベント 09
6 リポスト 18
7 リアクション 25
8 バッジ・表彰 58
16 汎用リポスト 18
40 チャンネル作成 28
41 チャンネルメタデータ 28
42 チャンネルメッセージ 28
43 チャンネル投稿ミュート 28
44 チャンネルユーザミュート 28
1021 Bid 15
1022 Bid confirmation 15
1040 OpenTimestamps 03
1063 ファイルメタデータ 94
1311 ライブチャットメッセージ 53
1971 問題トラッカー nostrocket
1984 通報 56
1985 ラベル 32
4550 コミュニティ投稿の承認 72
5000-5999 ジョブ要求 90
6000-6999 ジョブ結果 90
7000 ジョブフィードバック 90
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
10015 興味・関心リスト 51
10030 ユーザー絵文字リスト 51
13194 ウォレット情報 　 47
10096 ファイルストレージサーバーリスト 96
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
30078 アプリケーション固有データ 78
30311 ライブイベント 53
30315 ユーザーステータス 38
30402 Classified Listing 99
30403 Classified Listing 99
31922 日付指定のカレンダーイベント 52
31923 時刻指定のカレンダーイベント 52
31924 カレンダー 52
31925 要返信のカレンダーイベント 52
31989 推奨ハンドラ 89
31990 ハンドラ情報 89
34550 Community Definition 72

メッセージ型

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

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
r 参照 (URL, etc) petname
r リレーURL marker 65
t ハッシュタグ --
alt 概要 -- 31
amount 文字列化されたミリサトシ -- 57
bolt11 bolt11 インボイス -- 57
challenge チャレンジ文字列 -- 42
client 名前, アドレス relay URL 89
content-warning 理由 -- 36
delegation 公開鍵, 条件, 委任トークン -- 26
description インボイス/バッジの説明 -- 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 バッジの名前 -- 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
zap 公開鍵 (hex), リレー URL weight 57

NIPsの受け入れ基準

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

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

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.

License

All NIPs are public domain.

Contributors

About

No description, website, or topics provided.

Resources

Readme
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

No packages published

Languages

  • Shell 100.0%