Wire-protocol specs for nostrnests-style audio rooms, in the style of Nostr NIPs and Blossom BUDs. Each spec documents one self-contained capability that a client or relay can implement; two compliant peers implementing the same set of EGGs round-trip without further coordination. Layout: README.md cover, status table, conformance levels EGG-01.md Room event (kind:30312) required EGG-02.md Auth + WebTransport handshake required EGG-03.md Audio plane (moq-lite) required EGG-04.md Presence (kind:10312) required EGG-05.md In-room chat (kind:1311) optional EGG-06.md Reactions (kind:7) optional EGG-07.md Roles & moderation (kind:4312) optional EGG-08.md Scheduling (status=planned) optional EGG-09.md User server list (kind:10112) optional EGG-10.md Theming (c/f/bg tags) decorative EGG-11.md Recording decorative EGG-12.md Catalog track (catalog.json) optional Conformance levels (Listener / Speaker / Host) defined in the README so a deployment can declare "we implement EGG-01..EGG-04" and other peers know exactly what to expect. Each spec follows the same shape (Summary / Wire format / Behavior numbered MUST/SHOULD/MAY rules / Example / Compatibility) and fits on a single printed page. Wire formats are documented exactly as nostrnests + amethyst implement them on this branch — no hypothetical capabilities, no "future" tags without an EGG number.
4.5 KiB
EGG-07: Roles & moderation (kind:4312)
status: draft
requires: EGG-01, EGG-04
category: optional
Summary
Hosts and admins manage the room by re-publishing the kind:30312 event
with updated p-tag role markers, and (for kicks) by emitting a separate
kind:4312 admin command. Authorization is signature-based: receivers
gate inbound commands on the signer's role at the time of receipt.
Wire format
Role markers (in kind:30312)
The 4th element of a p-tag, when present, is the role:
["p", "<pubkey>", "<relay hint>", "host" | "admin" | "speaker"]
Effective roles:
| value | privileges |
|---|---|
host |
full control; one host per room (the event author) |
admin |
promote / demote / kick; cannot edit room metadata |
speaker |
may publish audio (EGG-03 put claim required) |
| (omitted) | listener — no publish rights |
Admin command (kind:4312)
{
"kind": 4312,
"pubkey": "<host or admin pubkey hex>",
"tags": [
["a", "30312:<host pubkey hex>:<room d>", "<relay hint>"],
["p", "<target pubkey hex>"],
["action", "kick"]
],
"content": "",
...
}
kind:4312 is an ephemeral event — receivers MUST NOT persist it past
the 60-second validity window defined below.
Behavior
Promote / demote
- To promote a listener to speaker, the host or an admin MUST re-publish
the
kind:30312event with the target added (or updated) as["p", <target>, "<relay>", "speaker"]. The new event'screated_atMUST be greater than the previous one. - To demote, the host or admin MUST re-publish the
kind:30312event without the role marker (drop the 4th element of thep-tag) or remove thep-tag entirely. - Hosts MUST NOT demote themselves. Demoting the host (changing the
event author's
p-tag fromhost) is undefined and MAY be ignored by receivers. - The
hostrole is determined by event authorship, not byp-tag marker. The["p", <author>, _, "host"]tag is descriptive only. - Speakers and admins SHOULD NOT delete or edit each other's role markers in their own re-publishes (only the host's re-publish is authoritative, but admins MAY drive promote/demote).
Kick
- To kick a participant, a host or admin signs and broadcasts a
kind:4312event withaction="kick"and ap-tag pointing at the target. - Receivers MUST gate inbound
kind:4312events:- The signer MUST currently hold
hostoradminrole on the activekind:30312(most recentcreated_atper(kind, pubkey, d)). - The event's
created_atMUST be within the last 60 s. - The
a-tag MUST match the room the receiver is in. - The
["action", "kick"]element MUST be present. Events failing any gate MUST be silently discarded.
- The signer MUST currently hold
- The TARGET of a kick MUST disconnect from the audio plane (close the moq-lite session) and tear down the in-room UI.
- The kick command does NOT also demote the target. The host MAY follow
up with a
kind:30312re-publish dropping the target's role tag; the client-side filter then prevents future presence events from the target re-rendering them in the participant grid. - The relay MUST NOT enforce kicks. Authorization is purely client-side and signature-based.
Example
Host promotes a listener to speaker:
{
"kind": 30312,
"pubkey": "abc...host",
"created_at": 1714003250,
"tags": [
["d", "office-hours-2026-04"],
["room", "Office Hours"],
["status", "open"],
["service", "https://moq.nostrnests.com"],
["endpoint", "https://moq.nostrnests.com"],
["p", "abc...host", "wss://relay.example", "host"],
["p", "def...co", "wss://relay.example", "speaker"],
["p", "ghi...newSpeaker", "wss://relay.example", "speaker"]
],
"content": "",
"id": "...",
"sig": "..."
}
Admin kicks a disruptive participant:
{
"kind": 4312,
"pubkey": "jkl...admin",
"created_at": 1714003280,
"tags": [
["a", "30312:abchost:office-hours-2026-04"],
["p", "mno...troll"],
["action", "kick"]
],
"content": "",
"id": "...",
"sig": "..."
}
Compatibility
kind:4312 is intentionally a Nostr event, not a moq-lite control message,
so non-broadcasting clients (web, mobile, headless bots) can apply
moderation without speaking to the relay.
Future EGGs MAY introduce additional action values (e.g. "mute",
"warn"). Implementers MUST treat unknown actions as no-ops.