对比
nostrfy vs strfry
两者都是单二进制的 Nostr 中继，将事件存储在 LMDB 中并使用相同的协议。它们做出了不同的权衡： strfry 是成熟的 C++ 中继，拥有写入策略插件系统；而 nostrfy 是用 Rust 编写的引擎，将运营者所需的功能 — 群组、媒体、REST、管理 — 打包在一个二进制文件和一个配置文件中。
一览
| nostrfy | strfry | |
|---|---|---|
| 语言 | Rust | C++ |
| 许可 | MIT OR Apache-2.0 | GPL-3.0 |
| 存储 | LMDB（无需外部数据库） | LMDB（无需外部数据库） |
| 配置 | 单个 nostrfy.toml，热重载（SIGHUP） | strfry.conf，热重载 |
| 公布的 NIP | 34 个（实现 36 个，含可选） | 11 个核心 NIP |
| NIP-29 群组 + LiveKit | 内置 | — |
| Blossom 媒体服务器 | 内置（本地磁盘或 S3/R2） | — |
| REST API | 内置 /api/v1 | — |
| 管理 API | NIP-86 JSON-RPC，可委派管理员 | — |
| Negentropy（NIP-77） | 支持 | 支持 — strfry 是它的发源地 |
| 写入策略 / 插件 | 内置白名单/黑名单 + NIP-86 | 写入策略插件接口 |
| 迁移工具 | nostrfy migrate-strfry | strfry import / export / sync |
许可
strfry 采用 GPL-3.0 许可，要求衍生作品以相同条款发布。 nostrfy 采用 MIT 或 Apache-2.0 双许可，因此可以嵌入闭源产品并自由重新许可。 如果你的中继是商业或其他许可栈的一部分，这往往就是决定性差异。
配置与运维
- nostrfy 由单个带完整注释的
nostrfy.toml配置：身份、限制、存储、访问控制、Blossom 和 RPC 集中在一处。大部分设置在 SIGHUP 时热重载。 - 每个选项都会在中继启动前由
nostrfy check验证 — 错误的类型、不可能的限制和锁定组合都会连同修复建议一起报告。 - 守护进程自带日志轮转、实时统计、健康端点和 Prometheus 指标；CLI 管理访问列表、升级和迁移。
内置功能
nostrfy 无需外挂附属服务，而是内置了公共中继通常需要的服务：
NIP-29 群组 + LiveKit
中继强制的群组、管理事件和中继签名的群组元数据，外加通过 LiveKit 的音视频房间。
Blossom 媒体服务器
内容寻址的上传运行在独立主机名上，支持本地磁盘或 S3 兼容存储桶（AWS S3、Cloudflare R2）。
REST API
只读 /api/v1 运行在自己的读取线程上 — 可按 npub、nevent 或 naddr 查询事件，支持计数、统计和搜索。
NIP-86 管理
JSON-RPC 管理 API，支持 Bearer 或 NIP-98 认证、委派方法授权和邀请码。
strfry 的优势
strfry 仍然是极佳的选择：它开创了 negentropy 协议，支持零停机重启和可选的 WebSocket 压缩， 其写入策略插件接口让你能在每次发布时运行任意逻辑。如果你需要插件沙箱，而不需要这份清单上的其他功能， strfry 非常合适。如果你更希望在开箱即用的方案里拥有群组、媒体、REST 和管理 — 或者需要宽松许可 — nostrfy 是更短的路。
从 strfry 迁移
你不必从头开始。nostrfy migrate-strfry 读取 strfry 自己的导出格式，验证每一个事件，并导入整个数据库 — 包括 NIP-09 删除、NIP-29 管理副作用和
首次出现时间戳。它是离线的、支持 dry-run，且可安全重复。