Phase 40 · planning only
Account / auth implementation decision gate
Compare local-only, magic link, OAuth, and passkey horizons — zero provider wiring until reviewers approve a path.
Gate recommendation
defer until reviewed
No authentication implementation until Phase 40 reviewers approve a path — continue local snapshot authority or pilot minimal auth only after explicit sign-off.
Summary
- No authentication implementation until Phase 40 reviewers approve a path — continue local snapshot authority or pilot minimal auth only after explicit sign-off.
- Options under review: Continue local-only · Magic link / email · OAuth (social / platform) · Passkeys (later).
- 6 matrix criteria scored — implementation complexity stays documentation-only until approval.
- Privacy defaults: 4 principles; deletion/export: 3 requirements documented.
Auth options
- local_onlyContinue local-onlylow
Keep `PersistedClientSnapshotV1` authoritative on-device — no accounts required for rehearsal value.
- magic_link_emailMagic link / emailmedium
Passwordless email continuity — learners verify inbox once, then bind device snapshots to a stable learner key.
- oauthOAuth (social / platform)medium
Delegated sign-in through a hosted identity vendor — fastest path to cross-device restore for some audiences.
- passkey_laterPasskeys (later)future
WebAuthn-style device-bound credentials after baseline email or OAuth continuity exists.
Decision matrix
| Criterion | Local | OAuth | Passkey | |
|---|---|---|---|---|
| Ship rehearsal value without backend Gameplay and ledger fidelity still mature on one device — auth is accelerant, not prerequisite. | favored | deferred | deferred | deferred |
| Cross-device continuity Email or delegated OAuth restore snapshots; passkeys layer on after baseline accounts exist. | not recommended yet | favored | favored | deferred |
| BYOC privacy risk Any hosted path demands explicit opt-in — local-only keeps shorthand off the wire by default. | favored | neutral | neutral | neutral |
| Implementation blast radius (Phase 40) Matrix recommends deferring implementation until reviewers sign this gate — no SDK work yet. | favored | deferred | deferred | not recommended yet |
| Club-host ergonomics Hosts often prefer inbox-based invites over social-login variance at community tables. | neutral | favored | neutral | deferred |
| Future multiplayer seat binding Stable learner keys help roster sync later — still distinct from ledger transport. | deferred | favored | favored | deferred |
Decision areas
- Continue local-only — Can product value ship without accounts for another milestone?
- Magic link / email — Do hosts need inbox-verified continuity without social login politics?
- OAuth posture — Will learners expect a familiar platform button for return visits?
- Passkeys later — When does phishing-resistant hardware matter relative to club-night ergonomics?
- Guest → account migration — How does anonymous local snapshot promote to signed-in learner without clobbering BYOC?
- Privacy defaults — Which slices may sync when identity appears?
- BYOC note protection — How are shorthand anchors encrypted and exportable?
- Local snapshot migration — How does `schemaVersion` uplift interact with first sign-in?
- Private table setup ownership — Who owns salon roster drafts once accounts exist?
- Future multiplayer identity — How do seats map to learner keys without leaking notebooks?
- Deletion & export — What must learners download or erase on request?
Phase 40 non-goals
- Auth provider SDK integration, hosted user tables, or credential storage in Phase 40.
- Payments, tournaments, marketplace flows, or stakes metadata tied to accounts.
- Embedding official NMJL card typography inside identity payloads.
- Realtime multiplayer transport as part of the auth milestone.
After sign-off, choose minimal auth implementation or continue local-only and deepen gameplay — Phase 40 does not commit engineering either way.