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 @[email protected] 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!)

[Tamschi]

I'll reply to #1471 (comment) here since I think this post would be off-topic in #1471.

---

[…] (and we are at 275M monthly users anyways).

We should definitely look into letting instances provide ATProto handles for their users by default alongside this feature here.

@pcottle In case you're not aware, one of the hard caps Bridgy Fed has with its current infrastructure is how many ATProto handles it can provide at once (#744). As of a few days ago, that was at 28k/50k used, and while increasing it doesn't seem to be too much of a problem right now, I think it's likely you'd exceed that very quickly if you enabled the bridge by default for everyone who has federation enabled.

I'm sure you'd also prefer your users to have @….threads.net handles rather than appearing as @….threads.net.ap.brid.gy handles on Bluesky.

@snarfed I think we can assume that the account that performs the instance opt-in is also authorised to configure handle defaults for the domain via DM in some way, but Bridgy Fed would also need a way to inform an instance of the relevant @id/DID/handle mapping changes whenever one occurs so that they can update their DNS and/or .well-known setup accordingly.

I'll sketch two options that are relatively on-protocol, if that's okay:

We could DM them to the service account as plaintext separately, but I think a much better solution would be to attach that information as extra properties to the Create-Note (DM) or Accept-(/Undo-Accept-?)Follow activities we send towards the users on those occasions. (Even if Threads doesn't support AP DMs properly, they could still easily handle those statuses internally.)

Alternatively, we could send separate activities to users just for DID-and-handle updates, which to me seems the cleanest overall but would require most original semantics.

The off-protocol option would probably be some kind of webhook call, but that seems like it would require additional interactive setup.

[pcottle]

I got a mini brief on the 28k/50k handle issue, but I figured we only take up those slots as either people opt-in (in the case of opt-in) or people get followed/followed by in the case of opt-out (which would be a much smaller number).

But you're right, if a lot of the tech threads folks start jumping onto the bluesky bridge experience, we might hit that limit.

What are the steps for serving AT handle resolution on our domain but not having to host an entire AT frontend? Especially if its just the steps associated with DID:
https://www.w3.org/TR/did-core/

it would be easy for us to defend that work

[Tamschi]

Bluesky users can't natively look up a remote account that's not present on their network already, unfortunately.

In theory it would be possible to integrate it into the existing request flow though, i.e. when someone requests a user on an opt-out instance (via Chat message to @ap.brid.gy), it would announce the account to ATProto only then and reply that the account is now bridged due to the instance opt-in. I think that would be strange behaviour for smaller instances, but it could make sense for Threads.

Bridgy Fed uses did:plc:… rather than did:web:… in order to properly support migrations (#1137), and it takes care of the DID management for bridge accounts automatically.

On your end, you'd only have to set up DNS or serve the did:plc:… string as text/plain at https://${handle}/.well-known/atproto-did for each account so that AppViews can validate the handles. (See near the end of How to set your domain as your handle - Bluesky)
Bluesky checks these endpoints regularly and displays "⚠️Invalid Handle" instead of the @… if both fail.

[snarfed]

Thank you @Tamschi! @pcottle, @Tamschi knows the current Bridgy Fed architecture well, all the info here so far is spot on.

Bluesky users can't natively look up a remote account that's not present on their network already, unfortunately.

This is the key open question for instance-level opt-in right now. In the fediverse, user discovery is pull-based. When you search for someone's handle, your instance/client queries their webfinger and fetches their actor on demand. On Bluesky, though, we'd have to create a Threads user's bridged Bluesky account and profile ahead of time to make it visible.

We could do that! And even start bridging their posts immediately too. That's the most aggressive form of default-on bridging, which would generate the most load, and pressure on DNS capacity (#774), and also probably worry the most people from a privacy perspective.

The less aggressive approach, as @Tamschi mentioned, would be to bridge a Threads user only on demand, when a Bluesky user requests them. Safer and more conservative, not as good for discoverability.

I'm open to both. The first (proactive) way would be a huge increase in load, though, at least assuming we start bridging posts proactively too, so I probably wouldn't do it until we have an org and (probably) funding in place.

[pcottle]

I know discoverability is worse for the on-demand model but I think that's the right downside to choose. In my mind the networks would start to merge like so:

• bridge is on, Threads is opt-out, Bluesky is either opt-in or opt-out
• the bridged Bluesky users start getting follows from Threads users organically once thats available
• A follow to any bridged account means we make the Threads account on-demand (so the engaged and tech-centric threads profiles start getting created, aka the people who would benefit from the bridge)
• Through normal account discovery (media recs, reposts, mentions and replies, etc), those Threads users get follows back from Bluesky (at least from bridged users, ideally from everyone on bluesky).
• Chill vibes as people can now discuss!

Does that make sense? If threads serves our own DIDs, does that resolve the DNS capacity concerns?

[Tamschi]

I think it makes sense for Bridgy Fed to first automatically push an opt-out-instance's ActivityPub user to ATProto when they Follow a Bluesky user, if needed. We'd want that to avoid #1102.

The DID documents themselves should be served by Bridgy Fed, in my eyes. That saves quite a lot of special-casing on our end.
If you serve just the handle verifications for your users, that alone avoids any issues with DNS capacity on our end.

What's the regex for Threads usernames? ATProto are only a subset of DNS-compatible hostnames: #982
If your usernames don't contain ., then I think you can use a single wildcard DNS entry and wildcard cert pair and only hit your database in the GET /.well-known/atproto-did handler.

I think both active notifications and a Bridgy Fed API to look up the DID for a bridge handle are feasible. The latter has the advantage that it avoids timing issues ("⚠️Invalid Handle") and doesn't need explicit recovery, but it would still be good to cache it for a bit. (It's really too little data to use an ETag or such, but we can send Cache-Control: public, max-age=…, stale-while-revalidate=… if that expires before a Threads handle can be reused by someone else. Even if not, the worst failure case would be seeing "⚠️Invalid Handle" temporarily on the new account reusing the name. We could of course also include the ActivityPub @id in the response for you to cross-reference.)

There are a few general edge cases we'd need to decide on, also involving interactions with other instances:

• If Bridgy Fed receives a bridged mention of a not-yet-bridged opt-out user, should that first bridge that user?

  This is probably fairly easy to do either way around since pushing users to AT is idempotent, but not bridging them is affected by AP=>AT: link @-mention to fediverse profile if mentioned user hasn't enabled the bridge #1163.

• What do we do for opted-in Public replies to opt-out users' posts?

  With the current architecture, it's definitely easier not to bridge either post, as-is. I think that bridging earlier posts lazily could also result in a confusing sparse and non-chronological timeline on their Bluesky profile, since the site rarely actually orders by post date.

  (Natively on ActivityPub, seeing a reply usually pulls in the conversation up to its root step-by-step, but it's difficult to do this in ATProto since each post in a conversation has to mention the root's record key directly.)

[pcottle]

What's the regex for Threads usernames?

its

(?P<username>[a-zA-Z0-9_]+(?:\\.[a-zA-Z0-9_]+)*)

so we definitely allow periods :)

I'm also fine serving just the handle verifications, whatever avoids the DNS issues!

[Tamschi]

I assume you have the infrastructure to run a custom DNS server 😅

I think it's easiest if you serve _atproto.<handle>.threads.net TXT records dynamically then, but the principle is the same as for .well-known. You'd ideally first check if the user exists on your end, then with Bridgy Fed to get the DID string.

For reference, here is the ATProto handle regex from https://atproto.com/specs/handle#handle-identifier-syntax:

/^([a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?$/

Underscores are replaced with - by Bridgy Fed already, so there's no issue with those since you don't allow dashes or tildes.
That said, leading or trailing underscores and those adjacent to a . are currently not supported.

[pcottle]

Serving the .well-known might be easier for internal execution at Meta (given the systems involved) -- its possible to take that approach still right?

[Tamschi]

Yes, I think so, but with some caveats.

In theory you may be able to use a wildcard entry for the entire DNS zone, but a cursory check tells me that could get a bit implementation-defined on the receiving end.
It seems for wildcard TLS certificates to be fully compliant, you'll have to use a separate one for each level of nesting (but e.g. *.*.threads.net or *.*.*.threads.net should each work everywhere, as long as each is the only entry in the respective certificate. Some browsers at least seem to be a bit more lenient, too, though).
Edit: I think I either misread or found an unreliable first result earlier. From what I can tell, only the leftmost part, i.e. before the first ., is allowed to be * after all.

Which approach you take doesn't make a difference for Bridgy Fed and Bluesky always tries the other if one method fails, I think.

[michael-patchwork]

Thank you @Tamschi! @pcottle, @Tamschi knows the current Bridgy Fed architecture well, all the info here so far is spot on.

Bluesky users can't natively look up a remote account that's not present on their network already, unfortunately.

This is the key open question for instance-level opt-in right now. In the fediverse, user discovery is pull-based. When you search for someone's handle, your instance/client queries their webfinger and fetches their actor on demand. On Bluesky, though, we'd have to create a Threads user's bridged Bluesky account and profile ahead of time to make it visible.

We could do that! And even start bridging their posts immediately too. That's the most aggressive form of default-on bridging, which would generate the most load, and pressure on DNS capacity (#774), and also probably worry the most people from a privacy perspective.

The less aggressive approach, as @Tamschi mentioned, would be to bridge a Threads user only on demand, when a Bluesky user requests them. Safer and more conservative, not as good for discoverability.

I'm open to both. The first (proactive) way would be a huge increase in load, though, at least assuming we start bridging posts proactively too, so I probably wouldn't do it until we have an org and (probably) funding in place.

I can see that for Threads on demand is the way to go but for other Fediverse instances it would be good to offer the proactive approach, combined with a default mechanism for the instance to give users their own ATProto handles as @Tamschi suggests - the two go together. We have something about to go live which I'll message about

[Tamschi]

@pcottle Regarding #1305 (comment):

I looked into what's allowed in TLS certificates a bit more and *.*.… is definitely not allowed unless the rules changed recently. You could still do this if you have your own certificate authority to issue certificates dynamically (or equivalent), but otherwise it would be very difficult to go the .well-known-route while you have . in handles.

More details at https://security.stackexchange.com/a/39429, it seems it was originally allowed but then changed in the specification because in practice most vendors only allowed leftmost wildcards.

Sorry for the earlier confusion.

[pcottle]

I think converting .'s to some other character isnt the worst compromise. We just need to find an alternate (maybe -) that doesnt conflict with existing usernames :)

[snarfed]

Hah yes, we went through this whole arc ourselves, #830

In the end, we couldn't quite get there because we needed to at least try to support all of the different fediverse software out there, but the problem space is obviously more manageable for you all with just a single, centrally managed platform. Looking forward to seeing where you end up on this 😁

[Tamschi]

Bridgy Fed maps _ to - since the former isn't allowed either, so that does conflict, unfortunately.
. and - are also the only characters outside alphanumeric Basic Latin that are valid in ATProto handles.

[pcottle]

Well for threads we dont allow - in usernames at all, so mapping pcottle.influencer to pcottle-influencer is fine since no threads user can exist with the pcottle-influencer name right?

Just trying to confirm that threads is unblocked, even if the wider issue isnt quite resolved :)

[Tamschi]

The problem occurs if you have both pcottle.influencer and pcottle_influencer.
If you already deny that as confusable then it's all good, though.

(We'd also need some way to make the mapping configurable per instance, maybe.
I think we'd want to keep the .s for Bridgy Fed's own translations at least, and give others the option to.)

[snarfed]

We're only talking about Bluesky handles here, specifically custom domain handles that Threads might set for its users, right? Not AP actor ids or preferredUsername or anything else? If so then this seems fine, Threads can do whatever they want...? Custom Bluesky domain handles are opaque to BF, it doesn't translate to or from them or do anything else with them.

[pcottle]

Yep I'm just trying to make sure we can map all usernames over to valid subdomains, without ambiguity or collisions. Ideally without using . since thatll be easier to implement.

But this is all unrelated to the topic here (instance opt-in) so Ill take this convo elsewhere :P

[Tamschi]

We're only talking about Bluesky handles here, specifically custom domain handles that Threads might set for its users, right? Not AP actor ids or preferredUsername or anything else? If so then this seems fine, Threads can do whatever they want...? Custom Bluesky domain handles are opaque to BF, it doesn't translate to or from them or do anything else with them.

Doesn't Bridgy Fed fail to bridge if it can't assign an initial username by itself or if there's a collision with it?

[snarfed]

Doesn't Bridgy Fed fail to bridge if it can't assign an initial username by itself or if there's a collision with it?

Yes, but if @pcottle is only talking about how Threads would generate Bluesky custom domain handles, that should be unrelated.

[praichor]

Unfortunately, opt-in ultimately makes the bridge unusable in practice. As a Mastodon user, I cannot persuade everyone I want to follow on Bluesky to turn on the bridge. In particular, it is impossible to get the attention of celebitry users.

The service is only really useful with opt-out.

And how cool is this bridge!

I also cannot understand the arguments against opt-out: On both sides of the bridge, the basic idea of ​​federation is that the data can be accessed by any other server in the federation, not just current but also future ones. In other words, the data is completely public anyway. You agree to this as soon as you register with a federating social network.

Theoretical question: Would you disapprove, would there a reason against it or would there be anything stopping me from simply hosting a modified opt-out branch of bridgy-fed with a new domain myself? Whoever on Mastodon has something against it can then simply block the domain I use.

[Fauli1221]

@praichor this might be the ticket for you #1471

[praichor]

@praichor this might be the ticket for you #1471

Oh yes, this was the wrong ticket. I'll repost in the correct place.

[S0yKaf]

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

Hey, I'm pretty interested in this feature. Would it be possible to exempt masto.canadiancivil.com from the filter?
Currently looking into my options in terms of auto adding new users to bridgy-fed.

also, did mastodon remove the auto-follow feature? I know you can use the cli to make accounts follow someone but I can't find the option in the dashboard?

Anyways, seeing as its probably not desirable to bridge a user before they have profile pic I might setup some webhook to wait for that before initiating the bridge.

The 2 week old requirement is also going to have to be removed if the mechanism ends up being officially supported.
I'd argue this probably does more harm then good already. It's not ideal to have a new fediverse user have to wait 2 weeks to have the privilege of interacting with bluesky via bridgy.

Alternatively the relay options that was mentioned earlier seems pretty promising as a way to "activate" the instance opt-in. But just a traditional API could do the trick also.

I'll report back as I get further into my implementation.

[snarfed]

@S0yKaf love it! (We've been talking more in #1537 (comment).)

One catch is that Bridgy Fed doesn't yet support split-domain setups like masto.canadiancivil.com, ie where the server's hostname is different than the webfinger domain in users' handles. Sorry! That's #1031.

[S0yKaf]

@snarfed Could you lift the spam filter for masto.canadiancivil.com ? I'm ready to start testing my auto-follower implementation.

One catch is that Bridgy Fed doesn't yet support split-domain setups like masto.canadiancivil.com

What isn't supported exactly? because it seems to work just fine on masto.canadiancivil.com . I did notice that it bridged users using the full instance name instead of the webfinger, but besides that everything seemed to be working properly?

Is the whitelist something that wouldn't work because of the split domain?

Once its tested and working properly I'll most likely release this as a sidecar you can run along your mastodon instance. So it should be pretty painless for anyone who wants to "activate" instance opt-in.

ps: I really think the 2 weeks requirement isn't helpful since it can be easily spoofed
ps ps: but I also understand it stops potential spam coming from poorly moderated instances

[snarfed]

@S0yKaf awesome! I haven't implemented a per-instance bypass for the spam filter, but I can eventually. Until then, feel free to test with existing accounts on your instance that are older than two weeks.

Re split domain support, you're right, the main missing piece is just that it currently uses your instance's hostname in bridged handles, user pages, etc instead of the webfinger domain. Details in #1031. (And split domain support should be unrelated to spam filtering, per-instance bypass there, etc.)