Ask
Please bring previewnet's DotnsPopController up to #275. previewnet is running the contract generation from before it, while paseo-next already has it.
Why
host-rust-core main (since paritytech/host-rust-core#602) reads lite usernames the #275 way: every label is gated on DotnsPopController.isPopIssued(string), and lite names are expected in stored dotted form (alice.42). On previewnet neither holds, so a host built from main cannot create a lite person on previewnet — onboarding polls isPopIssued 30 times, every call reverts, and the CLI aborts with "dotNS username did not appear on Asset Hub after attestation" even though the People chain has already recorded the person and the identity backend accepted the name (202, QUEUED).
Evidence
Same controller address on both networks, same protocolRegistry(), same owner() — only the provenance read differs:
controller 0xcc932348606cc1f3318cadec5a5cd2ca447f8a4b
previewnet paseo-next
protocolRegistry() -> 0xd19e3d0c…fa846e 0xd19e3d0c…fa846e
owner() -> 0x4a519c30…cce099 0x4a519c30…cce099
isPopIssued(string) -> contract reverted: (empty) false
On previewnet the revert is identical for issued names in daily use (letsgoooo.36, stalectl.80), for freshly queued names, and for names that never existed; no variant of the capability exists (popIssued, isIssued, isPopName, the bytes32 forms, chatKey, usernameNodeOf, nameOf all revert). That is an absent selector, not a state answer. Labels on previewnet also still come back flattened (alice42).
Probe: ReviveApi_call via state_call against wss://previewnet.substrate.dev/asset-hub and wss://paseo-asset-hub-next-rpc.polkadot.io, controller discovered from DotnsGateway.DispatcherAddress, calldata isPopIssued(string).
Impact
Downstream products on previewnet (e.g. humanity-spa's weekly-game seat, which needs a lite person with correctly derived keys) currently have no working host: the released truapi-host 0.13.1 onboards but predates the key-derivation fix (host-rust-core#627), and main has the fix but cannot onboard against the pre-#275 contracts. Deploying #275 to previewnet lets main work there as it already does on paseo-next.
Note: #275 changes storage for new names; labels minted under the old contracts stay flattened, which is fine — those persons are unusable for the unrelated key-derivation reason anyway.
Context and full trail: paritytech/host-rust-core#720.
Ask
Please bring previewnet's
DotnsPopControllerup to #275. previewnet is running the contract generation from before it, while paseo-next already has it.Why
host-rust-coremain(since paritytech/host-rust-core#602) reads lite usernames the #275 way: every label is gated onDotnsPopController.isPopIssued(string), and lite names are expected in stored dotted form (alice.42). On previewnet neither holds, so a host built frommaincannot create a lite person on previewnet — onboarding pollsisPopIssued30 times, every call reverts, and the CLI aborts with "dotNS username did not appear on Asset Hub after attestation" even though the People chain has already recorded the person and the identity backend accepted the name (202,QUEUED).Evidence
Same controller address on both networks, same
protocolRegistry(), sameowner()— only the provenance read differs:On previewnet the revert is identical for issued names in daily use (
letsgoooo.36,stalectl.80), for freshly queued names, and for names that never existed; no variant of the capability exists (popIssued,isIssued,isPopName, thebytes32forms,chatKey,usernameNodeOf,nameOfall revert). That is an absent selector, not a state answer. Labels on previewnet also still come back flattened (alice42).Probe:
ReviveApi_callviastate_callagainstwss://previewnet.substrate.dev/asset-hubandwss://paseo-asset-hub-next-rpc.polkadot.io, controller discovered fromDotnsGateway.DispatcherAddress, calldataisPopIssued(string).Impact
Downstream products on previewnet (e.g. humanity-spa's weekly-game seat, which needs a lite person with correctly derived keys) currently have no working host: the released
truapi-host 0.13.1onboards but predates the key-derivation fix (host-rust-core#627), andmainhas the fix but cannot onboard against the pre-#275 contracts. Deploying #275 to previewnet letsmainwork there as it already does on paseo-next.Note: #275 changes storage for new names; labels minted under the old contracts stay flattened, which is fine — those persons are unusable for the unrelated key-derivation reason anyway.
Context and full trail: paritytech/host-rust-core#720.