MOCHA Personal Address Book

Introduction MOCHA users need to maintain a personal directory of contacts — mapping user identities (e.g., alice@provider.example) to display names and other metadata they trust. This address book must synchronize across all devices belonging to the same user without requiring a centralized contacts server. This document specifies:

The MOQT namespace and track structure for address book data
The contact card format (based on jCard )
The synchronization model across a user's devices
Group and object organization for efficient retrieval

Conventions and Definitions See BCP 14 . This document uses terminology defined in , including Provider, Organization, UserID, and Device. HDevID is defined in . The following additional terms are used:

Personal Address Book (PAB):: A per-user collection of contact cards synchronized across all of the user's devices via MOQT.
Contact Card:: A single entry in the address book, encoded as a jCard object. Each card maps an identity to a human-readable name and optional metadata.

Namespace and Track Structure

Namespace The MOQT tracks carrying address book contact cards use the following namespace tuple: , , "pab", ) ]]> Where:

Provider: The user's home provider domain
OrgID: The organization the user belongs to
pab: Literal string identifying this as a Personal Address Book namespace
UserID: The identity of the user who owns this address book

Track Name Each device publishes its address book updates on its own track: ) ]]> Where HDevID identifies the publishing device. Each device maintains its own track to avoid write conflicts between devices.

Example This represents the address book updates published by Alice's device "device-a3f2" within the "acme" organization on provider "example.com".

Group and Object Organization

Groups There is one group per calendar month. This provides a natural time-based partitioning that allows devices to efficiently fetch recent changes without downloading the entire history. Groups are numbered sequentially, with the group ID derived from the month:

Objects Each object within a group represents a single contact card operation (add, update, or delete). Objects are sequentially numbered within each group.

Contact Card Format

Overview Each object payload is a JSON document containing a contact card operation. The card data follows the jCard format defined in .

Operation Types ", "timestamp": , "card": } ]]>

Example: Adding a Contact

Example: Deleting a Contact

Synchronization Model

Device Publishing Each device publishes contact card operations to its own track. When a user adds, modifies, or deletes a contact on any device, that device publishes a new object to the current month's group on its track.

Device Subscribing Each device subscribes to the tracks of all other devices belonging to the same user. This is achieved by subscribing to the PAB namespace: , , "pab", ) ]]> The relay delivers objects from all device tracks within this namespace, allowing each device to learn of changes made on other devices.

Conflict Resolution When multiple devices publish conflicting operations (e.g., both update the same contact), the operation with the latest timestamp wins. If timestamps are equal, the operation from the lexicographically greater HDevID takes precedence.

Initial Sync A newly added device subscribes starting from the earliest available group to reconstruct the full address book state. The device applies all operations in group and object order, with later operations overriding earlier ones for the same contact identity.

Authorization Access to a user's PAB namespace is restricted to that user's own devices. The Token Service issues C4M tokens (or Privacy Pass tokens) scoped to the user's PAB namespace: //pab//msg/"] subscribe: ["mocha_v1///pab//*"] ]]> Each device can only publish to its own track but can subscribe to all tracks within the user's PAB namespace.

Security Considerations TODO

IANA Considerations This document makes no requests of IANA.