Instance Opt-in

[h-2]

I know that you got a lot of heat initially when starting the bridge as opt-out. I would still like you to reconsider this, or at least allow entire Mastodon instances to opt-in for their users. This would allow us to lobby the big instance admins on both sides to opt-in, while ignoring nerd and niche instances.

I really like cross-federation. In fact, I think it's probably one of the most important features we need right now. However, at the moment this feature is absolutely niche. On mastodon.social the bridge account has less than a 1000 followers ( 0.4 % of active users), and on bsky it has around 6000 followers (0.075% of total users). BUT for proper interaction users on both sides need to have opted in, so chances of two random users being connected are tiny 😢

Have you considered instance opt-in?

P.S.: is there a way to support this project with money? Patreon, Paypal, Github, SEPA?

[ygg2]

I think it wouldn't be good to create a situation where admins can do it aginst their users' wishes, potentially users who don't want to be bridged but haven't put #nobridge in their profiles because it's opt-in. There's already a lot of frustration over admins being the determiners of who an instance federates with (both in blocking and not blocking) especially without much transparency and the difficulties of migrating away as a user if you don't like the decision. It might also be kinda one-sided since Bluesky is more of a single user experience without really having PDS admins in the way fedi instances do

#966 should help a lot with opt-in though imo

[qazmlp]

There's some previous discussion about this: #1118

[h-2]

I think it wouldn't be good to create a situation where admins can do it aginst their users' wishes, potentially users who don't want to be bridged but haven't put #nobridge in their profiles because it's opt-in.

TBH, fediverse culture seems to be that you should just go to whatever instance where you like the rules, so I don't think this makes a difference one way or another.
Users can always block an instance individually. Or they can join another instance if they don't like the defaults on their instance. Some people did this when mastodon.social started federating with threads, but 99% of users couldn't care less.

Anybody can start their own Mastodon server and post the most terrible content. Federation with that server would still be opt-out (on instance basis or individual basis).
So there is no logical explanation for people being upset about bridgy being opt-out. The only difference is a different protocol/tech.

So I still think this should be pursued!

[qazmlp]

There's definitely a difference in baseline consent between ActivityPub and ATProto.

Both user-discovery and search-indexing of posts are mostly opt-in on AP, while they're effectively mandatory on ATProto.
From a purely technical point of view this isn't enforced in ActivityPub of course (since that's not technologically feasible), but ignoring these preferences is still a social boundary violation that regularly leads to services being widely defederated.

I think the most recent example in Newsflip, who implemented following of ActivityPub actors for their accounts without federating those profiles. They tried to get around not receiving content by default by mass-following from a service account, which got newsflip.com completely blocked on many large instances.
(The instance where my main account is suspended newsflip.com and limited newsflip.social to the point I can't see posts from there at all unless I follow the author.)

---

That said, it's very much true that baseline consent on individual instances can differ from the protocol at large, so the feature does make sense to me. Instance admins usually do have the tooling to poll their users and establish consent in matters like this, as well as to notify about policy changes ahead of time.

To avoid misunderstandings at the expense of Bridgy Fed, the bridged bio on other networks should clearly say that the account is bridged by default because the instance opted in though.

[snarfed]

Thanks for the discussion, all! And thanks @qazmlp for linking to #1118 . We don't really need to reopen the whole opt in vs opt out debate in general, but @h-2 you're definitely not the only person who wants this, a number of other fediverse instance admins have asked for it too.

Sounds like there's at least some rough agreement here, at least between you all: it's probably ok for instances to automatically opt their users into the bridge, if they warn people loudly beforehand, during signup, and if users can easily opt out.

As @h-2 mentioned, this feels similar to federation in general in the fediverse. Federation with other instances is usually open by default, and users and admins can both block/defederate specific instances if they want.

---

Concretely, here's how this would work, from #1118 (comment) :

One catch is that right now, at least the way fediverse software is generally designed, I'd still need to have the @bsky.brid.gy@bsky.brid.gy bot user follow each user on an auto-enabled instance like this, so that it delivers their posts to BF. So, they need some way to automatically have every new user follow the bot user, so that it will follow them back. It sounds like this is maybe possible in at least some software, eg Mastodon...

...but if that's necessary, and they do that, then there's nothing special I'd need to do on BF's end.

[snarfed]

@h-2 if you or any other Mastodon admin set this auto-following up, please let me know how it goes, I'd love to hear!

[qazmlp]

I'm pretty sure that wouldn't work as-is. Mastodon accounts start out without profile picture or bio, and they'd also not meet the account age requirement.

[snarfed]

Good points!

[snarfed]

When an instance is ready to try this, I can exempt them from the spam filter req'ts.

[h-2]

@h-2 if you or any other Mastodon admin set this auto-following up, please let me know how it goes, I'd love to hear!

I don't run my own instance, at least not at the moment. I am more interested in this from a user-perspective, i.e. I would try to convince the admins of the instances that I am on to activate such a feature.
The most important aspect from my POV is creating critical mass. Unless I can assume that most users on one network are able to interact with most users on the other network, it remains a niche feature. And tbh, repeatedly checking my mirrored profile page on BSky, checking if someone followed me there, then checking whether that person is not following me on Mastodon, then sending a message to that handle on the bridge to convince them to follow the bridge's handle on BSky... well it's just too much work to be viable in practice.

It's also, why I think the "follow the bridge account by default" is not bad, but it's also not what's going to bring about major change, since I don't imagine any instance retro-actively changing this for all their existing users.

For transparency: I recently opened this issue on the main Mastodon issue tracker, but have received only one (not very helpful) answer to date:
mastodon/mastodon#31771

[qazmlp]

For what it's worth, there's potentially still that "relay" method I mentioned to get specifically public posts in a lightweight way instance-wide, but that would definitely require quite a bit of setup on the Bridgy Fed side. That would be a nicely distinguishable self-service mechanism, too.

[snarfed]

@qazmlp yes! Do you know of any good technical docs on relays? What the protocol and format are, which activities are expected - ie is it just Creates for posts, or also Update/Delete, user profile Updates, etc? I've found lots of high level docs, and how to add them as a Mastodon admin, and projects, but nothing technical enough to build against.

[qazmlp]

@qazmlp yes! Do you know of any good technical docs on relays? What the protocol and format are, which activities are expected - ie is it just Creates for posts, or also Update/Delete, user profile Updates, etc? I've found lots of high level docs, and how to add them as a Mastodon admin, and projects, but nothing technical enough to build against.

I still can't find any official technical documentation unfortunately, but the gist is that relays are inboxes where you can Follow the …#Public collection: https://github.com/mastodon/mastodon/blob/592a7af27f7699d4751d2bea7785149d3c0e5d58/app/models/relay.rb#L48-L56
Only an authorised user (admin) can create this kind of Follow activity, so this should be enough for authentication.

The relay doesn't need to follow back, I think, (and possibly doesn't even need to be an actor!) though AodeRelay will do so if its relay/instance actor is followed directly: https://git.asonix.dog/asonix/relay/src/commit/a23b30cc91cad42a67c9c8d31ae76f946cca4969/src/jobs/apub/follow.rs

After the initial follow is Accepted, the instance will send public activity to that inbox. This could differ by software, but from Mastodon you will get at least Updates and Deletes for Public posts (along with Creates), as well as any Updates and Deletes for accounts:
https://github.com/mastodon/mastodon/blob/592a7af27f7699d4751d2bea7785149d3c0e5d58/app/models/relay.rb#L48-L56.
https://github.com/mastodon/mastodon/blob/592a7af27f7699d4751d2bea7785149d3c0e5d58/app/models/relay.rb#L48-L56

I'd suggest to just use your general inbox and handle everything as normal (i.e. with the usual filters), aside from a special case for that …#Public Follow and Undo-Follow.

At this point the relay could also start sending public activity to the follower, but for Bridgy Fed I definitely wouldn't do that for relay-follows outside hashtag- or Bluesky-feed-based opt-ins for example. (I do not know how relays handle authorization for those. I guess Mastodon may have an API that tells you who the admin is?)

Edit:

Misskey handles it the same I think, not requiring an actor. I didn't check for distribution there, but logically it should include user updates and deletes just like Mastodon (because those users are very likely to be known through the relay via relayed posts).

[snarfed]

The most important aspect from my POV is creating critical mass. Unless I can assume that most users on one network are able to interact with most users on the other network, it remains a niche feature.

Btw, I very much agree with this. I tried to make the same point, clumsily, here, before BF's Bluesky support launched:

If bridges were opt-in, and I could only follow 4% of people on other networks, they would be drastically less useful. I know I’d be much less likely to keep building and running them. My personal interests don’t justify anything, of course, but the utility of these bridges might. I hear regularly from a wide range of people that they love Bridgy and Bridgy Fed, that they connect them to other people in ways that they might not otherwise, and that they find real, deep value in those connections. That wouldn’t happen, for the most part, if they were opt-in.

[qazmlp]

Yeah, it's unfortunate that there's such a mismatch in expectations.

Arguably, if an ActivityPub user has all of

{
  "https://www.w3.org/ns/activitystreams#manuallyApprovesFollowers": false,
  "http://joinmastodon.org/ns#discoverable": true,
  "http://joinmastodon.org/ns#indexable": true
}

and Bluesky as a whole was opt-out (so that all followers are visible and can be blocked if necessary), then that could reasonably be interpreted as Bluesky/ATProto-compatible as long as the bridged profile requests to not be web-visible, but I'm sure there'd still be people who'd complain about it quite fiercely even then. (It'd also potentially behave a little weirdly still, as changing any of these would have to turn off bridging. At least that's theoretically not destructive in ATProto.)

(At least indexable is opt-in, not sure if discoverable is. indexable may be younger than Bridgy Fed, not sure.)

[h-2]

As a related, but minor point to improve the situation:
Currently my fedi profile is mirrored as-is into BSky, except that

[bridged from [warhammer.social/@heretic_han...](https://warhammer.social/@heretic_hannes) on the fediverse by [fed.brid.gy](https://fed.brid.gy/) ]

is added at the bottom. I would suggest changing this message to something that is more useful, e.g.

**To properly interact with this account, you need to also follow @ap.brid.gy.**
[More information here](link to documentation)

The core information that people need, is that they need to also follow the bridge. That's more important than a link to my original profile which most BSky users won't be able to interact with directly anyway.

If you feel like adding things to the profile steals too much of the available text, could maybe instead add a sticky post to the profile? That would give more room for a message a la:

LARGE WARNING IMAGE

**To properly interact with this account, you need to also follow @ap.brid.gy.**

This is account is mirrored from ....

More information about the bridge between BSky and Fedi is here ....

[qazmlp]

I strongly prefer the link to my profile, personally.

That said, there are a few issues that make what you propose tricky. For one, the profile bio length limit is low on Bluesky, so any added text cuts off more of the bio.

Second: Bluesky bios don't support pretty links. They are plaintext that's enhanced on the presentation side, not Markdown or HTML.

Third, Bluesky currently doesn't support pinned posts at all.
(It would be very nice if we could eventually pin a custom post specifically on Bluesky, though!)