Show the nostr pubkey in both encodings, not just npub - #6
Merged
nothing-stops-this-train merged 1 commit intoJul 28, 2026
Merged
Conversation
The Swap Server tab showed only the bech32 npub, while Electrum's "Choose Swap Provider" dialog lists the raw hex: swap_dialog.py sets the Pubkey column to SwapOffer.server_pubkey (== event.pubkey) and keeps the npub only as hidden item data, used as the return value and stored in SWAPSERVER_NPUB. Same key, two encodings -- but they look nothing alike, so an operator comparing the tab against a taker's provider list reasonably concludes the GUI is displaying the wrong key. The identity box now has an npub row and a hex row, each independently copyable, plus a one-line note that takers list the hex form. The hex was previously only in a tooltip, which is easy to miss. The identicon is unchanged and remains the fastest check: both sides feed the *hex* into pubkey_to_q_icon, so the coloured square beside the npub matches the one beside this server in a taker's list. (Passing an npub there is not a different colour but an outright error -- pubkey_to_rgb_color asserts len 64 -- which a new test pins down.) Tests: both encodings render and stay in sync (the npub must decode back to the displayed hex, and the hex must equal keypair.pubkey.hex()[2:], the value SwapOffer.server_pubkey carries), the hex Copy button copies the hex, the identicon is derived from the hex, and a wallet with no nostr key blanks both rows and makes copying a no-op rather than pasting an empty string. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013zETFC6MhnsCuxvQDGxqV5
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
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.
The report
Nothing was actually wrong — they are the same key in two encodings, which
look nothing alike:
npub1hdd8atxxf9tz284ecgqjpe3eht…(63 chars)bb5a7eacc64956251eb9c20120e639ba…(64 chars)swap_dialog.pysets that column toSwapOffer.server_pubkey— the raw hexevent.pubkeyoff the nostr event — and keeps the npub only as hidden itemdata (
ROLE_NPUB), where it is used as the return value and written toSWAPSERVER_NPUB. It is never rendered. Verified rather than assumed: the npubdecodes back to exactly the hex the provider list displays.
The change
Showing one encoding alone reasonably reads as "the GUI is displaying the wrong
key", so the identity box now shows both, each independently copyable, with a
dimmed one-liner explaining the relationship:
The hex was previously only in a tooltip, which is easy to miss.
The identicon is unchanged and remains the fastest visual check that a provider
entry is your server: both sides derive it from the hex via
pubkey_to_q_icon, so the coloured square matches.Note found while testing
Feeding an npub to
pubkey_to_q_iconis not merely a different colour — it is ahard error, because
pubkey_to_rgb_colorassertslen == 64. A refactor thatpassed the wrong form would crash rather than silently mismatch. There is now a
test pinning that behaviour.
Tests
163 total, green with and without PyQt6 (19 Qt tests, which skip cleanly when it
is absent). New coverage asserts the two rows cannot drift apart:
keypair.pubkey.hex()[2:], the exact valueSwapOffer.server_pubkeycarries;than pasting an empty string.
🤖 Generated with Claude Code
https://claude.ai/code/session_013zETFC6MhnsCuxvQDGxqV5