Recognize Canon declaration challenges in connect sign-requests - #9
Open
cdonnachie wants to merge 3 commits into
Open
Recognize Canon declaration challenges in connect sign-requests#9cdonnachie wants to merge 3 commits into
cdonnachie wants to merge 3 commits into
Conversation
A Canon (canon.rxd.zone) creator declaration arrives as a sign-request whose challenge is the canonical declaration message. Recognize both message versions in the protocol module (pure, display-only — the signature always covers the raw challenge verbatim): v2's canon-declaration:wallet-connect:v2:<network>:<body> head already matches the recognized connect-challenge shape, and v1's pipe form is recognized explicitly. The approval screen shows a "Canon declaration" badge, skips the not-a-standard-connect warning, and renders the declaration structured — what the key recognizes or revokes, network, dates, comment, plus a permanence note — above the exact signed text. Stacked on fix/sanitize-untrusted-display-text (uses sanitizeForDisplay for the hostile label/comment fields). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NQWcT2EiTgiMS2487f7ger
New connect request type mirroring mint-request's self-funded commit+reveal pattern: the dApp hands over a SIGNED Canon declaration document (exact JSON string — its bytes are the docHash identity), and after approval the wallet publishes it as a cnd1 anchor pair, funded from its own RXD UTXOs. The commit script is a minimal non-token covenant (OP_HASH256 <sha256d(payload)> OP_EQUALVERIFY + own-key p2pkh); the reveal scriptSig appends the payload push behind sig+pubkey via buildTx's input-script callback. Nothing is minted. Anchoring is permanent, so the gate is strict: the envelope refuses any document that is not a well-formed declaration (both message versions), and the flow re-verifies the signmessage signature against the signer address inside the document before building anything. The approval screen renders the declaration structured with a permanence warning and the exact bytes to be committed; results return commit/reveal txids (or unsent hex for broadcast:false) plus the docHash. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NQWcT2EiTgiMS2487f7ger
Standalone NFTs with no container or creator token to derive trust from declare as kind "work"; the parser accepts it and both approval panels render it as "individual work". Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NQWcT2EiTgiMS2487f7ger
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
A Canon creator declaration arrives as a
sign-requestwhose challenge is the canonical declaration message. Without recognition, the approval screen shows the orange Unrecognized badge and the "Not a standard connect request" warning for a format this wallet can fully understand.parseCanonDeclarationin the protocol module: a pure, display-only parser for both canonical message versions. v2 (canon-declaration:wallet-connect:v2:<network>:<body>) already matches the recognized connect-challenge shape; v1 (canon-declaration|v1|…) is recognized explicitly. A challenge that fails the parser is simply not a Canon declaration — never an error.Security notes
sanitizeForDisplay(this is why the PR is stacked on Show what is actually being approved: sanitise untrusted text, render data outputs #8).extractChallengeNonceechoes something short and harmless into callbacks.Stacked on #8
Base is
fix/sanitize-untrusted-display-text— this diff is only the recognition commit. Merge #8 first; GitHub will retarget this tomainautomatically.Tests
vitest run src/connect/__tests__/protocol.test.ts— 130 passing, including round-trips for both message versions, terminal-comment pipes, revocations, and rejection of every tampered shape.🤖 Generated with Claude Code
https://claude.ai/code/session_01NQWcT2EiTgiMS2487f7ger