Show HN: OpenSlots – Trustless, Privacy-Preserving Scheduling over Nostr

Show HN: OpenSlots – Trustless, Privacy-Preserving Scheduling over Nostr(github.com)

1 points by tanimasa 153 days ago | 2 comments

I built OpenSlots, a zero-knowledge scheduling application that works without a trusted server.

Most scheduling tools (When2meet, Doodle, Calendly, even self-hosted ones) leak significant metadata: who meets whom, when, and how often. OpenSlots treats scheduling as a client-side protocol rather than a hosted service.

Key ideas:

- No trusted third party: Runs as a browser-based thick client. Nostr relays are used only as untrusted storage.

- End-to-end encryption (NIP-44): All room data and availability are encrypted with ChaCha20-Poly1305.

- URL fragment key distribution: The symmetric room key lives only in the URL fragment and is never sent to servers or relays.

- Blinded indexing: Room identifiers are indexed on relays via HMAC-SHA256(room_id, key), preventing trivial enumeration or mapping by relays.

Relays can observe ciphertexts, tags, and timing, but cannot read meeting content or recover room identifiers without the key. This removes the central database as a point of trust.

This is not full anonymity: IP addresses and timing remain observable. The goal is trust minimization and metadata reduction, not network-layer anonymity.

Demo and documentation: https://openslots.pages.dev

Technical Details: https://github.com/tani/openslots

Feedback is welcome, especially on the threat model, blinded indexing design, and usability trade-offs of URL-as-bearer-key approaches.

Privavault 153 days ago |

Really like the Nostr approach here. The trustless calendar coordination problem is thornier than most people realize – you need to handle timezone conversions, availability windows, and preference weighting without leaking private schedule data to a central server.

One question: how are you handling the case where someone's availability changes after they've shared slots? With end-to-end encryption, you can't really do server-side invalidation. Are you relying on clients to broadcast updates, or is there a different pattern you're using?

I've been working on encrypted document workflows and ran into similar state synchronization challenges when you can't trust the intermediary.

tanimasa 153 days ago | |

Since you mentioned encrypted document workflows, you likely suspected that we can't rely on the server to manage state transitions. You are correct: we rely entirely on client-side validation of "Replaceable Events" (Nostr NIP-01/NIP-33).

Here is the pattern OpenSlots uses to handle availability changes:

The Mechanism: Parameterized Replaceable Events

The original text mentioned "publishing encrypted, replaceable events." In the Nostr protocol, this refers to specific event kinds where relays are instructed to only store the newest version of an event from a specific pubkey with a specific identifier (the d tag).

1. Immutable Identity, Mutable State: The "Room" or "Schedule" is identified by a deterministic ID (derived from the random seed in the URL). This is the d tag.

2. The Update Loop: - When the host changes availability (e.g., removes a Tuesday slot), the client generates a new availability bitmask. - It encrypts this new payload with the same key (so existing URL holders can still read it). - It signs and publishes a new event with the same d tag but a newer created_at timestamp.

3. Resolution (LWW): - Relay Side: Relays discard the old event and store the new one (purely based on timestamp and ID, zero knowledge of content). - Client Side: Even if a relay sends multiple versions (due to propagation delay), the client logic applies a Last-Write-Wins (LWW) policy, simply rendering the event with the latest timestamp.

Why this works for Scheduling

Since scheduling (in this specific context) is usually single-writer (the host defines availability) and multi-reader (attendees view it), we avoid complex merge conflicts.

- Host: Sole authority on the "Availability" event. - Attendees: Sole authority on their own "Request/Booking" events.

If an attendee tries to book a slot that was just removed (a "stale read"), the host's client—upon receiving the booking request—checks it against its current local state and rejects it cryptographically (or simply ignores it), preventing the double-booking.