Identity and membership

There is no account system anywhere in bae. A device’s identity is an Ed25519 keypair it generates for itself and keeps in the OS keyring; the public key is the identity. Who belongs to a library is a set of signed records in the cloud home, verifiable by anyone holding them, issued by no server. The machinery is coven’s; this page is how bae uses it.

Membership records

Each owner writes an append-only stream of signed membership entries into the cloud home: this key was added with this role, this key was removed. Every entry links to the previous one, and each owner signs a head declaring their stream’s tip, so a provider that drops or reorders records is detected rather than believed. What the library accepts is the union of every owner’s verified stream.

On every pull, each changeset’s author is checked against this record: signed by a current member, with a role that may write. Changesets from removed devices, from keys never added, or with invalid signatures do not apply. The provider stores the records but cannot forge them; only holders of owner keys can change membership.

Roles

Owner and Member both read and write the library; owners additionally approve and remove devices. bae’s founding device is an owner and every device it approves joins as a member. (A third role exists in the underlying machinery, a read-only follower, which bae does not currently assign.)

The join handshake

Adding a device is one local pairing session with explicit human verification:

1. An owner starts Add a device. bae listens briefly on the local network and shows one pairing code. It contains the listener addresses, an ephemeral session key, the library name, the provider, and an expiry — no library key or lasting storage credentials.
2. The joining device scans the code, creates its device keypair, signs in to the provider when required, and sends its signed public key and provider account identity through the encrypted local connection. Both devices show the same fingerprint.
3. The owner compares the fingerprints and approves that exact identity. Approval grants its cloud account access where required, signs the membership entry, and seals the library key and final storage access to the new device’s public key.
4. The sealed package returns through the same authenticated local connection. The joining device opens it, bootstraps from cloud storage, and starts syncing.

An expired, interrupted, or rejected pairing grants nothing.

Revocation

Removing a member appends a signed removal and rotates the library key to a new generation the removed key never receives (see Encryption). On storage that can revoke access, access is also withdrawn. What was already synced to the removed device stays with it; data cannot be unsent. Everything after the rotation is out of its reach.

Recovery codes

A recovery code bypasses membership on purpose: it is the cloud home’s coordinates plus the library key, in one bearer string, for restoring your own library with no surviving approver. It is generated on demand, stored automatically in the iCloud Keychain on Apple platforms, and is exactly as sensitive as the library itself.