It’s legal to scrape websites and this is doing it in a way that activity pub is designed to support. You can’t be mad another instance is reading your data, that’s what the fediverse is.
I think people will end up finding bridgy annoying frankly, but it seems like a useful tool that takes federated content and lets websites build things that used to be only available by adding Facebook pixel and Twitter links to your site.
Going out on a limb, but the for profit corporation being able to suck up your posts is probably what has many upset. I personally would block such a service as I don’t see these for-profit corporations as part of the fediverse, but as leeches out to Extend, Embrace, Extinguish.
but open data is an objectively good thing. This means anyone can suck up the data and build something instead of just Meta and X and people who pay millions of dollars to access that. Let everyone suck!
Open yes, but Bluesky is not open, they are after free content to make the corporate investors a return at all costs. If a non-profit wants to use my server to add content to their platform, I have no issue with that. But a for-profit can pay me for content if they want it, I don’t work for them or use their platform.
Open data as in publicly accessible without a login gate. Bluesky though does have this stupid login wall option but it can be bypassed very easily so it’s still open.
I do agree with you about how Bluesky is still a for-profit American corporation and nothing free or selfless ever came from one so it shouldn’t be trusted implicitly.
The same argument could be used for copyright itself, and why we have non-commercial licenses for things. Just because you are giving something away as free (as in beer), doesn’t mean that some for-profit should be able to just use it to drive up their user base and make the corp more money. I think content creators, or at the very least in the fediverse - server owners, should be able to limit what corporations can suck up to further corporate profits at the expense of the fediverse.
If you want to run a server and donate your resources to make a for-profit corp money, that is your right, but to tell everyone that they should have no control of their content is unacceptable to me.
You can’t stop them from sucking up your data as long as your posts are public.
Even if it was made illegal, how would you even know they’re doing it? It’s not like these companies are afraid of breaking the law, they’ll just get a small fine if they get caught anyway.
Mainstream social media sites and apps collect an extreme amount of data for the companies running them. For this reason, you are already far better off using alternative like Lemmy or Mastodon. But don’t be delusional, you can’t expect privacy when you make public posts.
I don’t disagree that it would be a good thing if you could limit what these corps can suck up, it just doesn’t really seem possible.
I don’t think the argument is even about privacy, but giving away someone else’s (or in this case potentially a whole network of people’s content), and admins resources in order to drive some corporate profits they aren’t even getting a share of. If someone needs to chat with someone on Bluesky that bad then they should just make an account, not undermine a whole network so they can be lazy.
I can absolutely understand that sentiment, but that’s not quite how the bridge works.
I’ve chosen to put my content on mastodon, and my friend prefers bluesky. The bridge just shares content across so now we can interact.
I think that’s better than mastodon and bluesky each cutting off their bosses to spite their own faces. Fragmenting the between is why X didn’t die a much deserved death after Elon Musk bought it.
Tbh X is not the real enemy here imo. The bigger danger is losing the open protocol battle to something proprietary and both Meta and Bluesky are very shady with their intentions.
Eh, X and Musk are always the enemy. I get what you’re saying, but ultimately it’s important to keep in mind that the underlying impetus is still Musk being a far-right bigot that has bought X to explicitly make it a haven for fascists, bigots and haters.
I kind of agree, Meta’s take of pulling content but no contributing back is clearly bad for the platform, but I don’t see Bluesky as being shady, though I haven’t followed what they do.
I thought the whole point of federation was the open standard allows anyone to be on the same standing as the larger corporations, so from that perspective I think it only works if you also allow large companies to participate.
Bluesky is a for-profit company. There’s zero precedence of a for-profit developing an open protocol AFAIK. I’d love to be proven wrong but I’m not optimistic to say the least.
I’m sure there are, a lot of the internet developed that way.
TBH I don’t know much about Bluesky, except that it’s a Twitter one with it’s own federation protocol, and I don’t get what the value of any project adopting their protocol over activity pub is.
Yes, but consuming data and using someone else’s data for profit are 2 different things. Don’t believe me, start reposting a large news websites data verbatim with AdSense on it and see how quickly the cease and desist comes.
If we’re allowed to - and happily do - copy over content from for-profit websites with bots, it feels a bit weird to then get angry about that happening in reverse, no?
Plus, oh no, interoperability. We get to just interact with people instead of everyone sitting in their respective walled gardens.
If we’re allowed to - and happily do - copy over content from for-profit websites with bots, it feels a bit weird to then get angry about that happening in reverse, no?
Not at all. It’s a matter of asynchronous power play.
We can do the former as a fight against power, but we have to fight for it. When they do it to us, it’s “just business” and we have no defense.
for profit corporation being able to suck up your posts is probably what has many upset
They can already do that without a bridge. And it doesn’t “suck up your posts”. It works just like any other instance. They have to search for you and follow you. Then they receive posts going forward, but they won’t get historical posts.
I personally would block such a service
Good! You can do that and that is a perfectly reasonable solution. That’s part of what has ppl upset on the other side of this argument. All of this arguing and vitriol is happening over a service that you can block like any other fediverse actor.
What has people upset is that the “service” is opt-out instead of opt-in, and one someone else is making for server admins without warning. If this person wanted to run a server and give their own content to the corporate overlords that is their choice, but making something to give others content away without their consent doesn’t sit well with a lot of people.
The microblog side of the fediverse is really hostile to scraping or indexing of any kind. On the one hand, I get the idea of safe spaces and not wanting your data to be public, but then why are you on an instance that federates openly?
It seems to me that anything that’s being federated out by ActivityPub is public by nature. If you don’t want it to be public, you should use an allowlist, or just don’t post publicly.
I guess I just assume that everything I’m posting is being scraped and archived forever, because there’s no way to ensure it’s not. It’s ironic that the fediverse is so hostile to this fundamental fact of the internet when ActivityPub is basically designed to just hand out information to whoever asks. It seems like there’s a conflict between the protocol and the culture.
I think it’s about usage rights. People are fine with their post being on their chosen end of the fediverse forever but don’t want corporations and news sites to generate a profit by using the posts. That is independent of federation, federation just makes it easier.
The other thing, that I see even more people upset about, is that the bridge requires you to Opt-Out, rather than Opt-In for being included.
It’s totally fine if you want to be included, especially if you have friends on BlueSky. But, it’s just a shitty practice that is all too prevalent in new tech. AI companies are doing the same thing - if you’re an artist, you’re supposed to magically know all of these new, obscure AI startups and somehow find how to opt-out of being included in their training data set. It’s ridiculous.
Same concept here, I would have had no idea this was a thing, if not for people speaking up about it. Some people make a conscious choice to join Fediverse communities because they want nothing to do with big tech and want more control of their data and privacy and who has access to it. Why is such a big deal to respect that?
The bridge is nothing more than another Activitypub instance. You can block it in the same ways that you can block existing Mastodon or Lemmy instances. If users want to opt in to federate with it, they should also have to opt in manually to federate with every single Lemmy instance.
Saying that the bridge is nothing more than another ActivityPub instance is very disingenuous.
While it may be built upon the ActivityPub protocol, but its main purpose is to act as a bridge to non-federated platforms, which is unique to that instance. When signing up for a fediverse instance, it should be known to the user that their data will be shared within the fediverse network. But, no permission is given to share on any platforms outside the fediverse network, using non-ActivityPub protocols.
So, no, opt-in should not be necessary for all instances, but in the case of the bridge, it is, because it’s enabling a feature that users haven’t explicitly agreed too and isn’t a core part of the ActivityPub protocol. And since the bridge is being made open-source, should users also be expected to track down any other instances that pick up and use it and manually block and opt-out of those?
This asks zero sense as there’s n disclosure on hardly any instance. Also, there’s several non ActivityPub protocols and bridges that have long since been used and peoples content shared
Artists very much retain legal rights to the art they create. Hence the current lawsuits against various AI companies. Meanwhile it depends on jurisdiction whether a comment/thought you write on a public-facing website can be considered your legal production for a civil lawsuit. It’d be trivial if it were a closed site with a very selective admission process with some easily evaluated barrier (say, only people who study at university XYZ are allowing on the otherwise private forum of that university), but public-facing it’s more ambiguous.
You can still try to sue someone who taking that content, but it’s not as clearcut that someone violates your rights as with artists and their art. Meaning that there’s less basis for someone wanting this to always have to be explicitly opt-in and get explicit permission. At least right now. This might very well all change as a result of AI lawsuits.
Tbh, I wasn’t talking about the legalities of AI or copyright law. I was using that as an example of why opt-out is a shitty business practice that makes people frustrated and upset. Because people commenting on this post and defending the bridge don’t seem to understand that.
Ok, then please tell me, in terms of giving one’s consent, exactly how the two are different?
Because I fail to see how opting out in either case is any way a different process than the other.
The developers are putting the onus on the end user that is affected, and relying on them having knowledge that their product exists. Then it is the users’s responsibility to figure out the process to remove themselves from the user group and trusting the developer/admins to actually take any action to do so.
This is the only argument I am trying to make - opt out is bad. Please stop using it when developing technologies that affect user’s data and/or privacy.
in terms of giving one’s consent, exactly how the two are different?
Because in the second case, the user is choosing to post on a network where any other server can request their posts. A bridge is just an instance that understands more than one protocol. There’s no difference in it and any other server requesting your posts. That’s how the network works.
Thank you for confirming my point, because you are still just referring differences in the technology itself. I asked how opting out is different in either case, and the fact is they are not.
The fact that the Bridgy developer is making it a possibility is what matters, and that they consciously chose to make it opt-out. It’s apparent that they already spent time and effort into implementing a system that allows you to add a hashtag to your profile to signal that you want to opt out. Why not just make it the other way around, and make it for opting in? Surely all the people who would want to be able to bridge wouldn’t mind that? It doesn’t matter if you think this is something innocuous or insignificant, because to others, it isn’t. And if you think that’s because of a misunderstanding in the user with the technology, then the developer needs to do better in explaining that and gaining users trust. You don’t build trust in users by using practices like opt-out, which is again, the only argument I am trying to make.
I said the two things are different, you said how does that make asking for consent for the two things different, and my response was that for one of them it already works that way without your consent. That is a clear difference. Yes, I’m talking about the technology to explain the difference, because it’s a concrete fact. Your argument that a bridge should be opt-in requires an abstract boundary that some instances are are allowed to federate on an opt-out basis and others are not.
You don’t build trust in users by using practices like opt-out, which is again, the only argument I am trying to make.
The instance you’re on uses opt-out practices. You didn’t consent to your post federating to kbin.social and yet here we are. If you don’t trust the bridge, fine, block it. Every tool on the fediverse that you already use to deal with its inherently opt-out nature is available for you to use with this bridge.
Ok, let me explain my POV from a different perspective:
By signing up for an account, whether it be on a Lemmy or Mastodon or any other ActivityPub implementation, I have consented to functionality in which my posts are distributed to other instances within the Fediverse. It’s widely advertised and clearly explained that is how things function. I can readily find which implementations are part of the fediverse. And yes, within that system, I can use blocking/unblocking of users, communities, and instances, as a form of moderation that I can manage. But as a common user, I don’t have the option of easily block all instances that use a common ActivityPub implementation, which is why bridges require special consideration. I can’t, in a user friendly way, specify that I don’t want to ever be connected in any way to a bridge instance or any of its incarnations and limit my consent to ActivityPub implementations of my choosing, because that’s something not possible to do do with any other type of instance either. Bridge instances are not comparable to other implementations like Lemmy or KBin, et al, solely because their function is to translate data to other protocols and move that data to other decentralized networks outside and separate from the fediverse, which operate under different rules and policies. As such, they should not be treated like other instances when federating. Or maybe, they shouldn’t even be an instance at all. Making it an instance that can federate may be the easiest way to implement the bridge functionality across multiple ActivityPub implementations, but in doing so, makes it overly obscure to end users.
Without historical knowledge, or going all the way to the ActivityPub docs is there any mention of bridges or even what they do or what they bridge to/from, unless you read through their documentation as well. So, to the common user, we have no knowledge that being able to directly communicate with platforms like BlueSky or Nostr is possible, or is being actively developed, and foreknowledge of this would likely inform some user’s choice in joining the fediverse. Unless this functionality is made common knowledge to the user when they sign up for an instance, or when an instance decides to federate with a bridge, then it should be opt-in, because it’s enabling functionality that users currently are unaware of and may not want. Common users are not notified when their instance federates with other instances, so unless they actively check, they have no idea of changes to the federation of their instance. Right now, there is a very concrete boundary, in that without a bridge, it’s not possible to directly interact with non-federated, separate platforms like BlueSky or Nostr.
This is why people are having an adverse reaction to this whole ordeal, specifically people whom are actively avoiding said platforms. And as I said in my previous post, because the Bridgy developer consciously chose to enact an opt-out policy, specific to their project and outside the norms of other instances, it has been perceived that this is something different that they are trying to force on to people without their consent and behind their backs.
Just because opt-out is the norm for other use cases, doesn’t mean it should be used for all new functionality that is introduced to the fediverse. Besides, there are numerous features across ActivityPub implementations that are opt-in. And telling users that are concerned, just block it if you don’t want it, is frankly a lazy solution, that pushes blame and does nothing to alleviate user concerns or gain trust. Such attitudes drive people away from the fediverse, rather than attract.
I have done my due diligence and read a whole lot of documentation over the past couple of days to better understand ActivityPub and protocol bridges. So my comments are not meant to be taken as I am trying to come off as an expert, because I am far from it. I am just trying to get people to see the other side of the story and at least consider where people are coming from and why exactly they are arguing for opt-in, even if the other side feels like it’s an unfounded overreaction.
Thank you for the detailed explanation. It matches what I’ve heard from others while having this same debate. Now allow me to explain my side.
I have consented to functionality in which my posts are distributed to other instances within the Fediverse. It’s widely advertised and clearly explained that is how things function. I can readily find which implementations are part of the fediverse
This is the part I think is wrong and the cause of all of this. You can not find which implementations are part of the fediverse. No tracker that you can use has an up-to-date and accurate listing of implementations. New ones come online every day as some random developer builds something new. The fediverse doesn’t have clear boundaries and I think the advertising that you mentioned does a disservice by implying it does. The fediverse is similar to the web; they’re both based on open protocols and can be guided but not controlled, because anybody can build something on those protocols.
One response to this fuzziness has been to demand most features be opt-in. The reason I don’t think this is tenable is because you have to have a hard boundary to determine what should be opt-in and what is ok to be opt-out. Your heuristic was native ActivityPub implementation. I don’t think this scales (I feel like you’re going to say this is a technological argument and therefore invalid, but it’s also a social argument. Ppl don’t want to use something that they have to constantly maintain. Constantly adding new servers/users to an allowlist is a chore that would drive ppl away. See google+ circles). It doesn’t scale because like I said above new implementations pop up every day and these implementations are starting to branch away from the static archetypes we’re used to (Twitter-like, Facebook-like, Reddit-like, etc). And some of them are existing projects that add AP support.
For instance, Hubzilla/Friendica has been bridging AP content for years. Do all of those instances require opt-in because they use a different protocol in addition to AP? There have also been bridges that translate RSS feeds to AP actor for years. Did the owners of those RSS feeds opt-in and should they have been required to?
What I’m trying to say is I think you’re right that you can never keep up with the boundaries of the fediverse and where your posts end up. And I don’t think there’s an easy delineation for what should be opt-out vs opt-in. So instead we should be demanding that implementations add controls to our posts. Thinks like ACLs and OCAPs would allow you to control who can see your posts and interact with them and not care about new bridges/instances/whatever. Which is why I think the argument over opt-out vs opt-in is a distraction that will only keep the fediverse in this quasi-privacy space where you’re dependent on yelling down any actor who is doing something with yours posts you don’t like.
I don’t understand the frustration.
It’s legal to scrape websites and this is doing it in a way that activity pub is designed to support. You can’t be mad another instance is reading your data, that’s what the fediverse is.
I think people will end up finding bridgy annoying frankly, but it seems like a useful tool that takes federated content and lets websites build things that used to be only available by adding Facebook pixel and Twitter links to your site.
Going out on a limb, but the for profit corporation being able to suck up your posts is probably what has many upset. I personally would block such a service as I don’t see these for-profit corporations as part of the fediverse, but as leeches out to Extend, Embrace, Extinguish.
but open data is an objectively good thing. This means anyone can suck up the data and build something instead of just Meta and X and people who pay millions of dollars to access that. Let everyone suck!
Open yes, but Bluesky is not open, they are after free content to make the corporate investors a return at all costs. If a non-profit wants to use my server to add content to their platform, I have no issue with that. But a for-profit can pay me for content if they want it, I don’t work for them or use their platform.
Open data as in publicly accessible without a login gate. Bluesky though does have this stupid login wall option but it can be bypassed very easily so it’s still open.
I do agree with you about how Bluesky is still a for-profit American corporation and nothing free or selfless ever came from one so it shouldn’t be trusted implicitly.
This argument makes no sense. Everything you post is already public.
The same argument could be used for copyright itself, and why we have non-commercial licenses for things. Just because you are giving something away as free (as in beer), doesn’t mean that some for-profit should be able to just use it to drive up their user base and make the corp more money. I think content creators, or at the very least in the fediverse - server owners, should be able to limit what corporations can suck up to further corporate profits at the expense of the fediverse.
If you want to run a server and donate your resources to make a for-profit corp money, that is your right, but to tell everyone that they should have no control of their content is unacceptable to me.
You can’t stop them from sucking up your data as long as your posts are public.
Even if it was made illegal, how would you even know they’re doing it? It’s not like these companies are afraid of breaking the law, they’ll just get a small fine if they get caught anyway.
Mainstream social media sites and apps collect an extreme amount of data for the companies running them. For this reason, you are already far better off using alternative like Lemmy or Mastodon. But don’t be delusional, you can’t expect privacy when you make public posts.
I don’t disagree that it would be a good thing if you could limit what these corps can suck up, it just doesn’t really seem possible.
I don’t think the argument is even about privacy, but giving away someone else’s (or in this case potentially a whole network of people’s content), and admins resources in order to drive some corporate profits they aren’t even getting a share of. If someone needs to chat with someone on Bluesky that bad then they should just make an account, not undermine a whole network so they can be lazy.
Following that logic, if someone on Lemmy needs to chat with someone on Mastodon that bad they should just make an account.
Calling someone lazy for building and running a service which bridges between different protocols is both dumb and rude.
Mastodon is part of the fediverse though, and is open and a nonprofit. Bluesky is neither of those things, and that is why it’s different.
And giving the resources from a free and open network to a for-profit corporation is both dumb and rude IMHO.
Do some research before you make incorrect claims.
AT (the protocol used by Bluesky) is an open protocol with an open reference implementation.
AT supports federation (and with this bridge could be made part of the fediverse).
Bluesky itself is also open, and while the company is for-profit that doesn’t change anything for people running their own Bluesky servers.
I’ll say it again - you’re not giving them anything they aren’t already able to (legally) acquire.
I can absolutely understand that sentiment, but that’s not quite how the bridge works.
I’ve chosen to put my content on mastodon, and my friend prefers bluesky. The bridge just shares content across so now we can interact.
I think that’s better than mastodon and bluesky each cutting off their bosses to spite their own faces. Fragmenting the between is why X didn’t die a much deserved death after Elon Musk bought it.
Tbh X is not the real enemy here imo. The bigger danger is losing the open protocol battle to something proprietary and both Meta and Bluesky are very shady with their intentions.
Eh, X and Musk are always the enemy. I get what you’re saying, but ultimately it’s important to keep in mind that the underlying impetus is still Musk being a far-right bigot that has bought X to explicitly make it a haven for fascists, bigots and haters.
I kind of agree, Meta’s take of pulling content but no contributing back is clearly bad for the platform, but I don’t see Bluesky as being shady, though I haven’t followed what they do.
I thought the whole point of federation was the open standard allows anyone to be on the same standing as the larger corporations, so from that perspective I think it only works if you also allow large companies to participate.
Bluesky is a for-profit company. There’s zero precedence of a for-profit developing an open protocol AFAIK. I’d love to be proven wrong but I’m not optimistic to say the least.
I’m sure there are, a lot of the internet developed that way.
TBH I don’t know much about Bluesky, except that it’s a Twitter one with it’s own federation protocol, and I don’t get what the value of any project adopting their protocol over activity pub is.
anyone can spin up a server and federate, anyone can suck up your data, corporations, governments or unknowns
Yes, but consuming data and using someone else’s data for profit are 2 different things. Don’t believe me, start reposting a large news websites data verbatim with AdSense on it and see how quickly the cease and desist comes.
If we’re allowed to - and happily do - copy over content from for-profit websites with bots, it feels a bit weird to then get angry about that happening in reverse, no?
Plus, oh no, interoperability. We get to just interact with people instead of everyone sitting in their respective walled gardens.
Not at all. It’s a matter of asynchronous power play.
We can do the former as a fight against power, but we have to fight for it. When they do it to us, it’s “just business” and we have no defense.
Plenty of for-profit companies use open protocols and don’t harm them in the slightest.
Almost any website you visit, for example.
They can already do that without a bridge. And it doesn’t “suck up your posts”. It works just like any other instance. They have to search for you and follow you. Then they receive posts going forward, but they won’t get historical posts.
Good! You can do that and that is a perfectly reasonable solution. That’s part of what has ppl upset on the other side of this argument. All of this arguing and vitriol is happening over a service that you can block like any other fediverse actor.
What has people upset is that the “service” is opt-out instead of opt-in, and one someone else is making for server admins without warning. If this person wanted to run a server and give their own content to the corporate overlords that is their choice, but making something to give others content away without their consent doesn’t sit well with a lot of people.
deleted by creator
The microblog side of the fediverse is really hostile to scraping or indexing of any kind. On the one hand, I get the idea of safe spaces and not wanting your data to be public, but then why are you on an instance that federates openly?
It seems to me that anything that’s being federated out by ActivityPub is public by nature. If you don’t want it to be public, you should use an allowlist, or just don’t post publicly.
I guess I just assume that everything I’m posting is being scraped and archived forever, because there’s no way to ensure it’s not. It’s ironic that the fediverse is so hostile to this fundamental fact of the internet when ActivityPub is basically designed to just hand out information to whoever asks. It seems like there’s a conflict between the protocol and the culture.
I think it’s about usage rights. People are fine with their post being on their chosen end of the fediverse forever but don’t want corporations and news sites to generate a profit by using the posts. That is independent of federation, federation just makes it easier.
The other thing, that I see even more people upset about, is that the bridge requires you to Opt-Out, rather than Opt-In for being included.
It’s totally fine if you want to be included, especially if you have friends on BlueSky. But, it’s just a shitty practice that is all too prevalent in new tech. AI companies are doing the same thing - if you’re an artist, you’re supposed to magically know all of these new, obscure AI startups and somehow find how to opt-out of being included in their training data set. It’s ridiculous.
Same concept here, I would have had no idea this was a thing, if not for people speaking up about it. Some people make a conscious choice to join Fediverse communities because they want nothing to do with big tech and want more control of their data and privacy and who has access to it. Why is such a big deal to respect that?
The bridge is nothing more than another Activitypub instance. You can block it in the same ways that you can block existing Mastodon or Lemmy instances. If users want to opt in to federate with it, they should also have to opt in manually to federate with every single Lemmy instance.
deleted by creator
Saying that the bridge is nothing more than another ActivityPub instance is very disingenuous.
While it may be built upon the ActivityPub protocol, but its main purpose is to act as a bridge to non-federated platforms, which is unique to that instance. When signing up for a fediverse instance, it should be known to the user that their data will be shared within the fediverse network. But, no permission is given to share on any platforms outside the fediverse network, using non-ActivityPub protocols.
So, no, opt-in should not be necessary for all instances, but in the case of the bridge, it is, because it’s enabling a feature that users haven’t explicitly agreed too and isn’t a core part of the ActivityPub protocol. And since the bridge is being made open-source, should users also be expected to track down any other instances that pick up and use it and manually block and opt-out of those?
This asks zero sense as there’s n disclosure on hardly any instance. Also, there’s several non ActivityPub protocols and bridges that have long since been used and peoples content shared
The situation is not truly comparable, tbh.
Artists very much retain legal rights to the art they create. Hence the current lawsuits against various AI companies. Meanwhile it depends on jurisdiction whether a comment/thought you write on a public-facing website can be considered your legal production for a civil lawsuit. It’d be trivial if it were a closed site with a very selective admission process with some easily evaluated barrier (say, only people who study at university XYZ are allowing on the otherwise private forum of that university), but public-facing it’s more ambiguous.
You can still try to sue someone who taking that content, but it’s not as clearcut that someone violates your rights as with artists and their art. Meaning that there’s less basis for someone wanting this to always have to be explicitly opt-in and get explicit permission. At least right now. This might very well all change as a result of AI lawsuits.
Tbh, I wasn’t talking about the legalities of AI or copyright law. I was using that as an example of why opt-out is a shitty business practice that makes people frustrated and upset. Because people commenting on this post and defending the bridge don’t seem to understand that.
I think there’s a huge difference in scraping your content to churn out a for-profit “AI” and federating your public posts on a federated network.
Ok, then please tell me, in terms of giving one’s consent, exactly how the two are different?
Because I fail to see how opting out in either case is any way a different process than the other.
The developers are putting the onus on the end user that is affected, and relying on them having knowledge that their product exists. Then it is the users’s responsibility to figure out the process to remove themselves from the user group and trusting the developer/admins to actually take any action to do so.
This is the only argument I am trying to make - opt out is bad. Please stop using it when developing technologies that affect user’s data and/or privacy.
Because in the second case, the user is choosing to post on a network where any other server can request their posts. A bridge is just an instance that understands more than one protocol. There’s no difference in it and any other server requesting your posts. That’s how the network works.
Thank you for confirming my point, because you are still just referring differences in the technology itself. I asked how opting out is different in either case, and the fact is they are not.
The fact that the Bridgy developer is making it a possibility is what matters, and that they consciously chose to make it opt-out. It’s apparent that they already spent time and effort into implementing a system that allows you to add a hashtag to your profile to signal that you want to opt out. Why not just make it the other way around, and make it for opting in? Surely all the people who would want to be able to bridge wouldn’t mind that? It doesn’t matter if you think this is something innocuous or insignificant, because to others, it isn’t. And if you think that’s because of a misunderstanding in the user with the technology, then the developer needs to do better in explaining that and gaining users trust. You don’t build trust in users by using practices like opt-out, which is again, the only argument I am trying to make.
I said the two things are different, you said how does that make asking for consent for the two things different, and my response was that for one of them it already works that way without your consent. That is a clear difference. Yes, I’m talking about the technology to explain the difference, because it’s a concrete fact. Your argument that a bridge should be opt-in requires an abstract boundary that some instances are are allowed to federate on an opt-out basis and others are not.
The instance you’re on uses opt-out practices. You didn’t consent to your post federating to kbin.social and yet here we are. If you don’t trust the bridge, fine, block it. Every tool on the fediverse that you already use to deal with its inherently opt-out nature is available for you to use with this bridge.
Ok, let me explain my POV from a different perspective:
By signing up for an account, whether it be on a Lemmy or Mastodon or any other ActivityPub implementation, I have consented to functionality in which my posts are distributed to other instances within the Fediverse. It’s widely advertised and clearly explained that is how things function. I can readily find which implementations are part of the fediverse. And yes, within that system, I can use blocking/unblocking of users, communities, and instances, as a form of moderation that I can manage. But as a common user, I don’t have the option of easily block all instances that use a common ActivityPub implementation, which is why bridges require special consideration. I can’t, in a user friendly way, specify that I don’t want to ever be connected in any way to a bridge instance or any of its incarnations and limit my consent to ActivityPub implementations of my choosing, because that’s something not possible to do do with any other type of instance either. Bridge instances are not comparable to other implementations like Lemmy or KBin, et al, solely because their function is to translate data to other protocols and move that data to other decentralized networks outside and separate from the fediverse, which operate under different rules and policies. As such, they should not be treated like other instances when federating. Or maybe, they shouldn’t even be an instance at all. Making it an instance that can federate may be the easiest way to implement the bridge functionality across multiple ActivityPub implementations, but in doing so, makes it overly obscure to end users.
Without historical knowledge, or going all the way to the ActivityPub docs is there any mention of bridges or even what they do or what they bridge to/from, unless you read through their documentation as well. So, to the common user, we have no knowledge that being able to directly communicate with platforms like BlueSky or Nostr is possible, or is being actively developed, and foreknowledge of this would likely inform some user’s choice in joining the fediverse. Unless this functionality is made common knowledge to the user when they sign up for an instance, or when an instance decides to federate with a bridge, then it should be opt-in, because it’s enabling functionality that users currently are unaware of and may not want. Common users are not notified when their instance federates with other instances, so unless they actively check, they have no idea of changes to the federation of their instance. Right now, there is a very concrete boundary, in that without a bridge, it’s not possible to directly interact with non-federated, separate platforms like BlueSky or Nostr.
This is why people are having an adverse reaction to this whole ordeal, specifically people whom are actively avoiding said platforms. And as I said in my previous post, because the Bridgy developer consciously chose to enact an opt-out policy, specific to their project and outside the norms of other instances, it has been perceived that this is something different that they are trying to force on to people without their consent and behind their backs.
Just because opt-out is the norm for other use cases, doesn’t mean it should be used for all new functionality that is introduced to the fediverse. Besides, there are numerous features across ActivityPub implementations that are opt-in. And telling users that are concerned, just block it if you don’t want it, is frankly a lazy solution, that pushes blame and does nothing to alleviate user concerns or gain trust. Such attitudes drive people away from the fediverse, rather than attract.
I have done my due diligence and read a whole lot of documentation over the past couple of days to better understand ActivityPub and protocol bridges. So my comments are not meant to be taken as I am trying to come off as an expert, because I am far from it. I am just trying to get people to see the other side of the story and at least consider where people are coming from and why exactly they are arguing for opt-in, even if the other side feels like it’s an unfounded overreaction.
Thank you for the detailed explanation. It matches what I’ve heard from others while having this same debate. Now allow me to explain my side.
This is the part I think is wrong and the cause of all of this. You can not find which implementations are part of the fediverse. No tracker that you can use has an up-to-date and accurate listing of implementations. New ones come online every day as some random developer builds something new. The fediverse doesn’t have clear boundaries and I think the advertising that you mentioned does a disservice by implying it does. The fediverse is similar to the web; they’re both based on open protocols and can be guided but not controlled, because anybody can build something on those protocols.
One response to this fuzziness has been to demand most features be opt-in. The reason I don’t think this is tenable is because you have to have a hard boundary to determine what should be opt-in and what is ok to be opt-out. Your heuristic was native ActivityPub implementation. I don’t think this scales (I feel like you’re going to say this is a technological argument and therefore invalid, but it’s also a social argument. Ppl don’t want to use something that they have to constantly maintain. Constantly adding new servers/users to an allowlist is a chore that would drive ppl away. See google+ circles). It doesn’t scale because like I said above new implementations pop up every day and these implementations are starting to branch away from the static archetypes we’re used to (Twitter-like, Facebook-like, Reddit-like, etc). And some of them are existing projects that add AP support.
For instance, Hubzilla/Friendica has been bridging AP content for years. Do all of those instances require opt-in because they use a different protocol in addition to AP? There have also been bridges that translate RSS feeds to AP actor for years. Did the owners of those RSS feeds opt-in and should they have been required to?
What I’m trying to say is I think you’re right that you can never keep up with the boundaries of the fediverse and where your posts end up. And I don’t think there’s an easy delineation for what should be opt-out vs opt-in. So instead we should be demanding that implementations add controls to our posts. Thinks like ACLs and OCAPs would allow you to control who can see your posts and interact with them and not care about new bridges/instances/whatever. Which is why I think the argument over opt-out vs opt-in is a distraction that will only keep the fediverse in this quasi-privacy space where you’re dependent on yelling down any actor who is doing something with yours posts you don’t like.