Nostr

平台 · 详解依据官方 页面编写，包括平台自身与辅助服务的页面。

另请参阅：如何阅读卡片 и 关于来源与方法.

概述

Nostr 不是平台，而是一种协议。名称的全称是 Notes and Other Stuff Transmitted by Relays——«通过中继传输的笔记及其他内容»。 网站 nostr.com 这样描述它： «一个无人拥有、也无人控制的自由开放网络»。

它的构造很简单，其余一切都建立在此之上。有中继—— 存储并分发消息的服务器。有客户端—— 人们借以阅读和写作的应用。还有密钥： 公钥的作用相当于用户名，私钥相当于密码；正是密钥而非某家公司， 赋予你对自身身份的权利。由于身份属于密钥 而不属于应用，你可以在不同客户端之间迁移，同时保留 资料、粉丝和发布内容。

从技术上看，一切都归结为一种对象类型。协议的基础文档 写道：唯一存在的对象类型就是«事件» (event)，签名与密钥使用 secp256k1 曲线上的 Schnorr 方案， 中继对外暴露一个 websocket 端点，客户端向其发送三类 消息：EVENT 用于发布，REQ 用于订阅某个查询， CLOSE 用于 关闭订阅。

对本手册而言，这意味着：Nostr 没有所有者、没有统一的 受众、没有广告后台、没有审核规则，也没有分成计划。 下文将说明取而代之的是什么。

这里有谁

Nostr 的受众数字并不存在——按通常的理解也不可能存在。 不存在一台会统计用户的中心服务器：有的是众多互相独立的中继， 每一个都只看得到自己那部分人。

只能通过具体的中继间接判断。nostr.com 上的客户端 默认连接六个中继，并把它们的列表直接显示在界面里： relay.nostr.com、relay.damus.io、nos.lol、 nostr.bitcoiner.social、nostr.mom 和 relay.snort.social。 中继目录，项目建议在第三方服务 Nostr.watch 上查看；客户端目录则在 nostrapps.com （关于中继的页面、 关于客户端的页面）。

语言和国别的分布没有，也不可能有：协议并不保存 用户的这类信息。资料页默认只包含 名称、简介和图片。

如何开始

通常意义上的注册不存在：账号就是一对密钥， 由应用生成。既不需要邮箱确认，也不需要电话号码， 更没有申请审核。

由此产生了项目自己提醒的主要风险： 私钥赋予对账号的完全访问权——持有它就能以你的名义发布、 修改资料、发送消息；如果密钥丢失且没有备份， 就不存在«忘记密码»这个 按钮。项目给出的实用建议是： 不要把私钥挨个粘贴进每一个应用——更安全的做法是使用 浏览器签名扩展或远程 签名器。

类似«蓝勾»的可验证名称是可以获得的：协议的一份单独 文档描述了把密钥绑定到域名的做法。客户端 从资料页取出形如 名称@域名 的地址，请求 https://域名/.well-known/nostr.json?name=名称，并把取回的 公钥与该条内容作者的密钥 比对。 对企业而言，这正是证明账号确实属于自己的方式： 确认来自对域名的控制权，而非审核人员的裁定。

没有单独的企业账号——因为连普通账号也不存在。 企业在 Nostr 的存在，就是一把绑定到自家域名的密钥， 以及（如果愿意的话）一个自建中继。

可以发布什么

格式由事件的«种类»决定，而种类写在单独的 文档里——NIP (Nostr Implementation Possibilities)。它们的清单 维护在公开仓库中，其中包括：短笔记 和讨论串、长文、图片和视频、 直播和«空间»、投票、日历事件、维基、种子、 列表、书签和引用 （NIP 清单）。

协议本身没有长度和体积限制——限制来自中继， 而且中继必须把它们声明出来。关于中继信息的文档描述了 这些字段：max_message_length——传入 JSON 的字节上限 （实际上也就限制了事件的大小），max_content_length—— 内容字段中的字符数上限，max_event_tags—— 标签数上限，max_subscriptions——同一连接上并发 订阅的数量，max_limit——单次请求响应中 事件数量的上限。

实际情况是这样。核对当日，中继 relay.damus.io 声明消息上限 1 000 000 字节、200 个订阅、查询上限 500 条事件；中继 nos.lol 是 131 072 字节、20 个订阅、同样 500 条事件； 中继 relay.nostr.com 是 131 072 字节、200 个订阅、500 条事件。这些数字分别属于各个中继， 换一个中继就会不同。

协议对内容没有禁令。有的是技术性标注： 一份单独的文档描述了敏感内容标记， 另一份描述对事件的举报，第三份描述 删除请求。 请注意«请求»一词：在 Nostr 里，删除是向中继提出的请求， 而不是保证。具体接收和保存什么，由中继的 所有者决定。

如何增长

协议中没有算法推荐流。给用户展示什么由客户端决定， 交出哪些事件则由中继决定。nostr.com 上的客户端 把这一点直接呈现出来：它的界面里有«关注»、 «全局»和«自己»三种信息流选项，下方是已连接 中继的列表。

由此得出项目自己解释过的一个实际结论：如果 Nostr 看起来很慢或很空，原因可能在中继；部分 中继快速可靠，部分会掉线且不响应，加入 几个好的中继会带来很大改变。 在 Nostr 里增长，首先意味着把内容发布到那些 确实有读者的中继上。

广告后台并不存在：协议既没有出售展示量的平台， 也没有统计展示量的机制。内置 统计同样没有；最接近的是 COUNT 请求，中继 会尽力执行，且结果是近似的。

协议提出的反垃圾手段颇为特别：关于 工作量证明的文档允许中继要求新事件完成 指定的计算难度。 第二种手段是钱：一部分中继是付费的，这降低了垃圾信息， 因为维护中继需要花钱，而用户也就有了 守规矩的理由。

变现路径

没有平台，也就没有来自平台的分成。但存在人与人之间的 直接支付，而且它们写在协议本身之中。

这一机制叫作«zap»——通过 Lightning 网络的支付。 协议文档引入了两类事件：9734——zap 请求， 即付款人向收款人的钱包索取账单， 9735——收据，即收款人钱包确认账单 已支付。 流程是这样的：客户端从收款人资料页取出其支付 端点地址，确认它支持 Nostr，向其发送 签名后的请求并取得账单；支付完成后钱包发布 收据。 收据的意义也在同一处解释：它让客户端可以把 支付直接显示在信息流里——出于乐趣，或作为反垃圾 手段。

这套方案里没有平台抽成——钱从钱包直接到钱包。 但同样也没有平台的保障：支付的送达由 Lightning 网络和你选择的钱包服务商负责。

除 zap 之外，协议清单还包含其他资金机制： 募集目标 (zap goals)、徽章、Cashu 钱包和«nutzap»、远程 连接钱包，以及人与人之间的订单 事件。 其中每一项都由客户端自愿实现。

工具与自动化

Nostr 没有«官方 API»，原因与它没有所有者一样： 协议本身就是接口。任何程序都可以 向中继打开 websocket 并直接与之交互 （基础文档）。 开发者密钥、访问申请和应用审核都 不存在。

在动手搭建服务之前，值得读一读清单本身给出的 提醒：«这里的 NIP 不是协议的检查表。没有任何东西 强迫任何程序实现某个 NIP。每个 应用自行选择完成其任务所需的 子集»。 这意味着，不能仅因为某项功能被写进文档就指望它存在： 需要核实具体的中继是否支持它。 核实的方式是有的：中继通过 HTTP 提供一份文档， 其中列出所支持的 NIP、程序名称、版本、联系方式 以及自身服务条款的 链接。 上面提到的三个中继声明了相同的组合：三者都运行 strfry 程序，支持 NIP 1、2、4、9、11、28、40、45、 70 和 77。

在现成工具方面，项目提到了用于签名的浏览器扩展 和远程签名器，以及 自家的签名器 Pomegranate。 客户端与中继的目录维护在协议之外——在 nostrapps.com 和 Nostr.watch 上（关于客户端的页面、 关于中继的页面）。

限制与规则

• 没有统一规则。 不存在任何一份对网络中所有参与者 作出禁止性规定的文档。规则由中继所有者制定； 协议只是规定了 在中继信息中给出服务条款 链接。
• 限额由中继设定并自行声明：消息大小、 内容长度、标签数量、订阅数量、查询 上限。
• 中继可以要求按认证协议登录 或对新事件提供工作量 证明。
• 删除没有保证：文档描述的正是«删除 请求»， 执行与否由各个中继自行决定。
• 密钥丢失不可逆。 不存在找回 访问权的办法。
• 网络没有法律框架。 责任由中继所有者 和作者承担；协议不存在一个可以与之签约的 法人实体。NIP 清单本身发布在仓库中， 未注明许可证。

适合谁

适合那些看重不依赖平台所有者的项目：身份属于 密钥，而不属于某家 公司，账号无法被集中封禁， 对某个中继不满意时换一个中继即可。 也适合开发者：接入网络既不需要应用 密钥，也不需要批准。

适合与比特币和 Lightning 相关的项目：支付 以 zap 的形式内置于协议， 这也是其资金机制中最成熟的部分。

如果你需要可预期的触达和报表，就不合适： 这里没有什么可衡量的——既没有平台，也没有统计，更没有广告 后台。也不适合大规模群发和«推广»：中继 有权要求付费、登录或工作量证明，并可以不作任何说明 就切断你。如果机构内部要求与服务提供方 签订合同，同样不合适：协议不存在这样的一方。

来自事实库的已核实数据

本详解所依据的已核实数据摘要。

平台简介

平台如此自述：«Nostr is a free and open-source protocol for social media and other things - controlled by users, not platforms.»

自述：这是平台对自身的表述，不是独立评价

来源, 已核查 2026-07-28

Nostr（Notes and Other Stuff Transmitted by Relays）被描述为无人拥有、无人控制的自由开放网络；中继存储并分发消息，客户端提供读写

这是协议而非平台：没有所有者、广告后台和报酬计划

来源, 已核查 2026-07-28

唯一的对象类型是事件（event）；签名和密钥采用 secp256k1 曲线上的 Schnorr 方案；中继开放 websocket 端点，客户端发 EVENT 发布、REQ 订阅、CLOSE 关闭订阅

协议基础文档 NIP-01

来源, 已核查 2026-07-28

从何开始

nostr 的准入没有单一的规则制定者：«Nostr (Notes and Other Stuff Transmitted by Relays) is a free and open network that nobody owns or controls»；协议提案汇编对自身也作同样说明：«NIPs listed here are not a protocol checklist. Nothing forces any software to implement any NIP»

引文逐字摘录，来源语言为英语。第二条出自 NIP 汇编的 README：https://raw.githubusercontent.com/nostr-protocol/nips/master/README.md。对读者的实际结论：不存在对全网都强制的统一准入条件；条件由每个中继和每个应用各自设定，且各不相同

来源, 已核查 2026-08-07

中继有权关闭写入、要求签名登录或工作量证明：NIP-11 限制清单中列有 «auth_required»、«restricted_writes»、«min_pow_difficulty»、«payment_required»；«Your client should expect that requests exceed these practical limitations are rejected or fail immediately»

引文逐字摘录，来源语言为英语，保留原文拼写。协议层面没有申请、邀请和审核；上述都是单个中继的属性，可通过向中继请求其信息文档获知

来源, 已核查 2026-08-07

账号与访问

账号是一对密钥，而不是平台所有者那里的一条记录：«Every account has Nostr keys. Your public key is like your username and can be shared with anyone. Your private key is like your password and must be kept safe. These keys give you ownership of your identity, rather than a company owning it for you»

引文逐字摘录，来源语言为英语。获取密钥不需要注册、身份确认或审批：密钥对在设备上生成。形如 名称@域名 的可验证名称是可选项，由单独的 NIP-05 描述

来源, 已核查 2026-08-07

账号是一对密钥：公钥相当于用户名，私钥相当于密码；身份属于密钥而非应用，因此可以更换客户端而保留资料和关注者

没有注册、邮箱确认和申请审核

来源, 已核查 2026-07-28

私钥丢失且没有备份时无法恢复访问：不存在“忘记密码”按钮

项目建议不要把私钥填进每个应用，而是使用签名扩展或远程签名器

来源, 已核查 2026-07-28

形如 名称@域名 的可验证名称：客户端请求 https://域名/.well-known/nostr.json?name=名称 并将得到的公钥与帖子作者的公钥比对

对公司而言，这是靠掌控域名而非靠版主决定来确认账号的方式

来源, 已核查 2026-07-28

可以发布什么

NIP 清单描述的内容包括：短笔记和会话串、长文、图片和视频、直播和语音空间、投票、日历事件、维基、种子、列表、书签和引用

NIP 清单不是义务：没有什么能强制软件实现任何一个 NIP

来源, 已核查 2026-07-28

这里的资金规则

接受谁。 打赏没有关注者、观看量或发帖数门槛：zap 经 Lightning 网络在人与人之间直接进行，唯一条件是接收方有带 lnurl 地址的钱包——«Client calculates a recipient's lnurl pay request url from the zap tag on the event being zapped, or by decoding their lud16 field on their profile»

引文逐字摘录，来源语言为英语。门槛为零：NIP-57 既不要求关注者数，也不要求观看时长或账号存续期。金额上下限由接收方钱包的 «minSendable» 和 «maxSendable» 字段设定，而不是由网络设定

来源, 已核查 2026-08-07

网络没有佣金，也没有能收佣金的主体：资金绕过协议、经接收方钱包流转，nostr 不参与结算——NIP-57 只描述两类事件，打赏请求记录和收据记录：«9734 is a zap request… 9735 is a zap receipt, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a zap request has been paid»

引文逐字摘录，来源语言为英语。钱包或 Lightning 网络节点可能收自己的手续费——那已经不是 nostr，其数额 NIP-57 未规定。网络没有佣金、分成和提现门槛，因为不存在替人保管资金的中间方

来源, 已核查 2026-08-07

协议把人与人之间的支付描述为经 Lightning 网络的 zap 打赏：事件 9734 是打赏请求，事件 9735 是接收方钱包对账单已付的收据

方案中没有平台佣金：资金从钱包直达钱包；送达责任在 Lightning 网络和钱包服务商

来源, 已核查 2026-07-28

NIP 清单还包含募集目标（zap goals）、徽章、Cashu 钱包和 nutzap、远程钱包连接，以及人与人之间的订单事件

每种机制由客户端自愿实现

来源, 已核查 2026-07-28

价格

协议不收钱，但单个中继可以收：NIP-11 为收费预留了字段——«Relays that require payments may want to expose their fee schedules»：«fees»：«admission»（准入费）、«subscription»（订阅，含 «period» 字段）、«publication»（发布费，注明事件类型）；中继限制清单中有 «payment_required» 标志

引文逐字摘录，来源语言为英语。数字由每个中继自行设定，因此全网没有统一的准入价格。NIP-11 文档中作为 nostr.wine 中继响应样例给出的例子：«fees»: «admission»: ({«amount»: 18888000, «unit»: «msats»})——这是文档样例中该中继的声明，不是我们的计算，也不是对当前价格的承诺

来源, 已核查 2026-08-07

限制与上限

中继在信息文档中声明自身限制：max_message_length（传入 JSON 的大小）、max_content_length（内容字段的字符数）、max_event_tags、max_subscriptions、max_limit；还可能要求认证和工作量证明

NIP-11 文档；协议自身没有长度和大小限制

来源, 已核查 2026-07-28

截至核查日，中继 relay.damus.io 声明消息上限 1 000 000 字节、200 个并发订阅、单次查询上限 500 个事件；软件为 strfry

该数字属于这一个中继，别的中继数字不同

来源, 已核查 2026-07-28

中继 nos.lol 声明消息上限 131 072 字节、20 个订阅、单次查询上限 500 个事件

通过请求中继信息文档测得

来源, 已核查 2026-07-28

中继 relay.nostr.com 声明消息上限 131 072 字节、200 个订阅、单次查询上限 500 个事件；声明的 NIP 为 1、2、4、9、11、28、40、45、70、77

damus.io 和 nos.lol 声明的是同一组 NIP

来源, 已核查 2026-07-28

限制

没有统一规则：接受和存储什么由中继所有者决定；协议只是在中继信息中预留了服务条款链接

删除被描述为“删除请求”，执行并无保证

来源, 已核查 2026-07-28

反垃圾手段：中继可以要求指定难度的工作量证明或认证；部分中继收费，项目解释说这能减少垃圾信息

项目推荐 Nostr.watch 作为中继目录、nostrapps.com 作为客户端目录

来源, 已核查 2026-07-28

nostr.com 的机器人规则文件允许所有代理抓取全站

单独核实过

来源, 已核查 2026-07-28

法律

NIP 清单仓库发布时未指定许可证

协议没有可与之签约的法人实体

来源, 已核查 2026-07-28

API 访问

nostr.com 上的客户端默认连接六个中继：relay.nostr.com、relay.damus.io、nos.lol、nostr.bitcoiner.social、nostr.mom、relay.snort.social

清单可在界面中直接看到

来源, 已核查 2026-07-28

不存在单独的“官方 API”：接口就是协议本身，任何程序都可以向中继打开 websocket；开发者密钥和应用审核不存在

具体功能的支持情况需按中继信息文档核实

来源, 已核查 2026-07-28

语言

首页界面语言：en

语言取自标记属性，各语言版本取自 hreflang

来源, 已核查 2026-07-28

目录分区： 全部同类 另请参阅： 目录索引 · 排程服务对比 · 按场景选择 · 平台限制