Tag: Interoperability

The easiest platform to leave is the one that does not own the entire network.

ActivityPub is built around that idea.

The W3C describes ActivityPub as a decentralized social-networking protocol with both client-to-server and federated server-to-server APIs. In plain English: different services can run different software on different servers and still exchange social activity with one another.

See the W3C ActivityPub Recommendation.

A provider can be replaced without replacing everybody

Mastodon is one widely used ActivityPub implementation.

A Mastodon user belongs to a particular server, but can follow and interact with compatible accounts on other servers. The server operator controls the local account and local moderation. The wider social graph crosses provider boundaries.

That changes the cost of leaving.

Mastodon’s migration tools allow a user to create an account on another server and initiate a move. Compatible software can transfer followers to the new identity. Following lists, blocks, mutes, and other lists can also be exported and imported.

See Mastodon’s account migration documentation.

The person still changes providers.

The entire network does not have to change providers with them.

That is a very different failure mode from a closed social platform where leaving the operator means leaving everybody who remains inside it.

Open does not mean frictionless

The protocol does not magically make every dependency portable.

Mastodon currently does not import a user’s old posts or media into the new account. Followers can move, but followed accounts must be imported separately. Some relationships may require new approval. A server administrator still controls the machine hosting the account and can establish local rules or shut the server down.

Different ActivityPub implementations also support different features.

Interoperability reduces dependence. It does not erase it.

Protocols change where the leverage sits

Email provides the older version of the same lesson. Gmail does not need to own Outlook for a Gmail user to send an Outlook user a message because the network is built around shared protocols.

ActivityPub applies that structure to social networking.

The practical value is not philosophical purity.

It is bargaining power.

If one provider becomes expensive, poorly moderated, unstable, or simply annoying, users have at least some path to another provider without demanding a synchronized migration from the whole community.

A protocol cannot guarantee a good service.

It can make one bad service less synonymous with the network itself.

Google Talk did something that now feels almost exotic: it let people on other compatible messaging systems talk directly to Google users.

The service used XMPP, an open messaging standard. Google’s own developer documentation described Google Talk as fully interoperable with other services supporting server-to-server XMPP federation.

https://support.google.com/code/answer/56278

That meant the network boundary was softer than the company boundary.

Federation did not require Google’s permission

Google’s documentation said outside service providers did not need special approval to federate with Google Talk. If their servers supported the XMPP standard, their users could communicate with Google Talk users and vice versa.

https://support.google.com/code/answer/55704

Another Google help page listed Earthlink, Gizmo Project, universities, corporations and individual XMPP servers among the kinds of systems that could participate.

https://support.google.com/code/answer/55703

That is genuine interoperability. A person could choose a different provider or client without necessarily abandoning everyone on Google Talk.

Then the product direction changed.

Hangouts replaced Talk without XMPP federation

In May 2013, Google announced Hangouts as the replacement for Google Talk. Google’s old developer documentation now carries the same blunt notice on multiple pages:

Hangouts does not support XMPP.

https://support.google.com/code/answer/55693

The messaging service still worked. Google users could still talk to Google users. What disappeared was the open bridge that had allowed independently operated XMPP systems to participate in the same conversation network.

That is a different kind of product change from removing a button.

A button can be relearned.

A protocol boundary decides who can connect at all.

Adoption makes lost interoperability expensive

Once enough contacts, organizations and conversations accumulate inside one provider, losing federation creates a practical choice for outside users: move closer to the dominant service or accept reduced reach.

Google had legitimate product reasons to build Hangouts differently. Messaging had expanded beyond simple text and presence into richer media, mobile synchronization and tightly integrated Google services. Open standards can also constrain how quickly proprietary features evolve.

But that tradeoff belongs in the record.

The original system advertised openness as a feature. The replacement system kept the audience while dropping the protocol that made cross-provider communication possible.

Interoperability is most valuable before a platform wins.

It is also easiest to remove after everyone has already arrived.