NIP-XX: Encrypted Event Networking (Nostrautica Protocol)

draft optional

This NIP defines a protocol for privacy-preserving event networking on Nostr: encrypted attendee registration, an encrypted per-event directory, AI-assisted matchmaking through an organizer-chosen coordinator service, moderated pre-recorded talks, members-only event content, and MLS (Marmot) group chat with multi-device support.

1. Terms and actors

Space: the thing attendees join. It is published in one of exactly two kinds, and its canonical identifier everywhere is the coordinate <kind>:<E_id-pubkey>:<d> (the coordinate):
- Event — a NIP-52 kind 31923 calendar event. It happens on a date, in a place, and ends. Interoperates with any NIP-52 client.
- Community (added 2026-09-13) — a kind 31612 standing group. No date, no venue, no end. See §2.1.
Everything downstream of the coordinate — the 31600 config, the ECK, the roster, the directory, matching, chat — is addressed by the coordinate and is identical for both. Where this document says "event" without qualification, it means either.
E_id: the event identity keypair. Signs everything "official" the event publishes. Never used for encryption. Held by the organizer and co-organizers only.
E_inbox: the event inbox keypair. Signs nothing, ever. Its pubkey is the NIP-44 encryption target for all inbound attendee submissions. Held by organizers and the coordinator.
ECK: Event Content Key, a versioned 32-byte symmetric key encrypting all outbound member-only content. Rotated forward-only on revocation.
Coordinator: an optional headless daemon with its own keypair, granted E_inbox and ECK custody by the organizer. It transcribes, profiles, matches, publishes member-only records, and administers group chat. It can never sign as E_id.
Attendee account key: the user's normal Nostr identity (local, NIP-07, or NIP-46).
Chat device key: a per-browser/per-device keypair used only for Marmot/MLS chat (§10). One account may have several concurrently.

All hex values are lowercase. hex32 means /^[0-9a-f]{64}$/.

1.1 Community (kind `31612`)

A community is a standing group: people who already share a chat somewhere and could network if they knew who to talk to. It has no start, no end and no venue.

Why not 31923 with a placeholder start. Kind 31923 is a NIP-52 time-based calendar event whose start is mandatory. A community publishing one would have to invent a value — its creation moment is the only defensible choice — and every NIP-52 calendar client on the network would then show it as a zero-length event on the afternoon it was made, and index it in date filters. That is publishing noise into other people's software to satisfy a field that carries no meaning here. A community is simply not a calendar event, so it gets its own kind and calendar clients never see it.

Tags. 31923's minus time and place:

tag
`d`	the space identifier, identical to the `31600` config's `d`
`title`	required
`summary`	optional
`image`	optional
`t`	optional hashtags

No start, no end, no location, and no NIP-52 D day-index tags. A community that carried a day index would reappear in exactly the date filters this kind exists to stay out of.

Everything else is unchanged. The 31600 config, the ECK, the roster, the directory, the match lists and group chat are addressed by coordinate and behave identically. There is no mode tag on the config: the kind in the coordinate is the single source of truth, and a second one would only be somewhere for the two to disagree.

Coordinate handling. Anywhere an event identity is required — a key grant, a coordinator grant, a membership coordinate — the kind must be one of 31923 or 31612 and nothing else. That guard is an allowlist (audit R18) and widening it to two values does not weaken it: every downstream record is keyed by the whole coordinate string, so 31612:<E_id>:<d> authorises nothing for 31923:<E_id>:<d> and the two namespaces stay separate even for the same author and identifier.

Forward and backward compatibility. No existing kind changed and no existing tag changed, so every record published before this section stays valid and byte-identical. A client that does not know 31612 does not see communities at all, which is the correct degradation: it cannot misread one as an event, because it never resolves the coordinate. No v bump; the 31600 config inside a community still carries v=2.

Approval. A community defaults to approval: "open" (§6.3): anyone holding the invite link is a member. An older client or coordinator meeting "open" falls back to "manual" per the tolerant-parse rule, which is stricter than intended rather than looser.

2. Wire version

PROTOCOL_VERSION = 2.

Public events carry the tag ["v","2"]. Encrypted and JSON payloads carry "v": 2.
Parsers MUST reject any payload whose v is not exactly 2 (z.literal(2), not "any positive integer"). Clients SHOULD surface an "update required" message when they observe a higher version from an authority key they trust (the event's E_id or configured coordinator).
One exception, and only one: a 31604 roster payload may declare v: 3 when it is paginated (§6.2.1). That kind alone has a wire problem — it is a single NIP-44 payload with a hard 65,535-byte ceiling — and scoping the bump to it avoids a flag day across every other kind to fix one of them. A roster that fits keeps v: 2. No other payload, and no event v tag, may be anything but 2.
Readers of public custom kinds MUST ignore events whose v tag is absent or not "2".
Rationale: an explicit-rejection parse means a future breaking payload can never be silently misparsed under the wrong semantics; forward compatibility is achieved by bumping v and shipping clients first.

Custom kinds occupy the addressable block 31600–31611 and the gift-wrap rumor block 21600–21610.

3. Ordering, replaceability, and revisions

These rules give every reader (app and coordinator, fetch and stream paths alike) one deterministic answer for which replaceable event is current, and give every mutable submission an explicit, replay-safe order. They are global and normative.

3.1 Latest-event rule (all replaceable/addressable kinds)

For any two events with the same (kind, author, d): the event with the higher created_at wins; on a tie, the event with the lexicographically lowest id wins (the NIP-01 convention). Every reader (app and coordinator, fetch and stream paths) MUST apply exactly this rule, so two conforming implementations never disagree about which replaceable event is current.

3.2 Monotonic publishing

A publisher of a replaceable event MUST set created_at to max(now, previous_created_at_for_that_address + 1). This makes §3.1 deterministic in practice and removes same-second collisions between successive business updates.

3.3 Revisioned mutable submissions

Sender-mutable records carry an explicit application revision; sender-chosen timestamps are never the primary ordering key.

21601 profile submission content carries rev (int ≥ 0, required). The coordinator stores the applied (rev, created_at, rumor_id) and MUST reject a submission whose key is not strictly greater under lexicographic comparison (rev, created_at, id-inverted), i.e. higher rev wins; equal rev: higher created_at wins; equal both: lowest rumor id wins, and a loser is discarded, never applied.
21609 talk submission content carries revision; a submission with revision equal to the stored one and a different content hash MUST be rejected (a content change requires a revision bump). Equal revision and identical content is an idempotent re-delivery.
21608 profile correction content carries rev with the same rule as 21601.

Clients maintain rev monotonically per (coordinate, kind) in their own storage and MUST bump it on every edit.

3.4 Admin command ordering and replay horizon

21604 admin commands carry two required fields:

expires (unix seconds): the command is void after this time. Clients SHOULD set created_at + 172800 (48 h) by default.
Per-subject ordering: the coordinator keeps, per (coordinate, command subject), the watermark (created_at, rumor_id) of the last fully applied command. A distinct command that does not supersede the watermark under the §3.1 ordering rule MUST be rejected. The watermark advances only once the command's entire effect chain (grants, roster, deletions, MLS actions, purge) has durably completed: a command interrupted by a publication, MLS, or database failure leaves the watermark unadvanced (recorded pending with per-publication progress), so redelivery of the same rumor resumes it to completion rather than being suppressed as stale. The subject is args.pubkey for approve/revoke/reprocess, (args.pubkey, args.talk_d) for talk commands, and the coordinate itself for recompute and detach.

On backfill/restore, an expired command is skipped: an old revoke or recompute can never re-execute after a database loss. Approve/revoke interleavings resolve deterministically per subject instead of by relay arrival order.

Coordinators MUST retain their rumor dedupe ledger (wrap id + rumor id) indefinitely rather than pruning it by age. A coordinator re-scans its inbox from since: 0 on install and on restore, so any dedupe entry aged out under a fixed time-to-live makes the corresponding rumor look unseen on the next rescan and lets it replay, and only 21604 admin commands carry an expires bound; join requests, submissions, and grants do not. Bounding the ledger safely again requires a durable, protocol-level generation or expiry model that covers every rumor kind, not admin commands alone. Only kind-scoped receipts with their own natural single-use expiry (such as consumed Marmot key packages) may be pruned by age.

3.5 Coordinator installation generation and detach

The 31600 coordinator tag is three-element: ["coordinator", <pubkey>, <gen>] where gen is a positive integer chosen by the organizer, strictly increasing across every attach/detach/re-attach of the event (persisted in the organizer's 30078 event-keys backup as coordinator_gen). The 21603 install grant carries the same gen. A malformed coordinator tag (a missing element, a non-hex pubkey, or a non-positive-integer gen) MUST be treated as no coordinator at all.

Coordinator rules:

A fresh install MUST be authorized by a fetchable newest 31600 (per §3.1) naming this coordinator with the same gen as the grant, whose declared inbox the grant's inbox_nsec derives. Unfetchable config is retryable, never authorization.
An install with gen ≤ the highest generation ever installed or detached for that coordinate MUST be rejected: a replayed historical 21603 can never re-install.
Detach is any newest 31600 that does not name this coordinator with the current generation, including a config with no coordinator tag, and a config naming another coordinator. On detach the coordinator MUST durably tombstone the installation (coordinate + last gen), close the event's subscriptions, cancel pending paid work, and delete its stored custody of E_inbox and the ECK; re-attaching requires a fresh grant with a new gen.
On startup the coordinator MUST revalidate the newest 31600 for every stored installation before resuming it. Fetch failure ⇒ the event stays suspended (no processing, no publishing) and revalidation retries; it does not resume leniently.
An explicit 21604 detach command (subject: the coordinate) triggers the same effects immediately, without waiting for a config re-fetch; the tombstone records whichever of the two signals arrived.

3.6 Grant authority

21602 key grants are accepted only when the seal author is E_id or the coordinator named (with current generation) in the newest fetchable 31600. A grant whose seal author is a formerly assigned coordinator MUST be rejected once a newer config no longer names it. Missing config is always "retry later," never "accept."

3.7 Detach hygiene, record authority, and handover

Deleting custody on detach (§3.5) is the honest coordinator's obligation; a malicious coordinator may retain copies of E_inbox and the ECK it held before detach. Detach therefore has protocol consequences beyond the coordinator's own state:

Key rotation on detach/replace. The organizer's client SHOULD rotate the ECK (the same machinery as attendee revocation) and SHOULD rotate E_inbox (mint a new inbox keypair, publish it in the new 31600 inbox tag, and include the new secret in the replacement coordinator's 21603) whenever detaching or replacing a coordinator. Senders always encrypt to the newest config's inbox, so inbox rotation is transparent to attendees; organizers retain old inbox secrets locally for reading history. As with every ECK rotation, this protects only future content, ciphertext already published under an old key or old inbox stays readable to whoever held it.
Record authority is pinned to the current assignment. Readers MUST accept coordinator-authored kinds (31603, 31604, 31605, 31606, 31610) only when authored by the coordinator currently named in the newest fetchable 31600, or by E_id. Records authored by a formerly assigned coordinator are ignored once a newer config no longer names it.
Handover republish. A newly attached coordinator MUST republish the event's member records (directory, roster, match lists, published talks) under its own key (bootstrapping from the previous coordinator's still-decryptable records where custody allows, and from reprocessing otherwise), so that record-authority pinning (above) never leaves members without a readable directory.

4. Encryption model

Every layer reuses an audited primitive (NIP-44 v2 for confidentiality, AES-256-GCM for media) with no bespoke cryptography.

Layer	Construction	Used for
Inbound	NIP-44 v2, sender → `E_inbox` pubkey, inside NIP-59 gift wrap	21600, 21601, 21608, 21609, 21610
Outbound member content	NIP-44 v2 with the raw 32-byte ECK as conversation key (no ECDH)	31603, 31604, 31606, 31607, 31608 `private`, 31610
Per-recipient	NIP-44 v2 ECDH, coordinator → recipient	31605, all grants/status rumors
Self-store	NIP-44 v2 self-conversation-key (or signer nip44 to own pubkey)	31602, 30078
Media	AES-256-GCM, fresh key + 12-byte IV per blob, whole-file	Blossom blobs

Every encrypt path enforces the 65,535-byte NIP-44 plaintext ceiling.
The ECK never signs anything.
Blinded addresses: d = hex(hmac_sha256(key, utf8("<coordinate>|<pubkey>")))[0..32] with key = current ECK (directory/match/talk addresses) or the account's self-blinding key (self-stores). Talk addresses use the literal-string variant hmac_sha256(ECK, "talk|<coordinate>|<speaker>|<talk_d>").
ECK versions are {id, key}; grants carry the full version list; receivers union-merge (a stale grant never downgrades custody). The current version is the highest id; rotation on revocation is forward-only and honest about it (old ciphertext stays readable to whoever held the old key).

5. Gift wraps

Per NIP-59: rumor (unsigned) → kind-13 seal (signed by the true author, NIP-44 to the recipient, empty tags) → kind-1059 wrap (one-time key, single p tag, created_at randomized up to 2 days into the past).

RUMOR_KINDS = {14, 21600–21610}. Nothing else may appear in a wrap; a leaked rumor kind is in the ephemeral range so relays won't store it.
Unwrap validation (every consumer): the outer wrap MUST be a valid signed kind-1059 event (id recomputed, Schnorr signature verified). The seal MUST be a complete signed kind-13 event with empty tags whose id recomputes and whose Schnorr signature verifies. NIP-44 decryption does not authenticate the seal author: ECDH yields the same conversation key for both parties, so a holder of the recipient secret can encrypt a seal claiming any sender pubkey and it decrypts cleanly. The kind-13 signature is therefore the sole proof of seal authorship, and every consumer MUST verify it before trusting rumor.pubkey (authorization throughout this protocol treats the seal author as an authenticated identity). Then: structural rumor shape; rumor.pubkey == seal.pubkey; rumor id recomputed and matched; created_at clamped to ≤ now + 900 s.
Subscription window: since = now − 259200 (3 days). Consumers dedupe by rumor id.
Coordinator dedupe: durable seen_rumors ledger keyed by wrap id and rumor id, retained indefinitely (§3.4); atomic in-process claim before dispatch; a durable cross-process lease is required before two daemons may share one database, until then, single-daemon operation per database is a stated constraint.

6. Kinds

6.1 Registry

Kind	Name	Signer	Visibility	`d`
31600	Event Networking Config	`E_id`	public	event `d`
31601	Invite List	`E_id`	public (hash-hidden)	event `d`
31602	Self profile / reuse library	account	NIP-44 self	blinded
31603	Directory Entry	coordinator (or `E_id`)	ECK	blinded
31604	Roster	coordinator (or `E_id`)	ECK	event `d`
31605	Match List	coordinator	NIP-44 → recipient	blinded
31606	Match Matrix	coordinator	ECK	event `d`
31607	Members-only Post	`E_id`	ECK	random stable
31608	Event Page	`E_id`	public + ECK `private`	event `d`
31609	Event Theme	`E_id`	public	event `d`
31610	Talk	coordinator (or `E_id`)	ECK	blinded
31611	Coordinator Announcement	coordinator	public	`nostrautica:coordinator`
31612	Community	`E_id`	public	space `d`

Rumor	Name	Seal author → recipient
21600	Join Request	account → `E_inbox`
21601	Profile Submission	account → `E_inbox`
21602	Key Grant	`E_id` or the currently assigned coordinator → attendee
21603	Coordinator Grant (install)	`E_id` → coordinator
21604	Admin Command	`E_id` → coordinator
21605	Organizer Grant	`E_id` → co-organizer
21606	Coordinator Status	coordinator → organizer, and optionally the affected attendee
21607	Chat Device Attestation	account → coordinator
21608	Profile Correction	account → `E_inbox`
21609	Talk Submission	account → `E_inbox`
21610	Attendee Withdrawal	account → `E_inbox`

Standard kinds used: 0, 1, 3, 5, 6, 13, 14, 1059, 10000, 10002, 10050, 10063, 24242, 30023, 30078, 31923/31924/31925, and Marmot's 30443/443/444/445.

31610 and 31612 extend past the originally-reserved 31600–31609 addressable block, and 21610 past the originally-reserved 21600–21609 rumor block; both remain inside their respective standard Nostr ranges (parameterized-replaceable 30000–39999, ephemeral 20000–29999).

6.2 Addressable kind specifications

Every field below is exactly what packages/protocol/src/schemas.ts and config.ts accept. ? marks an optional field; "(default …)" marks a field the schema fills in when absent; everything else is required. .strict() schemas reject unknown fields; the rest silently drop them.

`31600`: Event Networking Config

Class: parameterized-replaceable. Signer: E_id. Visibility: public; content is the empty string, every field lives in tags.
d: identical to the event's own 31923 d tag (one config per calendar event).
Tags:
- ["d", <event-d>], ["a", <coordinate>], ["v","2"], structural.
- ["inbox", <E_inbox-pubkey-hex>]: required, lowercase hex32.
- ["coordinator", <pubkey-hex>, <gen>]: optional, three-element (§3.5). Absent = no coordinator.
- ["relay", <wss-url>] × N, relay set for the event's encrypted traffic.
- ["chat_relay", <wss-url>] × N: relays used ONLY by the event's group chat (Marmot/MLS interop), omitted entirely when there are none. Kept out of relay on purpose: the Whitenoise interop relays accept only the chat kinds (0/3/445/1059/10000/10002/10050/30443) and answer every other kind with blocked: kind N is not accepted by this relay, so a reader MUST NOT publish this protocol's own events there. Chat operations use relay ∪ chat_relay; everything else uses relay alone. Compatibility: configs published before this tag existed carry the interop relays inside their relay tags; a reader SHOULD treat a known chat-only relay found in relay as if it had been in chat_relay (move, never drop: an existing group is routing over it), and a reader that does not understand chat_relay simply gets the general relay set, which is correct for everything except chat interop.
- ["blossom", <https-url>] × N, allowed Blossom origins for media.
- ["max_video_sec", <int>]: intro-video cap, default 90; "0" means unlimited.
- ["max_talk_sec", <int>]: talk cap, default 900; "0" means unlimited.
- ["matching", "on"|"off"]: default "off" (only the literal "on" enables it).
- ["match_visibility", "pair"|"event"]: default "pair".
- ["approval", "manual"|"invite"|"manual+invite"]: default "manual".
- ["eck", <int>]: bootstrap only: the ECK version in force when this config was last signed by E_id (default/floor 1). It is NOT the authority for the current ECK version. Because a coordinator cannot sign the E_id-authored 31600, coordinator-driven rotation (on revoke/withdraw) never updates this tag, so it goes stale after the first rotation. First-party readers MUST derive the current ECK from the coordinator-signed grants (21602/21605) and the roster (31604 eck_current), never from this tag. An organizer client that re-signs the config (attach/detach) MAY refresh the tag to the rotated version, but nothing may depend on it being current.
- ["nostr_context", <int>]: how many public Nostr events per attendee the coordinator summarizes as matching context; default 0 (off).
- ["lang", <iso639-1>]: event language; omitted when "en" (the implicit default).
- ["talks", "on"|"prerecord-first"]: omitted when talks are off (the default).
- ["chat", "marmot"] × N, group-chat backends; omitted when chat is disabled. Operative only when a coordinator tag is also present.
- ["retention", <days>]: optional positive integer. When present, the coordinator MUST delete the event's member records (31603, every 31604 page, 31605, 31606, published 31610 talks) via NIP-09 and cease processing <days> days after the event's end time, and clients MUST surface the declared retention at join time. Absent = indefinite retention. Deletion remains best-effort (relays may not honor NIP-09); the privacy model never depends on it succeeding, and client wording must not overpromise.
- ["parent", <31612-coordinate>]: optional, on a dated event only: the community this event belongs to (§15). At most one.
- ["child", <31923-coordinate>] × N: optional, on a community only: the events that belong to it (§15), at most 500. Omitted entirely when there are none.
Readers apply §3.1 to find the current config; it is the root of trust for every other kind on the event.

`31601`: Invite List

Class: parameterized-replaceable. Signer: E_id. Visibility: public, hash-hidden (the codes themselves never appear on the wire).
d: event d. Tags: ["d", <event-d>], ["a", <coordinate>], ["v","2"].
Content:
```
{ v: 2, invites: [{ h: hex32, label?: string ≤100 }] ≤10000 entries }
```
h = sha256(invite-pubkey). Voiding a code = republishing the list without its hash.

`31602`: Self Event Profile / Reuse Library

Class: parameterized-replaceable. Signer: the attendee's account key.
Sealing: the content is NIP-44 self-encrypted, the conversation key of the signer's key with itself (a local-key signer computes it directly; a remote signer calls nip44Encrypt targeting its own pubkey).
Two variants, distinguished by d and by the a field inside the ciphertext:
1. Per-event self-copy, d = blindedD(blindingKey, coordinate, ownPubkey).
2. Reuse library (spans every event the account joins), d = blindedDLiteral(blindingKey, "library").
blindingKey: a local-key signer uses selfConversationKey(sk) directly; a remote signer generates a random 32-byte seed once and self-stores it in a 30078 event with d = "nostrautica:blindseed".
Tags: [["d", <blinded>]] only, no a tag, so the address itself never reveals which event an attendee has joined.

Content (both variants share one schema):

{
  v: 2,
  a: <coordinate> | null,          // null on the reuse-library entry
  profile?: AttendeeProfile,
  media: MediaDescriptor[] ≤20 (default []),
  intro_texts?: string[≤2000] ≤20, // library entry only, in practice
  rev?: int ≥0                     // per-event self-copy only; the client's own
                                    // durable store of the last 21601 `rev` it sent
                                    // (survives a device change)
  correction_rev?: int ≥0           // same, for the last 21608 correction `rev`
}

AttendeeProfile = { about: string ≤5000 (default ""), skills: string[≤200] ≤50 (default []), looking_for: string ≤2000 (default ""), links: url-string ≤2048[] ≤20 (default []) }

`31603`: Directory Entry

Class: parameterized-replaceable. Signer: the coordinator, or E_id when the event has no coordinator. Sealing: ECK.
d: blindedD(currentECK, coordinate, attendeePubkey), rotates whenever the ECK rotates.
Tags: ["d", <blinded>], ["a", <coordinate>], ["eck", <version>], ["v","2"].

Content (ECK ciphertext):

{
  v: 2,
  pubkey: hex32,
  name?: string ≤200,               // display name, echoed from the join request
  profile: AttendeeProfile,         // as in 31602
  media: MediaDescriptor[] ≤20 (default []),
  ai_profile?: AiProfile,           // present once matching-derivation completes
  ai_profile_edited?: bool,         // set when a 21608 correction has been applied
  transcripts?: MediaTranscript[],  // every transcripts[i].x MUST reference a live
                                     // media[].x — a stale transcript is rejected
  intro_text?: string ≤2000,
  updated_at: int
}

AiProfile = { summary: string ≤5000, skills: string[≤200] ≤50, interests: string[≤200] ≤50, offers: string[≤200] ≤50, seeks: string[≤200] ≤50, translations?: { lang: string ≤35, about?: string ≤5000, looking_for?: string ≤2000, skills?: string[≤200] ≤50 } }

. MediaTranscript = { x: hex32, text: string ≤100000, lang: string ≤35, source: "stt"|"authored", updated_at: int }.

Coordinator publish-time hygiene: on top of the schema bounds above, the reference coordinator additionally re-caps at the moment it publishes, about/looking_for/ intro_text/name to 4000/4000/4000/200 chars, each skills entry to 200 chars within the schema's 50-item limit, links to 32 entries of ≤500 chars, transcript text to 8000 chars, and every LLM-authored string (ai_profile.*, match reasoning) is word-boundary-truncated to 2000 chars and has its https:///http:// prefixes stripped so injected text can't render as a clickable link. These are defense-in-depth caps tighter than the intake schema, not separate wire fields.
Deleted via NIP-09 (["a","31603:<coordinator-pk>:<blinded-d>"] + ["k","31603"]) on revocation or withdrawal.

`31604`: Roster

Class: parameterized-replaceable. Signer: the coordinator, or E_id without one. Sealing: ECK. d: event d for page 0 (not blinded); <event-d>:N for page N of a paginated roster (see below).
Tags: ["d", <page-d>], ["a", <coordinate>], ["eck", <version>], ["v","2"]. The v TAG is "2" on every page, including a paginated one — the event envelope is unchanged; it is the payload that declares a version.
Content:
```
{
  v: 2 | 3,                         // 3 only on a paginated roster, see §6.2.1
  eck_current: int >0,
  nostr_group_id?: hex32,           // this event's active Marmot MLS group (§10.4)
  pages?: int 2..40,                // page 0 of a paginated roster ONLY
  attendees: [
    {
      pubkey: hex32,
      d: string ≤200,               // that attendee's blinded 31603 d
      role: "attendee" | "organizer",
      chat_keys?: [
        { pubkey: hex32, label?: string ≤60, added_at: int,  // added_at: unix SECONDS
          external?: true }        // a linked external Marmot client's key (§10.5)
      ] ≤10                        // per-device chat keys (MAX_CHAT_KEYS_PER_ACCOUNT)
    }
  ] ≤700                           // per PAGE; ≤2000 across the whole roster
}
```
nostr_group_id is the authoritative event→group routing binding (§10.4); it is absent for chat-off events. chat_keys is absent for an attendee with no attested device. A payload carrying pages beside v: 2 is invalid and MUST be rejected.

Neither array cap is the operative limit. One 31604 is one NIP-44 v2 payload, so a page is bounded by that layer's 65,535-byte plaintext ceiling (§7.4). A minimal entry costs about 135 bytes and one carrying a chat device about 265, so a page holds somewhere between roughly 240 and 480 members depending on how many have attested a device — well under the ≤700 parse bound, which exists only so a hostile payload cannot allocate an unbounded array before the byte check runs.

A coordinator MUST NOT approve past MAX_ROSTER (2000) members or 40 pages, and SHOULD tell the organizer (a 21606 with error_category: "roster_full", and "roster_nearly_full" on the way there) rather than failing mid-publish with the ECK grant already delivered.

6.2.1 Roster pagination

A roster that fits in one NIP-44 payload is published exactly as it always was: one 31604 at the event's d, v: 2, no pages key, byte-identical to what shipped before this section existed. Nothing below applies to it, and that covers every event and community under a few hundred members.

A roster that does not fit is split across several 31604s under the same author:

page	`d`	carries
0	`<event-d>`	`pages`, `eck_current`, `nostr_group_id`, the first entries
N	`<event-d>:N`	`eck_current`, the next entries

eck_current and nostr_group_id are read from page 0 and are authoritative for the whole roster; a continuation page repeats eck_current only because the payload schema requires it. Entries are packed front to back, so appending a member changes the last page and nothing before it: a writer SHOULD republish only the pages whose contents actually changed, or one approval costs one relay publish per page for the length of the event. A reader fetches page 0, learns pages, and fetches 1..N-1 in a single REQ (#d: ["<d>:1", "<d>:2", …]) — two round trips, whatever the size.

Because <event-d>:N could also be some other space's own d under the same coordinator, a reader MUST check a continuation page's ["a", <coordinate>] tag as well as its author. The content is ECK-sealed per event, so a collision can only withhold a page, never forge one — but withholding it must not pass unnoticed. A reader that cannot read every page MUST NOT present the pages it did read as the roster; a partial membership list is indistinguishable from an event that shrank.

Why pages under distinct ds, and not the alternatives. A manifest kind naming the pages reads more cleanly, but the round-trip count is identical — page 0 already is the manifest — and it costs a kind allocation for nothing. Dropping chat_keys back out of the roster roughly doubles what one payload holds, but it takes the device list away from the only surface that renders it and buys a single doubling; that is a deferral, not a fix. And no compression or entry shrinking was available: pubkey is 64 hex chars, d is a 32-char blinded value, both already minimal.

What an old client does. This is the part that decided the design. Zod objects strip unknown keys, so simply adding pages would be silently ignored by every build already installed: it would read page 0, see 480 of 600 members, and render that as the complete event. So page 0 of a paginated roster declares v: 3, and an old client's strict z.literal(2) parse rejects it through the path §2 already defines — the roster is authored by a trusted authority, so the client surfaces "update required" instead of dropping it silently. It fails loudly, and only on the rosters it genuinely cannot represent.

This is the one payload field allowed to exceed PROTOCOL_VERSION, and the exception is deliberate. Bumping PROTOCOL_VERSION to 3 would achieve the same refusal and would also invalidate every 31600 config, join request, directory entry, match list and 21xxx rumor on the network — a full wire-v3 flag day across every kind, to solve a problem in exactly one of them. The bump is therefore scoped to the payload that has the problem. 31604 is the only kind whose v may be 2 or 3; every other payload keeps the strict literal-2 parse of §2.

`31605`: Match List

Class: parameterized-replaceable. Signer: the coordinator only.
Sealing: NIP-44, coordinator → the recipient attendee (ECDH, not ECK).
d: blindedD(currentECK, coordinate, recipientPubkey): ECK-derived so only members can compute the address, and only the recipient can decrypt the content.
Tags: ["d", <blinded>], ["a", <coordinate>], ["v","2"], no eck tag (the per-recipient encryption does not need one).

Content:

{
  v: 2,
  computed_at: int,
  matches: [
    {
      pubkey: hex32,
      score: number,
      similarity: number,
      complementarity: number,
      reasoning: string ≤2000,
      icebreakers?: string[≤280] ≤3   // concrete conversation starters the
                                       // coordinator derives alongside the
                                       // directional reasoning
    }
  ] ≤100
}

icebreakers is additive: a client without support for it simply ignores the field. The reference coordinator publishes the top-K matches by score (default K = 20).

`31606`: Match Matrix

Class: parameterized-replaceable, opt-in (published only when the event's match_visibility is "event"). Signer: the coordinator. Sealing: ECK.
d: event d. Tags: ["d", <event-d>], ["a", <coordinate>], ["eck", <version>], ["v","2"].
Content:
```
{ v: 2, computed_at: int, pairs: [{ a: hex32, b: hex32, score: number }] ≤200000 }
```
Pairs are canonically ordered (a < b); the matrix carries scores only, never reasoning. Deleted (NIP-09) when visibility changes away from "event".

`31607`: Members-only Event Post

Class: parameterized-replaceable. Signer: E_id. Sealing: ECK.
d: a random 32-hex identifier chosen at creation, stable across edits, not blinded (there is no a tag and no cleartext metadata; discovery is {kinds:[31607], authors:[E_id]}).
Tags: ["d", <random>], ["v","2"], ["eck", <version>].
Content (ECK ciphertext):
```
{
  v: 2,
  title: string ≤300,
  summary?: string ≤2000,
  image?: string ≤2048,
  published_at: int,     // set on first publish, preserved across edits
  author?: hex32,        // optional organizer attribution
  content: string ≤100000   // markdown
}
```
The reference editor additionally enforces ≤ 60,000 UTF-8 bytes of markdown at write time: comfortably inside both the schema's character cap and the NIP-44 65,535-byte plaintext ceiling. Edits re-encrypt under the ECK current at edit time; a post published before a rotation is never re-encrypted under the new key.

`31608`: Event Page (menu + layout)

Class: parameterized-replaceable. Signer: E_id. d: event d.
Tags: ["d", <event-d>], ["a", <coordinate>], ["v","2"], ["eck", <version>] (present only when a private blob exists), plus ["r", <target>, <label>] × N, the public menu, in display order.
Content:
```
{
  v: 2,
  sections: EventPageSection[] (default []),   // PUBLIC layout
  sources: ExternalFeed[] (default []),        // PUBLIC curated feeds
  private?: string                             // ECK ciphertext (below)
}
```
EventPageSection is a discriminated union on type:
- { type: "posts", source: "event"|"attendees"|"both", visibility: "public"|"members"|"both" }
- { type: "pinned", refs: string[] }: naddr references.
- { type: "attendees" }: roster preview; renders only for members.
ExternalFeed = { pubkey: hex32, tags?: string[≤100] ≤10, since?: int ≥0, until?: int ≥0, relays?: string[≤2048] ≤30, label?: string ≤200 }, at most 10 per page. Each entry is a standing query for public 30023 written by someone other than E_id that a reader folds into the event's OFFICIAL posts: the organization's own Nostr account alongside the per-event E_id, where pinned names individual articles and this names a rule. Fields AND together into {kinds:[30023], authors:[pubkey], "#t": tags, since}; an entry carrying only a pubkey means "everything this npub writes", so readers MUST bound the result (the reference client uses limit: 100 per feed).

Readers MUST re-apply the whole entry client-side rather than trusting the relay to have honoured the filter: in particular that pubkey matches, since nothing else stops a relay from answering with an article by someone the organizer never named. since/until bound the article's published_at, not its created_at: a NIP-23 edit bumps created_at without moving published_at, and created_at ≥ published_at always holds for an article, so a relay-side since is a valid prefilter while until MUST NOT be sent (it would drop an in-window article that was edited later). A source naming E_id is ignored: those posts are already the official feed.

sources is public and cleartext by design: every event it can name is a public 30023 anyway, so encrypting the query would hide nothing while making the curation invisible to other NIP-23 clients reading this page. It is additive and defaulted (a 31608 published before it existed parses unchanged and simply declares no feeds), and a writer that has none SHOULD omit the key entirely.

The ECK-decrypted private payload:
```
{
  v: 2,
  menu: (MenuItem & { pos: int ≥0 })[] (default []),
  sections: (EventPageSection & { pos: int ≥0 })[] (default [])
}
```
MenuItem = { label: string ≤200, target: string ≤2048 } (an https URL or a nostr:naddr… reference; not format-validated beyond length). pos is the item's index into the client-side list merged from the public and private items, the merge and its inverse split round-trip exactly.

`31609`: Event Theme

Class: parameterized-replaceable. Signer: E_id. d: event d.
Tags: ["d", <event-d>], ["a", <coordinate>], ["v","2"].
Content: raw CSS, plaintext, ≤ 32,768 bytes. Public. Explicitly not a secret-safe rendering boundary (see §13).

`31610`: Talk

Class: parameterized-replaceable. Signer: the coordinator, or E_id without one. Sealing: ECK.
d: blindedDLiteral(ECK, "talk|<coordinate>|<speaker-pubkey>|<talk_d>"), stable per (speaker, talk_d) under one ECK; changes on rotation, at which point the coordinator republishes under the new address and NIP-09-deletes the old one.
Tags: ["d", <blinded>], ["a", <coordinate>], ["eck", <version>], ["v","2"].

Content (ECK ciphertext):

{
  v: 2,
  pubkey: hex32,                 // the submitting speaker
  talk_d: string 1..64,
  title: string 1..200,
  description: string ≤2000 (default ""),
  speakers: hex32[] (default []),   // co-speakers; the submitter is implicit
  media?: MediaDescriptor,          // kind MUST be "talk"; present for recording/upload
  external_url?: https URL ≤2048,   // XOR with media: a YouTube or direct-mp4 URL
  external_kind?: "youtube" | "video",  // required when external_url is set
  source_type?: "recording" | "upload" | "external",
  transcript?: MediaTranscript,
  lang: string,
  revision: int ≥0,
  status: "pending" | "published" | "rejected",
  published_at: int
}

Additive fields (2026-07-24, no v bump): a talk carries exactly one of media (a Blossom recording/upload) or external_url (+ external_kind), an unlisted YouTube link or a direct .mp4 the speaker hosts off-Blossom, for clips too large to upload. The URL is inside the ECK ciphertext (members-only); the coordinator never fetches an external_url (the §8 media-fetch allowlist is Blossom-origin-only), so external talks are view-only. Never transcribed or matched. Only status: "published" talks are ever put on the wire in practice; "pending"/"rejected" describe the moderation queue the coordinator keeps privately.

`31611`: Coordinator Announcement

Class: parameterized-replaceable. Signer: the coordinator's own key. Visibility: public, plaintext (discovery record).
d: the literal "nostrautica:coordinator".
Tags: ["d","nostrautica:coordinator"], ["v","2"].

Content:

{
  v: 2,
  name: string 1..120,
  about?: string ≤2000,
  picture?: string ≤2048,
  operator?: string ≤200,
  relays: string[] ≤30 (default []),
  features: {
    matching: bool (default true),
    talks: bool (default false),
    chat: string[] ≤30 (default [])     // Marmot chat-relay URLs, when offered
  } (default {}),
  privacy?: { [role: string]: string },  // per-role disclosure tier, e.g. "private"
  terms_url?: https-string ≤2048,
  pricing?: {
    model: "free"|"per_user"|"per_event"|"negotiated"|"external",
    free_up_to_users?: int ≥0,
    summary?: string ≤280,
    checkout_url?: https-string ≤2048,
    currency?: string ≤16
  }
}

See §9 for how privacy and pricing are meant to be generated.

6.3 Rumor kind specifications

Every rumor below travels only inside a NIP-59 gift wrap (§5); none is ever a signed, relay-visible event on its own.

`21600`: Join Request

Seal author → recipient: attendee account → E_inbox.
Tags: ["a", <coordinate>]; optionally ["invite", <invite-pubkey-hex>, <schnorr-sig-hex>] (§7); optionally, on a join to a community, ["member_of", <child-31923-coordinate>, <signer-hex>, <schnorr-sig-hex>] (§15), at most 8 considered.
Content:
```
{ v: 2, name: string ≤200, message: string ≤2000 (default ""), rsvp_public: bool (default false) }
```
When rsvp_public is true, the client additionally publishes a public kind-31925 RSVP with ["a", <coordinate>], ["d", "<coordinate>:<attendeePubkey>"], ["status","accepted"].

`21601`: Profile Submission

Seal author → recipient: attendee account → E_inbox.
Tags: ["a", <coordinate>].

Content:

{
  v: 2,
  rev: int ≥0,
  profile: AttendeeProfile,
  media: MediaDescriptor[] ≤4 (default []),
  intro_text?: string ≤2000
}

Ordering per §3.3. intro_text is a text-only alternative to a recorded intro; it feeds the derived ai_profile the same way a transcript would, without a media blob.

`21602`: Key Grant

Seal author → recipient: E_id, or the coordinator currently named (with current generation) in the newest fetchable 31600 (§3.6) → the attendee.
Content:
```
{
  v: 2,
  a: <coordinate>,
  role: "attendee" | "organizer",
  eck: [{ id: int >0, key: base64(32 bytes) }],
  granted_by: hex32,
  parent?: { a: <31612-coordinate>, by: hex32, sig: hex64 }
}
```
granted_by MUST equal the seal author. parent (§15) is present only when the event belongs to a community; it is a membership proof the recipient may present to join that community. Receivers union-merge the granted ECK versions into local custody: a stale grant never removes or downgrades a newer known version, and an attendee-role grant never downgrades a stored organizer role.

`21603`: Coordinator Grant (install)

Seal author → recipient: E_id → coordinator.

Content:

{
  v: 2,
  a: <coordinate>,
  gen: int >0,
  inbox_nsec: hex32,
  eck: [{ id: int >0, key: base64(32 bytes) }],
  config_relays: string[] ≤30
}

Seal author MUST equal the coordinate's E_id. Install authorization and the gen rules are §3.5.

`21604`: Admin Command

Seal author → recipient: E_id → coordinator.
Content:
```
{
  v: 2,
  a: <coordinate>,
  cmd: "approve" | "recompute" | "reprocess" | "revoke" | "talk_publish" | "talk_reject" | "detach",
  args: { [key: string]: unknown } (default {}),
  expires: int
}
```
args by command: approve/reprocess/revoke → { pubkey }; talk_publish/ talk_reject → { pubkey, talk_d }; recompute/detach → {}. Seal author MUST equal the installed event's E_id. Ordering, expiry, and detach's effects are §3.4 and §3.5.

`21605`: Organizer Grant

Seal author → recipient: E_id → co-organizer.

Content:

{
  v: 2,
  a: <coordinate>,
  eid_nsec: hex32,
  einbox_nsec: hex32,
  eck: [{ id: int >0, key: base64(32 bytes) }],
  config_relays: string[] ≤30,
  granted_by: hex32
}

Seal author MUST be exactly E_id; granted_by MUST equal the seal author. Grants full, irrevocable custody of E_id, E_inbox, and every known ECK version, a co-organizer is cryptographically indistinguishable from the event's creator (§13). Receivers union-merge the granted ECK versions the same way 21602 does.

`21606`: Coordinator Status

Seal author → recipient: the coordinator → the organizer (E_id), and, for status restricted to one attendee's own pipeline items, optionally also → that attendee.

Content:

{
  v: 2,
  a: <coordinate>,
  pubkey?: hex32,             // affected attendee, when the item is attendee-scoped
  stage?: string,             // job type, e.g. "process_attendee"
  state?: "poison" | "cleared",
  attempts?: int ≥0,
  error_category?: string,    // sanitized class, never raw attendee/provider text
  retryable?: bool,
  billing?: {
    state: "ok" | "payment_required" | "grace",
    reason?: string ≤500,
    checkout_url?: https-string ≤2048,
    due?: number ≥0,
    currency?: string ≤16,
    grace_until?: int
  },
  at: int
}

A status is a poison/health report (the poison fields set), a billing update (billing set), or both. A rumor sent to an affected attendee is scoped to that attendee's own submission/talk pipeline failures; billing status is sent only to organizers.

`21607`: Chat Device Attestation

Seal author → recipient: the attendee's account key → coordinator.

Content (.strict()):

{
  v: 2,
  a: <coordinate>,
  op: "add" | "revoke" | "link" | "link_confirm",
  chat_pubkey: hex32,
  label?: string ≤60,       // required when op:"add" ("Chrome on laptop") or op:"link"
  client_id?: string ≤120,  // stable per-device kind-30443 key-package slot id
  proof?: schnorr-sig-hex,  // required when op:"add"; forbidden on link/link_confirm
  code?: string ≤32         // required when op:"link_confirm"; forbidden otherwise
}

proof is a BIP-340 signature by the chat device key over

sha256(utf8(JSON.stringify(["nostrautica-chat-device-v2", <coordinate>, <account-pubkey>, <chat_pubkey>, <rumor created_at>])))

. Full mechanics are §10.2. link/link_confirm bind an external Marmot client's key (§10.5). They were added after v2 froze, additively: every add/revoke rumor is unchanged, and a coordinator that predates them rejects such a rumor at its strict parse.

`21608`: Profile Correction

Seal author → recipient: attendee account → E_inbox.
Tags: ["a", <coordinate>].

Content:

{
  v: 2,
  a: <coordinate>,
  rev: int ≥0,
  overrides?: {
    summary?: string ≤5000,
    skills?: string[≤200] ≤50,
    interests?: string[≤200] ≤50,
    offers?: string[≤200] ≤50,
    seeks?: string[≤200] ≤50
  },
  hidden?: bool,                 // publish the directory entry with NO ai_profile
  hidden_fields?: ("summary"|"skills"|"interests"|"offers"|"seeks")[],
  report?: string ≤2000          // free-text "this is inaccurate" note to the organizer
}

The subject is the seal author: an attendee can only correct their own directory entry. overrides is bounded exactly like ai_profile itself. Ordering per §3.3. The correction is stored by the coordinator and re-applied on every 31603 republish (surviving reprocessing); authored identity fields (about/skills/looking_for/ links) are never touched by a correction.

`21609`: Talk Submission

Seal author → recipient: the speaker (attendee account) → E_inbox.
Tags: ["a", <coordinate>].

Content (.strict(); a present media.kind MUST be "talk"):

{
  v: 2,
  a: <coordinate>,
  talk_d: string 1..64,          // stable per-speaker id; editing resubmits the same id
  title: string 1..200,
  description: string ≤2000 (default ""),
  speakers: hex32[] (default []),  // co-speakers; the submitter is implicit
  media?: MediaDescriptor,         // XOR external_url (exactly one required)
  external_url?: https URL ≤2048,  // YouTube or direct-mp4 URL hosted off-Blossom
  external_kind?: "youtube" | "video",   // required when external_url is set
  source_type?: "recording" | "upload" | "external",
  process_for_matching: bool (default false),  // opt-in to STT + matching
  revision: int ≥0 (default 0)
}

Ordering per §3.3. A talk carries exactly one of media (Blossom recording/upload) or external_url (+ external_kind); this is a shared schema refinement with 31610. process_for_matching (default false, additive 2026-07-24) is the only thing that opts a Blossom talk into coordinator transcription + matching: un-opted talks are stored and publishable but never transcribed, and external talks are never fetched at all. Since the content is .strict(), the app and coordinator ship these additive fields in lockstep. Normative caps: at most 10 distinct talk_d per speaker per event (edits to an existing talk_d are uncapped).

`21610`: Attendee Withdrawal

Seal author → recipient: the withdrawing attendee's account key → E_inbox.

Content (.strict()):

{ v: 2, a: <coordinate>, delete_data?: bool (default true) }

Semantics: attendee-initiated removal from the event, the same effect chain as an organizer revoke (roster/directory/match removal, NIP-09 deletions, ECK rotation), triggered without requiring organizer action. delete_data: false requests removal from future publications while retaining the coordinator's already-processed artifacts (e.g. to support a later re-approval without reprocessing); the default is full deletion. The withdrawing client SHOULD also delete its own Blossom blobs (uploader-authorized) and its 31602 per-event self-copy. Ordering uses the §3.4 per-subject watermark, where the subject is the sender. Rejoining afterward is a fresh 21600 join request.

7. Invite codes

An invite code is a throwaway nsec, transported only in the URL fragment (#/e/:naddr/join?code=<nsec>).

31601 content carries h = sha256(invite-pubkey) per code (hash-hidden: observers can't enumerate or front-run codes).
Proof: the join request carries ["invite", <invite-pubkey-hex>, <sig-hex>] where the signature is BIP-340 over:
```
challenge = sha256( utf8( JSON.stringify(
    ["nostrautica-invite-v2", <coordinate>, <attendee-pubkey-hex>] ) ) )
```
The literal first element is a domain-separation tag; JSON-array encoding is injective, so the challenge can never collide with a differently-shaped message that happens to serialize to the same bytes.
Verification is stateless: sha256(invite-pubkey) ∈ newest 31601 ∧ signature valid.
Single-use: the coordinator claims per invite pubkey, first-processed wins; later uses fall back to the manual approval queue (a benign failure mode). This is eventually consistent by design: the organizer client and the coordinator do not share claim state, so a code can independently be "used" once locally by each.

8. Media descriptors

.strict() schema; unknown fields are rejected (a descriptor drives coordinator fetch and transcoding, so an unexpected field is a hard error, not a silently-ignored one).

{
  "kind": "intro" | "talk",
  "url": ["https://…", …],                 // https-only, ≥ 1 entry
  "x": "<sha256 hex of ciphertext>",
  "ox": "<sha256 hex of plaintext>",
  "size": "<int ≥ 1, ciphertext bytes>",
  "m": "<mime type>",
  "duration": "<seconds, number ≥ 0>",      // REQUIRED when m starts with audio/ or video/
  "encryption-algorithm": "aes-gcm",
  "decryption-key": "<base64, decodes to exactly 32 bytes>",
  "decryption-nonce": "<base64, decodes to exactly 12 bytes>"
}

Crypto: AES-256-GCM, a fresh key and 12-byte IV per blob, single-shot whole-file (no range/streaming playback). The decryption key and nonce travel inside the descriptor, never as a separate event. A "fresh copy" (decrypt → re-encrypt with a new key/IV) produces an unlinkable blob hash, breaking cross-event linkage by ciphertext reuse.
Coordinator enforcement, tighter than the schema's per-field bounds:
- At most 4 media descriptors are processed per 21601 submission; the schema itself caps a submission's array at 4 entries (MAX_SUBMISSION_MEDIA), while the 31602 self-copy/reuse-library variant allows up to 20 (it legitimately holds more across an attendee's history).
- At most 500 MiB declared total per submission.
- A descriptor's declared duration is checked against the event's max_video_sec/ max_talk_sec (§6.2 31600).
- The coordinator MUST compare the actual downloaded ciphertext length against size and reject a mismatch, and SHOULD probe the real decoded duration before running speech-to-text and reject media exceeding the event's limit regardless of the declared value.
- Blossom fetches are restricted to the event's 31600 blossom origin allowlist.
The https-only rule applies again at render boundaries: a client must not surface a plain-http media URL as a clickable/loadable resource even if one somehow parsed.

9. Coordinator lifecycle, billing, and announcements

Install / detach / startup revalidation: §3.5. Detach hygiene, record authority, and handover: §3.7.
Billing principal: the event identity (E_id). Coordinator configuration names its free-tier allowlist free_eids, a set of E_id pubkeys, since nothing in the protocol authenticates a personal-organizer identity independent of the events they create. The coordinator persists a typed billing principal per installation.
Billing is a persisted state machine: internally evaluating → ok | grace | blocked, re-evaluated at install, on attendee-count change, on submission revision, at job claim, and immediately before provider spend. blocked stops paid work but never blocks revoke, detach, roster repair, or status publication. A state transition emits a 21606 with the billing block; the wire has no "blocked" state of its own, a blocked installation is reported as billing.state: "payment_required".
Announcements (31611) are generated from resolved runtime provider routes, not configured intent: the privacy disclosure map describes where attendee data actually flows for each processing role, not merely what an operator intended to configure.

10. Group chat (Marmot/MLS) and multi-device

10.1 Model

One MLS group per event, created and administered by the coordinator (admin bot): add-on-approval, remove-on-revoke, member-driven device adds via attestation.
Chat identity is per device. Every browser/device mints its own chat device keypair on first chat use, for all account types (local key, NIP-07, NIP-46). There is no shared chat key, no relay backup of chat secrets, and no cross-device restore of chat identity. A device is added by attestation and removed by revocation; loss of a device is handled by revoking its key, not recovering it.
One account may hold up to MAX_CHAT_KEYS_PER_ACCOUNT = 10 concurrent device keys per event. Each device gets its own MLS leaf, its own key package (kind 30443, with a stable client_id slot per device), and its own Welcome; each device sees history only from its own join epoch forward (MLS semantics: history never syncs, by design).

10.2 Chat Device Attestation (21607)

Sealed by the account key to the coordinator (schema in §6.3). proof is a BIP-340 signature by the chat device key, required on op:"add", over:

sha256( utf8( JSON.stringify(
  ["nostrautica-chat-device-v2", <coordinate>, <account-pubkey>, <chat_pubkey>, <created_at>] ) ) )

The coordinator MUST verify the proof before binding a device to an account, an account cannot attest a key it does not control. Only attested device keys are chat members: the coordinator authorizes exactly the active attested device keys and nothing else: the attendee/organizer account pubkey is never an implicit chat identity. A local-key account is no exception; it mints and attests its own per-device chat key like any other account type (§10.1), and that attested device (not the raw account key) is what participates. (The one way an account key can become a chat member is an explicit §10.5 link of that key, which makes it an attested, roster-visible, cap-counted, revocable device like any other.) op:"revoke" needs no proof (the account is evicting a key it already named; possession is irrelevant to that decision). Bindings are per (coordinate, account); a chat pubkey MUST NOT be bindable to two different accounts; rebinding it to the same account (e.g. re-add after revoke) mints a fresh binding. On account revocation from the event, all of that account's device leaves are removed from the MLS group.

10.3 Device profiles (kind 0 on chat relays)

So that other Marmot clients (e.g. White Noise) display a human name for each device member, every chat device publishes a kind 0 profile signed by the chat device key, to the event's chat relay set only (the Marmot relays. Never the account's general relays):

{ "name": "<account display name>", "about": "<note pointing at the account's npub>", "picture": "<optional>" }

name equals the account's event display name (falling back to a generic label); devices belonging to one account share the same name. about references the owning account's npub in prose, so external clients can verify and group devices by account. This is an accepted, stated consequence: the device→account link is public on the chat relays; the ECK-encrypted roster chat_keys mapping remains the authoritative binding for Nostrautica clients themselves.
The app MUST NOT publish or fetch account kind 0 on chat relays, and MUST NOT publish device kind 0 anywhere else.

10.4 Event→group routing

The roster's nostr_group_id is the authoritative binding from coordinate to the active MLS group. A newly received Welcome joins into an unbound candidate state: no listener binding, no history replay, no display, no sending until a verified roster nostr_group_id matches. Roster-fetch failure keeps the candidate pending, fail-closed: a client that cannot verify the binding must not guess it.
The coordinator SHOULD additionally include the event coordinate in the Marmot group's name/description metadata as defense in depth; clients treat it as a hint, not authority.

10.5 Linking an external Marmot client

An approved attendee MAY link the identity of an external Marmot client (e.g. a White Noise npub, W) to their account for one event, so that the coordinator adds W to the event's group and the attendee can also chat from that client. W may equal the account key or be unrelated to it. The external client cannot produce a §10.2 proof (it never sees the challenge), so possession is proven differently, and the coordinator, never the attendee, adds W: it holds the account⇄key binding and removes the key again on revoke or withdrawal.

Request. The account seals a 21607 {op:"link", chat_pubkey: W, label} (no proof, no code). The coordinator MUST reject it unless the sealer is an approved attendee of an event with an active group, and MUST apply the same rules as op:"add": W bound to another account is refused (first binder wins), and W counts toward MAX_CHAT_KEYS_PER_ACCOUNT. A W already actively bound to this account needs no new proof; the coordinator just re-syncs it.
Self-link (W = the sealing account key): the seal proves possession. The coordinator binds W immediately and adds it.
Any other W: confirmation code. The coordinator:
- keeps at most one pending link per (coordinate, account); a newer request supersedes the older one, whose code stops working;
- SHOULD rate-limit requests per (coordinate, account) (reference: 5 per hour), since each one makes it invite a key the requester chose;
- discovers W's kind-30443 key package (event relays first, then W's own kind-10002 relays) and resolves W's kind-10050 inbox relays the same broad way (default relays plus the chat interop relays, then W's kind-10002 relays);
- creates a fresh two-member Marmot group (coordinator as sole admin, plus W) named "Nostrautica: confirm White Noise link", gift-wraps the Welcome to W's inbox relays, and posts one kind-9 application message carrying a one-time code and an instruction to type it into Nostrautica and not to share it;
- generates the code with a CSPRNG: CHAT_LINK_CODE_LENGTH = 8 characters from CHAT_LINK_CODE_ALPHABET = "23456789ABCDEFGHJKMNPQRSTUVWXYZ" (no 0/O, 1/I/L), displayed as XXXX-XXXX; stores only a hash of it, bound to (coordinate, account, W); expires it after 30 minutes; and kills it after 5 wrong attempts.
Confirm. The attendee accepts the invite in the external client, reads the code, and types it into Nostrautica, which seals {op:"link_confirm", chat_pubkey: W, code}. Both sides compare codes after normalizeChatLinkCode (uppercase; spaces, dots and dashes removed). On a match the coordinator binds W to the account as an active chat key flagged external, adds it to the event group through the normal member-sync path, and then removes W from the confirmation group and discards that group (best effort). The coordinator SHOULD NOT invite W to the event group with the key package the confirmation group consumed while a rotated one may still appear (reference grace: 90 s); after that it MAY use it, which is correct for a last-resort key package.
Afterwards W is an ordinary attested device: it is listed in the roster's chat_keys with external: true (so Nostrautica clients can label it), counts toward the cap, and is removed with the existing op:"revoke" (a real MLS Remove). A linked external key is never promoted to MLS co-admin, even for an organizer. Like any new member it sees messages from its join epoch forward only.
Feedback. Outcomes reach the account as 21606 notices with stage: "chat_link": state: "cleared" when the code has been posted or the key linked, and state: "poison" with one of these error_category values on refusal: chat_link_unavailable, chat_link_rate_limited, chat_link_no_key_package, chat_link_failed, chat_link_no_pending, chat_link_expired, chat_link_code_wrong, chat_link_too_many_attempts, chat_device_cap_reached, chat_key_bound_to_other_account, chat_key_package_ineligible. Clients treat an unknown category as a generic failure.

The code proves that whoever typed it could read a group only W's holder can decrypt. It does not stop W's holder from deliberately handing the code to someone else, which is equivalent to them consenting to the link.

11. Talks

Normative caps: at most 10 distinct talk_d per speaker per event; a talk carries exactly one of a media descriptor (whose kind must be "talk") or an external_url (+ external_kind:"youtube"|"video"); a published 31610 is republished under a new ECK on rotation, with the old-address copy NIP-09-deleted. External-URL talks (a YouTube link or a direct .mp4 hosted off-Blossom, for clips too large to upload) live inside the ECK-encrypted content (members-only), but are never fetched by the coordinator (the §8 media-fetch allowlist is Blossom-origin-only), so they are view-only: never transcribed, never fed into matching. process_for_matching (default false) gates whether a Blossom talk is transcribed and folded into matching at all; talks are not matched by default.

12. Deletions

The coordinator issues NIP-09 kind-5 with both ["a", "<kind>:<pubkey>:<d>"] and ["k","<kind>"] for: a revoked or withdrawn attendee's 31603, a 31606 on visibility downgrade, and obsolete 31610 addresses after rotation or rejection. Deletion is best-effort; the privacy model never depends on relays honoring it.

A retention sweep that deletes a 31604 MUST cover every page address the roster could have used (<event-d> and <event-d>:1…<event-d>:39), not only the pages it currently has. A roster that grew and later shrank leaves higher pages on relays that no reader asks for — pages on page 0 says they are not there — but they still hold member pubkeys, and nothing records how many pages an event ever had. Deleting an address that was never published is a no-op at the relay; missing one leaves member data behind.

13. Security considerations

Forward-only revocation: anyone who held a key reads everything published while it was current, forever. Stated in organizer UI. MLS chat removal has real post-compromise security, unlike ECK rotation.
Coordinator trust: reads all event-encrypted content, holds E_inbox/ECK, grants, publishes member records, reads and administers chat. Cannot sign as E_id. Its authority ends at detach (§3.5), enforced by record-authority pinning (§3.7).
Accepted metadata leaks: attendee counts (directory-entry counts), submission timing (E_inbox p-tags), cross-event blob-hash linkage without a "fresh copy," chat relay traffic patterns, device-profile names on chat relays (§10.3).
Organizer CSS (31609) is presentation control by the same party that controls all rendered text; it is not a secret-safe boundary. Clients MUST NOT render event themes on routes where secrets (invite nsecs, key backups, chat handoff) appear.
Prompt injection into AI profiles/matching by attendee content remains semantically possible; outputs are length-capped and URL-neutralized at the coordinator's publish boundary (§6.2 31603); organizers see provenance.
21605 organizer grants are irrevocable full custody: co-organizers are cryptographically indistinguishable from the creator. Scoped roles are not part of this protocol.
Readers MUST only accept coordinator-authored kinds from the currently assigned coordinator (§3.7): a formerly assigned coordinator's records are ignored once a newer 31600 no longer names it.

14. Constants appendix

Wire-normative bounds (packages/protocol/src/schemas.ts, crypto.ts, giftwrap.ts, config.ts, event-page.ts unless noted):

NIP-44 plaintext ceiling: 65,535 bytes, enforced at every encrypt entry point.
Blinded d length: 32 hex chars (128 bits of HMAC-SHA256 output).
Gift-wrap subscription window: now − 259,200 s (3 days). Wrap timestamp randomization: ≤ 2 days into the past. Rumor future-timestamp clamp: RUMOR_MAX_CLOCK_SKEW_SEC = 900 s (15 min).
Admin command replay horizon: ADMIN_COMMAND_TTL_SEC = 172,800 s (48 h), client default.
MAX_NAME 200, MAX_MESSAGE 2000, MAX_ABOUT 5000, MAX_LOOKING_FOR 2000, MAX_SKILLS 50, MAX_SKILL 200, MAX_LINKS 20, MAX_URL 2048, MAX_INVITE_LABEL 100, MAX_INVITES 10000, MAX_REASONING 2000, MAX_MATCHES 100, MAX_ROSTER 2000 (total across roster pages), MAX_ROSTER_PAGE 700 (entries in one 31604 page), MAX_ROSTER_PAGES 40, MAX_RELAYS 30, MAX_MEDIA 20 (31602), MAX_SUBMISSION_MEDIA 4 (21601), MAX_D 200, MAX_MATCH_PAIRS 200000, MAX_TITLE 300, MAX_POST_BODY 100000, MAX_NOTES 2000, MAX_NOTE 5000, MAX_LANG 35, MAX_TRANSCRIPT_TEXT 100000, MAX_INTRO_TEXT 2000, MAX_LIBRARY_TEXTS 20, MAX_TALK_TITLE 200, MAX_TALK_DESC 2000, talk_d length 1..64, MAX_CHAT_KEY_LABEL 60, MAX_CHAT_KEY_CLIENT_ID 120, MAX_CHAT_KEYS_PER_ACCOUNT 10, MAX_CHAT_LINK_CODE_INPUT 32, CHAT_LINK_CODE_LENGTH 8 (alphabet CHAT_LINK_CODE_ALPHABET, §10.5).
External-client link (§10.5, coordinator reference values): code lifetime 30 min, 5 wrong attempts, 5 link requests per account per event per hour, 90 s grace before reusing the key package the confirmation group consumed.
Icebreakers (31605, §6.2): ≤ 3 per match entry, ≤ 280 chars each.
Members-only post markdown editor cap: 60,000 UTF-8 bytes (MAX_MEMBERS_POST_MARKDOWN_BYTES). Theme CSS: 32,768 bytes (MAX_THEME_CSS_BYTES).
Roster page packing budget once a roster paginates: 60,000 UTF-8 bytes (ROSTER_PAGE_TARGET_BYTES, §6.2.1). Whether to paginate at all is decided at the real 65,535-byte ceiling, so a roster that fits today is never split.
Media descriptor: size ≥ 1 byte; duration required for audio/* and video/* mime types; decryption key decodes to exactly 32 bytes, nonce to exactly 12 bytes.

Coordinator operational defaults (packages/coordinator/src/coordinator.ts and neighboring modules, tunable per deployment, not part of interop compatibility):

DEFAULT_MAX_EVENTS 50 installations per coordinator.
Media processing: ≤ 4 descriptors processed per submission (MAX_MEDIA_PER_SUBMISSION, mirrors the schema's MAX_SUBMISSION_MEDIA), ≤ 500 MiB declared bytes per submission (MAX_SUBMISSION_MEDIA_BYTES).
MAX_TALKS_PER_SPEAKER 10 distinct talk_d per speaker per event.
Gift-wrap live-processing retry backoff: [5 s, 30 s], then the rumor is left unseen for the next backfill rescan.
Pipeline job retry: default backoff escalates from 1 s through hourly and then four-hourly steps, keeping a job retrying for at least 3 days before it poisons and emits a 21606 status.
Matching: topK 20 (match list size), batchSize 10 (scoring batch), embedding prefilter default threshold 50 attendees / topM 30 / random 10.
Publish-time defense-in-depth caps on 31603 (tighter than the intake schema, §6.2): about/looking_for/intro_text/name 4000/4000/4000/200 chars, links 32 × 500 chars, transcript text 8000 chars, LLM-authored strings (ai_profile.*, match reasoning) word-boundary-truncated to 2000 chars with URL schemes stripped.
Marmot: key-package kind 30443, group-message kind 445 (routed by #h); the Whitenoise relays (wss://relay.us.whitenoise.chat, wss://relay.eu.whitenoise.chat) are the chat interop set: carried in the config's chat_relay tags and in the group's own MLS routing state, never in the event's relay set.

15. Space hierarchy: a community and its events

A community (31612, §1.1) can own dated events (31923): a meetup series and its meetups. Membership flows up only. Whoever is approved for one of a community's events may join the community without a second approval; nothing flows down, so a community member is not a member of any event they did not join, and leaving an event does not leave the community. Each space keeps everything it has today: its own E_id, E_inbox, ECK, roster, directory, matches and group chat.

15.1 The link

A link exists between community P and event C iff, in the newest configs (§3.1):

C's 31600 carries ["parent", P], and
P's 31600 carries ["child", C].

Both sides are required. Each is signed by its own E_id, so the community's organizer decides which events confer membership (an unrelated event naming someone else's community as its parent gains nothing), and the event's organizer decides which community its attendees are offered. A parent MUST be a 31612 coordinate and a child a 31923 coordinate; readers drop any other value fail-soft. Removing either tag ends the link for every future join; memberships already granted are not revoked.

The two spaces need not share a coordinator, nor have one at all. Organizer clients SHOULD default a child event to its community's coordinator and relays.

15.2 Membership proof

A signature by an authority of the child, which is C's E_id or the coordinator named in C's newest 31600, over:

challenge = sha256( utf8( JSON.stringify(
    ["nostrautica-member-of-v1", <P coordinate>, <C coordinate>, <attendee-pubkey-hex>] ) ) )

The domain tag and the JSON array follow §7's construction. The proof binds the attendee, the child and the parent, so it cannot be replayed for another person, event or community. Authority is evaluated at verification time against C's newest config: a proof signed by a coordinator C has since replaced stops verifying.

15.3 Carrying the proof

In the child's key grant. When C is linked to P, an authority issuing a 21602 for C SHOULD include parent: { a: P, by, sig }. When a link comes into existence for an event that already has approved attendees, C's coordinator (or, without one, an organizer client) SHOULD re-issue a 21602 carrying the proof to each of them once, so that people who joined before the link can join the community too. Receivers union-merge as usual (§6.3); the proof field is independent of custody.
In the community join. The attendee's client sends an ordinary 21600 to P's E_inbox (plus a 21601 profile, typically a copy of the one it gave C) with ["member_of", C, by, sig]. The attendee's own signer seals it: no party joins anyone to a community on their behalf.

15.4 Verification and approval

Whoever approves joins to P (its coordinator, or an organizer client in manual mode) accepts a member_of tag iff:

C is linked to P (§15.1), checked against both newest configs;
by is an authority of C (§15.2); and
the signature verifies.

A coordinator that accepts it auto-approves the join exactly as for a valid invite (§7): same roster ceiling, same grant path. Without a coordinator, an organizer client SHOULD show the verified membership next to the request and MAY approve it in one action. Direct joins to the community (invite or manual approval) are unaffected.

15.5 Clients

The join form of a child event MUST disclose that joining also makes the person a member of P, with its title, and SHOULD let them opt out. With consent, the client sends the community join itself once the child's grant (carrying the proof) arrives.
Holding a proof for P without being a member or a pending applicant of P (for example after a re-issued grant), a client SHOULD offer joining P in one action rather than join silently.
A child event's page links to P; a community's page lists its children (§3.1-newest config), upcoming first.

15.6 Compatibility

Additive only, no v bump. Readers that predate this section ignore the parent and child tags and drop the grant's parent field. A coordinator that predates it treats a member_of join as having no invite and queues it for manual approval, which is stricter than intended rather than looser.

NIP-XX: Encrypted Event Networking (Nostrautica Protocol)

1. Terms and actors

1.1 Community (kind 31612)

2. Wire version

3. Ordering, replaceability, and revisions

3.1 Latest-event rule (all replaceable/addressable kinds)

3.2 Monotonic publishing

3.3 Revisioned mutable submissions

3.4 Admin command ordering and replay horizon

3.5 Coordinator installation generation and detach

3.6 Grant authority

3.7 Detach hygiene, record authority, and handover

4. Encryption model

5. Gift wraps

6. Kinds

6.1 Registry

6.2 Addressable kind specifications

31600: Event Networking Config

31601: Invite List

31602: Self Event Profile / Reuse Library

31603: Directory Entry

31604: Roster

6.2.1 Roster pagination

31605: Match List

31606: Match Matrix

31607: Members-only Event Post

31608: Event Page (menu + layout)

31609: Event Theme

31610: Talk

31611: Coordinator Announcement

6.3 Rumor kind specifications

21600: Join Request

21601: Profile Submission

21602: Key Grant

21603: Coordinator Grant (install)

21604: Admin Command

21605: Organizer Grant

21606: Coordinator Status

21607: Chat Device Attestation

21608: Profile Correction

21609: Talk Submission

21610: Attendee Withdrawal

7. Invite codes

8. Media descriptors

9. Coordinator lifecycle, billing, and announcements

10. Group chat (Marmot/MLS) and multi-device

10.1 Model

10.2 Chat Device Attestation (21607)

10.3 Device profiles (kind 0 on chat relays)

10.4 Event→group routing

10.5 Linking an external Marmot client

11. Talks

12. Deletions

13. Security considerations

14. Constants appendix

15. Space hierarchy: a community and its events

15.1 The link

15.2 Membership proof

15.3 Carrying the proof

15.4 Verification and approval

15.5 Clients

15.6 Compatibility

1.1 Community (kind `31612`)

`31600`: Event Networking Config

`31601`: Invite List

`31602`: Self Event Profile / Reuse Library

`31603`: Directory Entry

`31604`: Roster

`31605`: Match List

`31606`: Match Matrix

`31607`: Members-only Event Post

`31608`: Event Page (menu + layout)

`31609`: Event Theme

`31610`: Talk

`31611`: Coordinator Announcement

`21600`: Join Request

`21601`: Profile Submission

`21602`: Key Grant

`21603`: Coordinator Grant (install)

`21604`: Admin Command

`21605`: Organizer Grant

`21606`: Coordinator Status

`21607`: Chat Device Attestation

`21608`: Profile Correction

`21609`: Talk Submission

`21610`: Attendee Withdrawal