Build a Bonafide App
Accounts & Credentials
Why a Bonafide login exists, what it does, and what it never does.
Bonafide is built around connections rather than a central identity. So why does it have usernames and passwords?
Because logging into an app and identifying yourself to someone else are two different things.
A Bonafide credential is used to authenticate you to your own database. It isn't shared with people you're connected to, and it plays no part in establishing those connections. Your login doesn't become an address that others can use to find or contact you.
The protocol keeps these concerns separate. An app needs a way to know you're authorized to access your data. The people you're connected to don't need to know anything about how you log in.
One database per person
Every person using a Bonafide app has their own database.
This is different from having a row in a shared users table or a tenant ID that separates records in a common database. Each person's data is stored separately.
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 multiple Bonafide apps with the same database, each app has its own credential.
For example, you could use Pools and another Bonafide app with the same underlying data, but sign into each with a different username and password.
Changing or removing one app's credential doesn't automatically affect the others.
This lets applications manage their own access without requiring everyone to use one universal login across the network.
Password handling
Passwords are stored as salted hashes, never in plaintext.
Since recommendations for password hashing change over time, each stored hash also needs to record the algorithm and parameters used to create it.
That allows an implementation to recognize an older hash and replace it with one using stronger settings after a successful login. The person doesn't need to reset their password simply because the hashing requirements have changed.
Who creates the database?
Database creation, sign-up, and credential provisioning are handled by whoever operates the Bonafide Agent behind an application.
The protocol defines how agents and connections work, but doesn't prescribe a particular sign-up experience or database provisioning process.
Today, Bonafide Technologies Inc. operates the hosting infrastructure used by Bonafide apps. As independent hosting becomes available, other operators will be responsible for provisioning and managing the databases they host.
If you're developing an app, see Getting Started for the application-side integration.
For the technical requirements, see spec chapter 9: Agent Access & Credentials.