FAQ

The Bona Fide Connection Protocol ("Bonafide") is an open protocol that gives each person their own database, their own connections, and control over what they share and with whom. Different apps can be built on top of it.

See What is Bonafide?.

No. Bonafide is the protocol, and apps are built on it. Pools is the first one.

Think of how email works. Email uses open protocols, and Gmail is one of many apps that use them.

No. They're apples to oranges. A blockchain is a shared ledger that many parties maintain and agree on. Bonafide doesn't have a shared ledger or use tokens.

Each person has their own database, and information travels between connections using encrypted messages relayed by routers. There's no blockchain involved.

Yes, by design, but not fully in operation today.

Each person's data is held in a separate database, and connections don't depend on a central identity system. But Bonafide Technologies Inc. currently operates the hosting and router infrastructure.

Router federation will allow independent organizations to host and interoperate. We're targeting the end of 2026 for that work, with individual self-hosting planned for later.

Bonafide Technologies Inc. currently develops and stewards the protocol. Bonafide grew out of Protegra, the software company we've been running since 1998.

We plan to establish a non-profit Bonafide Foundation to take over stewardship of the protocol, with broader participation in its development.

See Foundation.

Each takes a different approach to decentralization and interoperability. They also use addressable identities, such as handles, server addresses, or WebIDs.

Bonafide is built around connections instead. Two people establish a connection by exchanging a code, without needing a public address that strangers can look up. This changes how people can be contacted, how privacy works, and how unwanted communication can be prevented.

It doesn't mean everything has to be private. Businesses, publishers, and people who want a public presence can still have one.

Bonafide also supports multiple domains, so the same underlying connections and access control can be used for messaging, sharing, marketplaces, and other kinds of applications.

We think these differences make Bonafide useful for a particularly broad range of applications. The other projects are doing important work too, and we're glad they exist.

We called it the Bona Fide Connection Protocol, or "Bonafide" for short.

Bona fide comes from Latin and means genuine or in good faith. It pretty nicely sums up the kind of technology we're trying to build.

The people in the connection they're shared through. Content exchanged over an established connection is encrypted using keys specific to that connection.

The two parties establish their shared secret using X25519, a form of Diffie-Hellman key exchange, and content is encrypted using AES-256-GCM. Each connection has its own keys, and the router doesn't have the keys needed to read the messages it relays.

There's a current limitation involving the first two messages of the connection handshake, which we explain below.

No content. It only sees routing information, as it relays encrypted messages between two people.

It looks up an opaque key and a domain, forwards the message, and has no key to read it.

It holds nothing that identifies a person.

There's one known limitation in the connection handshake, and we've documented it in the specification.

The first two handshake messages are encrypted using a key shared across deployments, because the connection-specific secret hasn't been established yet.

The router can't read those messages, but another deployment holding that shared key could potentially decrypt them if it had access to the traffic.

Messages exchanged after the handshake use connection-specific keys and aren't affected by this limitation.

The planned fix is to include key material in the connection code itself. We're targeting the end of 2026 for that change, alongside router federation.

Bonafide gives each person a separate database rather than keeping everyone's information together in one shared set of tables.

This reduces some of the risks associated with large centralized databases, including mistakes in access controls that expose one user's data to another.

But more importantly, it makes it unattractive to hackers. An attacker gets one person's database at a time. When everyone has their own database, there's no shared users table to dump and no way to pivot from one person's data to another's.

Credentials live inside the same isolated database, so there's no central login store to steal either. Even if an attacker gets someone's connections, they can't send or receive data, because that has to go through the router, which won't communicate with untrusted actors.

It's simply way too much work for a hacker for very little reward.

Only people you've connected with.

There are no public addresses that strangers can use to contact you. A connection requires an exchange of a code, and you control how many times a code can be used.

You can publish a code if you want people to be able to connect with you. A business might do that, for example.

Either person can disconnect at any time. Once the connection ends, it can no longer be used to contact the other person. They'd need another valid code to reconnect.

That's quite different from blocking someone on email or social media. Blocking leaves the address or account in place. With Bonafide, disconnecting removes the connection itself.

Either person can end a connection at any time, without needing the other's permission.

The protocol's removal process deletes the content shared over that connection from both sides.

Yes. Bonafide controls who receives your content and how far it travels inside the network.

It can't stop a person from taking a screenshot of what they were allowed to see, but that's true of almost every system you use with other people you trust.

What the protocol does guarantee is that apps honor the hop limit you set, so content doesn't travel further inside Bonafide than you allowed.

You need a login for the app you're using, but that login is only used to access your own database.

It's not shared with other people and isn't used to establish connections. If you use multiple Bonafide apps with the same database, each app has its own login.

One of you generates a single-use code that expires, then shares it with the other person in whatever way you trust.

The other person enters the code, and the apps establish the connection.

You don't need to exchange phone numbers, email addresses, or usernames.

Yes, provided the apps implement the same domain.

Your data and connections live in your database, so another compatible app can work with the same information.

That's an important part of the design, but it isn't available yet.

Today, Bonafide Technologies Inc. is the only hosting provider. Router federation will allow other organizations to host, but moving an account between independently operated hosts isn't specified in v0.1.

Account migration is a future piece of work. We'd rather be clear about that than imply it already works.

Pools is the first app built on Bonafide. It's not social media and it's not a group chat. It's somewhere in between.

You create private spaces for sharing different things with different people, with conversations under each post. There are no public counts, ads, or algorithms deciding what you see.

Pools is available on iOS and Android.

Get Pools →

You define a schema for the information your app shares, add handlers for the four message types (connection, subscription, content, and command), and use the reference Bonafide agent library.

The library handles much of the underlying complexity of the decentralized system, so you can spend more time building the app itself.

See Getting Started.

JavaScript.

No. The reference library handles much of the protocol through a small registration API.

The specification is there when you need the technical details or want to understand exactly how something works.

Not yet. For now, applications use the infrastructure hosted by Bonafide Technologies Inc.

Router federation will allow independent organizations to operate their own routers and interoperate with the rest of the network.

A domain is a shared contract for a particular kind of application. It defines the information apps can exchange, how access to that information is controlled, and the commands that act on it.

When different apps use the same domain, they can understand and work with the same kinds of information.

See Domains & Interoperability.

Yes. You can propose one through a GitHub issue or pull request, or reach out to discuss what you're building.

See Adding new domains.

The specification text is published under CC BY 4.0. Code and machine-readable schemas in the specification repository are licensed under the Mozilla Public License 2.0 (MPL-2.0).

See License.

AI agents built on Bonafide use the same connection and access control model as other applications.

An agent needs an authorized connection to interact with someone. What it can access, receive, or share through the protocol is governed by the permissions on that connection. That limits opportunities for unsolicited communication and unrestricted data collection through the network.

Not yet. We plan to establish a non-profit Bonafide Foundation to take over stewardship of the specification from Bonafide Technologies Inc.

The Foundation would manage the change process and allow broader participation in developing the protocol.

We're looking for sponsors and donors to help make that happen.

Support the Foundation →

Open a GitHub issue or pull request.

We ask contributors to read the relevant parts of the specification and explain the problem they're trying to solve, so proposals can be considered in the context of the overall design.

See the change process.