Roadmap

This roadmap distinguishes what is shipped and verified, what is built but not yet independently verified in production, and what is planned but not yet built. Version numbers follow standard semantic versioning: additive, non-breaking features are minor releases (v2.1.0, v2.2.0, ...); a genuinely breaking change to the engine's public API would be the next major release (v3.0.0), which is not currently planned.

Shipped — cryden v2

The bullets below were true at v2.0.0. Everything after that first paragraph has since shipped as additive, non-breaking v2.x releases — see Features for how each one works and Engineering Review for an independent look at the whole codebase as it stands today.

• Signup, login, logout (single session and all sessions)
• JWT access tokens (stateless, short-lived) with algorithm-confusion attack rejection
• Opaque refresh tokens (SHA-256 hashed at rest) with rotation and full reuse-detection (entire session family revoked on detected reuse)
• Session listing and revocation, with ownership verification
• Database-backed account lockout after repeated failed login attempts
• Change password (requires current password, revokes all sessions on success)
• Delete account (requires current password)
• Email change with confirmation-before-effect (via a single-use, expiring verification token)
• Rate limiting (per-user/IP, on login and signup)
• Structured audit logging, separate from operational logging
• Automated test suite covering unit tests per package and Postgres integration tests, including the reuse-detection and lockout-persistence properties specifically

Since shipped, additive and non-breaking:

• OAuth login/signup with any provider, with explicit account-collision handling rather than auto-linking
• Two-factor authentication: TOTP and passkeys (WebAuthn), sharing one login-pause state
• Magic-link (passwordless) login for existing accounts
• Recovery (backup) codes as a second-factor fallback
• Breached-password checking (interface-only) and a configurable password policy
• Login anomaly detection and credential-stuffing detection, both strictly report-only
• Named/fingerprinted sessions (device plus optional geolocation)
• A Redis-backed rate limiter, as a drop-in second implementation of the same interface
• Argon2id as a second password hasher, with automatic upgrade-on-login from bcrypt
• A second production storage backend, SQLite, alongside Postgres
• Cloud logger integration primitives (level filtering, redaction, fan-out)
• Extensible JWT claims, for a host to attach its own authorization data to access tokens
• API keys for machine-to-machine auth, deliberately outside the second-factor system
• Webhooks, so the engine notifies the host app of key events instead of waiting to be polled
• Four read-only, surface-only AI-assisted admin tools: a weekly digest, a support-ticket assistant, a config tuning advisor, and an Ask-AI widget for a host's own end users

Shipped — api (HTTP wrapper)

• Full REST surface over every engine capability listed above, under a versioned /v1 prefix
• Consistent {data}/{error: {code, message}} response envelope
• Edge (per-IP) rate limiting, layered on top of the engine's own rate limiting
• A working, automated smoke test that runs the entire flow (including reuse detection) against a live server over real HTTP
• CI that builds, vets, applies migrations against a fresh Postgres instance, starts a real server, and runs the smoke test against it on every push

Shipped — csax (admin CLI)

• config init, migrate up/down/status, users get/unlock, sessions list/revoke/revoke-all, audit tail, health, version
• Zero engine changes required — built entirely on the already-published public engine API and existing store methods

Shipped — sdk-js (JavaScript/TypeScript SDK)

• Full client for every api endpoint
• Automatic silent token refresh and one-retry on an expired access token
• Pluggable token storage (defaults to localStorage in a browser, in-memory elsewhere)
• Typed error codes (CrydenError.code) matching the API's error contract exactly
• Verified against a real, live api instance (Postgres → engine → API → the actual built npm package), not just unit-tested in isolation

Shipped — typebook (reference application)

A full-stack Google Keep-style notes app (Go/net/http backend, React/Vite frontend) built specifically to exercise every CrydenSync feature in a realistic setting — session management, password change forcing logout, email change round-tripping, account deletion cascading correctly. Serves as both a proof-of-concept and a template for a real production app.

Not yet independently verified

• The engine has extensive automated test coverage, including real integration tests against live Postgres and SQLite databases and genuine WebAuthn ceremonies, but has not yet undergone external, professional security audit.
• The api repository's edge rate limiter default threshold is a reasonable starting estimate, not a value derived from observed real-world traffic.

Planned — near-term (v2.x, additive, non-breaking)

• api and cli catching up to the engine. The engine (cryden) now ships everything listed above under "since shipped," but the api HTTP wrapper and the csax CLI were built against an earlier engine surface and have not yet been updated to expose OAuth, second factors, API keys, webhooks, or the AI-assisted admin tools over HTTP or the command line. This documentation set will get an equivalent pass once those two repositories catch up — see the note at the top of this file's cryden-specific sections for what "caught up" means in practice.
• Python SDK, mirroring sdk-js's design (thin HTTP client, typed errors, pluggable token storage) once the JavaScript SDK's shape has been validated by real use.
• React-specific SDK layer (useCryden() hooks, a <CrydenProvider> context) built on top of the base JavaScript SDK, once the base SDK has seen real-world use.

Planned — later, deliberately deferred

• Package distribution for csax via npm/pip (pre-built binaries with thin wrapper packages, the same pattern used by tools like esbuild or ripgrep), so non-Go developers can install the CLI without a Go toolchain. Deferred until the CLI's command surface has stabilized through real use — packaging something still being reshaped is wasted effort.
• A hosted, multi-tenant CrydenSync Cloud offering. Explicitly out of scope for the foreseeable roadmap and would represent a significant philosophical and architectural departure (see philosophy.md) requiring its own deliberate decision, not an incremental extension of the current self-hosted model.
• Organizations/multi-tenancy, SSO via OIDC/SAML, RBAC/permissions, and data export/delete-my-data. Explicitly out of scope pending a deliberate go-ahead from the project owner, the same discipline that has governed every tier of engine work so far — not started casually just because a slot opened up.
• SMS OTP and passwordless primary passkey login (passkeys are currently a second factor only; no-password-at-all primary login via passkey is a natural fast-follow now that magic-link forced the shared "login without a password" plumbing to exist).

Philosophy behind this roadmap's sequencing

Every addition to this roadmap follows the same discipline applied throughout v2's development: define the interface only once there is a real, concrete consumer ready to use it; prove each layer works end-to-end (including real integration tests, not just unit tests in isolation) before building the next layer on top of it; and prefer a smaller, honestly-scoped, well-tested surface over a larger one that repeats the mistakes that made a full rewrite necessary in the first place.