feat(dashpay): show the username people typed, not the normalized form - #933
Merged
Conversation
The voting screens rendered Platform's homograph-normalized label, so a contest for "pizza" appeared as "p1zza" — which reads as a typo to the people whose name is being voted on. The normalization is not reversible client-side, so this needed the spelling to come off the wire; dashpay/platform#4331 decodes it from each contender's `domain` document. Contests now lead with what people actually typed, and keep the normalized form as supporting information rather than dropping it: - The list row shows the typed spelling, with the stored form beneath it in small monospace whenever the two differ. - The detail screen titles on the typed spelling and adds a "Stored as" row plus a one-line explanation of why they differ. - Contender rows show each requester's own spelling, falling back to the truncated identity id when their document could not be decoded. - When contenders typed *different* spellings that normalize to the same value — the situation a contest exists to resolve — all of them are shown joined by "or", rather than arbitrarily picking one. Search now matches both forms, so typing "pizza" finds the contest whether the row reads "pizza" or "p1zza". Nothing is reverse-engineered from the normalized label: `0`→`o` and `1`→`i`/`l` are ambiguous, so a contest with no decodable contender document keeps showing the normalized form rather than a guessed one. Requires dashpay/platform#4331 (adds `label` to `DashSDKContender`, so the xcframework must be rebuilt). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
📝 WalkthroughWalkthroughThe change adds contest display-title helpers, contender display-name fallbacks, updated voting-screen presentation, and search matching for both normalized and submitted username labels. ChangesContest display and search
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
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.
Why
The voting screens render Platform's homograph-normalized label, so a contest for
pizzashows asp1zza. That reads as a typo to the very people whose username is being voted on.This was written as part of #923 but landed after that PR was squash-merged, so it never reached
develop— hence this follow-up PR.Why it needed an SDK change first
Normalization maps
o→0andi/l→1. It is lossy and ambiguous —p1zzacould be pizza, plzza or p1zza — so no client can recover the spelling by guessing.dashpay/platform#4331 (merged,
8f98180c55) decodes the spelling from each contender'sdomaindocument, where it was already on the wire, and derives the ordered, de-duplicated label list in Rust.What changes
pizzafinds the contest whether the row readspizzaorp1zza.Contenders who typed different spellings
That is the situation a contest exists to resolve, so all distinct spellings are shown joined by "or" (
pizza or p1zza) rather than arbitrarily picking one. The ordering and de-duplication happen in Rust (DashSDKContestInfo.requested_labels); Swift copies the result verbatim, perpackages/swift-sdk/CLAUDE.md's thin-bridge rule.Nothing is guessed
A contest with no decodable contender document keeps showing the normalized form. The normalized label is never reverse-engineered, and never hidden — it stays visible as supporting information wherever it differs.
Testing
Clean
dashpaybuild against mergedv4.2-dev(8f98180c55) with the xcframework rebuilt for both slices.developdoes not currently build against mergedv4.2-dev, independent of this PR.a9ff688a8callsManagedPlatformWallet.invitationProspectiveIdentityId, which does not exist in any merged platform branch — so that cross-repo change is still in flight. Verified plainorigin/developfails identically, then temporarily stubbed that one call locally (not committed) to confirm this branch's own code compiles clean. Worth resolving before merging anything that needs a green app build.Runtime behaviour is still unverified — whether real contests carry decodable labels needs a testnet check.
🤖 Generated with Claude Code
Summary by CodeRabbit