[codex] Add public Paykit payments to contacts#531
[codex] Add public Paykit payments to contacts#531ben-kaufman wants to merge 27 commits intomasterfrom
Conversation
1d622bc to
18a0af9
Compare
18a0af9 to
f1a122e
Compare
This comment has been minimized.
This comment has been minimized.
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
5b94276 to
3d1f2b2
Compare
|
Quick testing notes:
|
|
Ok, I think this makes sense. But I guess it should go through design/product acceptance fyi @aldertnl
|
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3ea3f5832a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| await VssBackupClient.shared.reset() | ||
| VssStoreIdProvider.shared.clearCache() | ||
|
|
||
| try await PubkyProfileManager.removePublicPaykitEndpoints(context: "AppReset.wipe") |
There was a problem hiding this comment.
Keep wipe flow resilient to endpoint unpublish failures
Make the public-endpoint cleanup best-effort here instead of hard-failing the entire wipe. removePublicPaykitEndpoints performs remote operations and can throw on transient network/session issues; because it now runs before wallet.wipe() and database/keychain cleanup, users in offline or degraded network conditions can be blocked from completing reset flows (forgot PIN, recovery reset, dev wipe), leaving local sensitive state uncleared.
Useful? React with 👍 / 👎.
| func contactActivities(publicKey: String) async throws -> [Activity] { | ||
| try await coreService.activity.get(contact: publicKey, sortDirection: .desc) |
There was a problem hiding this comment.
Apply replaced-transaction filtering to contact activity list
Filter contact activities with the same replacement-transaction logic used by syncState() before presenting them. This method currently returns raw coreService.activity.get(...) results, so contact-specific history can surface replaced/boosted originals that are intentionally hidden in the main activity feed, causing duplicate or stale sent entries for the same payment flow.
Useful? React with 👍 / 👎.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Tested roughly against this plan. Tested against staging. Areas tested and 🟢 for me (encountered issue #536, but seems unrelated to paykit).
Some testing notes / observations:
|
piotr-iohk
left a comment
There was a problem hiding this comment.
LGTM, remaining obesrvations can be addressed separately, issue for tracking: #539
ovitrif
left a comment
There was a problem hiding this comment.
LGTM
Tested using same script like on Android counterpart ([codex] add public contact payments).
Focused on validating, besides happy flow, edge cases to ensure Public pay2contact payment methods are always up-to-date.
ovitrif
left a comment
There was a problem hiding this comment.
Validated fix in last commit for Payky 🎉
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 768c3d05a8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if app.lnurlPayData != nil { | ||
| return .lnurlPayAmount | ||
| } |
There was a problem hiding this comment.
Route fixed LNURL contact payments to confirmation
When appropriateSendRoute returns .quickpay for a contact LNURL payment, this branch always forces .lnurlPayAmount, even for fixed-amount LNURL requests. That regresses fixed flows from a direct confirmation path to manual amount entry, and can leave users stuck on a disabled continue button when balance is below the fixed amount (instead of reaching normal confirmation/validation). Preserve fixed-amount behavior by routing fixed LNURL contacts to .lnurlPayConfirm rather than always .lnurlPayAmount.
Useful? React with 👍 / 👎.
| private func handleAddContactScan(_ input: String) { | ||
| navigation?.navigateBack() | ||
| navigation?.navigate(.addContact(publicKey: input)) |
There was a problem hiding this comment.
Reuse pubky route resolution for add-contact scans
The add-contact scanner path now unconditionally navigates to .addContact(publicKey:), so scanning your own pubky or an already-saved contact no longer opens the existing profile/detail route and instead drops into an error flow (self/duplicate). This is a functional regression from the main scanner behavior and makes contact QR scans from the contacts tab fail for valid existing keys; route this through the same resolvePastedPubkyRoute logic used elsewhere.
Useful? React with 👍 / 👎.



Summary
Notes
Validation
swiftformaton touched Swift filesgit diff --checkxcodebuild -resolvePackageDependencies -project Bitkit.xcodeprojvss-rust-client-ffigenerated bindings.globdependency.