Files

T

Claude 5c40e27fde docs(nestsClient/specs): EGG-00..EGG-12 — Extensible Gossip Guidelines

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.

2026-04-27 03:54:45 +00:00

2.4 KiB

Raw Blame History

EGG-09: User server list (`kind:10112`)

status: draft requires: NIP-01 category: optional

Summary

A user MAY publish a list of nests servers they prefer to host on. Clients read this list to default-fill the "service" and "endpoint" fields when the user opens a new room, and to suggest peer rooms in discovery surfaces.

This is the audio-rooms equivalent of the user-server-list patterns in Blossom (BUD-03) and Mostr.

Wire format

kind:10112 is a NIP-01 replaceable event with one entry per server:

{
  "kind": 10112,
  "pubkey": "<user pubkey hex>",
  "tags": [
    ["server", "<https URL — moq-auth/moq-relay base>"],
    ["server", "<https URL>"],
    ...
  ],
  "content": "",
  ...
}

Each ["server", url] is one entry. The relative ordering MUST be preserved by receivers — earlier entries are higher priority.

Behavior

Each server value MUST be a fully-qualified URL beginning with https://. Receivers MUST reject (drop) entries that are not well-formed HTTPS URLs.
Receivers MUST de-duplicate entries by exact-string match after trimming a single trailing /. Order of remaining entries MUST be preserved (the FIRST occurrence wins).
When the user opens the create-room sheet, the client SHOULD pre-fill the EGG-01 service and endpoint fields from the FIRST entry in the list (a single nests deployment serves both via the same base URL today).
Users MAY enumerate up to 64 servers. Receivers MUST tolerate longer lists by truncating to the first 64.
Hosts who list a server in their kind:10112 are not declaring an alliance — they are merely advertising "I will probably create rooms here". Receivers MUST NOT use the list as a moderation signal.
The list is purely a defaults / discovery hint. A kind:30312 event's own service / endpoint tags are authoritative for that specific room and override the user list at join time.

Example

{
  "kind": 10112,
  "pubkey": "abc...host",
  "created_at": 1714003000,
  "tags": [
    ["server", "https://moq.nostrnests.com"],
    ["server", "https://moq.example.org"]
  ],
  "content": "",
  "id": "...",
  "sig": "..."
}

Compatibility

A peer that does not implement EGG-09 simply does not pre-fill server fields and does not surface "rooms hosted by this user are usually on…" hints in profile screens. All other interop is unaffected.

2.4 KiB Raw Blame History

EGG-09: User server list (kind:10112)