Overview
Currently there is no authentication layer in any sync mode. This issue is a discussion/planning space to work out the right strategy before any implementation begins. No approach has been decided yet.
What already exists
A lightweight access control layer is already in place across sync modes:
- Each browser has a persistent UUID (
annotate_author_id in localStorage) attached to every thread and reply. Edit and Delete are gated to the browser that created the item.
- Resolve is intentionally collaborative — open to all peers.
- In P2P mode, even the admin cannot unilaterally delete another user's content; the admin's "Clear all" purge broadcasts to peers but ownership-gated actions remain enforced per browser.
- The server enforces ownership via
checkOwnership on mutation endpoints, rejecting requests where authorId does not match.
This is a trust-on-first-use model: the authorId UUID is self-issued and unverified. It prevents casual interference but offers no protection against a peer who deliberately spoofs a known UUID.
Per-mode considerations
Offline — no auth needed. Single-browser, no network, no other parties involved.
Server sync — straightforward in principle; the question is which mechanism to adopt. Candidates include a static shared secret passed as a header, per-user API tokens issued by the server, or delegating to an external provider (OAuth / OIDC). The choice mainly depends on how much user management the server is expected to own.
P2P — the open problem. The room ID functions as a shared secret for data access, and the existing authorId model provides ownership gating, but neither authenticates identity. A peer who knows someone's UUID can spoof it over the data channel. Questions that need answering before a design can be proposed:
- Is verified identity in P2P actually a requirement, or is the current model sufficient for the intended use cases?
- If spoofing resistance matters, what trust anchor is available in a serverless browser-to-browser model? (Candidates: pre-shared signing keys, a challenge-response over the WebRTC data channel, or binding to a server-issued token when a relay is present.)
- How would stronger auth interact with the existing ownership model without breaking the collaborative Resolve behaviour?
Status
No strategy has been decided. This issue is open for discussion. Implementation should not begin until a concrete proposal is agreed for at least the server sync mode, and separately for P2P.
Overview
Currently there is no authentication layer in any sync mode. This issue is a discussion/planning space to work out the right strategy before any implementation begins. No approach has been decided yet.
What already exists
A lightweight access control layer is already in place across sync modes:
annotate_author_idin localStorage) attached to every thread and reply. Edit and Delete are gated to the browser that created the item.checkOwnershipon mutation endpoints, rejecting requests whereauthorIddoes not match.This is a trust-on-first-use model: the
authorIdUUID is self-issued and unverified. It prevents casual interference but offers no protection against a peer who deliberately spoofs a known UUID.Per-mode considerations
Offline — no auth needed. Single-browser, no network, no other parties involved.
Server sync — straightforward in principle; the question is which mechanism to adopt. Candidates include a static shared secret passed as a header, per-user API tokens issued by the server, or delegating to an external provider (OAuth / OIDC). The choice mainly depends on how much user management the server is expected to own.
P2P — the open problem. The room ID functions as a shared secret for data access, and the existing
authorIdmodel provides ownership gating, but neither authenticates identity. A peer who knows someone's UUID can spoof it over the data channel. Questions that need answering before a design can be proposed:Status
No strategy has been decided. This issue is open for discussion. Implementation should not begin until a concrete proposal is agreed for at least the server sync mode, and separately for P2P.