Skip to content

extend SMP protocol to support name availability queries by labelhash - #1863

Open
brenzi wants to merge 59 commits into
masterfrom
ab/snrc-resolver-SMP-NAVL
Open

extend SMP protocol to support name availability queries by labelhash#1863
brenzi wants to merge 59 commits into
masterfrom
ab/snrc-resolver-SMP-NAVL

Conversation

@brenzi

@brenzi brenzi commented Sep 5, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Let users query name availability by labelhash (without revealing plaintext name unless it resolves)
They should get a precise answer with details in all possible cases (expired, grace, auction, reserved)

  • bump SMP protocol version to 22
    • make sure to roll out snrc resolver (which is reverse-compatible) before upgrading any production SMP relay to v22. otherwise .testing names will stop resolving for everybody using v22 relays

e2e test against

brenzi and others added 20 commits September 3, 2026 17:23
@brenzi
implement resolving 2LD names by labelhash
a8cee35
@brenzi
tiny test addition
bd4b07a
@brenzi
simplify language
e670d9f
@brenzi
report expiry and availability correctly
9b2ff82
@brenzi
compare block instead of wall clock
41678c7
@brenzi
simplify language
2cfc6d3
@brenzi
simplify language
e4e3d0d
@brenzi
map resolver 410 to NAME NOT_FOUND (a lapsed name is an answer, not a…
7e91f2e 
… failure)
@brenzi
split error into a machine-readable code and a human message
17451a6
@shumvgolove
resolver: reduce comments
ad4077b
@shumvgolove
merge ab/resolver-labelhash-query
bcc9b36 
# Conflicts:
#	scripts/resolver/README.md
#	scripts/resolver/service/snrc-resolve.py
#	scripts/resolver/service/test_snrc_resolve.py
@shumvgolove
resolver: reduce comments, remove REVIEW.html
c47aedd
@brenzi
extend SMP protocol to support name availability queries with accurat…
e3f00b4 
…e and meaningful replies
@brenzi
review fixes
69cce33
@brenzi
more review fixes
783f0aa
@brenzi
docs shortening and other review fixes
45d314c
@brenzi
add catch all for furture variants
c99cc61
@brenzi
adversarial review (against simplex-chat) fix
5c48027
@brenzi
next iteration fixes
3b4a7f2
@brenzi
adapt house style
99adfe9
@brenzi brenzi mentioned this pull request Sep 6, 2026
Open
epoberezkin
epoberezkin reviewed Sep 7, 2026
View reviewed changes
Comment thread src/Simplex/Messaging/Server/Names.hs Outdated
epoberezkin
epoberezkin reviewed Sep 7, 2026
View reviewed changes
Comment thread src/Simplex/Messaging/Server/Names.hs Outdated
epoberezkin
epoberezkin reviewed Sep 7, 2026
View reviewed changes
Comment thread src/Simplex/Messaging/Protocol.hs Outdated
epoberezkin
epoberezkin reviewed Sep 7, 2026
View reviewed changes
Comment thread src/Simplex/Messaging/Protocol.hs Outdated
epoberezkin
epoberezkin reviewed Sep 7, 2026
View reviewed changes
Comment thread src/Simplex/Messaging/Protocol.hs Outdated
epoberezkin
epoberezkin reviewed Sep 7, 2026
View reviewed changes
Comment thread src/Simplex/Messaging/Protocol.hs Outdated
epoberezkin
epoberezkin reviewed Sep 9, 2026
View reviewed changes
Comment thread src/Simplex/Messaging/Protocol.hs Outdated
epoberezkin
epoberezkin reviewed Sep 10, 2026
View reviewed changes
Comment thread src/Simplex/Messaging/Protocol.hs Outdated
epoberezkin
epoberezkin reviewed Sep 10, 2026
View reviewed changes
Comment thread src/Simplex/Messaging/Protocol.hs Outdated
epoberezkin
epoberezkin reviewed Sep 10, 2026
View reviewed changes
Comment thread src/Simplex/Messaging/SimplexName.hs Outdated
@brenzi
brenzi removed this pull request from stack #1862 September 10, 2026 11:29
@brenzi
brenzi changed the base branch from ab/snrc-resolver-expiry-and-availability to master September 10, 2026 11:29
This was referenced Sep 10, 2026
Closed
Closed
@brenzi brenzi changed the title extend SMP protocol to support name availability queries extend SMP protocol to support name availability queries by labelhash Sep 10, 2026
@brenzi
derive NameRegistration JSON the same way on every build
288978a 
  sumTypeJSON switches to the _owsf form on swift builds, but this JSON is
  the RNAME payload and the resolver's HTTP contract, so a swift client and
  a Linux relay would disagree on every field. taggedObjectJSON is what it
  already resolves to everywhere else.

  The label modifier keeps the reservedReason_ collision escape out of the
  API, as AgentWorkersDetails does: both arms now say reservedReason.
@brenzi
fix resolver boundary: status before body, cover /v2, drop dead field
ccdb4c8 
  httpGet read the response body before checking the status, so an oversized
  error page surfaced as a transient "response too large" instead of the
  authoritative status. Reverting it to its previous shape restores that and
  removes the status test both callers had been re-deriving.

  registration() had no tests at all, though it is the endpoint SMP v22
  consumes. RegistrationV2Tests covers the three answer shapes, the error
  paths and the exact key set of each, which is the wire contract.

  auctionUntil was always None with no consumer. The spec claimed a reason
  word travels unchanged; a resolver can only send a word it has, and SNRC's
  registry records a number.
@brenzi
fix review findings
a3fb63f
@brenzi
resolver errors say what went wrong, not "no such name"
ef97b86 
  /v2/resolve answers 200, 400 or 502, and an unregistered name is
  NRAvailable, so no status means "not registered". Mapping 400/404/410 to
  NOT_FOUND made a misconfigured relay deny every name, and hid a relay
  upgraded ahead of its resolver. All three now surface as RESOLVER.

  rslvNotFound would have gone dead, so it counts what its name says: an
  availability answer the encoder downgrades for a session below v22. The
  wire is unchanged.

  A hashed query the registrar cannot name is refused with 502 rather than
  answered with a record named "unknown", which the client rejects anyway.
  NRRUnknown is capped to 32 printable characters again, as the spec says.
  A registered name that is also reserved no longer offers a date it will
  never free up on. rentPrices is registrationPrices throughout, and
  yearPriceUSD is USDCents rather than a bare Int64.
@brenzi
fix regressions found reviewing the last two commits
2b2d2d4 
  resolveNameMsg read the version off thParams', which on the PFWD path is
  the proxy's session, not the client's. It takes the version as an argument
  now, so each call site passes its own — the forwarded one uses fwdVersion.

  reservedReasonOf matched the reason words before capping, so "internal
  review" became NRRUnknown "internal", which encodes back as NRRInternal.
  Capping precedes the match, so what is kept encodes to what it decoded.

  Four agent tests still pinned NAME NOT_FOUND from a 404 stub, and two spec
  statements still described the old mapping. A registrar that does not
  record labels cannot answer a hashed query, which the resolver README now
  says.
@brenzi
docs sweep
ac442e4
epoberezkin
epoberezkin reviewed Sep 11, 2026
View reviewed changes
Comment thread src/Simplex/Messaging/Client.hs Outdated
epoberezkin
epoberezkin reviewed Sep 11, 2026
View reviewed changes
Comment thread src/Simplex/Messaging/Client.hs Outdated
epoberezkin
epoberezkin reviewed Sep 11, 2026
View reviewed changes
Comment thread src/Simplex/Messaging/Names/Record.hs Outdated
@brenzi

brenzi commented Sep 11, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author
  • e2e tests green: hardhat (.simplex names v2 contracts) - RESOLVERv2 - SMPv22 - CLIv22
  • test the version matrix pre/post for all stages locally with hardhat (.simplex names v2 contracts)
  • test a v22 client against v22 smp7 against mainnet .testing
  • test a v22 client against stable pre-v22 smpX against mainnet .testing

Version matrix: resolver x SMP relay x client

Run live on a local hardhat chain with the lifecycle fixture, .simplex.

binary build behaviour
relay pre master 200129a max SMP v21, queries /resolve
relay post branch 1cb8146 max SMP v22, queries /v2/resolve
client pre branch, currentClientSMPRelayVersion capped to 21 plaintext query, decodes via oldRegistration
client post branch hashed query, full NameRegistration
resolver pre master 200129a snrc-resolve.py serves /resolve only
resolver post branch serves /v2/resolve, /v1/resolve, /resolve

/name <name>.simplex

relay resolver client alicename (registered) ghostname (never registered)
pre pre pre registered NAME NOT_FOUND
pre pre post registered NAME NOT_FOUND
pre post pre registered NAME NOT_FOUND
pre post post registered NAME NOT_FOUND
post pre pre NAME RESOLVER "HTTP 404" NAME RESOLVER "HTTP 404"
post pre post NAME RESOLVER "HTTP 404" NAME RESOLVER "HTTP 404"
post post pre registered NAME NOT_FOUND
post post post registered, expires 2036-09-08, free to register from 2036-12-07 unless renewed by owner available, $10.00 a
year

Only relay=post + resolver=pre is broken, and it fails every name: /v2/resolve
does not exist on the old resolver, while /health still reports it ready.
Upgrade the resolver before the routers.

An old client against a full v22 stack degrades as specified: bare registered
with no expiry, and NOT_FOUND for a name that is in fact available. Only
post/post/post carries expiry, grace and a price.

Old relay, both resolvers: states the table above does not reach

resolver lapsedname (past grace) barename (registered, no resolver set) heldlapsed (past grace + reserved)
pre registered NAME NOT_FOUND registered
post NAME RESOLVER "HTTP 410" registered NAME RESOLVER "HTTP 410"

Two behaviour changes while the resolver is ahead of the relays. A lapsed name
stops resolving to its stale record, which is the intended fix, but arrives as a
raw 410 because master's mapResolverError has no 410 case. A registered name
with no resolver set flips from NOT_FOUND to resolving with an empty record.

epoberezkin
epoberezkin previously approved these changes Sep 11, 2026
View reviewed changes
@brenzi
fix resolver v2 for subnames (#1867)
85901ea 
* fix resolver v2 for subnames

* simplify doc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@epoberezkin epoberezkin epoberezkin left review comments
@spaced4ndy spaced4ndy Awaiting requested review from spaced4ndy spaced4ndy is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@brenzi @epoberezkin @shumvgolove