Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bumblefudge opened this issue Jun 19, 2024 · 0 comments

Comments

@bumblefudge
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant