AP: DM bot user to prompt remote users to enable (opt into) the bridge #1148
Comments
|
Hmm, one problem is that unlike in Mastodon, you can disable DMs completely or only allow them from followed people, and the default is followed only. So actually in most cases the bridge will not be able to DM that person on Bluesky. |
|
Oh damn, that's a great point, I'd forgotten that followed only is the default. Hrmph. |
|
Maybe for those that they cannot DM, just have it publicly mention? |
|
Definitely an option! I'm reluctant to make these prompts public though. |
|
If you do make it public I think I'd prefer if you just keep the name of the user who initiated the follow anonymous and/or just tell them to follow the account to bridge instead of a yes/no prompt (just my opinion, but I wouldn't want to publicly respond to a follow request) Also, out of curiosity, would this send a DM for every single follow request? Or just do it the first time it happens? |
|
Right, that's why I'd rather it not be public. If BF is DMing you, it feels important for fairness etc to include the user who originally requested that DM - and also hopefully more motivating - but it doesn't feel appropriate to be public. (And yes, you'd still be able to enable the bridge by following as well as by replying.) This will only send a DM once, the first time, not for each request. |
|
Maybe for the users who don't have DMs enabled for everyone (so most), make it auto-accept on the Bluesky side and see what the general public's reaction is on Bluesky and then reconsider if necessary? 😅 |
|
What I'm saying is that IMHO the kind of GitHub thread like That One is highly unlikely in this case... and the DM request is also harder to do than on Fedi |
|
It's just my 2 cents but I feel like this should still be cautious on the Bluesky side, even though the expectations are different, because there's no ability to remove followers on there. |
I feel like this gets at the basic granularity issue with opt-in. Getting a DM that says "[person I've never heard of] on [platform I know nothing about] wants to follow you, follow [random account I've never heard of] to allow this!" is just spam, from an average-user perspective. Random garbage like this gets sent as DM and reply spam all the time and almost always earns an immediate block. There's a very big difference between "I want to allow this specific person I don't know to follow me on some creepy nerd platform" and "I'm okay with anonymous members of the public following my public posts". The former is much less invasive than the latter, but because the request is so specific it feels more invasive. That's the granularity problem. Or to put it a little differently, DMing people an individualized request makes bridging feel like a privacy violation, even though it is vastly less privacy impacting than having a public profile on Bluesky is to begin with. You can already follow Bluesky users anonymously via RSS! I wonder if the Bluesky devs would be interested in working out a solution that allows Bluesky users to more generically opt-out of their posts being followed by automated AT protocol accounts (like those created by Bridgy Fed). They seem extremely positive about BF so far, as a large number of them have followed the bridge account. |
|
Hmm, these are some good points @afontenot… |
Each given user would only ever get one of these DMs, ever, not one per follow request. @afontenot I'm curious if that changes your thinking at all...? |
As I was thinking about it, that's part of the problem. If they're just some random person, the DM is much more likely to be ignored as spam or result in an outright block. Sending the request under the name of the first potential follower makes it near certain that most users (especially popular ones) getting the DM are going to see some rando presented as the brand ambassador for Bridgy Fed. Users are trained that legitimate interactions come through the app's chrome, not through "content" like replies, DMs, etc. If you are a Twitter user and you get a message that says "please follow this account" or "someone on website X wants to follow you", that is a scam 100% of the time. Getting it with a random @xyz29520103 user you've never heard of attached to it is even worse than that. I anticipate 90% refusal rate even though the overwhelming majority of Bluesky users probably have no objection to their public posts being read over whatever protocol. Idea: maybe the DM could be sent as an opt-out with a time delay, rather than opt-in? In other words, when someone follows a Bluesky user from Fediverse for the first time, add the follow on the AT protocol, but don't start actually bridging the posts until (a) the person explicitly opts in, or (b) a certain time delay passes - e.g. one week, provided the user is active on Bluesky during that period. The DM could then be presented as informative, rather than demanding an (unwanted) interaction from the recipient. You could basically just explain in the DM (a) where this new follow is coming from, (b) what bridging means, (c) how they can explicitly consent to allowing bridging, (d) explaining how to individually block Fediverse users or the entire bridge, and (e) clarifying that they won't receive additional messages in the future. |
|
Yeah, I agree with a lot of those points and the current drawbacks, especially that the majority of people probably won't reply yes to the DM or follow the bot even though they're ok with bridging. I'm reluctant to add much more logic complexity though. If anything, I'd probably be more likely to just make Bluesky opt out and on for everyone by default. The biggest thing holding me back at this point may just be scaling. BF handles its current load fine, and I might be ready for something like 10x, but not 100x. I feel ok about the current architecture, but as always, I'm sure there are hidden bottlenecks in there that I don't know about. If I switched Bluesky to opt out, I don't know how much load would increase, but I expect at least a big multiple of the current traffic. |
But that would still only start bridging those users that were specifically requested to be bridged by someone on the Fedi side by DMing the bot, right? So I don't think that would be anything close to 10x? |
They'd be able to discover and follow any Bluesky user on demand, by searching in their fedi instance, like they already can for web sites. (I could require that they DM the bot first, but that seems like just added UX friction with no clear benefit.) The added load would be a gradual ramp, you're right, not 10x on day one, but I expect it would still end up as a substantial multiple of current load. |
|
Oh, so like, if you type |
|
Understood! Yeah it's tricky. Lots of people have instincts for how all this should work, which actions should have which effects, etc, but those instincts vary widely. The other interesting bit is, global ATProto relays/appviews mean that it's pretty black and white whether a fediverse account is bridged into Bluesky. The fediverse doesn't have a corollary though, ie there's no clear way to say whether a Bluesky account "is" or "isn't" bridged into the fediverse. If you search for a Bluesky account on one fedi instance, and it loads the profile, but you don't follow it, that profile will only be on that instance, without any posts, and will probably expire eventually. Is that Bluesky account then "officially bridged" into the fediverse? It's semantics, I guess, but it's hard to say 100% yes. Having said all that, right now I'm comfortable with it working like that. Someone has to explicitly search for a Bluesky account's full bridged handle to load its profile, and that seems like a pretty clear request to bridge them, easily as clear as DMing the bot, and far easier and more familiar to fedi users. |
|
You technically don't need to do any real persistence until someone actually follows (beyond some caching, I assume). Fedi users are mostly used to profiles not backfilling and the instances wouldn't normally pick up on older posts anyway (aside from pinned ones), so not handling post data unless there's a follower wouldn't break expectations. I'm not sure how much of a difference this would make, though. May be significant if you wire up @-mentions with the future id of not-yet-bridged Bluesky accounts and then someone scrapes Bridgy Fed through ActivityPub (which I expect happens, occasionally) or an instance prefetches profiles. |
On this note, Mastodon at least will keep profiles around indefinitely unless their WebFinger returns 410 Gone at some point or it receives a I'm not certain if it will refresh stale profiles periodically or only once there's a lookup due to related data access after that timeout. |
Ooh, right, I haven't realized that the posts won't be copied over to Fedi (or to that instance) unless someone there actually follows the profile. Yeah, that makes sense. |
Bridgy Fed does have the outbox endpoint that lists recent public activity, so in theory instances could populate the profile on demand when someone views it, but the most popular fediverse apps don't do that beyond maybe the pinned posts. |
Mastodon has had an issue open for backfilling statuses since 2016 (mastodon/mastodon#34) so I imagine eventually it'll be implemented in mastodon and its forks FWIW |
Background in #880. #966 is the corresponding issue for Bluesky. In short, fediverse users should be able to request bridging a Bluesky user by DMing their handle to @bsky.brid.gy@bsky.brid.gy. BF will then DM that user on Bluesky, and they can respond yes or no.
The text was updated successfully, but these errors were encountered: