ActivityPub: new bridgeable flag

[snarfed]

We'd like to propose a new boolean bridgeable property on AP actors and other objects that can be used to explicitly express consent, or lack thereof, to being bridged. This would be generic, for any bridge, not specific to Bridgy Fed. It's similar to the existing discoverable and indexable properties, which are relatively widely supported.

I'm currently writing this up as FEP-0036 and seeing if I can drum up support among implementers. Ideally, fediverse servers would add a "bridgeable" toggle to their user settings UIs, like many already have for discoverable and indexable.

[snarfed]

Draft FEP here: https://codeberg.org/snarfed/fep/src/commit/fep-0036/fep/0036/fep-0036.md

cc @anujahooja

[jonpincus]

It's certainly worth thinking about how to provide better support for this so thanks for taking the FEP by the horns and working on this! My first reaction is that it needs to be more flexible in a couple of ways:

• more than a boolean. I want to specify "no bridges at all", "no to opt-out bridges but opt-in bridges can ask for my consent", and "bridges are okay"

• scopable to specific bridges and/or targets. I need to be able to express that I am okay with Bridgy Fed (even though I'm not okay with Mostr, or really any bridges to Nostr or Threads).

[Tamschi]

Expanding on it, here's the case for including bridge-specific (base) rules in a generic property, rather than (entirely) relying on bridge-specific properties for that: It would allow non-admin users to specify this in a reasonably easy way without concerns about safety issues or future collisions.

Personally, I think it would be a good idea to use domains (or anything with a . in it) to specify specific bridges, hierarchically.
Someone may disallow brid.gy but allow bsky.brid.gy for example.

I'm not sure if domains should be used to specify targets, but personally I would tend to say "no", since networks like Nostr and ATProto don't rely on a specific domain for coordination (though Bluesky-the-lexicon uses the bsky.app and bsky.chat domains as namespaces at least). Even in cases where a target has an official bridge on the same domain, someone may want to use inofficial bridges only. This is probably something that has to be established by usage to an extent.

In terms of precedence, it may make sense to use explicit set intersections instead of specificity here. For example, an account may, more or less sensible, specify all of the following:

• Deny all Bluesky-target bridges (i.e. targeting the app.bsky ATProto lexicon namespace):
  • Deny Bluesky
• Deny all of Bridgy Fed but allow interactions with blogs through non-"Fed" Bridgy:
  • Deny brid.gy
  • Allow web.brid.gy
• As an exception:
  • Allow (Bluesky AND brid.gy) and/or
  • Allow (Bluesky AND bsky.brid.gy)

My reasoning is that, this way, other bridges can use this information to query brid.gy or bsky.brid.gy via WebFinger (with the @id of the bridged object) for the remote ID of objects they want to reference, like for example a parent post's at:// URI when bridging to ATProto. (The Bridge SHOULD NOT respond with a remote ID if the object is not at least passively present on the remote network.)

Specifying this here may be a bit out of scope, but I think WebFinger is a great solution for querying remote IDs since the response can proactively include all managed remote locations cleanly. In my eyes, such a mechanism is necessary to efficiently support bridging of conversations where some accounts allow only one bridge and others only another.

[jonpincus]

Also, what about visibility scopes? A couple of options here:

• the spec could apply that the actor's default bridgeable only applies to public posts (so individual unlisted or even followers-only posts could still have a bridgeable attribute)
• the spec could allow specifications for different policies at different scopes, for example allowing bridging of public posts but not unlisted.

Something that maybe wasn't as clear as it should have been in my previous post: the current proposal of a single boolean attribute means Bridgy Fed can only be used by people who consent in advance to any future bridge Alex Gleason, Meta or anybody else implements. Is that the positioning you want for Bridgy Fed? And, what impact would you expect that to have on Bridgy Fed adoption by trans and non-binary people?

[ygg2]

On allowing and disallowing specific bridges, it feels like it might go hand-in-hand with the discussion about picking what lexicons to bridge to (#1178).

I think another reason to not have "any bridge can bridge me" is ending up with duplicates of an account, but that's also a bit of a larger issue especially with the potential of double-bridging.

[tesaguri]

• scopable to specific bridges and/or targets. I need to be able to express that I am okay with Bridgy Fed (even though I'm not okay with Mostr, or really any bridges to Nostr or Threads).

I agree on the desire for a scoping mechanism because I don't think many users want there to exist multiple bridge accounts by different providers at the same time. But, assuming that many users end up scoping their consent to specific set of bridge providers, I suspect the proposed property wouldn't offer much advantage over the existing provider-specific opt-in flows, so I think it's worth reconsidering the user story.

[snarfed]

Thanks for the discussion, all! Really useful feedback here. I definitely understand, and agree, that users often need and deserve more control over bridging than just all or nothing!

As with all FEPs, one big challenge here is that we need to evangelize and drive adoption and implementation across a wide range of platforms, servers, client apps, etc. Realistically, I can't go do all or even most of that myself, even as PRs. Given that, the more work I ask other developers to do here, the less likely it is that they'll do it, whether in part or whole.

I expect the work here will be iterative. We could start with a boolean flag, and later expand it over time, once developers have implemented it and seen value from it. Also, as mentioned here, the underlying flag doesn't solely determine end user UX or control. Beyond domain blocking, users could turn off bridgeable and then still explicitly opt into eg Bridgy Fed. That's one way to do "allowlist" bridging on a per-bridge basis. Not ideal UX, but it's a start.

Finally, I see discoverable and indexable as pretty strong precedent here. I expect many users might want more controls for those too, eg yes, show my profile in directories, but only these ones; yes, index my original posts in search, but not my replies. Even so, right now those settings are usually just on or off, or at least the underlying AP flags are, and they still seem broadly useful and net positive so far.

(Also @ygg2 you're absolutely right about the duplicate bridging problem! That's #800.)

[ygg2]

That's an interesting idea about having bridgeable off but overriding for a specific bridge - if I understand right, since a bridgeable post should only be bridged if the actor is bridgeable as well, I would still be able to specify which posts I want bridged without other bridges picking them up.