Build a Bonafide App
Accounts & Credentials
Why a Bonafide login exists, what it does, and what it never does.
Bonafide's premise is that there's no central identity, only connections. So why is there a login at all?
Because a Bonafide credential does a different job. It never identifies you to a peer, a router, or anyone on the other end of a connection, and it's never part of the connection handshake. It exists for one purpose: to authenticate you to your own database. The guarantee that connections can't be linked to each other sits entirely outside of it. Credentials are a local concern, not a protocol-level one.
One database per party
Every person using a Bonafide app has their own database. That's different from a row in a shared users table, and from a tenant ID that scopes queries into a shared store. It's a fully separate database for each person.
That's what makes "no central identity" true at the storage layer, and not only on the wire. There's no central users table to breach, enumerate, or join against. Compromising one person's database tells you nothing about anyone else's, because there's no shared structure to pivot through.
Your credential, a username and password, is stored inside that same isolated database next to your content. There's no separate auth service or identity store to attack on its own. Getting at one person's credential means compromising that person's database, and only that one.
One credential per app
If you use more than one Bonafide app against the same underlying database, each app gets its own credential, with its own username and password, independent of every other app sharing that database. Changing or removing a credential in one app doesn't affect another app's access to the same data. So no app can lock you out of another one by accident.
Password handling
Passwords are stored hashed and salted, and never in plaintext, anywhere. Recommended hashing settings change over time as stronger algorithms and higher work factors become standard. So an implementation has to record the hashing parameters used for each credential, and upgrade the hash in place, transparently, the next time the person logs in successfully. Nobody gets locked out because the parameters changed after they signed up.
Who sets up the database
Creating the database a credential lives in, and handling sign-up, is the job of whoever hosts the Bonafide Agent behind an app. That's the server-side component that implements the protocol for the app. The protocol itself doesn't specify how. If you're building a Bonafide app, this is one of the pieces your hosting setup has to provide. That guide covers what else is involved in setting up an app on Bonafide.
For the full normative detail, see spec chapter 9: Agent Access & Credentials.