LOCAL-TRUE · not on-chain

Dual-state · private RSVP

Sealed Invite Studio

World-class educational RSVP studio for Midnight’s dual-state model: seal an invite (public title + commitment), collect private RSVPs whose guest identities stay in the vault, then prove capacity still holds — or selectively admit — without publishing the guest list. By @kshot9000 · nightdream.xyz.

Seal an invite Private RSVP Capacity theater Donate ADA
S Seal R RSVP ? Shortcuts D Donate
Honest scope: local HTML/JS simulation only. Does not run Compact, a proof server, Lace, or real ADA / DUST transfers. Does not claim GitHub Pages is live until Actions are enabled. SHA-256 commitments here are a teaching stand-in — verify against official Compact / Zswap crypto before shipping.

Invite journey

Labeled phases from sealed invite → private RSVPs → capacity proof / admit. Reject is first-class.

  1. 1
    Idle No open invites
  2. 2
    Sealed Public title + commitment
  3. 3
    RSVPing Guests sealed in vault
  4. 4
    Proven Capacity / selective admit

Phase: idle — seal an invite to open the night list.

The dual-state invite in one screen

Observers see event titles and commitment hashes. Guest identities, capacity, and venue notes stay in the private vault until you choose to disclose.

Public ledger

Invite board

Simulated public state holds event metadata + H(capacity ‖ venue ‖ notes ‖ salt ‖ domain) and RSVP commitments — never clear guest names.

  • Event title / when (clear)
  • Invite commitment hash
  • RSVP commitment hashes + guest tags
  • Capacity-proven / admit flags
Private vault

Local witnesses

Capacity, venue, guest identity, plus-ones, and salts live in localStorage — a stand-in for Compact witnesses that never leave the client.

  • capacity (host)
  • venueNotes (private)
  • guestName / plusOnes
  • salt (32-byte hex)

Sealed rail

Invites with veiled capacity and sealed guest identities. Observers see commitments only.

100% veiled (no invites yet)

Disclose rail

Capacity proofs and selective admits — range (under capacity) or full guest-list disclose.

0% disclosed

Seal an invite

Title + when stay public. Capacity + venue notes seal into a commitment before the invite opens.

Invite draft

Visible on the board. Keep it tasteful — no secrets here.
Stays in the vault. Used by capacity theater.

0/280

Vault preview SIMULATED

Salt
—
Capacity
—
Venue
—
Commitment
—

Opening publishes title + when + commitment only. Capacity stays sealed.

Private RSVP

Pick an open invite. Guest identity seals into a commitment; only the hash + tag hit the public board.

RSVP form

What the board shows — not your real name.

What the board learns

  • Sees: guest tag + RSVP commitment hash + timestamp
  • Does not see: real name, plus-ones, whether capacity is full
  • Prove later: use Capacity theater to show seats remain without numbers

Educational only — no wallet, no settlement, no Compact proof.

Capacity theater SIMULATED

Prove sealed RSVPs fit under capacity — or reject. Exact seats and names stay veiled unless you disclose.

Prove capacity clearance

Last proof
No proof yet
LOCAL-TRUE

Theater log

Awaiting proofs…

Invite board

Public invite board — commitments first, guest names only after selective disclose. Schema v2 localStorage · BroadcastChannel sync · JSON export/import. LOCAL-TRUE ≠ on-chain.

Invites: 0 RSVPs: 0 Admitted: 0

Anti-pattern vs safe pattern

Teaching sketches — not deployable Compact. Always verify against official docs.

✗ Anti-pattern — clear guest list on-chain
// BAD: public ledger sees every name
ledger {
  guests: List<Bytes<64>>;  // observers dox the party
  capacity: Uint<32>;
}
✓ Safer sketch — commit + witness
// BETTER (sketch): public commitment only
ledger {
  inviteCommit: Bytes<32>;
  rsvpCommits: List<Bytes<32>>;
}
witness capacity: Uint<32>;
witness guestName: Bytes<64>;
// prove seatsRemain without publishing names

These snippets are educational illustrations. Official Compact syntax, circuits, and Zswap commitments may differ — check Midnight docs before shipping.