Consider anonymous or pseudonymous comments

[missingbulb]

Feature request

Explore allowing anonymous or pseudonymous comments.

Today comments are tied to the signed-in Google identity. Investigate letting users post without exposing their real identity — either fully anonymous or under a stable pseudonym/handle.

Open questions

• Anonymous vs. pseudonymous (or both)? A stable pseudonym still lets us attribute upvotes and prevent ballot-stuffing while hiding the real identity.
• Abuse/moderation implications of removing the identity link.
• How this interacts with one-vote-per-user (issue: upvoting comments).

Tracking issue — feature request from the owner (exploratory).

[missingbulb]

🤖 Automated deep-review for discussion — plan, tradeoffs, executable-requirements proposals, and UI mockups. A proposal for review, not an authorization to implement; this one is exploratory, so the decisions for you are at the bottom.

Problem (restated)

Today every comment is welded to the poster's real Google identity, and that identity is exposed publicly through the CDN-cached GET /comments. Confirmed against server/src/handler.mjs → toPublicComment(): the public read projection returns authorName (the real Google display name, claims.name) and authorId (the stable Google sub). client/src/sidepanel.mjs renders that name verbatim as the byline. So a reader of any page sees who said what under their real name, and can correlate one stable authorId across every comment they've posted.

The issue asks us to consider letting people post without exposing their real identity — fully anonymous, or under a stable pseudonym/handle — while keeping the abuse/moderation and one-vote-per-user (#22) machinery that depends on a stable identity. This is exploratory: the goal is to frame the design space and the decisions, not to pick.

Recommended approach

Decouple the PUBLIC display identity from the PRIVATE author identity. This is the insight that makes every option tractable and is already half-built:

• authorSub (and authorEmailHash) stay server-private and unchanged — they already carry rate-limiting (enforceRateLimit(authorSub)), moderation correlation (authorEmailHash), and would carry one-vote-per-user (Upvoting comments #22). None of that requires the public to see who you are.
• What changes is only the public read projection (toPublicComment): replace the real-name byline (and the stable-sub authorId) with whatever anonymized display you choose.

A correction to the code's own comment: authorId is annotated "stable Google sub … not PII" — but a sub stable across every page is a cross-page linkable identifier, and authorName is the real name. Removing identity from the public surface does not weaken moderation (it reads the private fields).

Three points on the spectrum (you must choose — see verdict):

• (A) Fully anonymous — public byline is a constant ("Anonymous").
• (B) Stable per-user pseudonym — server derives a deterministic, non-reversible handle from authorSub (e.g. HMAC(serverSalt, authorSub) → adjective-animal), ideally per-thread so it isn't linkable across pages.
• (C) User-chosen handle — requires storage + a uniqueness/impersonation policy.

Implementation plan

The blast radius is small if private identity is preserved; it grows per option.

Option	Data-model impact	Projection (toPublicComment)	Reversible?	Notes
A — anonymous	none new	drop authorName; authorId → omit or per-thread token	Reversible (data intact)	Simplest. Loses "is this mine?" unless paired with a per-user token.
B — derived pseudonym	none new (derive on read from existing authorSub)	authorName → pseudonym(HMAC(salt, authorSub[, pageId])); authorId → same HMAC	Reversible (salt+sub kept)	Per-thread scope prevents cross-page linking; global scope gives a persistent identity.
C — chosen handle	new attribute authorHandle (+ uniqueness guard items under the single-table key, no GSI)	authorName → authorHandle	Effectively permanent once shown	Most product surface (composer UI, validation, impersonation rules).

Stays server-private in all options: authorSub, authorEmailHash, pageUrlRaw. Rate limit and #22 continue to key on authorSub. No GSI needed for A or B; C enforces uniqueness with a conditional-write guard item, preserving the no-GSI decision.

Migration is the one-way-ish part: existing comments carry real authorName; switching the projection retroactively hides real names from new reads (reversible) — unless you want existing comments to keep real names while new ones are anon, which needs a per-item flag.

Pros / cons (incl. development process)

• Abuse / moderation: no regression in any option — moderation reads authorEmailHash + authorSub, which stay. The accountability loss is purely public (the point of anonymity). B keeps a per-thread "same person" signal that deters drive-by sockpuppeting better than full anon.
• Accountability: A removes public reputation; B preserves per-thread reputation without real-name exposure; C invites impersonation ("real_ariel") — needs a policy.
• Migration of bylines: anonymizing all reads is reversible; a per-post choice needs a per-item flag; going back from C is awkward once users expect handles.
• Dev process: A/B are a server-only change + a trivial byline dom update — cheap, fits the executable-requirements model directly. C drags in composer UI, validation, uniqueness writes, impersonation/profanity policy — materially larger, with product-copy decisions.
• Upvoting comments #22 interaction: one-vote-per-user keys on authorSub (private) regardless of public display — no conflict.

Executable requirements (proposed)

New section §9 — Anonymized identity (exact leaves depend on the chosen option; these assume B/derived).

Leaf	Kind	What it proves
9.1	server	The public projection never contains the real authorName, the raw sub, or authorEmailHash — only the anonymized display fields.
9.2	server	Two comments from the same authorSub in the same thread get the same pseudonym; different subs get different pseudonyms.
9.3	server	The pseudonym is per-thread: the same authorSub on two pageIds yields different handles (no cross-page linkage) — or its negation, if global scope is chosen.
9.4	server	Rate-limit and the stored authorSub/authorEmailHash are unchanged by anonymization (moderation still works).
9.5	dom	The rendered byline shows the anonymized handle (not a real name).
9.6	logic (only if C)	Handle validation: length/charset/uniqueness/impersonation rules accept valid and reject invalid handles.

UI sample(s)

ANONYMOUS (option A)              PSEUDONYM (option B, per-thread)
┌────────────────────────────┐   ┌────────────────────────────┐
│ Great summary, thanks.     │   │ Great summary, thanks.     │
│ Anonymous · 3h ago         │   │ Teal Otter · 3h ago        │
└────────────────────────────┘   └────────────────────────────┘
                                  (same poster, same thread →
                                   same "Teal Otter"; different
                                   thread → different handle)

USER-CHOSEN HANDLE (option C) — composer affordance
┌────────────────────────────────────────────┐
│ Posting as:  [ Anonymous  ▼ ]               │  ← per-post choice (if chosen)
│              ( Anonymous / Teal Otter /     │
│                @myhandle )                   │
│ ┌────────────────────────────────────────┐ │
│ │ Write a note…                          │ │
│ └────────────────────────────────────────┘ │
│                               [ Post ]      │
└────────────────────────────────────────────┘

(A composer "Posting as" control is only needed for per-post choice and/or option C; a global policy needs no composer change.)

Dependencies & sequencing

• Informs Upvoting comments #22: Upvoting comments #22 keys on private authorSub; decide this issue's direction before Upvoting comments #22 ships a vote byline so vote UI doesn't re-expose identity.
• Doc dependency: dev/docs/privacy-policy.md and architecture §5/§11.5 byline rows must match the chosen projection.
• Touches only server/src/handler.mjs (projection + optional handle storage), client/src/sidepanel.mjs (byline), and new §9 cases. A/B need no new infra and no GSI.

Implementability verdict

NEEDS-DESIGN. Exploratory; each axis is a genuine product/architecture decision for you:

1. Which model? (A) fully anonymous · (B) stable derived pseudonym · (C) user-chosen handle. (Recommendation for minimal surface + some accountability: B.)
2. If B — scope? per-thread (no cross-page linkage) vs global (persistent public identity). (Recommend per-thread.)
3. New comments only or retroactive? anonymize all reads (hides existing real names too — reversible) vs new comments only (needs a per-item flag).
4. Per-post or global choice? a global policy (no composer change) vs a per-post "Posting as" control (more UI; mixes real-name + anon in one thread).
5. If C — impersonation/uniqueness policy (roughly triples the work; recommend deferring C).

No implementation should start until (1)–(4) are answered; (5) only if C is chosen.

---

Generated by Claude Code