Claude
5c40e27fde
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.
80 lines
2.4 KiB
Markdown
80 lines
2.4 KiB
Markdown
# 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:
|
|
|
|
```json
|
|
{
|
|
"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
|
|
|
|
1. Each `server` value MUST be a fully-qualified URL beginning with
|
|
`https://`. Receivers MUST reject (drop) entries that are not
|
|
well-formed HTTPS URLs.
|
|
2. 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).
|
|
3. 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).
|
|
4. Users MAY enumerate up to 64 servers. Receivers MUST tolerate longer
|
|
lists by truncating to the first 64.
|
|
5. 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.
|
|
6. 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
|
|
|
|
```json
|
|
{
|
|
"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.
|