这是Nostr协议的高级概述,详细介绍了事件(Event
)类型以及NIPs(Nostr Implementation Possibilities,Nostr实施标准)的工作原理。
Nostr的顶层设计
- Nostr有两个重要组件:客户端和中继器。
- 客户端是用户从中继器读取和写入信息的操作界面。在社交媒体环境中,可以将其理解为推特的网页端或者它的手机App。这种客户端的作用就是允许你从推特的中心化服务器中读取或写入数据。
- 中继器类似数据库(尽管它们除了存储数据还有很多其他功能)。它们接收客户端发送的数据并将数据存储在数据库中。其他客户端再从中继器中取出数据并展示给用户。
- 每一个用户都被标识为公钥。每一个事件(发送推文、更新关注列表等其他操作)都需要签名。客户端验证签名,确保其正确无误。
- 客户端从中继器抓取信息,并把信息推送给中继器。大部分时候,用户自己选择使用哪些中继器。中继器之间不需要相互通信,但以后或许会。
- 举个例子,在用户更新账户信息时,只需要让客户端发送类别(
kind
)为0的事件给他正在使用的中继器。中继器会存储这个事件。 - 当客户端启动时,它会从用户正在使用的中继器查询数据。客户端可以筛选并只显示关注用户的事件,或者显示所有用户的事件。
- 事件种类很多。事件里包含各种类型的结构化数据。最常用的数据结构通过NIPs定义,所有客户端和中继器都应当全方位用此标准处理数据。
- 用户在Nostr上看到的数据完全取决于所连接的中继器。下面的列表详细展示了Nostr的网络结构。
Nostr网络结构
上面的图表中包含3个中继器(Relay)和3个用户(Client)。图中每一位用户使用的客户端都不相同(也不在同一个平台)。
图表中的读、写情况如下:
- Bob可以看到Alice的所有推文,但无法看到Mary的任何推文(Bob甚至不知道Mary的存在)。
- Alice可以看到Bob的所有推文,但无法看到Mary的任何推文(Alice也不知道Mary的存在)。
- Mary可以看到Bob和Alice的推文。因为Mary只向中继器3写入数据,她可以从中继器2(保存Bob和Alice的数据)读取数据。
上图是一种非常简化的情况,但你仍然能从中看出,如何选择中继器对能查看谁的信息有非常大的影响。
事件(Events)
事件是Nostr上唯一的Object
结构。每一个事件结构都有一个类别(kind
)。类别用来标记事件的种类(用户实施了哪种操作或者接收了哪种信息)。
下面是kind
为1的某个事件(kind为1,代表短的文字信息,类似推特的推文)。
{
"id": "4376c65d2f232afbe9b882a35baa4f6fe8667c4e684749af565f981833ed6a65",
"pubkey": "6e468422dfb74a5738702a8823b9b28168abab8655faacb6853cd0ee15deee93",
"created_at": 1673347337,
"kind": 1,
"tags": [
["e", "3da979448d9ba263864c4d6f14984c423a3838364ec255f03c7904b1ae77f206"],
["p", "bf2376e17ba4ec269d10fcc996a4746b451152be9031fa48e74553dde5526bce"]
],
"content": "围墙的花园变成了监狱,nostr是拆掉监狱围墙的第一步",
"sig": "908a15e46fb4d8675bab026fc230a0e3542bfade63da02d542fb78b2a8513fcd0092619a2c8c1221e581946e0191f2af505dfdf8657a414dbca329186f009262"
}
<id>
代表事件的ID。<pubkey>
代表发送此事件用户的公钥。<created_at>
代表该事件创建的时间。<kind>
代表事件的类别。<tags>
代表事件的标签。这通常用于创建链接、添加媒体,或者提到其他用户或其他事件。<content>
代表事件的内容。在上面的例子里,表示短推文的内容。<sig>
代表签名。客户端用此验证该事件确实由拥有该公钥的用户所发出。
事件类别
下面是目前事件的类别列表。最新的类别列表可以在Nostr NIPs repository找到。
kind | 描述 | NIP |
0 | Metadata | 1, 5 |
1 | Short Text Note | 1 |
2 | Recommend Relay | 1 |
3 | Contacts | 2 |
4 | Encrypted Direct Messages | 4 |
5 | Event Deletion | 9 |
7 | Reaction | 25 |
8 | Badge Award | 58 |
40 | Channel Creation | 28 |
41 | Channel Metadata | 28 |
42 | Channel Message | 28 |
43 | Channel Hide Message | 28 |
44 | Channel Mute User | 28 |
45-49 | Public Chat Reserved | 28 |
1984 | Reporting | 56 |
9734 | Zap Request | 57 |
9735 | Zap | 57 |
10002 | Relay List Metadata | 65 |
22242 | Client Authentication | 42 |
24133 | Nostr Connect | 46 |
30023 | Long-form Content | 23 |
1000-9999 | Regular Events | 16 |
10000-19999 | Replaceable Events | 16 |
20000-29999 | Ephemeral Events | 16 |
30000-39999 | Parameterized Replaceable Events | 33 |
30008 | Profile Badges | 58 |
NIPs
Nostr实施标准(A Nostr Implementation Possibilty, 简称NIP),用来规范兼容Nostr的中继器和客户端软件,哪些必须、哪些应当、哪些可以实施。NIP是概述Nostr协议工作原理的参考文档。
我为什么要关心NIPs?
Nostr是一种去中心化协议,并不被某一个中心化机构所垄断(比如推特)。这意味着协议的发展方向取决于我们所有人!我们可以建议和倡导变革,并对他人提供的想法提供反馈。
作为社区的积极成员,大家对Nostr网络的后续发展方向都有一定的话语权。主代码库中的NIPs已经通过,可以通过pull request添加新的想法。