Skip to content

feat(signer,sdk): sign DotNS identity via explicit legacy signer#214

Closed
ReinhardHatko wants to merge 1 commit into
feat/dotns-identity-signingfrom
feat/dotns-identity-explicit-signer
Closed

feat(signer,sdk): sign DotNS identity via explicit legacy signer#214
ReinhardHatko wants to merge 1 commit into
feat/dotns-identity-signingfrom
feat/dotns-identity-explicit-signer

Conversation

@ReinhardHatko

Copy link
Copy Markdown
Contributor

Stacks on #212 (feat/dotns-identity-signing) — merge that first; this targets its branch.

Problem

signMessageWithDotNsIdentity resolves the username → owner AccountId, then signs by finding that account in the connected-accounts list. On Proof-of-Personhood / product-account hosts (e.g. Polkadot Desktop) the host exposes only a per-dapp product account and never enumerates the user's identity account — so the owner is never found and signing fails with:

DotNS username "…" resolves to …, but no connected wallet account matches that AccountId.

That makes DotNS-identity signing unusable on exactly the hosts the product targets.

Fix

Probing Polkadot Desktop confirmed these hosts will still sign with an account when it is named explicitly via host_sign_raw_with_legacy_account, even though they withhold it from getLegacyAccounts() enumeration. So:

  • HostProvider.signRawWithLegacyAccount(publicKey, data) — signs with an account named by public key, via a shared legacySignerFor(publicKey) helper now also used by mapAccounts (dedupes the legacy-account construction).
  • SignerManager.signRawWithLegacyAccount(publicKey, data) — thin delegation, mirrors getUserId / createRingVRFProof.
  • signMessageWithDotNsIdentity now prefers an already-connected account (no extra prompt) and otherwise signs via the explicit legacy signer, instead of throwing when the owner isn't enumerable.

Validation

  • Probed inside Polkadot Desktop: the identity account that owns the People username is withheld from getLegacyAccounts() enumeration but signs when named explicitly — the case this PR unblocks.
  • tsc --noEmit clean for signer + sdk; existing signer suite passes (102/102).
  • Dedicated unit tests for the new path are a follow-up.

🤖 Generated with Claude Code

`signMessageWithDotNsIdentity` required the account that owns the DotNS /
People username to appear in the connected-accounts list. On
Proof-of-Personhood / product-account hosts (e.g. Polkadot Desktop) the host
exposes only a per-dapp product account and never *enumerates* the user's
identity account — so the owner resolved from the name was never found, and
signing failed with "no connected wallet account matches that AccountId."

Probing Polkadot Desktop showed such hosts still sign with an account when it
is named explicitly via `host_sign_raw_with_legacy_account`, even though they
withhold it from `getLegacyAccounts()` enumeration. Route through that path:

- HostProvider.signRawWithLegacyAccount(publicKey, data), built on a shared
  `legacySignerFor(publicKey)` helper now also used by `mapAccounts`.
- SignerManager.signRawWithLegacyAccount(publicKey, data) (delegates).
- signMessageWithDotNsIdentity prefers an already-connected account (no extra
  prompt) and otherwise signs via the explicit legacy signer, instead of
  throwing when the owner isn't enumerable.
throw new Error("Host provider is disconnected");
}
return this.accountsProvider.getLegacyAccountSigner({
dotNsIdentifier: "",

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should it be empty?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK yes, to get the legacy account signer you just leave the dotns identifier empty

@TarikGul

Copy link
Copy Markdown
Member

Closing since its been completed in: #212

@TarikGul TarikGul closed this Jun 16, 2026
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.

3 participants