feat: add subscription requests

[ben-kaufman]

Description

This PR adds subscription proposals to contacts, building on the payer flow merged in #685.

• Create a daily, weekly, monthly or yearly subscription with an amount, name, optional description and optional public Pubky icon.
• Reuse Payment Request amount entry, recipient rows and expiry controls; send to one saved, privately linked contact.
• Distinguish queued from sent proposals and pending from accepted subscriptions. Show creator subscribers/received payments, with delete/cancel but no edit.
• Validate the wire-size limit before uploading/enqueueing, downsample icons, and count valid billing-period payments once without generating payer prompts for creators.

Discover, autopay and renewal UI are intentionally excluded. Icon hosting is public by design. Adds one changelog fragment.

Base: master, including the merged payer PR. No additional unmerged branch dependency.

Custom icon limits

Custom subscription icons remain enabled. Paykit rc54 stops successful Pubky file responses once they exceed the caller's limit. iOS applies a 1 MiB limit to both the descriptor and image blob, requires descriptor redirects to stay in the same Pubky namespace, decodes images to at most 512 pixels, and caps its memory and disk LRU caches at 32 MiB each.

The current Pubky HTTP client can still buffer an unbounded error response body before Paykit receives it. Transport buffers and the current response chunk can also use memory beyond the retained file bytes.

Safe publication and cleanup remain unresolved. Avatar filenames are shared by content, and a proposal call can fail after enqueueing. Deleting an uploaded image on every error could break another profile or a queued proposal. The remaining publication and cleanup work, plus the corresponding Android integration for #1239 or its merged successor, is deferred. This PR does not fix those risks or claim complete security readiness.

Linked Issues/Tasks

• Payer foundation: feat: add Paykit subscriptions #685.
• Android counterpart: feat: add subscription requests bitkit-android#1239.

Design

• Intro
• Overview
• Create Subscription
• Choose Recipient
• Sent Proposal

Screenshot / Video

Recordings are silent at 4× speed using test wallets. All attached media was inspected and shows only Bitkit, including its keyboard; no device home screen, photo picker or other app is included.

Final keyboard and recipient behavior:

ios-keyboard-fix-4x.mp4

Final recipient and keyboard screenshots

Earlier create → recipient → sent → overview walkthrough

This walkthrough predates the final keyboard and recipient sizing/spacing corrections. The recording and screenshots above show those final corrections.

ios-figma-audit-4x.mp4

QA Notes

Manual Tests

• 1. Subscriptions → Create Subscription → Amount: enter a positive amount; set name and frequency; choose one privately linked contact and expiry → Propose Subscription: sent confirmation shows the recipient, amount and frequency.
• 2. Create Subscription → upload custom icon → Choose Recipient → back: amount, name, description, frequency and icon remain intact; the receiver sees the same public icon.
• 3. Receiver → Review & Subscribe → accept and manually pay: creator changes from pending to one subscriber/one received payment attributed to the payer; the creator does not get a payer payment prompt.
• 4. Pending or accepted creator subscription → Delete → Swipe To Delete: cancellation reaches the receiver; existing payment history is retained; deleted creator proposal remains absent after restart.
• 5. Send with unavailable connectivity or oversized metadata: no false Sent confirmation, useful error and retained draft; retry works after correcting the condition.
• 6. regression: Payment Requests → Create Payment Request: shared amount, recipient selection and expiry behave as before.
• 7. Create Subscription → focus Name and Description in either order: button keeps its standard keyboard clearance, wrapped description/caret stays visible, scrolling and keyboard dismissal work; Choose Recipient and Back preserve the draft while either field is focused.

Live regtest creation/delivery/acceptance/manual on-chain payment, public icon transfer and cancellation passed in both directions with Android. Latest-build confirmation, pending deletion and restart also passed. Offline draft retention/retry was tested on Android. Live Lightning, mainnet and production push were not tested.

Automated Checks

• 156 focused XCTest cases passed. PaykitSubscriptionProposalTests.swift covers UTF-8 wire boundaries, escaped strings, reserved icon space and image downsampling/errors. PaykitPaymentRequestServiceTests.swift covers creator lifecycle, validation before upload/enqueue and proof aggregation, including fractional billing instants.
• The rc54 update passed an XcodeBuildMCP simulator app test build and 194 selected Paykit and Pubky image tests, including byte, decode and cache bounds. SwiftFormat lint and diff checks passed for the five-file update. This was a selected run, not the entire iOS suite.
• Existing payment-proof, send-confirmation, currency and fiat-formatting suites passed. No automated coverage was removed.
• Simulator E2E build passed with DEBUG E2E_BUILD, E2E_BACKEND=network, E2E_NETWORK=regtest; SwiftFormat lint passed for the touched Swift files. This was a focused test run, not the entire iOS suite.
• Final local review found no remaining actionable issues. Keyboard behavior was verified interactively; the focused unit suite does not automate those interactions.

[greptile-apps]

Confidence Score: 2/5

This PR is not safe to merge until subscription creation avoids orphaned public icon uploads and canceled creator subscriptions retain an accessible payment history.

Findings

1.   Icon Upload Is Nonatomic ▶
2.  Cancellation Hides Payment History ▶
3.   Remote Icons Lack Limits ▶
4.  Translations Contain English Placeholders ▶

Summary

• Builds recurring Paykit proposal terms with wire-size validation and icon downsampling.
• Separates payer subscriptions from creator-owned proposals and accepted subscriptions.
• Adds creator payment history, deletion controls, proposal confirmation states, assets, and localized strings.
• Refactors shared amount, recipient, text-entry, image, and segmented-control components for the new flow.
• The review identified non-atomic icon publication, inaccessible history after creator cancellation, unbounded remote icon decoding, and localization-workflow issues.

Diagram

sequenceDiagram
    participant Creator
    participant UI as Subscription UI
    participant Manager as Payment Request Manager
    participant Pubky
    participant Paykit
    participant Recipient

    Creator->>UI: Enter amount, metadata, frequency and recipient
    UI->>Manager: proposeSubscription(draft, target)
    Manager->>Manager: Validate expiry, endpoints and recipient
    opt Custom icon
        Manager->>Pubky: Upload public icon
        Pubky-->>Manager: icon_uri
    end
    Manager->>Paykit: Propose recurring payment request
    Paykit-->>Manager: Proposal record
    Manager->>Paykit: Process pending private messages
    alt Delivered
        Paykit-->>Recipient: Subscription proposal
        Manager-->>UI: Sent
    else Delivery pending
        Manager-->>UI: Queued
    end
    Recipient->>Paykit: Accept and submit payment proof
    Paykit-->>Manager: Active subscription and proof
    Manager-->>UI: Subscriber and received-payment history
    Creator->>Manager: Delete subscription
    Manager->>Paykit: Cancel recurring request

Loading

[ben-kaufman]

Checked this path. PubkyAuthApprovalSheet is not reachable while the Paykit UI is disabled. The only production call that opens it is handlePubkyAuthApproval, and handleScannedData rejects pubkyauth:// before that call unless PaykitFeatureFlags.isUIEnabled is true. Deep links go through the same handler.

[ovitrif]

utAck