How much control does / should a PDS have over user data?

[kueda]

I’ve been trying to wrap my head around atproto so thank you all for all the excellent documentation and discussion.

Can and should a PDS reject certain schema types? Like if you host a PDS and I store my data there, presumably you can reject me if you don’t like me, but what if you don’t like some of the content I want to store on your PDS? For example, if Bluesky is my PDS, do they have to host all of my non-microblogging content even if it’s a burden on them with no benefit to them?

And on the flip side, if Bluesky is my PDS and they decide they don’t want to host my leaflet / tangled / whatever content, what recourse do I have other than migrating all of my data to a different PDS or using different DIDs for different services?

Apologies in advance if I’m missing something fundamental. Still learning the ropes.

[yamarten]

In the ideal sense, PDS is lexicon-agnostic and does not favor any particular collection. (See also #3116.)

Technically, if you implement PDS to check the collection NSID in the record API, you can prohibit the creation of records such as Leaflet publications. In addition, in order to prohibit workarounds such as BlueDM, which embed data for different apps in the permitted type, additional record validations will also need to be implemented.
PDS administrators can add any edits to their host repository, so it is easier to delete them manually later. To prevent this, you'll have to move to a trusted PDS.

Please note that the boundaries of the service are not always clear. In the case of Bluesky, some third-party clients use their own records and embedded data to extend their functionality.

[kueda]

Thanks, that confirms my understanding of what's possible. In terms of what is desirable, though, why is it like this? At present most PDS operators are app operators like Bluesky, not agnostic data hosts like, say, S3. S3 doesn't care what content you store with them as (maybe within the limits of local law), but presumably Bluesky might, if at some point a large proportion of their storage and network costs are going toward data that has nothing to do with their microblogging business. That creates some risk to a content author of various atproto lexicons unless they self-host or there exists some PDS service they can pay for that is committed to being lexicon agnostic (does that exist yet?).

Related question: is there a way for a DID to be associated with multiple PDS? E.g. a client tries to post a Leaflet to a Bluesky PDS and it rejects the request, is there a way for a DID owner to specify that there are other PDSs to try, maybe specified by lexicon? Is that theoretically why the services part of the DID PLC resolution response seems to support multiple entries? That might solve the problem I'm posing.

[yamarten]

Bluesky's mission is to popularize their protocol, not their service, so it doesn't look like they want to impose stricter restrictions than general rate limits and size limits. They even accept ATFile, which uses PDS as file storage.
Some developers of atproto services that also provide PDS (e.g. Tangled, Spark, Blacksky) may have a reason to do it, but I've never heard of that. The simplest solution is to stop hosting and take you to other PDS (as many services do).

There is no function for one ID to point to multiple repositories, and it will not be planned. The reason why did:plc supports multiple services is because it may also refer to services other than PDS from the same DID. Labelers, appviews, and non-atproto services, etc.