With the rollout of permissioned data I've raised the concept of lack of adversarial space migration a few times but I want to give some more space to setup the problem, game out a few scenarios and then talk about what can reasonably done at a protocol level and how big a lift it would be.
ats or at
Whichever way to fall on the scheme discussion either with at:// or ats:// the structure of a permissioned data uri has remained largely the same since it was first introduced in the permissioned data diary 4 The structure is:
Space Owner DID
Space Type
Space Key
Repo Owner DID
Record Type
Record Key
The uri structure makes sense, an naturally follows the resolution process. However it's structure by placing the Space Owner as the primary authority introduces potential problems when that owner becomes hostile. Let's consider a few cases:
Introducing Discuss.it
Let's imagine an online discussion site, the site is divided into boards which can be public or private, each board gets to set it's own policies. Users post topics on boards that are then responded to by different users. People can up-vote and down-vote, and let's stop pretending this is unique - we're building reddit on the at-protocol.
The Naive good citizen
The first attempt to building Discuss It ends up taking a naive approach and uses the simple spaces implementation. Every board is going to be a space and the space owner is going to be the user who created the board.
Everything goes fine until one of the popular boards /d/aww has it's owner decide they no longer want to be the admin for the board. The only problem, all those posts have the original admin as the root authority. At first the admin feels like they could just hand over their account to a new admin but since this is atproto that will also mean handing over their bluesky posts, their blogs, their game saves, private chat messages, etc. In the end the admin decides the best solution is to just shutdown the board and let all the users repost their stuff over on /d/awwcute Most of the board's history is lost, but people do occasionally go back into the archive and dig up a past post.
The PLC maximalist
The second attempt to building Discuss It uses a did:plc for every board. Initially the did's rotation key is held by the user who created the board in their pds, but new rotation keys can be added as new admins are added to the board. The /d/ama board is a great success story having changed leadership a few times over the course of it's tenure. However there's admin drama brewing.
3 users currently administer /d/ama, let's call them Alice, Bob, and Carol. Bob and Carol don't think that the ama board should host sex workers and adult content creators but Alice disagrees. Bob and Carol decide that Alice shouldn't be an admin anymore, they want Dave to be an admin now. They use Bob's rotation key to update the PLC registry to remove Alice and add Dave. However Alice's key was first in the rotation list. She see's that she's been removed from the DID document and within the 72 hour window uses her key to instead remove Bob and Carol leaving just her as the sole admin. Bob and Carol try to fight back but as the holder of the key in the first position Alice has the ultimate authority.
Ultimately under Alice's direction many community member's are happy but there are many who don't want to be associated with sex work and adult content, they ultimately leave to start their own board d/iama, some of the new community members repost topics from the past but they lack the discussion that had made them so interesting.
The DID web solution
In a third attempt the creators of Discuss It have decided to forego did:plc and instead use did:web. This will let them put in place policies around community ownership transfer, hopefully avoiding a schism like the ama one.
The implementation works great, because the dids are now controlled by Discuss It directly they're able to put in place a system where communities can vote on admins. The /d/news board is having a bit of an identity crises and many of the users feel it's too America centric. The community votes and ultimately the admins stay the same. Some people start a /d/worldnews board for less America centric news but generally both boards are still well subscribed.
However Discuss It has been looking at a new round of investments and one of the major backers is the Saudi Sovereign wealth fund. It turns out one of the admins of /d/worldnews is a Saudi dissident. While Discuss It doesn't want to squash any free speech it does reserve the rights in it's terms of service to remove any admin. Their trust and safety team is able to find several posts that Discuss It can use as cover to remove the admin status of the dissident user. The worldnews board is up-in-arms and even vote the admin back in but the admin removal is permanent. In protest many users move off of the Discuss It app to a competitor that uses the same records. However since the did:web for the worldnews board is owned by the Discuss It domain even a move to a new app doesn't re-instate the admin.
When things went really off the rails
Up till now Discuss It has been a pretty good citizen of atproto, however they recently got acquired by a private equity fund. In an attempt to generate revenue They've started to sell ads but after the big /d/worldnews debacle many users no longer use the official Discuss It client and are not seeing their ads.
In an attempt to move people back into the official Discuss It app they switch the policy on the spacehosts that they have been running for all the did:plc and did:web spaces. The space hosts now only authorize the official Discuss It app. They've also locked down their app view to only the official app. Most of the users were already on the official app so they don't notice but people on competitive apps are up-in arms. Of course what's even worse is the newly announced policy that private groups are going to become a paid feature, and any user that is currently part of a private group will loose access to hat group unless they subscribe to Discuss It. Because Discuss It controls the space dids and the space hosts they can also control the space credentials.
Discuss It knows this seems like problematic behavior but they put out a press conference citing poorly written clients causing undue strain on the system.
Anti-social actor
The moves that have enraged the Discuss It community are clearly against the spirit of AtProto but they're all well within the bounds of the permissioned data design. Users who have used their own DID as an space DID, or users who hold the rotation key in the first position of a plc DID have an out, they can move to a new space host. The users who have something locked away in a did:web are the ones who are truly screwed.
Adversarial Migration
In the PDS realm we talk about adversarial migration, that is the PDS doesn't want you to migrate but can't stop you.The beauty of did:plc is that the PDS is not also the holder of the did, that means that the indirection built into the did documents allow you to move records between pds' without moving at uris.
Spaces dids offer the same benefits for space hosts, someone who controls the did controls the host and can switch the host. However as I've laid out there are many cases where the person controlling the DID is the problem.
Non-technical solutions
Generally we need a way to help users understand the type of space they're working in, and it's a good assumption that the controller of a DID is the effective owner of any records in its space. This plus norms let us name and shame the same way we do for apps that use transition:generic.
Ultimately many of the problems that would require migration are related to interpersonal issues and having the community structure's in place to resolve these issues before they cause schisms is important.
Shared keys
One technical solution that could be implemented on the PLC side is the use of Shamir secret sharing. This approach would allow splitting the first positioned rotation key of a DID into N parts and require K of those parts to reassemble it. What does that mean in practice? In our example with the ama discussion board, Alice as the holder of the first positioned plc rotation key could override Bob and Carol. Keys in a DID are required to be ordered and order determines their ability to override each other. Imagine instead of that first key position had required 2/3 of the key holders to agree. Bob and Carol now can out vote Alice. We may disagree with Bob and Carol's views but majority rule does seem more fair than arbitrary positioning.
Being able to share keys amongst admins and configure thresholds allows the people controlling a DID to work together and set their own policies for changing things like the space host.
Moving Records
Secret sharing solved a problem of DID owners disagreeing, but what happens when people whose records are part of a space disagree with the DID owners? What if they want to move records between spaces, duplicate records, or make them public?
It's trivial to copy records, and in fact in he /d/aww and the /d/ama examples above I talked about copying data. A copy of a record can be proven to contain the same content but there are two issues.
- 1.
Because PDS records are mutable we have to consistently ensure they say in sync
- 2.
He copy will nessesarily have a different aturi that is disconnected from the original.
An issue arises if a record containing an aturi exists in a different space than the one the aturi references. In our Discuss It example imagine a feature where I can quote a discussion from another board. If the user who created that discussion wants to move it to another board the reference will still point at the old board.
Spaces don't store records
Conceptually a record is in a space, but in practice it's more accurate to say that a record is authorized by a space. This gives us the opportunity to break the conceptual relationship without breaking the practical one. Spaces still authorize access to records but a record can be part of 0 - n spaces. Moving a record between spaces would be the process of adding an authorizer and then removing the old authorizer. "Deleting" all the records from a space would be removing that authorizer from all records.
There's a few things this would enable in practice:
X-posting: in our Discuss It example a record for a discussion could be part of multiple boards by using multiple space authorizers. The responses and upvotes could be posted in 1 or more spaces allowing you to take a space specific view of a collection of records or a hybrid view across multiple spaces.
Partial community migration: When some of the users in /d/news decided to move to /d/worldnews they could selectively move both posts and comments with them without removing them from their original board
Unexpected Permission Modality Transition
This is my new at proto space term (UP-MiTts?) that covers a specific case of permissioned data. Becuase all records in a space (represented by a space did, stype, skey triple) are permissioned together these records must all become public, all become private, all allow your aunt Gertrude to access etc.
That causes a problem if you put records in the space that shouldn't be shared with the same modality as other records. Our Discuss It example doesn't have a clean example of this problem, but let's take a recipe book: A naive implementation may have a "book" of recipes be a space, share the book with your household and you can both contribute to it. However the second you want to share the tomato soup recipe you made for your husband's cousin's Canadian Friendsgiving you're stuck either inviting them to your recipe book or copying the recipe into a new book. If we could move the recipe to it's own space there'd be no issue.
Solution Time
Shamir Shared Secrets are a solution that exists both at the reference PDS and PLC level and I think is a needed one to make community governance possible without trusting hosts whose incentives aren't going to stay community aligned. It's not a silver bullet but it's implementable on top of he existing spec and a poc could be done in a long weekend.
Moving records between spaces is a harder problem and one that needs some aturi, and http status code juggling. It still feels tractable. The most simplest solution I've come up with would be to enforce record uniqueness across did/rtype/rkey even between spaces. That would mean that you could treat two urlis with the same did/rtype/rkey triple as the same record even if the space-did/stype/skey triple were different. There's some gymnastics to do in order to prevent leaking space participation but it's a plausible solution. The nice thing about this is that it allows for a migration or a record from being in 0 - n space to also being public or even potentially a transition away from public to permissioned. That fits use cases for stream place and cavu reader.
Adversity
Communities like the hypothetical Discuss It system we've been discussing are some of the first use cases for spaces. History has shown us that drama amongst community admins is likely something we'll experience days if not hours after those go live. We should be ready for adversity, and maybe the answer is the status quo – you're data is stuck in the community and the platform can exert controls, but maybe, just maybe we can build a path into a community that is governed by it's members independent of any platforms.
We've all experienced the drama of having the people who control the platforms we love turn into weird billionaires. However this is often a distant and barely impactful event. The "community forum drama" is a much more visible and understood thing for most people. If a AtProto community platform could promise a way to survive drama I think more people would see the appeal than "take your twitter posts with you" offers.