English | 繁體中文
Cinderous (@cinderous/client + cinderous-relay)
Private, local-first sync and collaboration over Nostr — between your own devices and small teams.
Same wire format as Nostr. On top of it: one key per device, a Git-like sync layer, WebRTC P2P with relay fallback, and a relay you deploy to your own account in one click.
💡 Why Cinderous?
Nostr was designed for public broadcast: posts, follows, censorship resistance, and general-purpose relays that keep as much as they can. Local-first apps such as CinderSync and Cinder Coffice need the opposite: private data that moves only between devices you own, through a relay nobody has to trust.
Cinderous is not a fork of Nostr. Events are plain NIP-01; the client uses NIP-17 / 42 / 44 / 59 / 98 and the relay advertises NIP-01 / 11 / 13 / 40 / 42 / 62. What changes is the purpose, and the layers added on top (ADR 0065):
| Typical Nostr | Cinderous |
|---|
| Purpose | Public broadcast | Private sync and collaboration between your devices and small teams |
| Relay | General-purpose public store | Your own relay (one-click deploy to your Cloudflare free tier, or Docker / Fly / home tunnel): private path, allowlist, app lanes, retention cap, quotas — and treated as untrusted (ADR 0064) |
| Identity | One key = one public person | One key per device, paired into a roster (SAS check); a single device can be removed |
| Data model | Immutable event stream | Git-like sync: version graph, three-way merge, conflict callouts, tombstones, offline queue, local history and checkpoints |
| Transport | Relay only | Relay + WebRTC P2P (large files, TURN, resumable), falls back to the relay automatically |
| Encryption | NIP-44 / NIP-59 per event | The same NIP-44 / NIP-59, plus two optional engines: Cinder EK (epoch keys rotated weekly) and Double Ratchet for live channels, both with an ML-KEM-768 hybrid key exchange |
What the relay can and cannot see
- Cannot see: message and file contents, file names (end-to-end encrypted on the device).
- Can see: IP addresses, connection times, message sizes, and recipient pubkeys. Encryption hides content, not metadata.
- Stores: encrypted offline messages and file chunks, until the retention cap (
--max-ttl-days, default 7; file lanes have their own). On Cloudflare they live in Durable Object SQLite; the Node host keeps them in memory unless --persist. Once the recipient device has processed and saved a sync message, it tells the relay (inbox ack, cinder_inbox_ack in NIP-11) and those copies expire 2 hours later instead (ADR 0067).
Precise security wording
- Post-quantum hybrid key exchange, not "quantum-safe": signatures are still secp256k1 (Schnorr), so authentication is not post-quantum.
- Forward secrecy depends on the engine: Cinder EK limits exposure to one key epoch (rotated weekly); per-message forward secrecy and post-compromise security come only from the Double Ratchet engine. Neither has had an external audit yet.
🏛️ Where the Relay Runs
| Cloudflare edge (Workers + Durable Objects) | Self-hosted (Docker / Fly / home tunnel) | Any public Nostr relay |
|---|
| Setup | One click from the app (REST API, no Node or wrangler) or cinderous relay deploy | cinderous relay deploy --provider docker / fly, or a relay build package | Paste a wss:// URL |
| Cost | $0 within the free tier | Your own hardware | $0 |
| Allowlist, lanes, quotas | Yes | Allowlist and quotas (no lanes) | No — the operator decides what is kept |
| Stored data | Encrypted, up to the retention cap | In memory, or SQLite with --persist | Whatever the operator keeps |
Apps choose; the SDK has no built-in default relay (CinderSync asks you to deploy or paste one).
🔐 Dual Pluggable Crypto Engines (Double Ratchet vs Cinder EK)
The Cinderous SDK (@cinderous/client) rejects one-size-fits-all cryptography, providing a unified ICryptoEngine abstraction for declarative engine selection and adaptive session negotiation:
This is the beginning of the README. Read the rest at the original. Read the full README ↗
