DM bot user to prompt remote users to enable (opt into) the bridge

[snarfed]

Blocking this on Bluesky OAuth since I want to identify the requesting Bluesky user and include their handle in the prompt DM, but I don't want to make them enter an app password. Bluesky team says OAuth is "a few weeks away," bluesky-social/atproto#2428 (comment), so we can wait.

[snarfed]

"A few weeks away" was a bit ambitious on their part. 😆 Also, interestingly, Bluesky shipped DMs before OAuth, so they have parity with the fediverse on that count. Given all that, I'm going to pivot to using DMs for the opt in prompt on Bluesky as well as in the fediverse. Renaming this issue to track that.

[snarfed]

In short, the idea here is that Bluesky users should be able to request bridging a fediverse user by DMing their handle to @ap.brid.gy@ap.brid.gy. BF will then DM that user in the fediverse, and they can respond yes or no.

[snarfed]

BF's DM logic is now generally protocol-independent, so I'm merging #1148 in here. Lots of good discussion there though!

[snarfed]

Also I expect I'll need some rate limiting here, since this is the first BF DM feature that lets people make it DM other people, not just themselves. Maybe something like 10/user/day and 1k/instance/day to start.

[qazmlp]

Does Bluesky count as a single instance in this context, or would it be each PDS? 🤔

I assume this will be subject to the same spam filter as bridging an account is, though I feel like it may be a good idea to require bridging the sender before sending a request, so that you can @-mention the bridge account for the recipient to check natively on their network.¹

Just to recap (because I may have missed something), what's your current plan for the per-addressee cooldown and feedback to the requester if it fails due to that?
I assume you'd want to purge stale data at least eventually.

It'd be really cool if the bot could log who requested bridging (even if unsuccessfully) and then notify those users once the bridge account becomes available on their network.

Footnotes

1. Though, this would make the issue Bridge follows from before bridging aren't bridged #1102 more prevalent. ↩

[snarfed]

Does Bluesky count as a single instance in this context, or would it be each PDS? 🤔

Good question! Probably each PDS.

I assume this will be subject to the same spam filter as bridging an account is, though I feel like it may be a good idea to require bridging the sender before sending a request, so that you can @-mention the bridge account for the recipient to check natively on their network.1

Yes! I definitely plan to require that the requester is bridged first. And the DM will come from the bridge bot account, so it should be easy to see and follow.

Just to recap (because I may have missed something), what's your current plan for the per-addressee cooldown and feedback to the requester if it fails due to that? I assume you'd want to purge stale data at least eventually.

Yup, it'd be nice to reply to someone once they hit their rate limit.

It'd be really cool if the bot could log who requested bridging (even if unsuccessfully) and then notify those users once the bridge account becomes available on their network.

Yes! I doubt this would happen in the first phase, I'd need to track everyone who requests a given user, but it's a good idea, definitely on the table.

[qazmlp]

[…] And the DM will come from the bridge bot account, so it should be easy to see and follow.

From e.g. @bsky.brid.gy@bsky.brid.gy or @ap.brid.gy, right?

I think we're on the same page about that. What I meant was @-mentioning the bridged account of the requesting user, so that the recipient can quickly look at that profile using their own network's client.

Just to recap (because I may have missed something), what's your current plan for the per-addressee cooldown and feedback to the requester if it fails due to that? I assume you'd want to purge stale data at least eventually.

Yup, it'd be nice to reply to someone once they hit their rate limit.

I mainly meant that as an "if someone already invited , don't let anyone do so (again) for hours" rule.

If someone's really popular, this feature could get spammy.

Especially if they're on Bluesky and have incoming Chats set to Everyone, as they can't simply mute the domain there. (Though it could still be inconvenient in Mastodon, since that doesn't have a good conversation manager at all.)

[snarfed]

What I meant was @-mentioning the bridged account of the requesting user, so that the recipient can quickly look at that profile using their own network's client.

Definitely! That's always been the plan. #1148 (comment)

I mainly meant that as an "if someone already invited , don't let anyone do so (again) for hours" rule.

If someone's really popular, this feature could get spammy.

Oh yeah, more than that, I've similarly always planned for this to only ever DM a given user once, total. Or maybe once per protocol/network. #1148 (comment)

[h-2]

How does this work? I could DM the bridge account from Mastodon, and it will nudge people on BSky to follow the bridge account, so that I can then follow them?

[qazmlp]

How does this work? I could DM the bridge account from Mastodon, and it will nudge people on BSky to follow the bridge account, so that I can then follow them?

I'm not sure how well this is documented and how much feedback there is in the process, but you DM their Bluesky handle to the bridge account via Mastodon and then the bridge account on Bluesky should nudge them, yes.

You have to have bridged your account towards the target network and the Chat message there will mention it was you who made the request.

Note that this isn't reliably available. Some ActivityPub users reject mention-only notes from users they aren't in contact with and on Bluesky the Chat function defaults to "from follows only" which means the bridge can't message them unless they change it. (Bluesky asks the first time someone opens the 'Chat' function.)
The bridge also only ever asks each user once, so if they don't know you, you doing so first could reduce the chances of them interacting with the bridge.

---

Note that Bridgy Fed appears to currently have about three days of delay in bridging posts from Bluesky, so you should expect some latency for their opt-in.

[snarfed]

Thanks @qazmlp! That's all accurate. The DM feature isn't officially announced or documented yet, but it should hopefully be working in the fediverse if you DM a Bluesky handle to @bsky.brid.gy@bsky.brid.gy.

[snarfed]

Also need to fix https://console.cloud.google.com/errors/detail/CMHloZaRmPXQZQ;time=PT1H;locations=global?project=bridgy-federated ?

[snarfed]

I've soft launched this for Bluesky too! You can chat a fediverse handle like @snarfed@indieweb.social to https://bsky.app/profile/ap.brid.gy and it will send them a fediverse DM that you want them to enable the bridge.

[mackuba]

Yayy! 🥳

[mackuba]

Is it supposed to reply something when I DM it?

[snarfed]

We have to poll for chat messages, so we currently do that once a minute, so it might take a minute.

Also, oof, the user you requested can't use Bridgy Fed yet because their username starts with a _ character. I'll update the DM handling to block those addresses.

[mackuba]

It doesn't message me back when they enable bridging, does it? It would be nice, because it looks like I just need to keep checking periodically now… (I checked and they do show up in the search now).

[snarfed]

Right, not yet, but it's a good feature request! I've filed #1321.

[snarfed]

Docs are up! https://fed.brid.gy/docs#dms , https://fed.brid.gy/docs#dm-request . I'll announce more loudly soon.

[mackuba]

What happens if a Mastodon user wants to ask a Bluesky user to bridge, but they have DMs closed / follows only?

[snarfed]

Good question! I expect they won't see the DM then.

[qazmlp]

It'd be nice if the bridge checked for that and instead replied to the requester that it's currently not possible because etc.

That'd leave open the option to send a working request if the person opens their DMs in the future.

[mackuba]

I think it would make sense if Bridgy checked that and answered with some kind of "I'm sorry Dave I'm afraid I can't do that" if the DMs aren't open (you can see that setting in the chat.bsky.actor.declaration record of the target account).

(Edit: dammit qazmlp was 1 minute faster :p)

E.g. mine: https://amanita.us-east.host.bsky.network/xrpc/com.atproto.repo.getRecord?repo=did:plc:oio4hkxaop4ao4wz2pp3f4cr&collection=chat.bsky.actor.declaration&rkey=self

[snarfed]

Agreed! Filed #1326.

[h-2]

Could the bridge be set up to nudge users not following the bridge whenever they interact with me (e.g. follow me) or my content (like or repost). This would be much easier than me tracking down follows and sending them messages myself.
I'd even be fine if the bridge replied using my own account on the foreign network to send this nudge, somethine like

Hi, thanks for following my account on BSky. Unfortunately, 
I cannot see this or follow back, unless you also follow @ap.brid.gy

That's because I am actually on [insert fedi instance] which is a "bridged"
server. You can find more information here: http:/...

[qazmlp]

I like the auto-nudge idea, though a potential problem is that starting a Chat conversation would cause some other issues in terms of broken UX (because Bridgy doesn't bridge between Chat and Mention-only due to large differences between them).

Still, if Bluesky remains opt-in, it would be nice if we could eventually set a custom message for this, followed by either leaving the conversation, if that's an option that prevents replies, or an automated explanation that Chat isn't truly bridged.

[qazmlp]

Also note that actions (e.g. follows) taken before bridging currently aren't bridged. There is an existing issue for the follow discrepancy.

[snarfed]

Yes! This kind of nudge is a good idea. BF already does it if you're not bridged and you reply to a bridged account, since that person won't see your reply. https://fed.brid.gy/docs#dms , #1205

[h-2]

a potential problem is that starting a Chat conversation would cause some other issues in terms of broken UX (because Bridgy doesn't bridge between Chat and Mention-only due to large differences between them).

it would be nice if we could eventually set a custom message for this, followed by either leaving the conversation, if that's an option that prevents replies, or an automated explanation that Chat isn't truly bridged.

I hadn't thought of that, but, yes, in that case it would be good to prevent regular DMs if they don't work anyway (not a big deal IMHO).

Still, if Bluesky remains opt-in,

Being opt-out would of course be much better 🙏🏻

Also note that actions (e.g. follows) taken before bridging currently aren't bridged. There is an existing issue for the follow discrepancy.

That's unfortunate, it makes it even harder to notify people afterwards to establish a proper connection...

BF already does it if you're not bridged and you reply to a bridged account, since that person won't see your reply.

I saw that, it's what prompted me to suggest this ✨

I think, to sum up, I would have any interaction that cannot be resolved properly because one party is not bridged (didn't opt-in or opted out) always lead to a DM to that party explaining how to establish bridging.

If DMs don't work, than iniating DMs or private messages should lead to an immediate reply from the bridge that these don't work.

[snarfed]

Sure! For DMs specifically, we could reopen #886. For other interactions, feel free to file feature requests!