swicg / activitypub-data-portability

Repository for data portability report and solutions for ActivityPub
https://swicg.github.io/activitypub-data-portability/
Other
15 stars 4 forks source link

How to handle privacy, if both servers support a given FEP... but also if they don't #23

Open bumblefudge opened 3 months ago

bumblefudge commented 3 months ago

Parking these thoughts here so that #22 can make vague references to it that get fleshed out in later PRs.

I think it's reasonable to try meeting end-user expectations around privacy, but it's slightly tricky because the concept of private objects versus public objects wasn't really specified in the original protocol, and very public-oriented implementations have kind of taken center stage, leaving privacy a kind of "unimplemented extension" in many ways. There are kind of two suggestions here:

1.) No one privacy extension should be hard-coded or tightly coupled into the LOLA spec.

2.) At the same time, there's nothing wrong with picking one illustrative example and thoroughly explore it as a representative one. There's one loose standard (invented by Mastodon and implemented by Pixelfed and other major servers... but I'm not sure there was a FEP written? ) called "authorized fetch", which specifies how cross-server authN can be done to check a hosting server's authZ policies for a given content, which is maybe the closest we have to a harmonized private-object extension. My recommendation would be to think through what happens if source server supports this extension/vocab/property but destination server doesn't, and vice versa.