Bluesky proposes a private-data protocol for ATProto

Bluesky's developers have unveiled a draft AT Protocol extension numbered 0016 — the so-called permissioned data, that is, data with an access perimeter. Today atproto is built as a “public broadcasting” protocol: a user publishes signed records to their repository on a PDS, and applications crawl these repositories and build views. The new protocol keeps the same general shape — DID-based authority, per-user repositories, records typed through lexicons — but serves entirely different scenarios: personal bookmarks and drafts, paid newsletters, private posts and “stories,” closed forums and group chats.

What is proposed

At its core is the notion of a space — an authorization and synchronization boundary, identified by the triple “authority, type, key.” Each participant stores their own records for a given space in a separate private repository on their own host; the space itself exists only as the aggregate of these repositories scattered across the network. To read or synchronize a space, an application must obtain a space credential, issued by the space's authority on the basis of two independent factors: a delegating token from the user's PDS and, if required, an attestation of the client application itself.

The authors are candid about the limits: the protocol provides access control, but not confidentiality. This is not end-to-end encryption — servers and authorized applications read the data, which is necessary for search, indexing, notifications and moderation. E2EE, if anyone needs it, is proposed to be layered on top separately.

Technical choices

Instead of a Merkle Search Tree, as in the public protocol, a private repository is described by a commit based on LtHash — a homomorphic hash built on a lattice problem (and therefore, as the authors note, resistant to quantum attacks). Adding or removing a record is a single cheap addition or subtraction, requiring no recomputation of the entire repository, and the result does not depend on the order of operations.

The commit signature deserves particular attention. The user does not sign a digest of the content directly: otherwise it would produce a “forwardable” cryptographic proof of what a person wrote in a private space. Instead the signature covers only random bytes, and the digest is bound to them with a symmetric MAC. The reader gets full authenticity, but a leaked commit remains “deniable” and proves nothing to a third party.

Synchronization is similar to the public one, but does without a relay: the application pulls repositories directly from hosts and maintains its own copy, reconciling it through a comparison of multiset hashes — a self-healing mechanism, where a missed operation is detected at the next synchronization.

Access and moderation

A user grants permissions through OAuth scopes of the form space:, and every PDS is required to support a basic space-management implementation (simplespace) — with a member list or the policies “public” and “application-managed.” Moderation keeps the previous model, with one caveat: a moderation service cannot see a space it has not been admitted to, and is forced to work as an ordinary reader, publishing labels not into the shared stream but as records within that same private boundary.

The authors emphasize: this is a draft, the terminology and behavior are still going to change, and the implementation itself is a work in progress.

Source: Lobsters