[Privavault]

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]

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.