💾 Archived View for idiomdrottning.org › ap-at-bridge captured on 2024-03-21 at 15:23:22. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-12-28)

-=-=-=-=-=-=-

Decentralizing the AP-AT bridge?

There’s a project bridging ActivityPub and AT proto that’s pretty far along.

But it’s set up to be a single, central bridge. On the AP side, it looks like one ginormous AP server that has all AT accounts. And vice versa on on the AT side, like one big AT server that has all the AP accounts in the world. (Not sure how that's gonna work with moderation and instance-blocking.)

Not to come across as too entitled around a project that’s already incredibly ambitious, but I was a li’l disappointed in that. We already have problems with big servers like mastodon.social and threads.net. I guess what I was hoping for was more a service you could run on your instance to AT-ify it.

The centralization does solve a huge problem.

Let’s say there were two competing instances of the bridge, one called bridge.taran and the other called bridge.eilonwy.

Let’s say there’s some celebrity on AT called Liza Radley that everyone loves. She is liza.radley.some.at.url.example. Because of the two competing bridges, she’d be in two places at once on the AP side, both at @liza.radley.some.at.url.example@bridge.taran and @liza.radley.some.at.url.example@bridge.eilonwy.

That’s not good, hackers, that’s not good.

Not just the duplicates themselves, but how it leads to the “two mirrors facing each other” effect where bridge.taran would think that @liza.radley.some.at.url.example@bridge.eilonwy is a real AP account and try to bring it into AT, and then bridge.eilonwy would think that liza.radley.some.at.url.example.bridge.taran is a real AT account and bring that copy back to AP as liza.radley.some.at.url.example.bridge.taran@bridge.eilonwy and so on endlessly.

Can we solve this somehow?

I mean, if changing either or both of the two protocols were on the table, it’d be pretty easy. Just as you don’t need to write out the instance name half of accounts on your own instance, because the protocol treats “local accounts” separately, it could just as easily treat “AT accounts” separately, without having to tie each of them mention to a specific bridge.

Or if through some FEP or another, AT bridges could be made recognizable on AP so that users of bridge.eilonwy could see the @liza.radley.some.at.url.example@bridge.taran, recognize (through I dunno webfinger or something, I don't understand this stuff technically) that bridge.taran is a bridge, and see that AT accounts from it are already bridged, and also to make a good-faith decision on whether to use refer to the other bridge’s version of that account or to make their own bridge of that AT user’s AT presence.

Bridgy Fed

Bridgy Fed status update | snarfed.org

Chat logs on Indieweb

Bi-protocol instances

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

After sending the above to FEP peeps more level-headed than myself, I thought of another approach. There could be “bi-protocol instances” where what you write pops up on both protocols, with mentions of other accounts on both protocols working, and boosts of stuff staying on the side of its own protocol, so AP people wouldn’t have to worry about getting boosted into AT space. And maybe the same could go for threads and any posts with mentions, they’d stay on the appropriate side.

This could even be implemented client-side, in a bi-protocol client that you could hook up to an AP account and AT account; your posts on your main timeline would go to both places, while replies would stay on the side of whomever you’re replying to.

A wonderful FEP

The FEP peeps pointed out that FEP-fffd is what I’m looking for:

fep/fep/fffd/fep-fffd.md at main - fediverse/fep - Codeberg.org