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.
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.