The P in PDS

AT Protocol gives every person a PDS, a Personal Data Server. One letter in that acronym decides how everything above it behaves, and almost nobody notices which one.

The P is doing the work. Your posts, your likes, your follows, and every other record you create live in a repo that belongs to you. You can move it to another host and take your identity with you. For social software that is not a convenience. It is the entire point, and it is the reason the protocol is worth building on at all.

Then you try to keep a company's files there.

Where personal stops being right

A designer joins your company and creates the brand files. Two years later she leaves. On AT Protocol those records live in her repo, under her DID, on her server. She owns them, because the protocol was built so that she owns what she writes. That is not a bug in her account. It is the model working exactly as designed, applied to a case it was not designed for.

The workarounds are all bad in a familiar way. You can make a shared company account and hand the password around, which is how teams ended up with a design@ Dropbox login and no idea who changed what. You can copy everything into a vendor's database and give up the portability you came for. You can ask people to hand their repos over when they leave, which is a social process pretending to be a technical one.

Every company that has used Google Docs, GitHub, or Frame.io has hit the same question from the other direction. Who owns this after the person who made it is gone? Those products answer it with an organization account, a billing owner, and an admin who can transfer things. The answer is unglamorous and it is the reason companies pay for them.

What Spaces changed

The Spaces alpha added permissioned records to AT Protocol. A space is a set of records that live in the members' own repos, readable only with a credential signed by the space authority. It gives the protocol something it did not have before, which is a way for a group to share data that is not simply published to the world.

The interesting part is that the space authority is just a DID. Nothing in the design says a DID has to be a person.

The same server with a different owner

So we made the authority an organization. The organization gets a data server of its own, holds the space, and owns the tree. People still write into their own repos, exactly as the protocol intends, and the organization keeps the result. Nobody has to give up their account, and nobody's departure takes the files with them.

On top of that we model a project as a filesystem rather than a record list, because that is what teams already know how to reason about. Paths, content hashes, a working checkout you pull, edits you make locally, and a publish step. If you have used git you already know the shape.

We considered coining a new acronym for the thing, a Project Data Server or some other respelling of the letters. We decided against it, because the letter that actually changes is not what the server holds but who owns it. We call it an Organization Data Server, and the pitch stays in the sentence rather than the initials. A company does not need a new three-letter word. It needs the same portable server everyone else gets, with the company's name on the deed.

What this does not fix

Spaces control access. They do not provide confidentiality. Every member of a space, and every server that stores it, can read the contents, and nothing is encrypted at rest. If your files would hurt you when read by someone with access, this is the wrong place for them today.

Both the protocol feature and our implementation are alpha. Most AT Protocol accounts cannot join a space yet, because the server behind the handle has to run a build that supports them.

Hosting an organization's server is also only as honest as its exit. A did:plc can only be repointed by a rotation key, so if we held the only key for an organization's identity, that organization could not leave without our cooperation and every portability claim above would be marketing. The rule we hold ourselves to is that the organization keeps a rotation key we do not control. We are not finished building that, and we would rather say so than imply otherwise.

Try it

There is a real project running on the production deployment, open to anyone at the public sandbox. You pick a display name, get a guest identity, and land in an organization-owned tree you can pull, edit, and publish to, with no account and no PDS required. Treat it as a public sandbox, because anything in it is world-readable and world-editable.

If the model is wrong, it should be obvious in about two minutes of clicking, which is the point of putting it there.