-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DM bot user to prompt remote users to enable (opt into) the bridge #966
Comments
"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. |
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. |
BF's DM logic is now generally protocol-independent, so I'm merging #1148 in here. Lots of good discussion there though! |
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. |
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.1 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? 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
|
Good question! Probably each PDS.
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.
Yup, it'd be nice to reply to someone once they hit their rate limit.
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. |
From e.g. 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.
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.) |
Definitely! That's always been the plan. #1148 (comment)
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) |
I've soft launched this for Bluesky too! You can chat a fediverse handle like |
Yayy! 🥳 |
Is it supposed to reply something when I DM it? |
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 |
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). |
Right, not yet, but it's a good feature request! I've filed #1321. |
Docs are up! https://fed.brid.gy/docs#dms , https://fed.brid.gy/docs#dm-request . I'll announce more loudly soon. |
What happens if a Mastodon user wants to ask a Bluesky user to bridge, but they have DMs closed / follows only? |
Good question! I expect they won't see the DM then. |
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. |
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 (Edit: dammit qazmlp was 1 minute faster :p) |
Agreed! Filed #1326. |
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 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. |
Also note that actions (e.g. follows) taken before bridging currently aren't bridged. There is an existing issue for the follow discrepancy. |
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 |
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).
Being opt-out would of course be much better 🙏🏻
That's unfortunate, it makes it even harder to notify people afterwards to establish a proper connection...
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. |
Sure! For DMs specifically, we could reopen #886. For other interactions, feel free to file feature requests! |
Here's how the prompt DM looks (update: originally put the wrong DM here, fixed now): Text:
|
This comment was marked as resolved.
This comment was marked as resolved.
@Tamschi hah yes! Sorry, moving too fast this morning. Fixed now. Thanks! |
I'd clarify that as "… by following @ap.brid.gy (this account)." As-is it's a tiny bit ambiguous and at scale some recipients may think a follow of the bridged user is being requested. |
Looks good otherwise though! I think I'd maybe start with |
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.
The text was updated successfully, but these errors were encountered: