Repository navigation
Conversation
Auto-approved requests deliver a blank passive banner (iOS has no supported full-suppression in an NSE) and rely on an immediate removeDeliveredNotifications to retract it. That remove raced process exit and often no-oped, leaving blank banners parked in Notification Center. Await the delivered-notifications lookup after the remove — the same keep-alive pattern sweepPriorBlankNotifications already uses — so the retraction actually lands.
…d account - addAccount(ncryptsec:password:) decrypts a NIP-49 ncryptsec via NostrSDK EncryptedSecretKey and re-enters addAccount(nsec:) so dedupe, per-device cap, Keychain write, and proxy registration behave identically to nsec import; decrypt failures surface as AccountError.invalidNcryptsec - Add Account sheet gains an ncryptsec segment (password field) and a QR scanner entry point; scans strip a nostr: prefix and auto- route ncryptsec1 values to the password mode - Onboarding import field accepts ncryptsec (password card appears on input) with the same QR scanner; camera string in Info.plist now covers key QR codes - tests: ncryptsec decrypt/wrong-password/malformed coverage in AppStateMultiAccountTests
- pass NIP-49 passwords raw (never whitespace-trimmed); they are arbitrary strings - strip a nostr: prefix on manual paste too, and route it through the same normalization as scans (paste + auto-flip + onboarding) - scanner now ignores QRs that are not nsec/ncryptsec/hex keys and keeps scanning instead of dumping any URI into the field - snapshot-protect the onboarding screen (plain TextField renders the pasted secret; audit ref A10.1) - clear stale error text when a paste auto-flips to ncryptsec mode - tests: ncryptsec-path dedupe, cap enforcement writes nothing, and failed-decrypt Keychain-first ordering
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.
What
Adds NIP-49 (
ncryptsec) import and key QR-code scanning to both key-import surfaces:ncryptsec1…(a password card appears automatically when the input is an ncryptsec) and gets the same QR scan button.How
addAccount(ncryptsec:password:)decrypts via NostrSDK'sEncryptedSecretKey(NIP-49), then re-enters the existingaddAccount(nsec:)path — so dedupe, the per-device cap, Keychain storage, and proxy registration behave identically to nsec import.AccountError.invalidNcryptsec("Couldn't decrypt this ncryptsec key. Check the password…").nostr:prefix and auto-route: anncryptsec1…value lands in the password mode, anything else in nsec/hex. Pasting an ncryptsec into the nsec field auto-flips modes instead of erroring.QRScannerViewcomponent;NSCameraUsageDescriptionupdated to also cover key QR codes.Testing
AppStateMultiAccountTests17/17 pass, including 5 new cases: decrypt-and-import stores the nsec under the right pubkey; wrong password and malformed input throw.invalidNcryptsecwith no account row and no Keychain write; re-importing an existing key via ncryptsec dedupes; importing past the per-device cap throws.accountCapReachedand writes nothing.nostr).c16daeb).The simulator has no camera, so the QR scanning path (onboarding scan button, Add Account sheet scanner, the camera permission prompt, and scanning a real key QR) could not be exercised during development — please verify on hardware.
Known follow-up (non-blocking)
EncryptedSecretKey.decryptis handed untrusted input (e.g. scanned QRs) with no way to peek at the declared scryptlog_nfirst — a craftedncryptsec1…with a hugelog_ncould force an expensive derivation. SDK-level (no FFI accessor); worth a rust-nostr feature request or an app-side bech32 peek before decrypt.