Opt in/out prompt #880
Comments
|
The discoverable opt-in idea wouldn't prompt you for every follow, it would only prompt you once, total, for the bridge as a whole. |
|
That is good. Being bombarded with prompts would drive me crazy. |
|
How will this work for people who don't accept DM's from strangers. By default, only my connections can send me DMs. |
|
Good question! I don't know yet. I have relatively little experience with fediverse DMs, I haven't used them much myself, and I wasn't expecting to develop with them. I'm open to ideas! |
|
I don't know how to address the DM issue, but I do know of some instances where you can potentially bypass sending the DMs. If a user's account is set so that followers have to be approved, then sending a DM is redundant since their own software asks if they want to allow them to follow. |
|
The fact that some users have chosen to further protect themselves by manually approving all follow requests should not be used as an invitation to skip any layers of protection. On the contrary on those cases you should be even more carefull and consider not sending them non-consentual harassment pms about chasers, techbros and nazis that are trying to invade their safe spaces through your bridge. |
I can't think of one statement of yours that concerns me more than that, except perhaps this: Yesterday you admitted not knowing that Mastodon users can't pre-block a domain name that doesn't exist yet on the Fediverse "if Mastodon only lets you do it after you've found an existing user on that domain, then you're right, you can't block it as a user yet. If so, that's definitely an unfortunate surprise." "definitely an unfortunate surprise" What about this entire process is supposed to inspire confidence in those of us your bridge will affect? |
|
It sounds like Mastodon needs up update its feature set. The people who complain the most come from platforms that have insufficient privacy, access control, and moderation features. People who use platforms that have better features in these areas never seem to complain about stuff like this because they have control of how their posts are distributed at the user level. To protect Mastodon users better, we might need to suggest some changes to Mastodon. |
|
@snarfed I just don't see the point of spending a bunch of dev time on this opt-in system. Being part of a federated social network is already an opt-in. If you don't want to federate with a node there's already built-in support for that via defederation. What's stopping someone from forking the project and running a fork that disables the opt-in system that federates everyone? |
|
@craftycorvid I think that is part of the problem. Many people who joined Mastodon didn't really understand what they were joining. They thought they were joining a platform, but they really joined an open network. And anyone can join an open network, even people they don't like. People don't have to ask permission to create a new email server, and people don't have to ask permission to connect their website to the world wide web, and similarly, people don't have to ask permission to join the fediverse. Requesting that this be opt-in is equivalent to requiring everyone to opt into seeing a new website. It doesn't make sense and is not scalable. Maybe we need discoverable opt-out instead of discoverable opt-in. Because opt-in for an open network is an oxymoron. And although I generally like to do things in a way that pleases everyone, I am not sure we should be appeasing people who drop F-bombs, insults, and threats. It just encourages them to pick up their pitchforks and attack others because their tactics work. They already have the ability to block and they already have the ability to defederate. And they do so liberally. Bluesky connecting to the fediverse is the equivalent of Threads connecting to the fediverse. It makes no sense that Bluesky is opt in and Threads is not. So I don't think we should implement opt-in. Instead implement discoverable opt-out. |
|
Instead of asking all users to opt-in, we simply contact all of the admins of known Mastodon servers one time (before the bridge goes live) and tell the admins that the bridge is going online soon and tell them how to block it for their users. They can, optionally, message everyone on their server to inform them of the upcoming expansion of the network. I think the Mastodon API has a way to contact admins of Mastodon servers. And there are several websites that have a list of Mastodon servers. Or maybe we can get the admins of prominent channels to give a PSA (public service announcement) on how to block the bridge with accurate information about how it works, instead of a bunch of inaccurate fear-based posts from people who don't understand what they joined. The bridge will become the talk of the town and the minority of people who care can block the bridge. After it goes live, we don't need to do anything other than honor block requests, because by that time Threads, WordPress, Tumblr, Flipboard, and others would have joined as well, and if people did not understand they joined an open network before, they will once that happens. The reason I mentioned contacting Mastodon server admins only is because most of the complaints are coming from Mastodon users or people who used to be Mastodon users. For those of us on platforms that pre-date Mastodon and pre-date ActivityPub, we already know that the fediverse is an open network. After all, Mastodon connected to us, not the other way around. Mastodon started as OStatus and created a bridge to ActivityPub and then switched to ActivityPub. So it is hypocritical of Mastodon users to complain about bridges when Mastodon joined the existing ActivityPub network via a bridge, and that Mastodon is already bridged to other protocols, like Zot, Nomad, Diaspora, and many others. |
|
consent is quite simple concept to understand and I'm sad that your education system failed to teach it. but I hope for the sake of the people that have to interract with you that your try to learn about it. we consented to joining an open network between different kinds of fedi instances. we didn't consent to a bridge stealing our notes to a corporate for-profit social media site. discoverable opt-out would require everyone using fediverse to recieve your messages and to figure out weather to block or to get their admin to block this bridge. that would push loads of unnecessary work to fedi users and that will certainly lead to mass defederation campaigns all over fediverse. those defederations can be easily avoided just by choosing opt-in model and then the people that actually want to use this bridge would be able to do it without having to first find and move to a non-defederated instance. your complete disregard for major issues raised here by minorities and your push for civility politics seem to suggest that your attitude towards software is very colonial hostile towards minorities. |
Good question! Nothing is stopping them, as far as I can tell. That's the beauty and (sometimes) tragedy of permissible open source licenses. Hopefully conversations like this one can get us all at least a bit closer to the same page, so that when anyone runs this kind of bridge, they set it up to do the most good, and maybe more importantly, prevent the most harm, to as many people as possible. |
|
Discoverable opt out vs opt in is also an interesting question. I think the idea in both cases is, the first time anyone tries to follow you over the bridge, you'd get a one-time prompt, for the bridge as a whole, and you'd choose whether to allow it or not. Would the only difference between discoverable opt out vs opt in be the default behavior, ie whether you're bridged or not, if you don't respond to the prompt? |
|
@TransCommunist69 This whole "opt-in" and "opt-out" argument is a distraction to what is really needed, which is better tools for users to protect themselves, such as better privacy, access lists, permissions, and moderation tools. Mastodon only has tools like block, but many other platforms have more and better tools to protect users. The term "open network" means that anyone including people you hate, can sign up. You have no protection whatsoever from these people joining. You did consent to that when you joined the fediverse, even if you did not realize it. It's like signing a contract. The small print you did not read is coming back to bite you. An analogy to consent is that Walmart is open to the public, you have no control over what customers are there. You did not consent to Mr. Jerk coming to Walmart, but Walmart is a public place, so Mr. Jerk can come into the store. Walmart can't kick them out until they misbehave. If they misbehave, then and only then can they be kicked out of the store. The real solution is building software that protects people better. And that is something that I and other people are actually working on. For example, fediverse-enabled communities would be a good fit for people who are vulnerable to being attacked. You can create communities (discussion groups, forums, etc.) that only have people you approve. Members only. You can make the group public or private, you can control who can post and who cannot; you can control who can comment on posts and who cannot, etc. But it is still connected to the fediverse, so people from all over the world can easily join your community (if you allow them to). This allows you to create a safe space with keeps trolls and bigots out while still being connected to the world. So we are not being insensitive. We are saying that you are looking at this from the wrong angle, and that there are better ways to protect people. Because, ultimately, people are going to connect. There are trans people on Bluesky, and there are black people in Bluesky. You cannot stop them from connecting, even if you don't like them and don't "consent" to trans people or black people joining. It is an open network. They are welcome to join. |
|
I appreciate the conversation, all, but let's please keep this issue focused on the discoverable opt in design and implementation specifically? Feel free to take the broader debate to the fediverse or anywhere else! |
|
@snarfed One issue that we have is that Mastodon and other platforms are built on the concept of opt-out, so they have no mechanism whatsoever to handle an opt-in scenario. (Well, they do have one mechanism for opt-in, and that is the setting that makes it so people can't follow you unless you approve the connection.) We may need to come up with some way to notify instances that the connection coming over your bridge is from a bridge (such as setting a flag in the follow request), and then we create some pull requests on Mastodon, Bluesky, and other platforms that contain code that detects your bridge flag. Ideally, we do it in an ActivityStreams, ActivityPub, and AT Protocol compliant way. That way, we give Mastodon and Bluesky the ability to actually detect your bridge, and admins and users can turn it on and off at will. And we write up the spec so that any project on the ActivityPub or AT Protocol can implement detection of a bridge if they want. And we don't have to worry about opt-in going the other direction. The very act of following someone on another platform is consent that you want to follow someone on another platform. So we only need to worry about incoming follow requests. |
True! More and more of them are adding support for opt-in, allowlist-based federation though. Which I think is great! Jon Pincus describes this well in https://privacy.thenexus.today/free-fediverses-and-consent/ . My current, straw man design for discoverable opt in is actually out of band entirely. When someone on Bluesky wants to follow someone on the fediverse who hasn't yet opted in, they'd enter the fediverse handle into a form on https://fed.brid.gy/, it would DM that person the prompt, and if they accept, it would then propagate their profile into Bluesky and allow following. This is obviously awkward and clunky, but it's how I'd need to do it even without any kind of opt in. Bluesky doesn't do on-demand remote profile lookup. Search in Bluesky only shows users (and posts, etc) that it already has in its own internal index. I never planned to proactively crawl and push all existing fediverse users into Bluesky, so I needed a way for people to request it to bridge specific individual fediverse profiles, on demand. Discoverable opt in just adds the DM prompt to that flow. |
My platform blocks DMs unless I allow you to follow me. How will you send a DM in that case? You can't. So there needs to be some alternative to DMs. |
|
@WisTex hmm. Which platform is that? Raconteur/Streams? |
|
"@WisTex hmm. Which platform is that? Raconteur/Streams?" The real point here is that the fact that profiles do not universally accept DMs -- and are very often turned off deliberately -- was pointed out to you at least a week ago and you admitted that you didn't have much experience with Fediverse DMs in the first place "Good question! I don't know yet. I have relatively little experience with fediverse DMs, I haven't used them much myself, and I wasn't expecting to develop with them. I'm open to ideas!" Here: #880 (comment) |
|
I'm using Hubzilla for most of my accounts. |
|
On most platforms, this is configurable by the user. Some platforms have "accept DMs from strangers" on by default, and some have "accept DMs from strangers" off by default. This is why I am thinking we will actually have to modify some of the platforms to detect bridges and give their users the option. Either by whitelisting your DMs so they always go through, or by giving users and admins a switch where they can opt-in or opt-out of your bridge. Because DMs (by itself) won't work for an opt-in system. |
|
@WisTex agreed! You're (both) right, DMs aren't necessarily a great mechanism for this, and won't work at all for some people. For example, beyond the fediverse, Bluesky itself doesn't have DMs at all yet. I'll think through alternatives, and I'm open to ideas. I'm reluctant to try to chase down all the dozens (hundreds?!) of fediverse servers and convince them to special case Bridgy Fed, and maintain those special cases working over time, but it's definitely one proposal that could work. Whatever we do, it's very possible that our first pass at discoverable opt in won't work for everyone, and we'll have to iterate and improve it over time. (Like all technology!) (And @MadokVaur I remember, I was there. 😁 This is a new idea, and concrete examples are useful for exploratory development. Learning is good! No one knows everything ahead of time. Working through problems in public like this, with input from knowledgeable people like you all, is useful. Thank you!) |
|
@snarfed Most of the people complaining seem to be on Mastodon (or originally came from Mastodon). The common theme from the people complaining is that they thought they joined Mastodon (or some restricted notion of the fediverse that revolves around Mastodon), and don't realize they really joined an open network with multiple protocols already attached to it. If we make a change to Mastodon to detect bridges, that covers 90% (perhaps even 99%) of the people who are upset about this. For the most part, the people on the other platforms already know that the network is open. After all, that is how their project connected to it in the first place. |
|
This is condescending and insulting -- at best "Those silly children on Mastodon! They don't understand The Open Network(tm)!!" No: we understand quite clearly the profound differences between two protocols -- ActivityPub and the ATProtocol -- a distinction you don't want to admit to since it blows a big hole in your arguments Bluesky is a known quantity The universe of ActivityPub distributions is a known quantity We understand what Bluesky is quite clearly -- that's why we're not on Bluesky Finally: Ryan. It's clear you're really listening to no one but your stans and cheerleaders Do not for one minute think that translates into no one listening to you We are listening, Closely With that, 10-4 and out I'm done bothering |
Except the Fediverse already includes multiple protocols, including OStatus, Zot, Nomad, OpenWebAuth, Diaspora, and more. The fediverse is not just ActivityPub. In fact, Mastodon did not even start off on ActivityPub. It started on OStatus and then later changed to ActivityPub. So this ActivityPub vs. AT Protocol argument is irrelevant, because Mastodon has ALWAYS been part of a multi-protocol network. And Mastodon used to be OStatus. So the very statement that the fediverse is ActivityPub demonstrates a basic misunderstanding of what the fediverse is. @snarfed is being kind enough to give you discoverable opt-in even though the request is based on a basic misunderstanding of what the fediverse is. If you want discoverable opt-in to be created to your liking, then I would recommend assisting him in creating it, especially since the existing network is based on opt-out, so opt-in is a new concept. So this whole opt-in concept is new and have never been tried before. |
|
A suggestion for a low-friction in-band universally-ish-accessible opt-in mechanism, maybe: Since you need an actor to send the initial notification, you could present a service account (marked as bot) per domain like The DM can be abridged, I think the important points are:
Blocking the account should act as not-opted-in even while it is still followed. That's very much a state that Mastodon and other AP software can surface, even when the UI only shows "blocked" and blocking always has priority over following in the software. I think this approach has a few advantages:
It also gives admins control to e.g. silence the opt-in account specifically, but still let their users opt in proactively with full functionality if they wish to. (That would ideally be explained in the documentation as one of several choices "for instance admins".) Another nice aspect is that this is most likely symmetric over networks… though on Bsky you'd have to use a second account to ping people (and ideally regularly post there that they should follow the other account instead in case they follow the wrong one) if you want to do opt-in there too… which is probably a good idea to avoid context-collapse-based misgivings though. You should probably also explain to AP users once(!) when a mention can't be delivered because the post visibility is too low, with a different/combined message when they reply directly to a bridged post without being opted in. It would be extremely cool if there was a short grace period and opting in within 30 minutes or so then bridged that specific mention or reply too, if it was visible enough. |
Thanks! Useful to know. It's not really my overall aim with Bridgy Fed, I'm more interested in fully functional bidirectional bridging, so if people really do have that use case, and they're not already served by eg RSS feeds like Mastodon recently added, I'd probably defer them to other bridges that might support them better. And no worries! I definitely appreciate the interest and ideas. Thank you for them! |
|
Couple of thoughts on the implementation based on reading your blog post:
That addresses the bksy -> fedi direction, but what about the reverse? Will bsky users get a DM? I think there's got to be some concern about (a) whether bsky admins will react well to a bot account sending hundreds of DMs to random users a day, and (b) whether bsky users will broadly understand what they are being asked to opt in to. Moreover, the broader concern is that most people who receive an unsolicited DM from a bot account will default to ignoring it, and taking no action counts as a bridge refusal in the proposal.
I'm not sure if you mean following the individual bsky user representation on Bridgy, or following the Bridgy agent (bot) itself as a default-allow. I really want a way to proactively allow bsky people to follow me with as little friction as possible, allowing stuff like this is why I joined an open federated network. (On the other hand, some people may want to opt-in on a per-user basis, and that should also be respected.) This part is off-topic, but I'm curious if you or anyone else have thoughts about whether Bluesky is likely to implement portions of the AP spec at some point anyway, like Threads did, thereby pre-empting this whole discussion and also (ironically) the whole debate about opt-in / opt-out in the first place. |
Bluesky is an open question, since it's so different. Notably, it doesn't have DMs or support for any non-public data at all. I could @-mention people instead of DMing them, which is uncomfortable since it's not private, but still possible. Alternatively, the norms and culture and expectations on Bluesky are very different than the fediverse, so opt out may be enough. Bluesky's federation also works very differently than the fediverse's. PDSes (Bluesky servers) are much more limited, admins don't make any moderation or federation or other decisions for their users besides storing their data, nor are there local, PDS-based "communities" like in the fediverse. PDSes don't even see any data from anyone other than the users they host. In those senses, PDSes are much more like web hosts than fediverse instances. Regardless, I'm open to thoughts here!
That may well be many people's default response. Short of making Bridgy Fed opt out in the fediverse, I don't know if there's anything to be done about that.
Sorry for being unclear. I meant the latter, following the Bridgy bot itself is a blanket opt in. I don't currently have plans to opt in per user. Blocks and mutes will work with bridged users just like normal; hopefully that's enough. |
Heh, yeah, it's definitely been discussed a ton. Short answer, they're unlikely, at best. From bluesky-social/atproto#1716 (comment) :
And bluesky-social/atproto#345 (comment) (from Nov 2022, granted):
|
|
Example DM AS2 object from Mastodon. Key bit is that {
"id": "https://indieweb.social/users/snarfed/statuses/112299993631140417",
"type": "Note",
"published": "2024-04-19T21:25:14Z",
"url": "https://indieweb.social/@snarfed/112299993631140417",
"attributedTo": "https://indieweb.social/users/snarfed",
"to": ["https://fed.brid.gy/fed.brid.gy"],
"content": "<p><span class=\"h-card\" translate=\"no\"><a href=\"https://fed.brid.gy/\" class=\"u-url mention\">@<span>fed.brid.gy</span></a></span> hi there, tap tap, this thing on?</p>",
"tag": [{
"type": "Mention",
"href": "https://fed.brid.gy/fed.brid.gy",
"name": "@[email protected]"
}]
} |
|
...and here's one from us that successfully shows up in Private mentions: {
"type": "Note",
"id": "https://fed.brid.gy/fed.brid.gy#test-dm-note-2024-04-19-i",
"actor": "https://fed.brid.gy/fed.brid.gy",
"content": "let's try AS2, shall we?",
"published": "2024-04-19T21:52:00Z",
"to": ["https://indieweb.social/users/snarfed"],
"tag": [{
"type": "Mention",
"href": "https://indieweb.social/users/snarfed",
}],
} |
part of setting up per-protocol bot users for #880
|
Everything is done here except Bluesky users triggering the prompt, #966. We're waiting on Bluesky's OAuth for that, hopefully coming in days to weeks. |
Maybe, if you have time, you could put up a blog post about the status of Bluesky bridging? Last I heard we were waiting on the federation limit to be raised, but I now appear to be able to follow some live Bluesky accounts, e.g. Summarizing the status quo, it looks like the decision was made to make Bluesky opt-in for now? I can see Bluesky users following @ap.brid.gy but no one else. Obviously, this isn't sustainable because most Bluesky users don't have any interest in (or knowledge of) the bridge, so I'm just wondering what the long term plan is here. Seems likely that it would be possible to run a private fork of Bridgy that only accepts follow requests from my Fediverse accounts, and follows Bluesky users with no opt-in. More generally, it would be neat for a Mastodon server to offer bridging "as a service", using Bridgy code to transparently interpret and follow Bluesky accounts, and also making user posts available on a Bluesky PDS for the reverse direction. Users who signed up would effectively become both Bluesky and Fediverse citizens automatically, with a single account for both. |
|
Yes! I'll definitely announce more widely once I'm ready for broader attention. You're right that I have a somewhat higher Bluesky federation limit now, but I'm still actively fixing bugs and waiting on other blocking issues like bluesky-social/atproto#2280 that (arguably) need to be fixed before I launch or announce more widely. And I still haven't made a significant decision on Bluesky opt in vs out. There's still a very good chance that it will be opt out, but I don't know for sure yet. You're right that since Bridgy Fed is open source, you can run your own instance, fork it, etc. I'd mildly discourage it, since I want to avoid proliferating duplicate bridged accounts for the same users (see eg #800), and 2) I'd worry that modifying it to only only bridge specific accounts would be incomplete, and "private" bridges would end up bridging other accounts too. |
|
I may be missing the point entirely here, and I'm not really much of an expert on this stuff, but isn't this project just translating between two different federation protocols? Beyond technical issues, I don't understand what the difference is between this bridge and just... normal federation. The only real problem I can see is that it would be harder to block the bsky "instance" seeing as the bridge can be hosted by a bunch of different people, but even then that seems like it's only mildly more annoying than blocking a bunch of different instances (what's the difference between blocking 3 new instances full of content you don't like compared to blocking 3 instances of the same bridged content you don't like?). I've also seen people complain that they don't want their data on atproto, but any data that can be bridged is already fully public information. Activitypub or any other protocol won't protect anyone from their own bad opsec, so it doesn't really make sense to reject a protocol on the basis that the data (that you're already sharing publicly!) would be less secure when using it. What actually is the problem here? This is a genuine question, reading the other issues/discussions about this is exhausting and I haven't been able to understand anything through all the people throwing insults at each other. |
|
Hi! The debate over the bridge itself, is it federation, opt in vs out, etc is well worn, so I'll defer that to the existing conversation and my earlier blog post.
Coordinating and de-duping people across bridges is definitely an important open question! We've started discussing it in #800.
Bluesky has a fundamentally different architecture than the fediverse. It's far less instance-centric: federation doesn't happen directly between instances (PDSes) at all, they talk to other tiers, specifically relays. BF bridges all of the ATProto network, but currently only the |
I see, how is moderation across the bridge going to be handled then, since bluesky doesn't do instance blocking? I believe they have their own composable moderation system, would the bridge be able to use that somehow? Also, the post you linked mentions "bespoke relays":
What would be the bridge's behaviour regarding those? They seem somewhat analogous to fediverse instances, so should they be treated like such? Of course, I imagine there's still time before that becomes relevant, but I'm just curious if any thought has been given to it yet. |
Yes! https://fed.brid.gy/docs#moderation, https://fed.brid.gy/docs#moderation-policy
No clue yet. It's a ways off in the future, as you mention. |
If you do implement some sort of opt-in system, I don't want a new notification every time someone follows me.
I use fediverse software that supports both public and private posts. If I post it publicly, that means I want everyone to see it and allow anyone to follow my public posts (unless I block them). If I make it private, it does not matter if someone follows me, because my software won't send them the post since they are not allowed to see my post unless I say they can.
Mastodon users might need an opt-in system because their software lacks privacy controls. But I don't have that problem since I don't use Mastodon.
So, however you set it up, I would like to have a way to tell your bridge to NEVER prompt me. Always allow the follow. ALWAYS.
So if you decide to implement opt-in, there should be a way to opt-out of the opt-in.
The text was updated successfully, but these errors were encountered: