Identity and membership

There is no account system anywhere in bae. Each person in a library is a coven member: a random, permanent member id and two key pairs, one to sign with and one that keys are sealed to, shared by all of that person’s devices and kept in each device’s OS keyring. A device is one installation, with its own id, belonging to one member. Who belongs to a library is a set of signed records in the cloud home, checked by every member’s device, issued by no server. The machinery is coven’s; this page is how bae uses it.

Membership records

All of a library’s history in the cloud home is one numbered sequence, and every device applies it in the same order. A change to membership or settings is an admin entry in that sequence, signed with its author’s key and judged against the state just before it, so every device reaches the same verdict on its own. An entry counts only if its author may make it, and the library always keeps at least one admin.

Every change a device sends is checked against this record: signed by a current member, from a device that hasn’t been removed. Changes from removed devices or members, from keys never added, or with invalid signatures don’t count. The provider stores the records but cannot forge them.

Roles

Admin and Member both read and write the library: coven checks no permission on library writes, so a read-only role couldn’t hold. Admins additionally invite and remove people, change roles, and rename the library. The person who gives a library its cloud home is its first admin.

Action	Who
Invite a person	an admin
Add a device	the person, from the new device, with their restore code
Remove a device	its person, or any admin
Remove a person	an admin
Rename the library	an admin

A person’s profile, ratings, history, and playlists are owner rows: only that person’s devices can change them, so a rating credited to someone was made by them.

Adding your own device

A restore code proves a device is its person’s, so it needs no approval:

1. The new device gets the code by scanning the QR code another of the person’s devices shows, from iCloud Keychain on Apple devices, or by typing it.
2. It reaches storage: on Dropbox and OneDrive by signing in to the person’s own account, on S3 with their access key, which the QR code carries beside the code.
3. It loads the library, checks that the code’s keys belong to a current member, and registers itself as a new device with an entry signed by those keys.

A code whose keys have since been replaced fails. Restoring always makes a fresh device; it doesn’t rescue another installation’s unsent edits.

Inviting a person

1. An admin enters the person’s provider account and picks their role. bae shares the library’s folder with that account, or on S3 makes an access key for them, and shows an invite: a QR code holding the library’s location, the member id chosen for the person, a one-time secret, and the library’s current name. It expires one day after it was made.
2. The person’s device scans it, signs in to their own account, makes their key pairs, and writes a join request to storage, encrypted with a key derived from the invite’s secret and signed with their new key.
3. The admin’s device, the only one holding the secret, shows the request, and the admin approves it.
4. Approval seals every store key to the person’s new sealing key, then adds the entry admitting them.
5. The new device opens its keys, loads the library, registers itself, and writes the person’s profile with the name they typed.

Declining, or letting the invite expire, takes back the provider access it granted.

Removal

Removing a device or a person is an admin entry, and its place in the sequence is a line in history: what the removed device or person sends after it doesn’t count, while what landed before stays. Removing a person also removes their devices and their private circle, and the keys they held are replaced before more data is written (see Encryption). Cutting off storage access is provider work: the device of the account that holds the library unshares the folder, and on S3 the person’s access key is deleted. What was already synced to a removed device stays with it; data cannot be unsent.

Restore codes

A restore code holds a member’s id and current private key pairs, the library’s store id, and its storage location; never storage credentials, sign-in tokens, or the library’s name. It is shown on demand, stored automatically in iCloud Keychain on Apple platforms, and is exactly as sensitive as the library itself: whoever holds it, with access to storage, is that person to the library. A person who loses every device and their code can be invited again by an admin to their existing member id, which replaces their keys.