00: Overview

Status: Draft, v0.1. License: CC-BY-4.0. See LICENSE-DOCS.

This document sets out the terms and the two-layer split used through the rest of the spec. It describes guarantees and message contracts between two independent parties, not any one app's implementation.

Imagine meeting someone new. You don't need an account or anyone's permission, you just start talking, and what you share is between the two of you. Meet someone else, and that's a separate relationship. Neither person knows about the other unless you tell them.

Or hiring a contractor: you share the job details and how to reach you, they share a quote and updates. None of it depends on any other contractor you've hired, or any other client of theirs.

Bonafide enables this online. Two parties connect and share directly, with no central service between them. Each connection stands alone. Nothing carries over to another, even for the same person.

Bonafide makes that last part precise, not just customary: each connection gets its own key material, generated fresh, never reused.

The rule: a connection must not expose anything that lets two connections of the same party be matched to each other.

What you choose to tell someone is different. You can always say "my other contractor recommended you." That's your choice, not a leak. Whether an app supports that kind of disclosure is up to the app, not the protocol.

Being connected also doesn't mean everything is shared. You and your contractor agreed to this job's details, not your next renovation or their other clients. Each kind of information needs its own agreement.

The rule: a party sends nothing it hasn't agreed to share, and receives nothing it hasn't agreed to receive.

That decision belongs to the two people involved, not Bonafide. Bonafide just provides the mechanism that enforces it.

That mechanism doesn't care what's being shared. A message, a photo, a contractor's quote, a store receipt, it's the same connect-and-agree pattern underneath. Bonafide isn't built around messaging, photos, or any one use, any of them can be built on top of it.

Terminology

A connection is the relationship itself, like the meeting or the hired contractor. Each one is independent, with its own key material.

A domain is whatever the connection gets used for, messaging, commerce, anything an app defines. Bonafide doesn't pick one.

A subscription is the agreement that lets one kind of information move, one side offering it, the other accepting it.

Content is whatever actually moves once a subscription allows it, a message, a photo, a quote, whatever a domain defines.

The two-layer model

Connections and subscriptions make up what we call Layer 1: who can reach whom, and what each is allowed to receive. Layer 1 doesn't know what's being shared, only who's allowed to receive it.

Domains and content make up Layer 2: what actually gets shared, and how. Layer 2 only runs on top of an established Layer 1 connection and subscription, nothing moves without both already in place.

A command is a one-off instruction, not something stored or shared further, like reporting a piece of content. A domain defines which commands it supports, the same way it defines content.

A router relays encrypted messages between the two parties of a connection without being able to read them. It's run by an operator, and addressed by an opaque routing token, nothing about identity or domain.

A Bonafide Agent is the software that implements this spec: it stores content, enforces a domain's rules, and manages connections and subscriptions on behalf of its users.

Interoperability

A domain isn't a piece of software, it's a shared definition. Email is a domain: Gmail, Outlook, and Thunderbird are different apps that all implement it, which is why a Gmail user can email an Outlook user.

Bonafide domains work the same way. Two apps that implement the same domain interoperate without their developers ever coordinating directly, because they're both just implementing what the domain defines.

That only works because what a domain defines is published, not kept private to one app. Any app that meets a domain's definition is an implementation of it, whoever built it.

Scope of this draft

Two things aren't covered yet: sharing only part of a content type's fields with a particular connection, and moving an account to a different host. Both are planned, see the README for what's next.

Conformance

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in RFC 2119 and RFC 8174, when, and only when, they appear in all capitals as shown here.

An agent that implements every MUST and MUST NOT requirement of a document is a conformant implementation of that document. SHOULD/SHOULD NOT marks a requirement an implementation can deviate from, but only for a reason it can justify. Conformance is not forfeited by a single deviation, but an implementation that ignores SHOULD requirements broadly should not expect to interoperate reliably with others that don't share its assumptions.