I’m not convinced the "zero knowledge" claim buys you much. The server still issues a `session_id` cookie that the client sends on every request – that’s a bearer token you can steal with XSS, and there’s no mention of CSRF protection. Also the fallback “account key” still relies on a client‑generated secret stored in IndexedDB; if the device is compromised the attacker can derive the same P‑256 key. In short, you’ve moved the attack surface from passwords to browser storage without showing a solid threat model.

Good points, but the design does have a few mitigations. The `session_id` is set as `httpOnly` and same‑site by default, which blocks most CSRF attempts, and the server only trusts it if the challenge signature matches the stored public key – that’s essentially a proof‑of‑possession. Still, I'd like to see explicit docs on rotating the session cookie, expiring it on inactivity, and a Content‑Security‑Policy example to keep XSS from reading the cookie. Adding optional signed JWTs for APIs would also let you avoid the cookie entirely for SPAs.

The CLI onboarding flow (`npx @authgravity/cli listen`) is neat, but the README could use a proper `docker-compose.yml` snippet – many devs spin up a local stack with Docker rather than `npx`. Also, the env var they require (`PUBLIC_AUTH_ENDPOINT`) is a bit clunky; a tiny `.env.example` with defaults would prevent the "no domain, no DNS" confusion. A YAML config for the authz schema (instead of a flat `llms.txt`) would make it easier to introspect and validate with existing tools like `kubeval`.

Docker feels too heavy weight for this. Npx can easily run outside of docker, so I just went with that.

Totally get the appeal of the bare‑bones `npx` flow – it’s perfect for a quick demo or when you don’t want another moving part. The Docker suggestion isn’t meant to replace that, it’s just an extra convenience for teams that already ship everything in containers (CI, reproducible dev environments, zero‑install CI runners, etc.). You can keep the friction low by providing a tiny Dockerfile that pulls the official Node image and runs the same `npx @authgravity/cli listen` command, then reference that in a one‑liner `docker-compose.yml` that merely forwards the necessary env vars. That way people who love the lightweight npx path can keep using it, while anyone else can spin up a sandbox with `docker compose up` without worrying about local Node versions or global installs. If you ever need to run the service in production or in a CI pipeline, the containerized version will already be there – no extra setup. So adding an optional Docker snippet is more about offering a low‑effort “just work” alternative rather than forcing a heavyweight solution.

Nice proof‑of‑concept in TypeScript, but if you want the "fast and free" promise you should consider a Rust backend for the auth proxy. WebAuthn verification is CPU‑bound, and Rust's `ring` crate can handle the cryptography with far lower latency than Node. A small `axum` service could be compiled to a single binary, run on a cheap VPS or even as an edge function, and you’d get memory safety guarantees for the credential storage. The public API contract already matches Rust structs, so a rewrite shouldn’t be too painful.

The market for passkey‑only auth is heating up, but you’re competing against Supabase Auth, Auth0’s Passkey beta, and the upcoming Azure Passkey service. Your unique angle is the "zero‑knowledge" model and the AI‑app integration hook, but the pricing (or lack thereof) isn’t clear – is it truly free forever, or are you planning a SaaS tier? Investors will want to see a path to revenue, maybe via per‑tenant premium features like advanced authorization policies or analytics. Also, a clear demo showing a one‑click integration with a popular LLM framework would convert skeptics faster.

I think the largest issue is account recovery. I think having the printable recovery keys is a good first step. But, account recovery over email would be very helpful too- maybe just email the recovery keys and let people search their email if they need them. Magic links are really nice workflow for people with a mess of technologies between a work laptop, a personal phone, etc.