Here's a sentence for you:

Bounce is a new cross-protocol social graph migration tool that uses a protocol bridging service to create an mirror account on the sending protocol, which simulates the effect of sending your social graph across protocols.

If you understand everything that's going on here, congratulations on also having open-social-web-brainworms.

I'm gonna go out on a limb here and assume that this is not everyone though.

The Bounce service launched in beta today, and I think there are multiple stories going on at the same time:

• What the hell is cross-protocol account migration, and how does it work

• The impact on 'credible exit', and how moving to a different protocol impacts this

• the shaping of language, and building towards a shared understanding of what 'protocol bridging' even is.

For an explanation of what this is, Sarah Perez at TechCrunch as a good article which makes explains it as follows:

To move accounts, Bounce first moves a user’s Bluesky account to a bridged account that straddles the two networks, then to the user’s Mastodon account. 

A New Social explains Bounce in more detail here:

An important feature with accounts on the open social web is that, as long as they're using the same protocol, you can technically "move" your account from one platform to another. For instance, since they both run on ActivityPub, if I have an account on mastodon.social, I can "move" my social graph from there to flipboard.social, if that's where I want to post from now on. That move maintains all of my relationships and allows me to continue posting without having to re-find my friends. You can do the same thing between ATProtocol-based platforms, such as Bluesky.

We're using that same functionality to "move" your accounts over Bridgy Fed. We take your Bluesky account and "move" it to your Mastodon profile's bridged account, and take your Bluesky profile's bridged account and "move" it into your Mastodon profile.

Credible Exit

Bluesky advertises itself with the idea of 'credible exit', the idea that you can meaningfully leave the service and take your social graph and data with you. Bluesky has mainly meant that in the context of ATProto:

• you can transfer your account to another data storage provider

• you can use other client/app on ATProto that is not the Bluesky app, if you disagree with Bluesky's ToS for example.

Bounce adds an additional layer to this all:

• you can now transfer your account to another protocol altogether.

In this way, the ability to use Bounce to migrate your social graph from Bluesky to Mastodon actually is a benefit to Bluesky: it further cements their claim of providing a credible exit. This lowers the barriers for people who are unsure about trying out Bluesky, there is now a way back.

Language and definitions

One challenge for Bounce, as well as Bridgy Fed, is the lack of shared references to help explain what this all actually is. Understanding why bridging software like Bridgy Fed matters, requires knowledge of how the open social web protocols work.

It creates new kinds of artefacts, such as 'mirrored' accounts on the bridge, which are a new concept that people are largely not familiar with. Furthermore, this type of account does not even have a good name to define what it actually is.

• When you have an account on either the fediverse or atproto, and want to interact with people from the other network, you can do this with a bridging service like Bridgy Fed. When you do this, people often describe this as having a bridged account.

• Services like Bridgy Fed (and Bounce) work by creating an additional account on the Bridgy Fed platform, that passes messages between the networks. When people on the other network want to follow your account, they do not actually follow your account natively: they follow this additional account on the Bridgy Fed service.

• It is unclear what this additional account is actually called. TechCrunch also calls this 'a bridged account', but there is no clearly defined term for it. The A New Social Team prefers not to use 'bridged account' here (due to that term already used for the other meaning), but there is no clear alternative. Mirror account maybe?

• Without clear definitions and names, it becomes even harder to explain a process that is already hard enough to explain what it is. I'm not sure if people who would be interested in using a tool like Bounce understand that this means that this depends on another 'mirror' account that is operated by another organisation. Clearer naming might help here.

Recently I wrote about how decentralised networks lead to fragmentation and decentralisation in the underlying protocols that power them. People might see bridging as a temporary solution to a problem caused by developers with a Not Invented Here Syndrome. Instead, I see this fragmentation and protocols that are only partially compatible with each other as a logical result of giving people freedom to build and hack whatever they want. Sure, it leads to interoperability issues and it can be annoying, but it is also an unavoidable result from the social dynamics that are part of truly open networks.

That means that bridging services and other software that focuses on making incompatible software compatible with each other will be part of the open social web for a while longer. And that means that there is also a lot of work to be done regarding language and explanations of what these tools actually do, and how they impact regular users.