Skip to content

Modding DX: make fork → mod → deploy smooth (surface identity, ownership & offline verification before the irreversible deploy) #13

Description

@sacha-l

The problem

Modding this template should be: fork → change something → redeploy. In practice the hard part isn't the code — it's a handful of invisible, irreversible facts that today only surface after a phone-signed, funded, ownership-binding deploy:

  • Who am I? The signer identity is never written to the repo or shown anywhere. You don't know which account you are until a deploy fails.
  • Is my name claimable? The template ships a hardcoded contract name that's already owned; there's no way to check before signing.
  • Does my mod even work? The only way to run the app end-to-end is a real deploy, so you can't verify a change before the irreversible step.

These were all hit in a single real mod+deploy session. The worst one isn't documented anywhere:

The identity/ownership trap (the one that actually blocks you)

pg deploy fails with:

✖ CDM package "@…/leaderboard" is already owned by 0x35cdb…, but the selected
  signer maps to 0xcf8a…. Update the Cargo.toml package value to a name you own,
  or deploy with the owner account.

The error points at renaming. But renaming doesn't help: renaming to a brand-new random name (@rps-<6 hex>/leaderboard) returned the same owner 0x35cdb. So it was never a naming collision — ownership is bound to the signer, and the registry attributes the name to a key you're not currently signing with. The real cause: the owner 0x35cdb and the active signer 0xcf8a are different keys that both display as the same Playground username (whiterabbit). You can be "yourself" and still not be the owner. There's nothing in the tooling to tell you this.

What would make it smooth (prompts the template/CLI should surface)

In order of when they should fire — full writeup with the failure each prevents in MODDER-PROMPTS.md:

  1. Show the signer identity at pg mod/setup — "you're signed in as <handle> (0x…); names you deploy are owned by this account."
  2. Auto-claim a unique contract name so the hardcoded-name collision can't happen. → PR Prevent the "already owned" deploy collision: npm run name:new #11
  3. Offline dev mode (?mock) so a mod is verifiable with no chain/phone/deploy. → PR Add offline dev mode (?mock): run & verify a mod with no chain, phone, or deploy #12
  4. Ownership preflight before signing — "claiming @X under 0x…: free / owned by you / owned by someone else" — and lead with the signer fix, not a rename when it's owned. (Needs a registry getOwner(name) — none exists today.)
  5. Identity reconciliation — warn when the owning key ≠ the current signer key even though the display name matches; if you deployed before, sign with the same account.
  6. Funding/allowance preflight with the exact gap + faucet links, instead of raw InvalidTxError {"Payment"} / AccountUnmapped.
  7. Signing readiness — "open the Polkadot app and keep it foregrounded; N approvals incoming" (per-tx push has a short timeout; otherwise it hangs at step 1).
  8. Don't pg logout to fix a hang — it can discard the session that owns your names and re-pair you as a different key.

What's already submitted vs what needs Parity

One-line summary

Tell the modder who they are, give them a name nobody owns, let them verify offline, and confirm ownership + funding before a single signature.

Today none of these are prompted, so every one is discovered after an irreversible deploy. Surfacing them turns modding into: name:new → verify at ?mock → deploy once.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions