Skip to content

Route on kind:10050 instead of kind:10002 and the relays tag - #17

Open
alejandro-runner wants to merge 1 commit into
mainfrom
alejandro-dev
Open

Route on kind:10050 instead of kind:10002 and the relays tag#17
alejandro-runner wants to merge 1 commit into
mainfrom
alejandro-dev

Conversation

@alejandro-runner

Copy link
Copy Markdown
Member

Closes #16.

Reservation rumors are gift-wrapped private messages. kind:10050 is the list a user publishes to declare where they receive private messages, which is exactly the question routing has to answer. kind:10002 describes where a user reads and publishes public notes, and a relay carrying someone's public activity does not necessarily accept or serve gift wraps addressed to them.

Spec — nostr-protocols/nips/rp.md

  • Relay Routing rewritten: clients MUST publish a kind:10050 and MUST look up the recipient's before sending. A counterparty with no discoverable list is unroutable, and clients SHOULD say so rather than publishing to a guessed relay.
  • The p tag is stated as not a routing mechanism.
  • New Legacy Routing Fallbacks subsection: relays is MAY, and when no kind:10050 is discoverable the fallback order is the thread's most recent relays tag, then kind:10002 read relays, then the p tag hint.
  • The relays tag definition is marked deprecated and optional; the four rumor examples carry the same note.
  • All six Protocol Flow sequences now route on kind:10050.

Schemas — kind-9901 through kind-9904

relays moves from a required contains to the anyOf / not optional pattern the other optional tags in these files already use, so a message omitting it validates and one including it is still shape-checked. All five schemas parse.

The open question in #16, decided

#16 left open whether to retire relays or demote it. Demoted, because reservations shipped in Milestone 1 on 2026-08-05 and a hard removal would break the running server mid-thread. Writers should stop emitting it; readers keep accepting it until deployed clients migrate. How long that transition lasts is still unsettled.

Not in this PR

The implementing services still route the old way, and none of them can publish a kind:10050 yet:

  • @synvya/capabilitiesbuild-reservation-request.ts still requires at least one relays URL. The builder for kind:10050 is capabilities#90.
  • server/src/routing/resolver.ts resolves from threadRelays only, with no relay-list lookup of any kind.
  • diners/ — publishes no relay list.

Until those land, this spec describes a routing mechanism nothing implements. The relays fallback is what keeps reservations working in the meantime.

Related

  • Synvya/docs#61 — takeout, which routes on kind:10050 and is why the divergence surfaced.

Reservation rumors are gift-wrapped private messages. kind:10050 is the
list a user publishes to declare where they receive private messages,
which is the question routing has to answer. kind:10002 describes where
a user reads and publishes public notes, and a relay carrying public
activity does not necessarily serve gift wraps addressed to them.

Clients now publish a kind:10050 and look the counterparty's up. The
relays tag is demoted from MUST to MAY rather than removed, because
reservations are live: readers keep accepting it, and kind:10002 and
the p-tag hint remain ordered fallbacks while clients migrate.

Schemas for kind:9901-9904 move relays from a required contains to the
optional anyOf/not pattern the other optional tags already use.

Closes #16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Route on kind:10050 instead of kind:10002 and the relays tag

1 participant