getUserId fails on Desktop and dotli: published truapi-host (0.10.1) drops dotted lite names, and the fix (#602) never shipped

On paseo-next-v2, provider.getUserId() from a product (t3ams, humanity) rejects on Polkadot Desktop 0.8.9 and on the deployed dotli with

{"tag":"Domain","value":{"tag":"V1","value":{"tag":"Unknown","value":{"reason":"No primary username for this session"}}}}

even though the device is paired. The same flow works on iOS. I went in assuming the .tld changes; it's actually the dotted lite-name change from dotns#275 landing on a core that predates #602, and the fixed core was never published.

What's happening

Desktop and dotli are pairing hosts (createWebWorkerPairingHostRuntime: polkadot-desktop/src/aggregates/truapi-runtime/truapiRuntimeUseCase.ts:34, dotli-community/packages/ui/src/bridge.ts:842). Both pin @parity/truapi-host@0.10.1 (desktop package.json:111, dotli packages/ui/package.json:37, same tarball hash in both lockfiles). 0.10.1 is also the newest version on npm.

After SSO pairing the session arrives with lite_username: None (runtime/sso_pairing.rs:233-241, same at the tag) and the core resolves the name itself: refresh_current_session_identity → resolve_session_identity_with_chain → DotnsPopController.pendingClaims / LabelStore.getLabels → classify_labels.

Since dotns#275 the controller keeps the separator, so a gateway name is session.14, not session14. At 0.10.1 classify_labels drops anything that isn't a bare DNS label (host_logic/dotns_gateway.rs:463-507 at the tag: if !is_dns_label(label) { continue; }, and is_dns_label rejects .). bare_store_label does the same on the LabelStore side (:756-763, pinned by its own test bare_store_label("app.alice.paseo", ".paseo") == None). So the labels come back from the chain, nothing survives classification, lookup_and_apply still reports Applied (runtime/identity.rs:132-140 at the tag) so there's no fallback, and the session installs without a username. get_user_id (runtime.rs:1386 at the tag, runtime/capabilities/account.rs:375 on main) then fails on primary_username().

#602 (1f10852d) fixes exactly this. It's in the 0.11.0 release commit (ef2a7383, #722). That release never reached npm, see below.

Evidence

I replayed 0.10.1's reads against paseo-next Asset Hub (wss://paseo-asset-hub-next-rpc.polkadot.io, ReviveApi_call dry-runs from the 0xEE.. origin, same encoding as encode_revive_call) for three lite identities the gateway minted on 2026-09-10:

DotnsGateway.DispatcherAddress          = 0xa889cca3fb4b07b98a11cc54c10f13dda20bc3db
  protocolRegistry()                    -> reverts
  TARGET()                              -> 0xcc932348606cc1f3318cadec5a5cd2ca447f8a4b   (#564's second hop, so discovery is fine at 0.10.1)

identity 5HDsUwdSqcUBVgVCXG5pgfmKVheXhP7E4imoe2nWBmjf6gk2   (//product//uid.paseo/index_bytes(0))
  StoreFactory.getLabelStore(identity)  = 0x0   (no store yet; the name is still a pending claim)
  DotnsPopController.pendingClaims(...) = [("session.14", mintedAt 1789015512)]
  0.10.1: is_dns_label("session.14") = false -> classify_labels -> {}   -> no username
  main:   dotted lite accepted, isPopIssued("session.14") = true

identity 5EtC5yKPcbzqCj8WoEbpT29ti6F2awnm9paiP5dfKzFwYNSY   pendingClaims = [("session.18", ...)]   same
identity 5EJSyFMP3qNhjQisQGpFY5VVSJszDBYTtf7tFR1jKPF64SJy   pendingClaims = [("session.42", ...)]   same

truapi-host identity-check --network paseo-next-v2 from a build off main finds all three.

previewnet is still on the pre-#275 controller (dotns#290 is open), so 0.10.1 should keep working there. I haven't tested that.

Why iOS is fine

iOS never asks the core to look the name up. Onboarding reads Resources.Consumers off the People chain (polkadot-app/Common/Services/IdentityServiceProtocol.swift:23-29), stores it, and passes it in at runtime.activateLocalSession(secret:, liteUsername:) (Modules/Products/TrUAPI/TrUAPIHostRuntimeProvider.swift:98), which becomes SessionInfo.lite_username (runtime/signing_host/local_activation.rs:60). get_user_id short-circuits on primary_username().is_some() before any dotNS read. The contract change can't reach that path.

Something that hid this on Desktop: the account badge shows a name even when the core has none, because UserButton.tsx:37 prefers the People-chain identity over the core's session (#850). The badge is not evidence the session has a username.

Why the fix isn't out

release.yml failed on both release commits at "Verify release manifests":

• 0.11.0 (ef2a7383, #722): https://github.com/paritytech/host-rust-core/actions/runs/34463179363 — .changeset/reliable-iframe-bootstrap.md still in the tree
• 0.12.0 (45ca2aca, #732): https://github.com/paritytech/host-rust-core/actions/runs/34595795535 — .changeset/temporary-unwatermarked-signing.md still in the tree

Release commit still contains unconsumed changesets. Run npm run version-packages.

Both times a PR carrying a changeset merged between version-packages and the release merge. npm view @parity/truapi-host dist-tags gives latest: 0.10.1 (published 2026-09-02). #744 (0.13.0) has a clean .changeset/ and is open.

What needs to happen

1. Get a truapi-host release with #602 onto npm. 0.11.0 is the last codec-1 line that has it; 0.12.0 moved to wire codec 2 and the changelog says hosts and products have to move together. Whether that's a 0.11.x cut from ef2a7383 or shipping #744 and moving the products at the same time is a release call — but right now nothing on npm resolves a paseo-next lite name.
2. Then bump polkadot-desktop (package.json:111) and dotli-community (packages/ui/package.json:37). No code change needed on their side, ProductRuntimeConfig didn't change between 0.10.1 and 0.11.0.
3. Until dotns#290 lands, a core with #602 fails the same way on previewnet (#720), so the two networks can't both work off one core until previewnet is upgraded.

Start with release.yml and the 0.11.0 release commit ef2a7383, then inspect package.json:111 in polkadot-desktop and packages/ui/package.json:37 in dotli-community. Run npm view @parity/truapi-host dist-tags and review #602 and #744 to determine the compatible release path. Done means a release containing the fix is published, both consumers use it, and getUserId resolves paseo-next-v2 dotted lite names without breaking the documented previewnet constraint.