feat: support Pubky signup

[ben-kaufman]

Description

• Accept app-authorized pubkyring://signup and auth-bearing pubkyauth://signup requests, plus direct pubkyauth://direct_signup and parameter-only legacy pubkyauth://signup, through the normal scanner and deep-link flow.
• Register the wallet-derived Pubky identity with the requested Homeserver and optional signup token.
• Keep the existing approval sheet when signup includes app authorization; direct signup skips that step because it carries no app or permissions request.
• Activate the returned Paykit session and continue into the existing profile setup flow.
• Show progress while direct signup completes, dismiss the scanner on terminal auth errors, report Already signed in when a local identity exists, and keep payment-only scanner state intact when rejecting Pubky requests.

This PR is stacked on #697 and uses its Paykit rc50 authorization model. Ordinary Pubky App sign-in must use that grant-auth model; compatibility with the older sign-in request is intentionally outside this signup PR.

Linked Issues/Tasks

Depends on #697.

Screenshot / Video

Not included; this reuses the existing scanner, authorization approval sheet, loading treatment, and profile setup UI.

QA Notes

1. With no Pubky identity, scan a signup QR from staging Pubky App; approve it, confirm the website continues, and complete profile setup.
2. With no Pubky identity, scan either direct signup format; confirm progress is visible, the approval sheet is skipped, and profile setup opens.
3. Scan a signup request while signed in and confirm the scanner closes with Already signed in.
4. Scan an invalid auth request and confirm the scanner closes with an error.
5. Confirm payment-only scanners reject Pubky requests without clearing the current payment flow.

Validation:

• 100 focused Pubky authorization, signup, and scanner tests passed
• SwiftFormat lint passed
• Translation validation passed

[greptile-apps]

Greptile Summary

This PR adds Pubky Ring signup URL parsing, wallet-derived identity registration, authorization approval, session activation, and resumable profile setup through the existing scanner and approval UI.

• Recognizes and validates pubkyring://signup requests while preserving payment-only scanner state.
• Registers the derived identity with the requested homeserver and optional token before approving the requesting app.
• Persists pending profile setup and routes authenticated users into the existing Create Profile flow.
• Adds focused parsing and scanner-state tests plus localization and changelog updates.

Confidence Score: 3/5

The PR should not merge until Ring signup can recover from intermediate failures and users can leave pending profile setup without being immediately redirected back.

The new flow can strand a remotely registered identity when approval or sign-in fails, and its navigation observer creates a repeatable Create Profile trap while setup remains pending.

Files Needing Attention: Bitkit/Managers/PubkyProfileManager.swift, Bitkit/MainNavView.swift

Important Files Changed

Filename	Overview
Bitkit/Managers/PubkyProfileManager.swift	Adds Ring signup and pending-profile state, but the signup sequence is not recoverable after an intermediate failure.
Bitkit/MainNavView.swift	Adds automatic profile-setup resumption, but route-driven reevaluation prevents users from leaving the setup screen.
Bitkit/Models/PubkyAuthRequest.swift	Adds strict parsing and validation for Ring signup parameters and reconstructs the corresponding authorization URL.
Bitkit/ViewModels/AppViewModel.swift	Routes Ring signup requests through the existing scanner while preserving restricted payment-flow state.
Bitkit/Views/Sheets/PubkyAuthApproval/PubkyAuthApprovalSheet.swift	Extends the approval sheet to execute signup and transition into profile setup, with partial-failure recovery delegated to the manager.
Bitkit/Services/PubkyService.swift	Adds low-level registration and Ring authorization operations used by the new signup sequence.

Sequence Diagram

sequenceDiagram
    participant R as Pubky Ring request
    participant B as Bitkit scanner
    participant H as Homeserver
    participant A as Auth relay
    participant P as Profile setup
    R->>B: pubkyring://signup
    B->>B: Parse and show approval
    B->>H: Register wallet-derived identity
    H-->>B: Registration complete
    B->>A: Approve authorization
    A-->>B: Authorization complete
    B->>H: Sign in
    H-->>B: Active session
    B->>P: Navigate to Create Profile

Loading

_{Reviews (1): Last reviewed commit: "feat: support Pubky Ring signup" | Re-trigger Greptile}

[piotr-iohk]

Regtest device QA, home Scan, QR from staging.pubky.app.

Staging e2e doesn’t finish — is that expected?
Signup QR does create a Bitkit identity and Create Profile (R2 / pubky6gifmnu…). Staging stays on the Ring / QR step after Authorize. Sign-in QR from the same flow is rejected (only Pubky grant auth URLs are supported). So this isn’t e2e with the Pubky staging app — Bitkit gets a local profile, the website never continues. If approveRingAuth is supposed to complete that session, it’s a bug. If the site only listens for Ring, say so; Ben’s “QR → sheet → profile” case is then only the Bitkit half.

No spinner after scan.
Scanner closes, home looks unchanged for ~6s while register/activate runs. Feels like the scan did nothing, worse when staging also doesn’t move. Need a loader from scan until the profile screen. Same on fail: first attempt logged identity_error at 09:15:30 UTC with no UI, retry at 09:18 worked.

Scanner stays up after already-signed-in / invalid auth.
handlePubkyAuthApproval toasts Already signed in or Invalid auth request and returns without hideSheet(). Camera sheet stays on top of home — Android dismisses it. Same early returns at the hasStoredIdentity guard and the parse-failure catch. Please dismiss the scanner there.

bitkit_logs_2026-09-03_09-45-08-ios.zip

ScreenRecording_09-03-2026_11-38-24_ios-compressed.mp4

[ben-kaufman]

@piotr-iohk Thanks for the device QA and logs. You found a real signup interop bug: Bitkit treated every pubkyauth://signup request as direct signup, even when Pubky App included relay, secret, and caps. I pushed a fix so auth-bearing signup requests now register the identity and then complete the relay authorization; parameter-only/direct signup still skips app authorization. Direct signup now shows progress, and the iOS scanner closes for invalid and already-signed-in requests.

The ordinary sign-in QR rejection is separate. These PRs use Paykit rc50’s app-scoped grant auth model, while staging Pubky App is still generating the older auth request format. Pubky App needs to update its sign-in flow to the new grant model for ordinary sign-in to work with Bitkit. Could you please recheck the staging signup path on this head?

[piotr-iohk]

Retested the rebased head on a physical iPhone 13 using the regtest build and a signup QR from staging.pubky.app.

Signup now completes end to end: Bitkit shows progress while processing the request, creates the Pubky identity, opens profile setup, and the staging website continues successfully.

Ordinary sign-in still fails because staging currently generates the older non-grant authorization request. As clarified, that is outside the scope of this signup PR.

The original signup interoperability and missing-progress issues are resolved for me.

bitkit_logs_2026-09-03_14-36-23-ios.zip

ScreenRecording_09-03-2026.16-31-36_1-ios.MP4

[ovitrif]

approveSignupAuth sets isProfileSetupPending before activateRegisteredIdentity returns. If activation throws, Create Profile takes the pending branch with a nil publicKey and cannot finish identity setup, and a later scan can toast already signed in if keychain persist already ran.

[ben-kaufman]

Restacked onto the updated #697 head (57dc1ccc) and pushed as 6f836b7a. All five signup commits are signed; range-diff confirms the signup patches are unchanged. Only the parent PR's SDK pin, Package.resolved, and changelog update are added to the resulting tree. The previous failing E2E job was rerun and was still in progress when this newer head was pushed; the new head needs its own CI verification.