If you’ve been following along on my series of blog posts about permissioned data, then you’re familiar with the concept of a bucket. This is the new protocol primitive that represents the authorization and sync boundary for a shared context.

I used the word “bucket” 41 times in the last post, and am not legally liable for any hospitalizations that resulted from that:

Anuj Ahooja

@quillmatiq.com

5d

Take a shot every time Daniel says "bucket" Then go to the hospital, probably

daniel 🫠

@dholms.at

continuing to build up our permissioned data protocol!

this one asks what a bucket actually is and where the data that constitutes a bucket is stored. it argues for maintaining the atproto ethos in the permissioned data protocol

as always, looking forward to hearing your thoughts!

3

2

Many people pointed out that “bucket” was a weird word for the concept we’re trying to communicate and doesn’t give the proper intuition. It’s time for me to admit that you’re right, eat a bucket of crow, and retcon this whole thing with a more intuitive name.

This is how you know we’re really figuring it out as we go along!

The problems with bucket

The biggest problem with the word bucket is that it implies data locality. I spent the last post arguing against a colocated bucket. I think this intuition is harder to establish than it ought to be while using the term “bucket”. If we had used a different name for this shared context, it may have been easier (both internally & publicly) to get to an understanding of them as being partitioned or sharded over all the PDSes of the members.

My other problem with “bucket” is that it doesn’t give us a good word for a user’s partition of the bucket (the thing with the actual commit over it). What do we call these? Bucket partitions? Bucket shards? Bucket segments? Bucket repos? None of these quite have the right ring to them. I think this is because “bucket” already sounds like a container and normally the container is the thing with the commit on it.

Permission spaces

After grabbing a fresh bucket of paint and working on the bikeshed with the protocol crew, we’ve decided on the term “Permission Space” or “Space” for short.

The term for a particular member’s records in a given space is a “Permissioned Repo”. Instead of taking the perspective of the space (which is made up of a bunch of partitions or shares) we take the perspective of the user (who has a permissioned repo that is shared with a particular permission space).

We feel that “permission space” gives better intuition about how this primitive functions primarily as an authorization/access boundary. It doesn’t sound like a container and as a result doesn’t imply data locality. “Permission space” and “space” are technical enough and fit the vibe of other atproto words like “repo”, “collection”, and “record”. However “space” is also accessible to non-technical users who may encounter the term in their PDS account management dashboard or during an account migration. “Permissioned repo” builds on the intuition of “repo” from the public protocol and prevents us from having to introduce an additional term.

Next up

Okay had to get that out of the way! I’m still planning to put out another post this week that gives a rough high-level sketch of the big picture for permissioned data including addressing, access control, and sync. I just didn’t want to switch up the terminology at the same time that I’m trying to describe the whole system. That post will use this new terminology so you can see it in action.

Stay tuned!