OK this will probably be an unpopular opinion, but regarding the #bluesky#bridge and whether it's ok to be opt-out... For me the discussion doesn't make much sense because this is how fedi works. When you enable federation, your posts are federated to any activitypub-supporting server, unless you opt-out by fediblocking. Do you approve all of these servers? Do you agree with their ToS? Have you read the ToS of all of them, or know where they belong to? No. I know this might make you insecure about your data, but it's better to be honest than create a false impression of control, which then feels attacked when Threads or Bluesky appear. I understand that somebody may not want their content appearing in Zuckerberg's or Dorsey's platform. But they could already be running an AP server that's federated to your server, and you will never know. This is what we signed up for, adopting an open protocol and using software that federates with everyone as the default. And tbh I like it this way - an opt-in federation would be a disaster for smaller servers, it would practically be impossible to federate. By using an AP-enabled server, I'm telling everyone that it's ok to interact with my content - unless I actively block them. It doesn't include an agreement for how or from whom this content will be used. The fact that both servers run AP-compatible software is only a technicality. So if Bluesky implemented AP support it would suddenly be ok that interacting with their users would be opt-out, like with every AP server?
Don't get me wrong, I understand that everyone wants to be in control of their social circle, and I support you if you want to block Threads or Bluesky bridges. But I don't really see how it's unethical to have a bridge that is opt-out, just like any other AP-server. Our only "agreement" is using an open protocol, not any common ToS. ActivityPub is not ethically superior by definition, anyone can adopt it, and we have the right to block them, and this is all by design, it's not a different corner of the internet, everyone in the internet can use the protocol and see/display your public content. The drama every time some server does basically what we allowed them to do and we don't like it, is getting really old quickly. It doesn't "protect" fedi, it only makes it hostile and boring. If you're concerned about who sees your content, please run a followers-only account and control your followers. Running a public account in an openly federated platform and then getting angry when you don't agree with every single server you're federating with is a recipe to make sure you'll be angry for years to come.
@panos@hsivonen This is not much different from free/libre open source software in a sense: you may not like that some people use the software you create, but if it's FLOSS then that's what you signed for, and adding terms to the license to prevent such use would make it no longer FLOSS.
That's how GAB can use Mastodon, 4chan can be built with PHP and YUI, etc. whether you like them or not.
Bryan writes a Bluesky <--> Fediverse bridge application
Bryan has total administrative control over said bridge application
Bryan effectively has a man-in-the-middle viewport into all bi-directional traffic through his bridge - don't try to claim this isn't true
What does Bryan do with the participant IDs and traffic content he can view?
Is there any notice or consent involved other than opt-in re: Bryan's monitoring and potentially using said bridge traffic?
Is there any option to opt-out for --> third parties <-- who are participating in a public conversation they believe is on one end only and do not want to be bridged over to the opposite side of Bryan's bridge?
Finally this has boiled over on the Bluesky #Github (where it's the most recent post in a very long thread):
"Interoperability with Mastodon/ActivityPub #1716"
@FinchHaven perhaps the solution would be for software supporting activitypub to also support atproto and vice versa, like friendica did, so that we don't need to go through one person's bridge. Nobody is obliged to do what friendica did, but if it's a valid concern, it's a possible solution.
I would really like to see a "sidecar" service, tbh. Something that you could run that would interface with your local server and then connect it over ATProto to bluesky (or whatever).
Then servers could basically choose to run the sidecar or not.
It doesn't solve all of the bridging problems, and there are some significant design considerations in making it work, but from a high level it's an elegant solution.
Add comment