I noticed this dissonance creeping into the wip collab doc as well:
Protocol primitive — ATProto and permissioned spaces.
The storage, authorization, and sync boundary. A space isn’t a container; it’s a coordination concept made of a space-owner DID, a single member list (the only ACL), an app allow/deny perimeter, and a sync boundary. Records live in each member’s own permissioned repo on their own PDS. Access is binary — you’re on the member list or you’re not — there are no protocol-level roles, and a space credential lets the holder read the whole space (no per-record or per-user read filtering).
Spaces are fundamentally containers of stuff. If an atproto space cannot be accurately described as a container, then it probably shouldn’t be called a space to begin with.
In the bikeshed thread from 3 months ago I noticed four people independently suggested zone, including@bnewbold.net
Seeing the spec fully typed out now, a zone seems to capture very well the kind of meta-place we’re talking about; not quite a place, but rather a subdivision of places stitched together. It’s a bounded area with gated entry, controlled by a zone authority.
Here’s how that comes out in spec language.
A zone is an authorization and sync boundary representing a shared social context. A zone may include many different types of records from many users.
The zone does not colocate records. Instead, each user stores their own records for a given zone in a permissioned repo on their own repo host. A zone is the union of these per-user repos across the network: an application presenting a zone pulls each member’s repo from its host, assembles the view, and applies access control to requesting users.
Each zone is identified by three values:
authority: a DID, the root of authority for the zone
type: an NSID describing the modality of the zone
zone key (skey): a string distinguishing zones of the same type under the same authority
Zone: an authorization and sync boundary for a set of permissioned records, identified by an (authority, type, skey) triple.
Permissioned repo: one user’s records within one zone, with a cryptographic commit, hosted on that user’s PDS.
Repo host: a service that stores and serves users’ permissioned repos.
Zone host: a service that answers for a zone as a whole, issuing credentials, enumerating writers, and routing notifications.
Zone authority: the DID at the root of a zone, which resolves to the space host and the key material for issuing credentials.
Zone credential: a token issued by the zone authority that grants read access to a space.
Delegation token: a token issued by a user’s PDS that an application exchanges with a zone authority for a space credential.
Client attestation: a token signed by an application’s own client authentication key, proving the application’s identity to a zone authority. Required only when a zone gates on app identity.
Syncer: an application that keeps its own copy of a space in sync by pulling from repo hosts.
I personally think you’re tackling the problem from the wrong angle. If “space” could mean both “the place where people coexist” and “the boundary”, why are you assuming it would be the boundary? Keep “space” to mean the place where people exist (which allows you to keep 90% of the terminology the same, including the “ats://” scheme) and just stipulate that when speaking about the boundary itself, we don’t talk about the space itself, but the space’s permissions or something similar.
I think the confusion here is that we’re talking about “spaces” as places people inhabit online, not physically in person. When you’re online you can be physically in many places (just like your data can be in many PDSs) but YOU can be “in” the same Discord channel as 6 of your friends, even though your data is being stored in 6 different locations (imperfect example since Discord is centralized but bear with me). As a result, the “space” we’re talking about is the Discord channel, while the “boundary” is more like the permissions list that defines who is able to read from and write to the channel. That boundary just tells you who can be there, not who is there.
I definitely agree that “place” and “boundary” are distinct. My one issue with this solution, though, is PD only instantiates the latter, and is agnostic on the former. The only things PD actually types up is:
the (authority, type, skey) primitive
the member list / ACL
the credential
The “place”, or the assembled social context, is whatever an app chooses to present when it pulls the member repos and builds a view, regardless of the PD context.
As such, I don’t think “the space’s permissions” works very well. The boundary, not the space, is what needs a rigid term. After all, it’s what gets a typed primitive and shows up in every compound term (space host, space authority, space credential all name the boundary, not the place). The rigid object should carry the rigid name, and the fluid view where app-level affordances live should keep the more intuitive word.
In this context, I do think “zone” fits better here. Like @erlend.sh said, it reads as a meta-place, a bounded subdivision with a fixed edge but variable contents. With this name, “space” is freed for the app-level social context an application assembles and presents.
So my perspective on this has changed a bit in the latest iteration, which I have not properly blogged / documented.
At the time of writing, PD plan had member lists associated with spaces. Roles naturally require member lists so the idea of re-using the member-list of spaces so store role data was the natural fit. So it was multiple semantic usages on top of the same technical affordance.
Anyway, now that is all moot because spaces no longer have membership lists in them. On that point:
I think this is slightly inaccurate since the PD proposal doesn’t have a membership list concept at the space level anymore. Either you are able to get a credential to the space or not, regardless of any possibly existing member list.
Also PD does define the permissioned repos as the the physical stores of data that are logically placed in the space.
On that point, I think this quote of the collab doc somewhat misrepresents spaces. I think spaces really are containers from many perspectives. Maybe you would call them “logical” containers and not “physical” containers, because they don’t literally store the actual data records. But I would call them a container in a similar way that a parcel of land could be considered a “space” that is carved out by law and not by walls.
Now obviously we can create abstract concepts on computers that don’t have perfect physical analogies, but I would argue that the people using the apps built on spaces are very much going to think of spaces as containers. A channel in Roomy is going to map directly to a permissioned space, and people will see it as a container for chat messages.
Even though the real data is spread out across different PDSes, It doesn’t seem categorically wrong to consider the space as having “encompassed” them logically.
All that said, I agree with this point here. It does make it conceptually somewhat difficult that spaces don’t necessarily even say which repos are a part of them.
The space acts kind of like a guard handing out keys. The guard is the only one allowed to hand out keys for his space, but he doesn’t actually guard the door. Instead, anybody in the world is allowed to make a door that can be unlocked by the any of that guard’s keys.
The data lies behind those doors. Some apps may use the key but only unlock some of the doors, and therefore only have some of the data. Apps may not even have a way of knowing which doors there are to unlock!
Even stranger, people who aren’t even allowed to get a key can make a door that is unlocked by the key!
Anyway, I don’t mind the “space” terminology. The more abstract impression of “realm” or “zone” might feel a little better, but I don’t know that there’s a word that we can use that clearly captures the strangely non-physical combination of affordances granted by permissioned spaces.
Because it’s kind of tricky no matter what, I don’t don’t really have anything against any of the suggestions so far.
Right, my bad! My brain is still operating on the old ACL language.
I think this is a valid point, the comparison of a “logical” container to land use carved out by law is quite strong. And, funnily enough, what’s the most common example of that kind of law in everyday life? Zoning laws. This is to say: the plainest English word for a parcel bounded by rule rather than by walls is a zone. This very analogy that makes spaces feel container-like is the same one that names the replacement! I don’t think that’s a coincidence as much as it is intuition.
Regardless of the particulars, though, here’s the most important point to me, the one that personally steers me toward a rename based on @zicklag.dev’s framing. The people who find “space” a perfectly clear term are a small group of fellow protocol nerds. The people who’ll actually trip on it are an unbounded stream of newcomers who aren’t here to weigh in. Tuning the name to what reads fine to this room optimizes for the one population that doesn’t pay the cost, against the one that does.
This is an especially important population to consider with PD. People take permissioning seriously — they want to know how their own private/semi-private data is handled. The test that matters to me most is this: Could I explain this infrastructure to a genuinely curious, non-technical friend and have them come away with a correct high-level picture, without nomenclature getting in the way?
“Space” makes that harder than it needs to be: a less technically minded person with no mapping for a “logical boundary” has to be talked out of the everyday meaning of the word before they can understand the real definition (and even then, the everyday meaning keeps reasserting itself every time the word reappears.). This is something that took me several days of reading to shake off; most other folks won’t be as dedicated as me.
And the problem is that we’re the people least able to judge whether this is overblown. After months steeped in the language, none of us have an intuition for how “space” reads for someone hearing it cold, and that’s hard to correct for even when we consciously try (relevant xkcd). So I’d rather not rest the decision on our own sense that “it’s fine.”
I’ll leave it here, since I think harping on this any more from my end would take resources away from the actual work of critiquing the PD protocol. But I’d love to hear what others think about this.
Ah that’s a good clarification. I figured that might be the case since the collab doc contains a lot of auto-generated summaries of prior discussions, so that’s probably not anyone’s official take.
Still, it does allude to a dissonance inherent to the terminology discourse when that is the averaged-out machine interpretation.
The “coordination concept not a container” is probably a bit misleading. We (as in the atmosphere ecosystem as a whole) are still learning how to discuss concepts like this. As @zicklag.dev pointed out, I think abstractly/logically/aesthetically, spaces will be thought of as containers. This shows up most prominently in the addressing scheme which puts the space as the location before the record in the space.
I’d actually argue the legibility/familiarity argument goes the other way than @baldemo.to is suggesting. Hopefully users mostly don’t have to engage with this term that much, though it is expected that it could show up oauth consent screens or generic account management interfaces. To me “space” is much more approachable & warm and carries connotations from other user-facing products. “Zone” strikes me as technical and somewhat off-putting.
Another consideration is that “space” doesn’t really clash with any existing technical/protocol/networking concepts. “Zone” clashes with stuff like DNS zones. There’s some analogy there but imo it’s also not quite right. It seems easier for communication to mint a new term than re-use an existing term with some faulty assumptions
. This is to say: the plainest English word for a parcel bounded by rule rather than by walls is a zone. This very analogy that makes spaces feel container-like is the same one that names the replacement! I don’t think that’s a coincidence as much as it is intuition.