Feature request: open signup + public subscriber profiles

[marcusbellamyshaw-cell]

Why this matters

The primary driver is comments. Comments are one of the most reliable engagement loops in publishing — readers who comment are significantly more likely to return, share content, and build a habit around the site. For a local history publication, they also generate user-contributed context (corrections, personal memories, local knowledge) that improves the content itself.

Emdash already has everything needed on the backend: the comment submission API, moderation queue, rate limiting, spam protection, and admin tooling are all fully built and production-ready. The authenticated user path in the comment endpoint is already wired — when a logged-in subscriber comments, their name and email are filled automatically from their account. The Comments and CommentForm components from emdash/ui are already live on post pages. The gap is almost entirely in the signup flow and two small config/API additions to the core. There is no new data model to design, no comment storage to build, no moderation system to write, and no comment UI to build.

The account/profile layer exists mainly to give comments a human face: a name, an avatar, a profile page that makes returning commenters feel like part of the community rather than anonymous form submitters. Without it you can still use anonymous commenting, but named accounts tied to real people produce higher-quality discussion and stronger retention.

---

What already works (no changes needed)

• SUBSCRIBER role exists at the lowest permission level
• OAuth login (Google/GitHub) — needs two env vars, routes already exist
• Passkey login — fully wired for existing users
• Comment submission API — POST /_emdash/api/comments/:collection/:contentId with rate limiting, honeypot, moderation queue, and authenticated-user detection
• Comment UI — Comments and CommentForm from emdash/ui are already available and wired into post pages

---

Three core gaps (changes to Emdash itself)

1. Open signup

Self-signup (/_emdash/api/auth/signup/request) is gated by the allowed_domains table. There is no "allow any email" mode — you have to enumerate every email provider.

Request: Add an open: true option to selfSignup in authConfigSchema that bypasses domain gating. When open: true, any email is accepted and assigned defaultRole.

auth: {
  selfSignup: { open: true, defaultRole: "subscriber" }
}

2. Magic link as primary signup path

New users must go through email-verify → passkey registration. The magic link flow only works for existing users. For a general-public audience, passkey registration during signup is too much friction.

Request: Make magic link work as a zero-friction signup path:

• If the email is not in the DB but open signup is enabled, create the account and issue a session on magic link click
• Passkey/OAuth can be added later from an account page

This means a reader can sign up by entering their email — one click in their inbox and they are in.

3. Profile edit API for subscribers

POST /_emdash/api/auth/me only supports dismissWelcome. There is no endpoint for a subscriber to update their own name, avatar_url, or data blob.

Request: Add PATCH /_emdash/api/auth/me accepting { name?, avatarUrl?, bio? }, gated to auth:manage_own_credentials (SUBSCRIBER level). Bio can live in user.data.bio.

---

Site-level work (not core changes)

Once the three items above land, the remaining work is standard Astro pages and components:

• Public login/signup page (Google OAuth + email-for-magic-link, not the admin URL)
• /account and /account/edit pages
• /profile/[username] public profile page
• Avatar handling (Gravatar fallback first, direct upload later)
• "Sign in to comment" prompt for anonymous visitors on post pages

---

Suggested implementation order

1. Open signup config flag
2. Magic link signup for new users
3. PATCH /api/auth/me
4. (Site work) Login/signup page, account pages, profile pages

[ascorbic]

I am quite wary about this even though we do have the surbscriber type, because it opens up a much larger attack surface than currently where there is no untrusted access to admin. I would be open to ideas though, possibly an entirely separate type of account, not shared with users, or maybe a way to make the accounts secure enough to support it. There is some overlap with the paywalls in #1467 which would also have the account concept without admin access.

[marcusbellamyshaw-cell]

The attack surface point is exactly right and I should have flagged it more explicitly. Even with SUBSCRIBER having minimal permissions, any path that creates a users row on behalf of untrusted public input shares the same table and session model as the admin — that's not a great place to be.

The cleanest fix is probably what you're hinting at: a completely separate public account type that never touches users or the admin session at all. Something like _emdash_public_accounts — its own table, its own lightweight session (magic link only, no passkey to start), no admin surface whatsoever. Comments, paywall gating, and profile pages all point at this separate concept instead of users.

That also maps cleanly onto the overlap you mentioned with #1467. If the paywall work is going to need a "member/subscriber" account concept anyway, it would make more sense to define it once there (or in a joint RFC) rather than have two half-baked implementations diverge. Happy to wait and coordinate with whatever shape that work takes, or to draft a joint proposal if that would help.

Do you have a view on whether #1467 is the right place to establish that shared public account model, or would a standalone RFC for the identity layer be cleaner?