feat: scan Sapwood's invite to add a phone for unlock - #22
Merged
Merged
Conversation
Reverses the enrolment QR direction (enrol-invite spec v1): "Add a phone" in Sapwood shows a one-off invite, and Cambium's "Scan Sapwood's code" reads it, seals its usual enrolment code to the invite's throwaway key with NIP-44, and publishes the reply once to the invite's relays, with a Retry on failure. From there the flow is unchanged: the board's hand-off, the five request words, then the check code. The old phone-shows-a-QR flow stays as a secondary "Show a code instead" option. NIP-44 v2 and just enough secp256k1 are implemented in pure Kotlin so the reply's ciphertext can be held to the shared Sapwood/Cambium test vector, which rust-nostr's native bindings cannot do on the host JVM.
…crypto The production reply builder used a naive, non-constant-time secp256k1 and a from-scratch NIP-44 v2 to hold the wire format to the shared Sapwood/Cambium vector, but that reasoning only holds for the test. UnlockNostr.inviteReplyEvent now generates the throwaway key, encrypts and signs entirely through rust-nostr's Keys/nip44Encrypt, matching deliveryEvent's existing pattern. Secp256k1.kt and Nip44.kt move to app/src/test as a test-only reference implementation; EnrolInviteVectorTest still checks the spec's wire format (NIP-44 v2 content, h/expiration tags) byte for byte against Sapwood. InviteReplyBuilder now only builds the pure, shared tag shape, tested by both the production builder and the vector test.
The reply was published straight from the relay-connect coroutine, which touches views off the main thread and would crash on the first scan.
Merged
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.
Cambium side of the reversed enrolment (see the Sapwood PR).
Keys.generate(),nip44Encryptv2, tagshandexpirationonly. It shows sending/sent/failed, with a Retry that republishes the same event. It then waits for the hand-off on its own relays plus the invite's, and shows the words and check code as today.src/testonly, to hold the wire format to the shared Sapwood vector byte for byte. Production never uses it.Tests: 271 JVM unit tests pass, assembleDebug OK. Not yet bench-tested end to end; do not merge before a round trip on hardware.