比較
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，且可安全重複。