Protect open platforms

This is a text automatically translated from Italian. If you appreciate our work and if you like reading it in your language, consider a donation to allow us to continue doing it and improving it.

Given the enormous success (really, it was greatly appreciated and we are very happy about it) of the article WhatsApp and the domestication of users, we decided to translate the second part of that article. The original articles were originally written by Rohan Kumar, fortunately in Creative Commons license. Thanks to this license, in fact, it was possible for us to translate them freely without running into copyright problems. You asked us for the translation of the second part of the article, also in Creative Commons. So that's what we'll leave you with right away Keeping platforms open, which we wanted to translate into Protect open platforms.

This is where the article originally written by begins Rohan Kumar and under licence CC BY-SA 4.0 and was written on February 23, 2021 and updated on March 3, 2021.

Protect open platforms

This is the second article in a series of posts identifying situations where floss (free software) alone is not sufficient to guarantee user freedom.

My previous article, Whatsapp and the domestication of users, received more attention than I expected. Some answers gave me a lot to think about ¹ especially with regards to actions that we can undertake. My suggestion is to read that article first; what it is is explained the domestication of the user and why it's a problem. I have listed three countermeasures: floss, simplicity and platforms open.

Complex problems, by definition, lack easy solutions. Simply choosing (or creating) a platform that avoids user domestication is not enough if that platform can change. The price of freedom is eternal vigilance; in addition to settling on the right platform, we need to ensure that it takes care of its users both in the present and in the future. Maintain a platform floss easy to maintain it's more simple ² than protecting a platform open.

How can we prevent an open platform from becoming a closed platform in the future?

How can an open platform become closed?

There are three ways to make a platform open become closed:

1. a forced migration to a different platform;
2. a single implementation becomes dominant, straddling specification and implementation;
3. dominant implementations that adopt too many non-standard features and behaviors.

These three approaches can overlap: they often feature platform monoculture and a single vendor controlling both the client and servers.

Forced migration

When a provider controls all parts of a service (for example, both a client and a server), it has the means to create what I call a platform in a box: a subset of a larger open platform that can evolve independently, without concern for compatibility or interoperability.

Controlling both the server and client allows a vendor to upgrade the client and server without worrying about breaking compatibility with other clients/servers. It could update the client to direct users to a server that uses a completely different closed protocol. This is what happened to many XMPP users in the early 2000s.

Case Study: Canning XMPP

XMPP (formerly known as Jabber) is an open, federated instant messaging protocol; anyone can set up their own XMPP server and talk to users on different XMPP servers, preventing one organization from owning the platform. Between 2005 and 2014, many proprietary chat platforms supported it: Google Talk, AOL Instant Messenger (AIM), Facebook Chat (later known as Facebook Messenger) e Skype These are just a few well-known examples. Some of these platforms even had server-to-server federation enabled.

Unfortunately, the users of these proprietary services have been boxed. Few Google Talk users spoke to Skype users, and Skype users rarely spoke to AIM users. Users remained on their own sub-platforms. The result was that all users were limited to speaking exclusively using their provider's software: one provider controlled the entire messaging flow, from a sender's client to the server to a recipient's client. Users were only exposed to a single XMPP implementation offered by a single provider.

Each of the platforms listed eventually blocked their users from migrating from XMPP. This would not have been possible if multiple implementations and providers interacted with each other. Imagine that Bob uses BobClient and BobServer to talk to Alice, and Alice uses AliceClient and AliceServer. BobClient, BobServer, AliceClient and AliceServer should all remain compatible and use the same protocol; A forced migration is unlikely to occur as it would break compatibility.

Now compare the situation with email: Despite Gmail's dominance, other email providers remain popular. Gmail users must be able to communicate with non-Gmail users and vice versa. Email is much less boxed compared to the aforementioned proprietary XMPP platforms. As a result, Google hasn't been able to control the email platform as easily; Google can't simply migrate Gmail users to a non-email platform that's incompatible with the rest of the email landscape to further domesticate its users.

XMPP is still alive and well, but its current popularity is a fraction of what it once was.

Influence of implementation

Standards are a kind of agreements made to ensure compatibility between implementations. Such agreements must be agreed upon by the implementations themselves. When an implementation becomes dominant, its influence in decision making with respect to shared standards also increases. Too much dominance can create a monoculture where the dominant implementation is the only implementation that conforms to specifications.

With sufficient leverage, a dominant implementation can serve as a reference implementation. Reference implementations are typically very useful and serve as a source of truth for testing other implementations. Problems can arise when specification development and production-level reference implementation become tightly coupled, leaving the feasibility of third-party implementation out of the decision-making process.

Case study: Matrix and Element

An example of this phenomenon is Matrix. Matrix is an open and federated instant messaging platform similar to reading, device testing… the list goes on and grows every month ³. The only client that implements all the necessary features is Element. In addition to being the most popular client, Element practically serves as the reference client implementation: it is developed by the same company that builds the dominant servers and most of the specifications. The tight coupling between Element and the Matrix specifications allows you to add features at a rate too fast for other clients to keep up with; virtually every Matrix user has to open Element at some point to perform an action that isn't supported in any other client. Server-side, Synapse is the only server that implements enough specs to be usable, with Dendrite coming in second. Both are made by the same company that develops Element.

Since there are no third-party clients and servers that can replace the official ones, one provider is close to controlling all parts of the platform. The increasing complexity required of clients and servers may also further entrench these dominant implementations, as I have explained previously. Matrix is close to being a boxed platform because the official client and server can move independently.

I don't think Matrix will become a completely closed platform anytime soon; the blog post “On Privacy versus Freedom” seems to put it on the side Good of the closed/open question. Applications like gomuks And FluffyChat they seem to keep up with Element well enough to serve as partial replacements. However, I find its current state problematic and much closer to closed in the closed/open concept compared to XMPP, IRC and email.

Feature creep not standard

Platforms are more than their protocols. Different implementations have unique behavior to distinguish themselves. Problems arise when unique non-standard features of dominant implementations grow beyond a certain point to create a closed loop within an open platform.

Case Studies: Email Providers

After reading my previous article, a few people have contacted me to ask my thoughts on certain email providers. There isn't much that can distinguish a standard email provider if it just hosts a simple email server. To stand out, email providers often implement many features beyond email standards compliance.

The vast majority of email accounts come from a small handful of dominant providers supported by large companies (Gmail, Yahoo! Mail, Yandex Mail, Mail.ru, iCloud, and others). Providers like Gmail are known for implementing advanced spam filters that are biased against non-mainstream email providers. Users who self-host email servers or use small providers often trigger false positives and end up having their messages incorrectly labeled as spam until they manage to build a reputation ⁴. Adding such a complex spam filter strengthens the email oligopoly by creating a barrier to entry for newcomers. Low volume senders are discriminated against, like found Migadu:

We have already seen malicious spam filters and misconfigured servers. In some cases recipients' servers have intentionally rejected correct emails just because we are a low-volume sender. Ironically, this is what an ideal sender should be like. To improve “admissibility” they obviously offer their own hosted email service at a high price.

Another example: email providers like Hey.com, Protonmail And Tutanota they offer many features that are incompatible with IMAP/POP3. Protonmail and Tutanota use their own non-standard E2EE implementation (rather than focusing on improving the UX for vanilla PGP) while Hey.com offers server-side mail organization. Users of these services must use official web, desktop and mobile clients ⁵. These three providers control both the client and the server, providing them with the means for vendor lock-in. Of course, there is a limit to the amount of lock-in these providers can achieve: as I explained in XMPP case study, these providers still need to support SMTP to remain compatible with the broader email landscape.

Solutions

The situation therefore does not appear to be the most rosy. Let's try to focus on the actions users and providers can take to keep platforms open.

What users can do

As a user, consider using clients and servers created by different groups of people to make it more difficult to box the platform. Choose implementations that suffer less feature creep. What distinguishes a client should not be which functionality it has, but as these are implemented. Obviously, having some unique features is great; problems arise when the number of unique features exceeds a certain threshold. Following both of these practices encourages implementations to stick to standards compliance, reliability, and compatibility rather thaninnovation. Choose boring technology rather than always shiny new features.

Try venturing outside the mainstream taking a look at less popular vendors or applications. All implementations start somewhere, and a variety of implementations prevents a rule from oligopoly.

When choosing a client and vendor, consider the vendor's incentives. Who are your suppliers accountable to? To users or investors? Have they passed the point of financial sustainability?

I'm not claiming that average users are doing anything wrong; expecting the average user to change their behavior for the greater good is naive. This advice is aimed at the subset of users who are technical and willing enough to think about the platforms they choose, and indirectly targeted at the people they can influence.

What suppliers can do

Rather than focusing too much on scalability, focus on making server-side software easy to install and federate. Close registrations if yours Instance it gets too big and encourages people to use different providers. There are several cases in the Fediverse that already do this. I'm not saying scaling isn't important; rather, I'm saying that reducing the barrier to entry for new vendors is an effective alternative approach to scaling ⁶.

Consider the copyleft license. Copyleft is one of the most powerful tools we have for protecting user freedom by preventing the creation of derivative works that seek to limit user freedom. This makes it harder for alternative implementations to keep changes to themselves while attempting to can the users. There WILDEBEEST AGPLv3 it is particularly effective because it requires the distribution of server-side code for network services; a viral proliferation of AGPLv3-licensed software could have mitigated the canning of XMPP users in the early 2000s.

Reference implementations are fine if they are not too dominant. Make sure other implementations can catch up. If necessary, slow down the evolution of a specification, let developers of other implementations participate in the decision-making process, and help them improve their implementations. Moving quickly and breaking things is not the best approach.

For example, Element and the Matrix.org Foundation would alleviate most of my concerns by doing the following:

• reduce new signups on the matrix.org homeserver by directing users to alternative servers run by different people;
• take a very conservative approach to new features until more server and client implementations reach parity with Element, Synapse, and Dendrite;
• focus on reducing the system requirements to host a server, reducing the barrier to entry for new providers. This is already underway with the development of Dendrite.

Disadvantages

The biggest disadvantage of the advice just given is the speed of development. Maintaining compatibility and specification compliance slows the rate at which new features can be added. As he claims Moxie, Signal may not have been able to implement as many features if it were an open platform; Specification-bound development is, by definition, bound. Users are limited by the lowest common denominator among the most popular participating implementations.

Open platforms with multiple providers and implementations often suffer from lower usability, especially when it comes toonboarding. Instead of simply opening the official app/website, users have to choose between multiple clients and providers. This can be a turnoff (for the worse) for casual users who just want to try something out. One of the best ways to improve the experience of onboarding is offering advice to your non-technical friends; you know them well and can probably help them make an informed decision.

Parallels to other situations

Programming languages driven by a standard rather than a reference implementation typically have greater portability, many good implementations, and are unlikely to fade away over time. Examples include C, C++, Common Lisp, JavaScript, and POSIX Shell. Compare this to a language like Python: so many packages depend on the CPython reference implementation's approach to C extensions that alternative implementations like PyPy must remain perpetually second-class citizens.

The standards- and consensus-based approach to platform development and the resulting inefficiency is a trade-off visible in many quarters, even outside of software development. Most forms of democracy suffer from bureaucracy and infighting that stifle progress. Some have argued that democracy's inefficiency is a feature, not a bug. As Nathan says Myhrvold:

The reason societies with democratic governments are better places to live than their alternatives is not because of any intrinsic goodness of democracy, but because its hopeless inefficiency helps blunt the underlying potential for evil. The constraint of maintaining constant popularity is simply too great a burden to bear. So, fortunately, very little is made that is extremely bad or extremely good.

Nathan Myhrvold

Perhaps the biggest benefit of abandoning the “move fast and break things” mentality is that in addition to making it difficult to improve a service quickly, abandoning this type of mentality also makes it difficult to quickly worsen a service.

Acknowledgments

Denver Gingerich helped me brainstorm early in the writing process and provided useful information for the section on XMPP.

Thanks to Barna Zsombor and carbolymer for giving good feedback on IRC.

1. This comment in particular[↩]
2. Please note that the words “easy” and “simple” are not interchangeable, although they have some overlap[↩]
3. You see This Week in the Matrix, a weekly blog of updates on the Matrix. In particular, look at the spec updates.[↩]
4. The official advice of Google And AWS describe this behavior in detail[↩]
5. Protonmail offers its own bridge That translates the Protonmail API in IMAP, allowing users to use their favorite email clients. This still doesn't change the fact that users must use official clients; in this case, the official client is the program bridge same[↩]
6. I decided not to use the cheeky subtitle “Scalability is bad” because I feared that readers of a certain orange website might take the joke too seriously[↩]

Join communities