Docs Menu

Domains & Interoperability

Domains & Interoperability

How independently built apps can work together on Bonafide, and what the protocol handles for developers.

Bonafide provides the common foundation for connections, access control, and sharing. Domains define what applications can do with that foundation. Many different domains can exist on Bonafide, and within each domain, independently built apps can work together.

Many domains, many interoperable apps

A domain defines the content types, relationships, access-control categories, and commands that applications use. It's a shared contract that different developers can build against.

Pools is the first published domain, bonafide.pools, and messaging is coming. Developers can also propose entirely new domains through a public process. See Build a Bonafide App.

A domain doesn't belong to any one app. Imagine someone using Pools and another person using a different app built on the same domain. Both apps understand the same content and sharing rules, so those people can interact without having to use the same application.

It's similar to email. Different developers build different email clients, but they don't need to coordinate with one another to make their apps compatible. They implement the same protocols.

There's another benefit. Because your data and connections live in your own database, a different app implementing the same domain can work with that information too. You can try another app without having to start over.

That's what makes interoperability interesting. Developers can create different interfaces, features, and business models while working with the same underlying network of people and information.

What this means if you're building an app

You define what your app does, what information it works with, and the experience you want to create. Bonafide provides much of the underlying machinery:

  • Connections. How two parties establish a private relationship without needing public addresses.
  • Access control. How people grant and manage permission to exchange different kinds of information.
  • Data sharing. How content is delivered, propagated, and maintained across separate databases.
  • Sharing through degrees of separation. How information can travel beyond the people it was originally shared with, while respecting the limits placed on it.

Your application still implements the behaviour specific to its domain, but you don't have to invent these underlying mechanisms yourself.

Sharing beyond the first connection

This last capability is worth explaining because it's a little different from how most apps work.

When someone shares content, they can control how far it travels. Without permission to propagate further, it stays with the people who received it directly.

A domain can define the rules for wider propagation, and an app can give the person sharing a way to choose how far their content is allowed to go. That distance is expressed as a hop limit.

Once the content is shared, its limit travels with it. An app receiving it can't simply decide to pass it further than the rules allow.

This means developers can build applications where information moves through networks of connections, without having to create their own system for managing who is allowed to share what with whom.

What this means for people using Bonafide

The most important consequence is choice.

If several apps implement the same domain, you don't have to convince everyone you know to move to a different app just because you've found one you prefer. You can use a different application while continuing to work with compatible data and connections.

The architecture also changes some familiar aspects of being online.

There's no requirement for a global feed. Bonafide doesn't maintain one central pool of everyone's content or decide what people should see. Applications work with information made available through connections and access permissions. They can present that information in different ways.

Strangers can't simply message you. Bonafide has no universal address that someone can look up to contact you. Private connections require an invitation and mutual agreement, removing the usual route for unsolicited messages and connection requests.

Control works in both directions. Subscriptions determine what information people have agreed to receive, while sharing permissions and hop limits govern how content can move through the network.

These are decisions made at the protocol level, not for each app to invent for itself.

The result is a common foundation that developers can build different things on, while people retain control over their relationships and the information they share.