Skip to content

Define the shared mobile product contract and Android mobile auth spec #19

Closed as not planned

Description

@altaywtf

Important

Cross-program gate for the mobile feature slices in both #14 and putdotio/putio-ios#123. Foundation and harness work may proceed, but mobile feature implementation must not settle product scope ahead of this matrix.

Part of #14 (W0). Deliverable lands in the Notion Frontend hub; coordinate with the parallel iOS rewrite epic so both platforms share one product contract.

Outcome

Android mobile has a real parity anchor. The shared v1 matrix and Android auth contract are proposed in putdotio/putio-frontend#34 and remain held until that PR lands.

Scope

  • Shared mobile product contract: one feature matrix used by both the iOS and Android v1 epics (files, search, history, transfers, playback, downloads, share, settings), with per-platform swaps listed explicitly (Chromecast↔AirPlay, documents provider↔Files app, AndroidX Auth Tab↔ASWebAuthenticationSession) — written once in the Notion Frontend hub, page Mobile app, referenced by both epics
  • Extend the Notion Frontend hub, page Auth and device linking, with the settled Android mobile auth flow: AndroidX Auth Tab with direct Activity Result delivery, exact putio://auth, Android Keystore-backed secure token storage, and dedicated public client ID 9677
  • Extend the Notion Frontend hub, page Analytics and tooling: add android to the app enum and place Android in the platform rollout order
  • Note the Android v1 offline-downloads divergence in the contract so iOS parity claims stay honest

Acceptance criteria

  • Both epics (iOS + Android) cite the same versioned contract doc for their v1 scope; no per-platform contradiction
  • Apple and Android mobile feature issues carry native dependency links to this issue before implementation starts
  • The matrix records each intentional launch delta, its owner, and whether it is parity, launch scope, or post-v1
  • Android auth spec pins Auth Tab, provider readiness, exact callback putio://auth, secure storage, and client 9677 so the mobile auth slice needs no further product decisions

Activity

  1. altaywtf commented on Aug 8, 2026

    @altaywtf
    MemberAuthor

    The parallel iOS epic landed: putdotio/putio-ios#123. The shared mobile product contract from this issue is the coordination point between the two programs — write it once in putio-frontend/docs/specs/mobile-app/ and have both epics cite it. Note putio-ios is public: keep the contract doc's private links out of any text quoted there.

  2. altaywtf commented on Aug 8, 2026

    @altaywtf
    MemberAuthor

    Grill decisions (2026-08-08) that bind this contract work:

    1. Change control: this issue produces a versioned v1 feature matrix. After it lands, any scope change requires updating the contract doc and noting both epics (putio-android#14 ↔ putio-ios#123) — change both or neither.
    2. Recorded deltas to write in: Android v1.0 ships the lean offline core (download, local availability, offline playback) while iOS ships the fuller bar (queue concurrency, multi-select, notifications) — Android fast-follows; Chromecast is v1 on both platforms (Chromecast support in the mobile app (VPN/tunnel-safe) #36 moved into W3); Android v1 has a richer transfers UI than the iOS parity bar; PostHog analytics is out of Android v1 (Sentry only) — the android app-enum addition to the analytics contract may still land here without app wiring.
    3. i18n: Android v1 is English-only with strings.xml discipline; no putio-i18n integration commitment.
  3. altaywtf commented on Aug 8, 2026

    @altaywtf
    MemberAuthor

    Addendum (mid-grill decision): Android v1 is dark-only on both form factors — iOS ships light+dark from milestone one, so record this as an explicit platform divergence in the matrix.

  4. altaywtf commented on Aug 29, 2026

    @altaywtf
    MemberAuthor

    Reconciliation checkpoint (2026-08-29):

    • putio-frontend#34 proposes the versioned mobile v1 feature matrix and Android auth contract. It is open and unmerged.
    • PR #60 proposes only a fail-closed Android auth foundation. It does not resolve the shared contract or enable live OAuth.
    • Create the Android mobile OAuth client id (owner: Altay/backend) #47 still blocks live sign-in: the backend and app must choose a verified HTTPS App Link or authorization code + PKCE, then record the exact variant registrations here.
    • The already-closed putio-ios#129 now records this issue as a dependency so the cross-platform contract gap remains visible.

    This issue stays open until the contract lands and the safe Android registration details are recorded.

  5. altaywtf commented on Aug 30, 2026

    @altaywtf
    MemberAuthor

    Reconciled 2026-08-30:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions