extend SMP protocol to support name availability queries by brenzi · Pull Request #1863 · simplex-chat/simplexmq

brenzi · 2026-09-05T15:07:37Z

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)

also lets resolver report auction info: Name is available, but at premium price - or wait.

Assumes these get merged and deployed for .simplex, but PR works against .testing names as well.

assumes merged implement configurable prices for oracle simplex-network/ens-contracts#28
assumes merged implement reservation reason enum simplex-network/ens-contracts#30
bump SMP protocol version

…e and meaningful replies

Co-authored-by: Evgeny <evgeny@poberezkin.com>

…P-NAVL

brenzi · 2026-09-09T07:09:25Z

tested e2e locally with hardhat

mocked cases with dummy values:

  ghostname      | can be registered for $10.00 a year
  abc            | can be registered for $10000.00 a year     (tier 3)
  abcd           | can be registered for $1000.00 a year      (tier 4)
  abcde          | can be registered for $100.00 a year       (tier 5)
  abcdef         | can be registered for $10.00 a year        (base)
  ab             | is too short: names need at least 3 characters
  internalname   | is reserved for SimpleX
  trademarkname  | is reserved to protect a trademark
  communityname  | is reserved for the community
  lapsedname     | can be registered for $10.00 a year        (expired = registrable)
  heldlapsed     | is reserved to protect a trademark         (reservation survives expiry)
  gracename      | is registered to someone else, free to register from 2029-02-15

also, too short names can be resolved, just not registered publicly

  resolver  ab.simplex  -> HTTP 200  status=registered  expires=2177738883  contact=<alice's link>
  carol: /c @ab.simplex (2 chars, forced)  | alice: connection started
  carol: /c @xy.simplex (control)          | is too short: names need at least 3 characters
  carol: /c @abc.simplex (control, 3ch)    | can be registered for $10000.00 a year

caveat:

Messaging is now inconsistent as it mixes resolvability with registrability

…resolver-SMP-NAVL

epoberezkin · 2026-09-09T16:50:38Z

-      else do
-        bs <- brReadSome (responseBody res) (maxResponseBytes + 1)
-        pure $ if BL.length bs > fromIntegral maxResponseBytes then Left BodyTooLarge else Right bs
+    bs <- brReadSome (responseBody res) (maxResponseBytes + 1)


why status check removed?

epoberezkin · 2026-09-09T16:51:22Z

+-- | GET <baseUrl><path>, returning the response status and body bytes within the
+-- size cap. Redirects are disabled and Authorization is attached only when
+-- configured.


some spurious linebreak changes

epoberezkin · 2026-09-09T16:52:03Z

 resolveHttp env name =
-  (>>= first InvalidJson . J.eitherDecodeStrict . BL.toStrict)
-    <$> httpGet env ("/resolve/" <> B.unpack (urlEncode True (encodeUtf8 name)))
+  (>>= nameResp) <$> httpGet env ("/resolve/" <> B.unpack (urlEncode True (encodeUtf8 name)))


that looks like some drive-by refactoring. What is it doing and why?

epoberezkin · 2026-09-09T16:53:36Z

+  (Nothing, Nothing) -> Left NOT_FOUND
+
+-- | The resolver's status words. An unknown status is not an answer.
+mapStatus :: Maybe NameRecord -> NameStatusResp -> Either NameErrorType NameRegistration


very complex - what is the problem here?

Looks like translation between what resolver returns and what we want in protocol.

We cannot upgrade all servers at once so what resolver returns should be compatible, so splitting "status" to separate record kind of makes sense from this point of view.

But a better solution would have been exposing a different version endpoint in resolver that responds to old server what it wants and to new server what it wants - the same type we defined elsewhere. This would avoid this mapping entirely.

I assumed the resolver and SMP relay get updated at the same time as they are shipped together. But yes, we could just introduce a new version in the url path and stay compatible with the old SMP relays. Anyway, I think it is a good idea to let the resolver respond with the data model that can be parsed straight into the SMP type

ah, now I remember: only one light client and resolver for the cluster, right? Then I suggest we do it properly with a /v2/ path on the resolver

epoberezkin · 2026-09-09T16:54:57Z

-      sendProtocolCommand c nm Nothing NoEntity (Cmd SResolver (RSLV name)) >>= \case
-        RNAME nr -> pure nr
+  | v >= namesSMPVersion =
+      sendProtocolCommand c nm Nothing NoEntity (Cmd SResolver (RSLV (nameQuery v name))) >>= \case


this decision is already made during the protocol encoding - why are we doing it here as well?

It feels like it's a knockdown effect of not putting the right type into the protocol. If we say that whether we use hash or name is version dependent, then RSLV should just accept SimplexDomain and compute its hash during encoding.

epoberezkin · 2026-09-09T16:58:00Z

  RFWD :: EncFwdTransmission -> Command ProxyService -- use CorrId as CbNonce, proxy to relay
  -- Resolve SimpleX name.
-  RSLV :: SimplexDomain -> Command Resolver
+  RSLV :: NameQuery -> Command Resolver


see comment above - I think it should remain SimplexDomain?

probably not...

epoberezkin · 2026-09-09T17:07:20Z

+-- hash, knows neither. The formula is in protocol/simplex-messaging.md.
+data NamePricing = NamePricing
+  { -- | US cents per year, for the lengths the registry prices specially
+    rentPrices :: Map Int USDCents,


rentPrices -> registrationPrices

epoberezkin · 2026-09-09T19:28:03Z


+-- | What RSLV asks about. Unlike SimplexDomain, which is always text, this may
+-- name a label by its hash.
+data NameQuery = NameQuery


I think the main source of the messiness and spread of version is this type - instead of being a plain sum, where a name is either domain or hash of domain it tries to make some merged shape that only complicates things. E.g., we know that we never need to look up subdomains as hashes, but this type allows it.

A much simpler type would have been this:

data NameQuery = NQDomain SimplexDomain | NQHash SimplexTLD LabelHash

Then conversion from name to query is always version independent, it's just NQDomain.

Encoding then remains version dependent, and it can send hash only if 1) version supports it 2) it's second level name 3) it's not web name. This would avoid multiple decision points that are currently present about how to encode the name, hashing would become part of encoding.

this also simplifies encodings, as it doesn't have to encode components separately - it only needs one-letter tag + either domain (that we already know how to encode) or TLD + hash.

brenzi added 8 commits September 5, 2026 16:53

extend SMP protocol to support name availability queries with accurat…

e3f00b4

…e and meaningful replies

review fixes

69cce33

more review fixes

783f0aa

docs shortening and other review fixes

45d314c

add catch all for furture variants

c99cc61

adversarial review (against simplex-chat) fix

5c48027

next iteration fixes

3b4a7f2

adapt house style

99adfe9

brenzi mentioned this pull request Sep 6, 2026

names lookup and availability by labelhash simplex-chat/simplex-chat#7461

Open

brenzi added 3 commits September 7, 2026 08:09

eth_call guard and cache constants

e6dc6c8

revert NAVL command and wrap it all into RSLV

c2c3bbc

doc fixes

0843238

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Server/Names.hs Outdated

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Server/Names.hs Outdated

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Protocol.hs Outdated

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Protocol.hs Outdated

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Protocol.hs Outdated

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Protocol.hs Outdated

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Protocol.hs Outdated

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Protocol.hs Outdated

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Protocol.hs Outdated

brenzi and others added 7 commits September 7, 2026 14:20

Update src/Simplex/Messaging/Server/Names.hs

b8cc019

Co-authored-by: Evgeny <evgeny@poberezkin.com>

Update src/Simplex/Messaging/Protocol.hs

8076504

Co-authored-by: Evgeny <evgeny@poberezkin.com>

Update src/Simplex/Messaging/Protocol.hs

1e5ddca

Co-authored-by: Evgeny <evgeny@poberezkin.com>

Update src/Simplex/Messaging/Protocol.hs

13f8cce

Co-authored-by: Evgeny <evgeny@poberezkin.com>

Update src/Simplex/Messaging/Protocol.hs

20ba720

Co-authored-by: Evgeny <evgeny@poberezkin.com>

protocol types refactoring

e4fab46

next iteration on types only

1e3d6fa

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Protocol.hs Outdated

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Protocol.hs Outdated

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Protocol.hs Outdated

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Protocol.hs Outdated

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Protocol.hs Outdated

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Protocol.hs

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/SimplexName.hs Outdated

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/SimplexName.hs Outdated

epoberezkin reviewed Sep 7, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/SimplexName.hs Outdated

brenzi added 8 commits September 8, 2026 08:28

rentPrices map

1dabe1d

claude answering ep review. to be continued...

82ca4af

separate labelhash and plaintext names cleanly

1a74598

align implementation with latest type changes to test against client

c0bf620

fix adversarial review findings

8b70633

trim diff

f229e61

Merge remote-tracking branch 'origin/master' into ab/snrc-resolver-SM…

7636c8e

…P-NAVL

align resolver with contract changes for names v2

5ccbca9

brenzi marked this pull request as ready for review September 9, 2026 07:09

brenzi requested a review from spaced4ndy as a code owner September 9, 2026 07:09

brenzi added 3 commits September 9, 2026 09:22

Merge branch 'ab/snrc-resolver-expiry-and-availability' into ab/snrc-…

e03e4bd

…resolver-SMP-NAVL

fix reverse compatibility with .testing mainnet

be35dbc

fix more robustly

9db84e1

epoberezkin reviewed Sep 9, 2026

View reviewed changes

Comment thread src/Simplex/Messaging/Protocol.hs

epoberezkin reviewed Sep 9, 2026

View reviewed changes

Uh oh!

Uh oh!

Conversation

brenzi commented Sep 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

brenzi commented Sep 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

brenzi Sep 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epoberezkin Sep 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

brenzi commented Sep 5, 2026 •

edited

Loading

brenzi commented Sep 9, 2026 •

edited

Loading

brenzi Sep 9, 2026 •

edited

Loading

epoberezkin Sep 9, 2026 •

edited

Loading