Still wrapping my head around the proposal, so preemptive apologies if this is already answered and I just missed it. With that said:
It’s not obvious to me how the proposal handles a space authority that becomes “malicious”.
As a concrete example, consider a private bookmarking app with no social features. It stores all its data in spaces on my PDS, using its own server as the space authority. Down the line, the developer decides to require a monthly payment, and stops issuing space credentials to any accounts without an active subscription.
What is my “credible exit” strategy? Obviously, all the data is still sitting in my PDS — but unless my PDS provides adversarial access to it without going through the space authority, we’re back to “export your data as a bunch JSON files”.
This gets even thornier when you consider group permissioned data, e.g. a forum rather than a private bookmarking app. In that scenario, rather than adversarially accessing data on my own PDS, the community would need to somehow migrate our space repos to another space authority.
1 Like
hey @jakelazaroff.com if you’re OK with it, I’d love to split this into a top level thread – LMK either way.
For forums, one mode might be community owned data – that is all the data is written into an account e.g. community forum as a DID, where all the posts live in the account of one community repo.
Same issue applies, just slightly easier since it’s all in one account.
Following from that, I hope multi-homing becomes a thing this year:
1 Like
Ah sorry — yes, that’s fine! Feel free to split into a new topic.
1 Like
Thanks! We have the technology! (should all redirect and such)
Hey Jake!
A few answers:
In situations like this, the user should really be the authority of the space. The “space authority” is not an application generally. It’s either the user’s DID for spaces that won’t transfer (such as bookmarks, mutes, newsletter, etc) or a newly minted DID for spaces that may transfer (such as communities, groups, DMs, etc).
You can always read your own data from your own PDS with an OAuth credential! Check out the read_self scope here: proposals/0016-permissioned-data at main · bluesky-social/proposals · GitHub
Ultimately this is the prerogative of the community governance structure. Governance of communities is flexible. And just to reiterate, the governance is generally in the community’s hands not in the application’s. The community DID has credible exit from whereever its hosted through similar mechanisms to individual account migration. In the event of malicious community governance, I do think community’s are still in a better spot than in non-atproto communities. A new community under a new DID could be created & each individual user that wants to migrate could export & reimport their data (updating URIs can be done deterministically). This is high-friction but not inconceivable.
I did see the read_self grant! It wasn’t clear to me whether you could obtain that without the space credential, but after re-reading I think that may be clarified in the following paragraph:
A space credential grants whole-space read/sync access directly, so the read and sync methods accept either a covering OAuth scope or a space credential. Write methods accept only an OAuth credential, since a write is attributed to the authoring user.
So that neatly solves the first use case. (I think that also makes things more convenient from an application design perspective; if I’m building a single-user app, I can essentially ignore the space authority and just use plain old OAuth tokens.)
A new community under a new DID could be created & each individual user that wants to migrate could export & reimport their data (updating URIs can be done deterministically). This is high-friction but not inconceivable.
That makes sense. I suppose this is an area where we can rely on “userland” tools to smooth things over — e.g. migrating PDSes is also a high friction operation, which is why tools like PDS Moover exist.
I think the terminology got a bit muddled here. There are two aspects to control/governance of a space:
- Space Host: the server/infrastructure currently hosting the Space Authority. Might be a PDS or a separate PDS-like service. Analogous to a PDS for individual atmosphere accounts. Entire spaces should definitely be able to “exit” from their Space Host via migration, either adversarial or not.
- Space Authority: the network identity associated with the space. For personal data (bookmarks, preferences, etc) this would be a regular atmosphere account. For collective group spaces, this would probably be a dedicated network identity (DID). Space Authorities can migrate between Space Hosts, just like regular accounts can migrate between PDS instances. For adversarial scenarios, it is necessary to have pre-registered a rotation key (to control the DID identity) ahead of time. That is more socio-technically complex for groups/communities than individuals, but doable. Similar to how ownership of property and secrets is more complex in an community: robust governance structures take some effort. If that governance system fails (eg, somebody in the group manipulates all the other leaders and seizes unilateral control), there isn’t a technical solution to that (maybe a legal one?).
I think the “userland tooling” similar to PDS Moover that will be most needed is to help manage/govern the rotation keys for community Space Authorities. Eg, software or minimal external service which supports basic safeties like “3 out of 5 stewards must agree to migrate a Space Authority to a new Space Host”.
1 Like