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

[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.

[ovitrif]

The write-side ordering from the last round is fixed at this head, thank you — setProfileSetupPending(true) now runs only after activateRegisteredIdentity returns, and the activation-failure path clears it again. What I found this time is the read side of that same flag: createIdentity trusts the UserDefaults-restored isProfileSetupPending without an active session, so one failed session restore after signup permanently dead-ends Create Profile. Details inline, along with two smaller points on test coverage and a duplicated loading view.

[ovitrif]

The write-time ordering in approveSignupAuth is fixed at this head, thank you — setProfileSetupPending(true) now runs after activateRegisteredIdentity. What I still see is the read side. isProfileSetupPending is restored from UserDefaults in init, and this branch trusts it without checking that a session actually came back. When initialize() lands on .restorationFailed it calls clearAuthenticatedState(), so publicKey is nil while the pending flag is still true; .profile then routes to PubkyChoiceView, whose Create Profile button navigates to .createProfile, and createIdentity re-enters this branch and throws PubkyServiceError.sessionNotActive. Nothing in the app clears the flag in that state, so a user who signed up but never finished the profile step and then has one failed session restore can never create a Pubky identity again. Could we require an active session for the pending branch — for example if isProfileSetupPending, let publicKey — and otherwise call setProfileSetupPending(false) and fall through to the normal deriveKeys()/sign-up path below?

[ovitrif]

approveSignupAuth is the new production entry point for both signup flows, and its whole contract is an ordering rule: the pending marker at setProfileSetupPending(true) must only be committed after activateRegisteredIdentity returns, and must stay clear when it throws. That rule is exactly what the last two commits on this branch fix, but no test in BitkitTests exercises it — the new tests only cover URL parsing and scan-scope rejection. This file already has the pattern for it: completeAuthenticationForTesting backs testCompleteAuthenticationRevokesSessionWhenActivationThrows, which is the same shape of test for the older auth flow. Could we add an equivalent #if DEBUG seam that injects the register, Ring-approve and activate closures, and cover both the success case and the activation-throws case asserting isProfileSetupPending stays false?

[ovitrif]

AGENTS.md says "If identical or near-identical UI exists elsewhere in the codebase, extract it into a shared component rather than duplicating it." Here the new signup overlay pairs ActivityIndicator with BodyMText(t("profile__deriving_keys"), textColor: .white64), which is the same pair CreateProfileView.loadingView already renders — grepping profile__deriving_keys returns only these two call sites. Two copies of the same deriving-keys spinner will drift apart in size, spacing and copy the next time either screen is touched. Could we pull the indicator and caption into one small shared view in Components/ and use it from both the overlay and CreateProfileView?