Help, please make a FEP to help competing bridges sort things out

[Sandra]

Hi there are some problems if there are multiple bridges running on the same ActivityPub network, can you please help sort this out?

[nightpool]

Unfortunately, there’s no easy way to do this on either side because accounts need to be authenticated.

that is, what the AP account “some.at.account@bridge.example” means, semantically, is “what bridge.example tells you some.at.account says”. because either bridge could lie, the host/bridge specifier is required.

[hamishcampbell]

Bridging protocols is a way of mediating the #geekproblem here is a thread on this thinking Lets talk about the protocol wars

@hamishcampbell

As a way out of this, I have been pushing bridges for a while as they are the lowest common denominator and can be built and implemented “permissionless” to allow people to cross #4opens protocols. “Permissionless” is important as the is no way you would get consensus to do this, without adding much more mess. Technically people codeing the protocols are bussey with tribalism to focus on cross protocol interop… or they would not be building a new protocol

Interesting issue you bring up with the confusern this might bring when people don’t cooperate (and yes they don’t) when people run 2 bridges and bridge twice

Pragmatically, instances can mediate this by blocking bridge instances that dont “cooperate” and host duplicates - would be nice to have some social mod/admin coding for this.

[silverpill]

Ideally, people should just stop inventing new protocols for no reason and use ActivityPub, which is a web standard.
Bridges are temporary workarounds, and I personally see no problem in having one centralized bridge. I also don’t think that duplicate accounts are a major issue, but some implementers may adopt FEP-fffd: Proxy Objects that describes how bridged content could be de-duplicated.

[Sandra]

Ideally, people should just stop inventing new protocols for no reason and use ActivityPub, which is a web standard.

Preaching to the choir there. If AT-bashing is gonna be the topic, someone’s gonna have to hold my beer because I hate AT and can rant for hours on how bad it is.

Bridges are temporary workarounds,

Some bridges have proven to be long-lasting, like webmail services (bringing SMTP to HTTP).

and I personally see no problem in having one centralized bridge

Not only does it have all the other problems of huge instances (AT proto has millions of uses), there are some other issues unique to bridging. If it becomes “the only” way for the protocols to talk to each other, like a needle’s eye on the federation, that’s not great.

I also don’t think that duplicate accounts are a major issue

It can cause infinite loops as I wrote in the OP.

[Sandra]

But something like FEP-fffd was exactly what I was looking for.

[snarfed]

Hi all! I’ve been thinking about this more recently.

FEP-fffd is great! It hasn’t seen much adoption afaik, and I worry about its impacts on interop with existing servers, but I do still plan to implement it in Bridgy Fed.

The specific use case I’m thinking about is, when bridge A sees an actor for the first time, is there a way for it determine whether that actor is already using (and prefers) a different bridge B, and therefore bridge A should ignore it and not bridge it?

Say bridge A translates between AP and ATProto. FEP-fffd says that ATProto is a well-known alternative protocol that’s identified by the did:... URI scheme. If I understand right, bridge A would fetch the actor, see if it has a rel=alternate or rel=canonical link pointing to a did:, and if it does, bridge A would ignore it.

(mediaType and URI schemes aren’t a great way to identify other protocols - eg did: and https: URIs are used by more than one protocol - but that’s a separate concern, and probably manageable. It’s also better than depending on each bridge to hard-code other bridges’s domains or other identities, detect those in links, and constantly keep those lists updated.)

The part I wonder about is beyond ActivityPub. FEP-fffd is great for AP actors, but bridges also need to look at users in other protocols to determine whether to bridge them. You could look at their corresponding AP actor, but you’d need to find it first. I’ve taken one stab at mapping ids and handles between protocols, but there’s obviously no standard, so you don’t necessarily know where to look.

Maybe more importantly, bridges bridge a number of different protocols. I’d love a way to do this across protocols, so that eg an ATProto <=> Nostr bridge could de-dupe bridged accounts and satisfy this same use case.

Many other protocols do have precedent for this, just like FEP-fffd. Web sites have rel=me links. Nostr has NIP-39. They don’t usually have a way to explicit tag an identity as a bridge, but they generally do have URI scheme or MIME type.

Should we use each of those individually? Should we look at user-provided profile links and detect bridged accounts that way? Are there other alternatives I’m missing?