Opt in/out prompt - Githubissues

WisTex commented 5 months ago

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.

snarfed commented 5 months ago

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.

WisTex commented 5 months ago

That is good. Being bombarded with prompts would drive me crazy.

WisTex commented 5 months ago

How will this work for people who don't accept DM's from strangers. By default, only my connections can send me DMs.

snarfed commented 5 months ago

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!

WisTex commented 5 months ago

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.

TransCommunist69 commented 5 months ago

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.

MadokVaur commented 5 months ago

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

WisTex commented 4 months ago

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.

craftycorvid commented 4 months ago

@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?

WisTex commented 4 months ago

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

WisTex commented 4 months ago

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.

TransCommunist69 commented 4 months ago

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.

snarfed commented 4 months ago

What's stopping someone from forking the project and running a fork that disables the opt-in system that federates everyone?

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.

snarfed commented 4 months ago

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?

WisTex commented 4 months ago

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

snarfed commented 4 months ago

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!

WisTex commented 4 months ago

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

snarfed commented 4 months ago

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

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.

WisTex commented 4 months ago

"it would DM that person the prompt, and if they accept, it would then propagate their profile into Bluesky and allow following."

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.

snarfed commented 4 months ago

@WisTex hmm. Which platform is that? Raconteur/Streams?

MadokVaur commented 4 months ago

"@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: https://github.com/snarfed/bridgy-fed/issues/880#issuecomment-1947829615

WisTex commented 4 months ago

I'm using Hubzilla for most of my accounts.

WisTex commented 4 months ago

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.

snarfed commented 4 months ago

@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!)

WisTex commented 4 months ago

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

MadokVaur commented 4 months ago

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

WisTex commented 4 months ago

@MadokVaur

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

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.

qazmlp commented 3 months ago

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 @opt-in@bsky.brid.gy that sends the initial DM, explains in its bio that it will never post anything and that following this account connects the account to the other network. Also suggest muting the account to privately ignore any future requests. (I think it's reasonable to expunge data and potentially send another DM after six months if the first one is ignored. Potentially legally required, really.) Also include a link to the documentation in the bio. Importantly, the service account should not follow.

The DM can be abridged, I think the important points are:

[user] would like to follow you from [network].
This bot helps you control the connection.
Follow to connect to that network. (Transmits only your public posts and profile info. This account will not post, ever. Unfollow at any time to disconnect and delete your data from the bridge.)
Mute instead to privately ignore [network]. The bridge won't know.

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:

Following, unfollowing and muting are universal actions that can generally be done without leaving someone's client of choice by human-controlled accounts, and following/unfollowing nicely doubles as authentication.
Following/unfollowing/blocking/unblocking are intuitive reversible actions.
If someone can't receive the DM, or just wants to be e.g. discoverable on Bsky without having an account there, following would allow someone to opt in proactively. Similarly, muting (or blocking the domain) would allow someone to privately opt out proactively.

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.

snarfed commented 3 months ago

@qazmlp yes! Thanks for the detailed ideas. You're right, in-band UX like this is definitely more convenient than a form on the https://fed.brid.gy/ web site, and following and blocking are an interesting alternative to DMs. I don't know if they're more intuitive than a few reply options to the DM itself, but maybe!

There's a lot of functionality and nuance described here, more than I expect I'd tackle at the beginning, but it's definitely interesting and promising.

(Also, "instance actors" like @fed.brid.gy@fed.brid.gy are already well established in AP for breaking the authorized fetch deadlock problem, so we'd probably use that actor.)

I still worry a bit about how to notify someone of their first follow request across the bridge. DMs seem ideal, as discussed above, but they're not universally supported across the fediverse. Maybe an unlisted @-mention would be more widely supported? I'm reluctant to use public @-mentions.

One nit: afaik muting is generally private, ie there's no way to tell that a given user has muted you, so we couldn't use that as a UX mechanism. (Every bridged user will show up as their own account, so muting @fed.brid.gy@fed.brid.gy wouldn't hide other bridged accounts.)

qazmlp commented 3 months ago

@snarfed

[…]

(Also, "instance actors" like @fed.brid.gy@fed.brid.gy are already well established in AP for breaking the authorized fetch deadlock problem, so we'd probably use that actor.)

I still worry a bit about how to notify someone of their first follow request across the bridge. DMs seem ideal, as discussed above, but they're not universally supported across the fediverse. Maybe an unlisted @-mention would be more widely supported? I'm reluctant to use public @-mentions.

Public @-mentions definitely wouldn't be a good idea, since they'd appear in discovery features. Admins generally can turn that off for specific accounts or instances, but better not to create more work for them, right? 😉

I think unlisted mentions by a service account are probably okay, even if they have some privacy implications. The copy on your website would have to mention that the request may be seen by others. If you go with "follow to opt-in", that would definitely have to be a separate account then, but you could @-mention it to make it easy to use.

There are some ways to limit the reach of unlisted posts, like only delivering them to the target instance as RSS Parrot does. That one seems to additionally not cache objects (i.e. doesn't expose them at their URL) which means they can't be boosted onto other instances, but that would likely be incompatible with Pleroma, since afaik that software will always do an object fetch instead of doing signature verification to authenticate inbox items.

One nit: afaik muting is generally private, ie there's no way to tell that a given user has muted you, so we couldn't use that as a UX mechanism. (Every bridged user will show up as their own account, so muting @fed.brid.gy@fed.brid.gy wouldn't hide other bridged accounts.)

Yes, I consider that to be a feature.

I noticed that some users were concerned about the bridge keeping a list of opt-outs during the initial backlash, so by muting the instance actor, they could ignore future notifications permanently without you having to keep a record of this.

I'm thinking about the use-case here where someone may want to follow a remote account (e.g. government account on AP that's not on AT) without opting their own account into the bridge. Maybe that should bridge at least their profile info, though, or rather have a tiny explanation like "This is a virtual bridge account on behalf of [web link to profile]. [length-limited display name] isn't currently sharing their posts or [likes/favorites] to [network]. More info: [link to docs]".

(If requests were reliable I'd include ", but you can request this by following back.", but that would definitely cause some interpersonal misgivings in some cases where the notification can't be delivered. Having this in the docs would be fine if you mention that "The user may not be notified in some cases where they previously ignored notifications." Detecting when the service isn't available for an entire instance would also help.)

You could notify users when their actions create or delete a virtual account on a remote protocol. "To follow bridged accounts, a virtual profile on [network] is necessary. Yours is [remote handle] and contains your display name and a link to your original profile. To undo, unfollow all bridged accounts on [domain]." I think that would help against misunderstandings. The deletion notification would definitely be nice to have for peace of mind, too.

There's potentially also a third level where someone may want to bridge all their interactions with bridged objects without bridging their unrelated actions, but that seems like a far-future feature.

I wonder if we're thinking differently about which account(s) send(s) the bridging request from remote follows. I was thinking they would come from a central account and @-mention the requestion bridged account (without delivery back across) like @bsky.fed.brid.gy@bsky.fed.brid.gy: "@example.com@bsky.fed.brid.gy has requested to follow you. …". (I'm not good enough at copywriting to come up with the best wording there.)
In that case, the "just mute requests but still see bridged posts" flow would be trivial.

Having the respective virtual account send a DM on behalf of the remote user sounds interesting, but even on networks where DMs are reliably available (Nostr? I haven't used it.), not being able to mute just all those notifications from just one remote network would be a problem for someone like me who'd want to never share to a specific one but would be totally fine with seeing when someone I follow boosts something originally from over there.

I may have totally misunderstood you though, and I don't have any formal qualification in UX design, so please take everything I write here with a grain of salt.

snarfed commented 3 months ago

I noticed that some users were concerned about the bridge keeping a list of opt-outs during the initial backlash, so by muting the instance actor, they could ignore future notifications permanently without you having to keep a record of this.

Ah, I see what you mean now. I only plan to DM each user at most once, to prompt them to opt in the first time someone requests to follow them over the bridge.

I'm thinking about the use-case here where someone may want to follow a remote account (e.g. government account on AP that's not on AT) without opting their own account into the bridge. ... You could notify users when their actions create or delete a virtual account on a remote protocol.

Interesting ideas! I'm happy to track all of these more involved ideas, but they all add complexity, sometimes a lot, so I doubt I'd do many or any of them for v1, or even anytime soon after.

For example, following without opting in raises a number of of non-obvious questions. For one, you need some account to do the following, on either side. I guess I could use the instance actor for that, and track and route posts to anonymized followers like this myself.

There's potentially also a third level where someone may want to bridge all their interactions with bridged objects without bridging their unrelated actions, but that seems like a far-future feature.

This sounds like a more involved version of #831. It could be nice! But it would take a substantial amount of new UX that I don't know how to do right now, especially since most users interact with Bridgy Fed indirectly, inside their existing social network, where I'm not able to directly build and surface new UX.

qazmlp commented 3 months ago

@snarfed I fully agree, except for one point:

[…] I guess I could use the instance actor for that, and track and route posts to anonymized followers like this myself.

There's precedent where a service (I think a different bridge or a software) enabled anonymous follows and people took it pretty badly. I think it would be good to avoid follows from service accounts to avoid the impression of a repeat.

Personally, I also do think this approach would cause serious problems, as then users couldn't (with their usual tools) remove a single problematic remote follower without cutting off the entire bridged network.

Seeing individual follow notifications is also very important for many marginalised groups. It lets us see when something is "off" on social media ahead of time and take precautions to avoid issues and hate. Not something I personally have to do much, fortunately, but I know people who do have to be cautious in this way.

I think it would be fine to automatically create barebones virtual accounts for remote followers without notification, as long as their bio makes it clear what they are and on whose behalf they are acting. It's not like they need to have web-visible HTML pages, and you can set flags to reduce their visibility in search (and on Bluesky online, I think bsky.app would create a web-public indexed HTML page without that).
One thing that may be very helpful with first impression though is if you gave them a placeholder profile picture representing their network rather than not setting one at all. (Bridging any image without explicit opt-in seems too spicy.)

I hope I don't come across as too demanding. I'm roughly aware of how much work projects like this one take and would look into contributing more directly if I wasn't entirely useless at Python specifically.

My motivation here is that I'd like to eventually use Bridgy to connect to friends on Bsky with the user experience I have on Mastodon, some of whom are not the biggest fans of the Fediverse for various reasons, so it's important to me to reduce unnecessary misgivings about the bridge and bridging in general.

snarfed commented 3 months ago

There's precedent where a service (I think a different bridge or a software) enabled anonymous follows and people took it pretty badly. I think it would be good to avoid follows from service accounts to avoid the impression of a repeat.

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!

afontenot commented 2 months ago

Couple of thoughts on the implementation based on reading your blog post:

The current design is that a Bridgy Fed instance actor (user) will DM you the first time anyone on Bluesky requests to follow or interact with you over the bridge. If you reply yes, or follow the Bridgy Fed user, you’ll be bridged. If you reply no, or ignore the DM, or block that user, you won’t be.

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.

You’ll also be able to follow or block the Bridgy Fed user to opt in or out proactively, ahead of time.

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.

snarfed commented 2 months ago

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.

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!

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.

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.

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

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.

snarfed commented 2 months ago

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.

Heh, yeah, it's definitely been discussed a ton. Short answer, they're unlikely, at best. From https://github.com/bluesky-social/atproto/discussions/1716#discussioncomment-7213814 :

Will there be some way for Bluesky or any atproto service to implement direct compatibility with ActivityPub standard, or vica-versa? In a meaningful way? Seems like a stretch. As a direct answer, phrased this way, it is not on the Bluesky roadmap.

And https://github.com/bluesky-social/atproto/issues/345#issuecomment-1314378964 (from Nov 2022, granted):

I'll just answer here: currently, no there's no plan for AP integration in the Bluesky client.

snarfed commented 2 months ago

Example DM AS2 object from Mastodon. Key bit is that to is just the target actor id. Docs: https://docs.joinmastodon.org/spec/activitypub/#Mention

{
    "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": "@fed.brid.gy@fed.brid.gy"
      }]
}

snarfed commented 2 months ago

...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",
    }],
  }

snarfed commented 2 months ago

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.

afontenot commented 2 months ago

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.

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.

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. @divy.zone. Thanks once again for your work on this!

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.

snarfed commented 2 months ago

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 https://github.com/bluesky-social/atproto/issues/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.

Void-0000 commented 2 months ago

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?). (Tangentially relevant note: Is this project intended to bridge all of atproto or just the "main" bsky instance? If it bridges everything, would that not make it impossible to block individual atproto instances (whenever that starts being a thing) rather than the entire protocol at once?)

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.

snarfed commented 2 months ago

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.

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

Coordinating and de-duping people across bridges is definitely an important open question! We've started discussing it in #800.

(Tangentially relevant note: Is this project intended to bridge all of atproto or just the "main" bsky instance? If it bridges everything, would that not make it impossible to block individual atproto instances (whenever that starts being a thing) rather than the entire protocol at once?)

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 app.bsky lexicons, ie semantics. If/when people add other lexicons, for eg events or other functionality, BF won't handle those until I add support for them.

Void-0000 commented 2 months ago

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.

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":

Small bespoke Relays could also service tightly or well-defined slices of the network, like a specific new application or a small community.

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.

snarfed commented 2 months ago

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?

Yes! https://fed.brid.gy/docs#moderation, https://fed.brid.gy/docs#moderation-policy

Small bespoke Relays could also service tightly or well-defined slices of the network, like a specific new application or a small community.

What would be the bridge's behaviour regarding those? They seem somewhat analogous to fediverse instances, so should they be treated like such?

No clue yet. It's a ways off in the future, as you mention.

snarfed / bridgy-fed

Opt in/out prompt #880