Post

new blog post on permissioned data in atproto! this one introduces "buckets", the protocol-level primitive for shared access control. I walk through two approaches that don't quite work and land on something that I think does let me know your thoughts!

dholms.leaflet.pubPermissioned Data Diary 2: BucketsThe second in a series of posts building up a solution to permissioned data on atproto. We introduce buckets: a new protocol primitive for creating a shared social context.

56 reposts288 likes

Probably a bit early to be discussing implementation, but a question I’ve been wondering about: Will alternative PDS implementations be able to support permissioned data? If so, what will that on-ramp look like? At what point will we have an opportunity to build and test that? Thanks. 😊

I’m working on a proposal for composable community infrastructure that maps very neatly into the ā€œbucketā€ concept. I think this is exactly how we should be thinking about things!

One use case for realm style private data might be early-access content (i.e. add locked webcomics). Ideally posts would become public after a set amount of time. Probably out of scope for the initial implementation, but it’s something I’ve been thinking about.

The bucket approach makes sense. Love the way you’ve laid this out. The questions at the end are super critical for how smoothly this works - looking forward to part 3. I’ve been involved in the AP version of figuring out how threads work in this context, and there’s plenty of trade offs as you say

I like the acl per record approach but how would verification be handled if you drop mst, some form of attestation or reduced signing?

yeah we still want some sort of cryptographic commitment over each bucket's contents but i also think rebroadcast-able signatures over permissioned data is an anti-pattern. and we don't really need the properties of the MST for permissioned data & it's kinda a heavy duty data structure

we'd still have some sort of commitment over record contents. still nailing down the exact mechanism, but something like: merkle tree root, XOR of record hashes, ECMH hash, rolling hash, etc then HMACing that which allows for repudiation unlike an asymmetric signature

Ok by coincidence I started on the Merkle tree root so I could have a known root to track on enrollment but had been trying to stay with mst so existing tools/apps could hook in easily and verify, going to look at those options a bit more

HMAC would require everyone in the bucket to agree to the same key, so you would likely need a GKA protocol like MLS, right?

Ohhh, I'm closely watching this one. The social network I'm working on (Hardcover.app) allows for readers to track various things in the system with permissions (public, people they follow, private to them). Still wrapping my head around ATProto, but permissions data will be a big part for us.

I suspect there will be lexicon and records which live in the bucket for things like groups, roles, assignment (relating these to each other and content)

Good question. Current thinking is each bucket would be tagged with a ā€œtypeā€ similar to the ā€œrealmā€ from the blogpost. So many apps could access a bucket, but each bucket would be ā€œmodality-specificā€. If only to make it so you could sensibly present it in oauth consent screens

One thing that I would like to explore is making the repo the unit of privacy. If I operate a PDS, I can have as many repos as I want and can use caller identity to decide who sees what.

thanks yeah, to me this "bucket" definition seems more like a Mastodon instance or META in that it's a custodian of shared trust. I wouldn't say that it's like a repo in any way other than having an identity and an API.

If there's any common agreement around that, we still have to decide how we participate in those shared private areas, and I wouldn't want to do that from my public repo. But then, I'm assuming that repos are cheap and that I can easily have one that is dedicated to a shared space.

I like this quite a bit, the buckets idea maps somewhat cleanly to MLS groups, though there is of course still a lot of unanswered questions.

Ah. I assume they have a base implementation that adheres to the protocol, but with these forward looking variants on top, which other peers ignore if they don't understand it, but it doesn't break the protocol?

if you mean if its gonna be backwards compatible to the current spec, yea its most likely just gonna be an extension so old apps will work the same but if they want to they can use the new stuff they talked about wanting to add separate apis for this only place that would need to update is the PDS

A+, questions to add to the open list Can buckets have relationships between them, like folders in Google Drive, with inherited permissions? How does an application create private spaces inside the community, like private channels for mods in a private community?

How can I give different access to apps in my community? For example, I want the agent to access public channels, but not the private mod channels. Unclear if the answer is (not) the same as prior questions.

Can a user block access to a specific app to their content across all buckets? eg. they have moral reasons that they never want xAi to read their posts