Nice-to-have: expose whether an account has a password set (e.g. hasPassword on getSession)

Nice-to-have: expose whether an account has a password set

Summary

It would be nice if the ePDS exposed a simple boolean — e.g. hasPassword — telling a client whether the signed-in account currently has a password set. Ideally on com.atproto.server.getSession (which clients already call), or via a small dedicated query endpoint.

This is a nice-to-have / low priority UX enhancement, not a blocker. Nothing breaks without it; it just lets apps phrase one button more accurately.

Why this is useful (the UX it unblocks)

ePDS's whole point is a smoother, passwordless sign-up: people create an account with an email one-time code and never set a password. A password is optional — you only need one to sign in to other AT Protocol apps (e.g. Bluesky) with your handle.

In certified-app, the account settings has a "Password" section. Today it can't tell whether the user has ever set a password, so it always shows the same label and copy ("Edit / Reset password"). For the many ePDS users who never set one, that's confusing — there's nothing to "edit" yet.

With a hasPassword flag, the app could branch the label and copy:

• hasPassword === false → "Set password" — "You sign in to Certified with an email code. Set a password if you'd like to also sign in to other AT Protocol apps (like Bluesky) with your handle."
• hasPassword === true → "Reset password" — the current behavior.

Small change, but it makes the passwordless-first model legible to the user instead of presenting a password they may not realize they don't have.

Why a server-side flag (vs. clients guessing)

Clients currently have no reliable way to determine this:

• com.atproto.server.getSession returns only did, handle, email, emailConfirmed, active — no password indicator (verified against a live ePDS account).
• com.atproto.server.createSession with an empty/incorrect password returns the same AuthenticationRequired ("Invalid identifier or password") whether the account has no password or just a wrong one — so it can't distinguish the two.
• An app could track "did the user set a password in our app", but that misses passwords set in any other app, so it can't answer the question correctly.

Only the PDS knows the truth, which is why exposing it server-side is the clean solution.

Suggested shape (additive, non-breaking)

A boolean on the session response is the most convenient for clients, since getSession is already on the hot path:

// com.atproto.server.getSession response
{
  "did": "did:plc:…",
  "handle": "alice.certified.one",
  "email": "…",
  "emailConfirmed": false,
  "active": true,
  "hasPassword": false   // <-- proposed addition
}

A dedicated query (e.g. app.certified.*.getAccountSecurity or similar) would work too if you'd rather not extend the stock getSession shape. Naming/placement is entirely your call — the only thing the app needs is a trustworthy boolean.

Acceptance

• A signed-in client can read whether the current account has a password set.
• The flag reflects passwords set in any app (server-side source of truth), and updates after a password is set/reset.