‌4

Federation: Treading the line between technical compromise and ideological choice

With the growing popularity of the so-called ‘Fediverse’, mainly known by its main projects, Mastodon1 and Pleroma,2 the introduction of OTRv4 and the vibrant scene of ‘chat-over-email’ projects, federated architectures are currently experiencing a phase of increased development and use. They are presented as alternatives, on the one hand, to centralised applications that introduce a ‘single point of failure’ in the network and lack interoperability, and on the other hand, to the p2p apps that necessitate higher levels of engagement, expertise and responsibility from the user (and her device). Federation is sometimes described as an ambitious technopolitical project; federated architectures open up the ‘core-set’ of protocol designers and involve a new kind of actor, the system administrator, responsible for maintaining the cluster of servers necessary for federated networks. Federation is believed to help alleviate the very high degree of personal responsibility held by a centralised service provider, while at the same time distributing this responsibility and the ‘means of computing’3 – the material and logistical resources needed by the system – with different possible degrees of engagement, favouring the freedom of users to choose between different solutions and servers.

As the previous chapter has also shown, the community of developers involved in the field of secure messaging is conducting lively debates about the limits and potentials of decentralised protocols – debates which we have retraced online. The discussions of the tensions between centralisation and more distributed architectural forms, such as federation, go hand-in-hand with debates over standards. Supporters of federated solutions claim that reusing existing standardised protocols or developing new open standards can enhance interoperability and solve the problem of ‘messaging silos’ (Kent 2019). Indeed, federated architectures appear to be well-suited to promoting localism and community-oriented smaller solutions, whose business model does not depend on the sheer numbers of users and the availability of their data for harvesting and aggregation. On the other hand, according to advocates of centralised solutions, federation can present problems in terms of security, as it is harder to audit all the different implementations of a federated protocol and ensure that all servers are well configured.4 Indeed, federated messaging solutions add a layer of complexity to the governance of the sociotechnical networks they structure, as they introduce the need for the decentralised administration of servers (or ‘instances’).

This chapter retraces debates about federation in encrypted messaging and analyses the shaping of federation as both an infrastructural and a social experiment, one that seeks a compromise between the distribution of responsibilities onto a larger number of actors, high levels of security, and better usability. We discuss federation as a political as well as a technical project that recognises the dangers inherent to centralised solutions but suggests a middle ground between centralisation and full-fledged distribution as in the case of peer-to-peer tools, the latter considered as requiring a steeper learning curve. In the chapter, we will analyse two approaches to federation. Firstly, we examine projects that develop new protocols, such as OMEMO and Matrix.org. Then, we analyse the ‘ecological’ approach to protocol development, which consists of upcycling older protocols and existing open standards, with the example of ‘Chat-over-email’ projects such as Delta Chat. The chapter shows how community-managed infrastructures and practices of ‘social encryption’ are used to enhance security beyond encryption protocols. We also analyse federation as a way to make messaging apps resilient to censorship, a factor that plays a more and more important role for users living in repressive contexts.

Decentralising to what extent? The ‘dependencies’ controversy revisited

When it comes to the community of developers debating online, the tensions between centralisation and federation are paralleled by debates over standards; the discussions have as a fil rouge the controversy about ‘dependencies’ which we introduced in the case of Signal, and the impact of different aspects of dependency for users’ Internet freedoms.

A well-known argument in favour of centralisation – and against standards – was made by Moxie Marlinspike, Signal’s lead developer, in a previously introduced (Chapter 2) blogpost (Marlinspike 2016), which attracted considerable attention and was widely quoted by developers, trainers and advanced users as a reason to opt for centralisation. According to this point of view, centralisation offers a better control ‘by infrastructure’ or ‘by design’, while federation can be ‘dangerous’ in terms of security, as it is hard to audit all the different implementations of the protocol and ensure correct updates. This first argument therefore frames the debate in terms of governance of a given project and its implementations. According to Marlinspike, it is the evolution of the market of end-to-end encrypted messengers that demands centralisation:

One of the controversial things we did with Signal early on was to build it as an unfederated service […] it’s entirely possible to build a federated Signal Protocol based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all (Marlinspike 2016).

Marlinspike argues that only centralised solutions can satisfy constantly changing consumer demand and the overall instant messaging ‘ecosystem’. Interestingly, he explains the success of current popular online communication systems as a result of the progressive evolution of federated protocols into centralised services (he uses, more precisely, the word ‘cannibalisation’):

It’s what Slack did with IRC, what Facebook did with email, and what WhatsApp has done with XMPP. In each case, the federated service is stuck in time, while the centralised service is able to iterate into the modern world and beyond (Marlinspike 2016).

According to Marlinspike, decentralisation seems to bring about more problems in keeping older and newer versions of an application interoperable. Michael Rogers, Briar’s lead developer (see Chapter 3), tends to agree when he explains why the Briar app public release took longer than expected:

We have an app that runs, it’s fairly stable, it looks like a fairly complete finished application. The reason that we do not release it now is because we need to change the data format and protocol details, and keeping interoperability with older versions in the decentralised network when you’re changing data format and protocol details is really difficult. So we want to postpone having to deal with that problem as late as possible by just doing limited test until those things stabilize before doing public releases (Michael Rogers, Briar lead developer – January 2017).

Thus, the Briar team implements ‘expiry dates’ into its releases in order to make it technically impossible to communicate between users of newer and older versions. This problem was also present in the case of a federated messaging ecosystem, Matrix.org, during its transition towards end-to-end encryption, when a multitude of older clients became incompatible with e2e. Therefore, decentralisation supposes a certain amount of coordination and community-oriented effort.

With respect to federation, another argument in favour of centralisation concerns the security that comes with greater control over changes in protocols and server administration. Marlinspike claims that social centralisation is needed to successfully respond to unsolved challenges, such as metadata protection:

If anything, protecting metadata is going to require innovation in new protocols and software. Those changes are only likely to be possible in centralised environments with more control, rather than less. Just as making the changes to consistently deploy end to end encryption in federated protocols like email has proved difficult, we’re more likely to see the emergence of enhanced metadata protection in centralised environments with greater control (Marlinspike 2016).

Peter Sunde, co-founder of The Pirate Bay and developer of the Heml.is messaging app, whom we have already met in Chapter 2, agrees – despite his preference for federated architectures, which were the initial model envisaged for Heml.is – that centralised control over servers may help enhance users’ privacy (social graphs, metadata):

The idea to begin with [when developing Heml.is messaging app] was to do federated servers, but then we realized that it was not possible because we also wanted to protect social graphs of how people communicate and in order to do that we needed to make sure that we have control over the servers… All these ideas and technological solutions are always a trade-off (Peter Sunde, Heml.is).

The previously discussed trade-off between security and usability (Norman 2009; Cranor and Garfinkel 2005; Yee 2004) also reappears when it comes to older federated protocols, such as XMPP. Despite the fact that this protocol is defined by its promoters as a ‘living standard’, in Marlinspike’s words, due to its capacity for protocol extensions, it is often criticised for its weak support of rich media and for the difficulty of developing it for mobile uses. Due to the relative freedom developers have to deploy a variety of XMPP-based clients, XMPP suffers – according to Marlinspike – from fractured client support, and the difference between various XMPP clients results in lack of consistency regarding feature support in various clients. This may create confusion for users:

Someone’s choice to use an XMPP client or server that doesn’t support video or some other arbitrary feature doesn’t only affect them, it affects everyone who tries to communicate with them. It creates a climate of uncertainty, never knowing whether things will work or not. In the consumer space, fractured client support is often worse than no client support at all, because consistency is incredibly important for creating a compelling user experience (Marlinspike 2016).

However, developers from the PGP and the XMPP/OTR community, and the growing galaxy of ‘Chat-over-Email’ projects, strongly oppose this critique from Signal in their own blog posts and on a number of mailing lists where developer discussions take place. For example, a developer involved in the Conversations and OMEMO projects argues that the ‘extensibility of XMPP is not a danger in itself. A good extension will spread naturally. Moreover, there’s a permanent incentive to innovate in XMPP’. This has led developers in certain communities to try to standardise versions of the Signal protocol applied to federated projects; for example, the OMEMO protocol has been submitted to the XMPP Foundation in order to be standardised.

Signal developers believe that older protocols like PGP and XMPP actually harm user security and should be abandoned; and as Chapter 2 shows, the Signal protocol has been crucial in boosting updates to these older protocols and setting up a ‘required minimum’ of features for instant messaging applications. Signal has deeply affected the market of instant messaging, not only by ‘informally standardising’ a number of technical features, but also by attracting financial investments towards centralised projects as opposed to decentralised or distributed ones:

I believe that the problems with decentralisation we have right now are more a problem of the lack of funding than a conceptual problem that decentralisation does not work. Most XMPP clients are developed by volunteers in their spare time. And it’s kinda obvious that one single developer that donates two hours a week of his spare time to develop an IM client is unable to compete with five full time developers like Open Whisper Systems for example (ChatSecure developer).

Giving (or reclaiming) choice, distributing responsibility

Opposed to Signal’s strong discourse on ‘consumer space’, which has modified the scene of secure messaging by inviting to the discussion table a more varied set of actors than the techno-idealists and crypto-enthusiasts of the early days, are discourses such as that of the LEAP team, which strongly defends open federated protocols (as opposed to self-made, closed or partly closed protocols):

Moxie came out recently and ‘arrowed’ himself as a centralist in his blogpost about this topic. I disagree with him. His argument is that… open federated protocols are simply too slow to adapt and they are too difficult to implement because there’s too many different players, you make a change and you break everything […] I think just because there are examples in the past of being difficult to change protocols does not mean that the idea of open protocols is dead. I think there’s definitely ways in which we can recognize the problems with open protocols so that we still can have interoperability but not be locked in an unchanging [ecosystem] (Elijah Sparrow, LEAP developer).

The arguments put forward by our respondents in favour of federated architectures concern several aspects: first of all, the danger of trusting one person or entity behind the service (‘putting all your eggs in one basket’, as Elijah puts it) and potentially enabling easier metadata leaks. From this standpoint, the personal responsibility of a centralised service provider is very high and puts the provider itself and all its users at risk. A federated solution would help to distribute this responsibility:

Signal is trusted because it’s Moxie, but if I was the government I could force Moxie to hand over the keys and tell him like… you can’t say anything anymore. But he would at least shoot the system down, like the case with Lavabit, the email service that Snowden used. That guy closed the service down instead of working for the government. But most people will not do that… The way to solve it is to have a federated system like you have your own data at your own location (Peter Sunde, Heml.is).

Even though developers agree on the fact that decentralised systems are harder to design, their motivation to work on federated systems seems to be grounded in both the political and technical aspects of federation, first and foremost the ‘empowerment’ it can offer to the user by providing the means to control their own data and enable better metadata protection:

I know there are journalist organizations that run their own XMPP server, primarily using desktop clients. I’d like to allow people to run their own infrastructure around their own data as much as possible. There are other great tools that do encryption, at that point you can use WhatsApp or Facebook, they are using the same Signal protocol. But you’re still not owning your data, all the metadata is controlled by a centralised system, they know all your contacts, who you’re messaging at what time. […] Other people feel differently. Like Moxie really wanted to do a vertically integrated centralised solution because it’s a lot more usable if you control all the technology pieces (ChatSecure developer).

Another argument in favour of federated architectures – this time, as opposed to both centralised and purely p2p ones – emphasises the freedom for users to choose between various services, as Matrix’s lead developer explains:

I had a long running dispute with Moxie Marlinspike about [decentralisation versus centralisation] basically because Matrix obviously is an interoperable decentralised network and he considers that a privacy risk because you can’t control the whole network, there may be implementations that may not be secure, there may be bugs that you cannot control, that leak sensitive information and that is a thing for privacy. I would argue however that decentralisation is also important for freedom, and the user’s ability to pick which service to use (Matrix lead developer).

In this sense, federated protocols are often compared to political systems, where users can ‘vote with their feet’ by leaving a server in favour of a better one. Federated protocols are said to provide better accountability and better control over the service providers. Moreover, the ease of migration offered by interoperable environments makes it possible for users to choose a better option without losing their social graphs.

There’s no way to establish any kind of accountability for centralised services that lock people in. It is very easy if people have federated services, they can just pick up and leave if their provider does something they may not like. So tomorrow Signal started to do that people were critical of, it would be very difficult to get people out of Signal to use something else (Elijah Sparrow, LEAP developer).

Indeed, our user interviews revealed among frequent XMPP users a peculiar attitude of ‘proximity’ with XMPP service providers, as well as a specific set of feedback practices between users and providers. The possibility of developing a client on top of an open federated protocol, with features needed by a specific user community, was also underlined as a positive aspect of federation, albeit that it limits the usage of these solutions to a more tech-savvy audience, or else requires localisation efforts.

Unlike developers, many high-risk users did not bring up the need for federation explicitly, but they raised it implicitly in how they formed trust relationships. Federation provides a suitable infrastructure for specific communities to organise without having to rely on intermediaries. In this sense, developers, high-risk users and trainers tend to build associations between specific configurations of political organisation and of technical infrastructure. For example, some developers and trainers justified federation as mirroring the organisation of anti-authoritarian social movements, which echoes w the conceptual analysis of the sociotechnical meanings of decentralisation proposed by Nathan Schneider (2019). Thus, there was a preference for systems that were considered politically trustworthy p by high-risk users; federation was generally viewed as positive in this regard by a minority of high-risk users. These users expressed concerns about centralised systems collecting their metadata, although few realised this would also be possible in most federated systems, albeit in a distributed form – which attests to the important ideological component included in the notion of federation.

Some developers believed the choice of federation to be inherently connected to not collecting metadata, and felt that models existed which were both usable and decentralised:

With Signal, it’s impossible to create a decentralised system because phone numbers aren’t decentralised. With XMPP it’s like an email address. Even users who aren’t technologically savvy can understand this is my user ID, and this is my server (OMEMO lead developer).

The ‘chat-over-email’ paradigm is also based on understanding the risks associated with synchronising contact books and depending on mobile operators. Moreover, federated projects promote interoperability as a solution to the walled gardens of secure messaging applications. Building a potentially open system, pluggable and modifiable according to the needs of a community, also means removing parts of the work from the developer team.5

The remainder of this chapter explores three federated protocols and the applications based on them: Conversations (and OMEMO protocol), Matrix.org, and the ‘chat-over-email’ effort, with projects such as Autocrypt/Delta Chat, LEAP and Pixelated. Through the case studies, we aim to explore the tensions between the elements of technical innovation and the politico-ideological choices that shape particular definitions of ‘freedom’, both for users and developers, in federated arrangements.

Conversations and OMEMO: Bringing future secrecy to XMPP

The federated end-to-end encrypted messaging app Conversations is based on XMPP and OTR/OMEMO.6 This project could be defined as a ‘one-man app’, its core developer working alone, driven by his own technical curiosity and relying on his own previous experience as user of XMPP and OTR:7

I am an XMPP user. When I got my first Android phone there were no good examples available for the platform. I actually decided to write my own app. I did maybe 95% of the code by myself. I do have occasional contributors on github but was pretty much alone (Daniel, Conversations/OMEMO lead developer).

Conversations is an end-to-end encrypted instant messaging application that offers users a choice of three encryption algorithms and an unencrypted (TLS-only) mode. This design solution is unique in the field and makes Conversations an interesting case-study. The choice between three different algorithms was, as one of the Conversations developers explained to us, his version of an answer to the interoperability problem; when he started working on Conversations, end-to-end encryption methods were available for different clients, and Conversations tried to be compatible with them all, so it had to implement OpenPGP as well as OTR.

As a third choice for encryption, the OMEMO protocol (recursive acronym for OMEMO – Multi-End Message and Object Encryption) was created with the idea of providing future and forward secrecy and deniability and gives the possibility of message synchronisation and offline delivery, which are both important features for a federated protocol. According to its creator, OMEMO was developed to solve specific limitations and problems that existed both in OpenPGP and in OTR:

One of the main limitations of OTR was that it didn’t work with multiple clients. If you are logged on your mobile client as well as your desktop client, OTR does not work. Open PGP had downsides as well: there wasn’t any verification built in, it did not have any forward secrecy or any other nice crypto traits that you wanted to have (Daniel, Conversations/OMEMO lead developer).

OMEMO was developed during the Google Summer of Code in 2015, using the LibSignal library.8 Daniel, Conversations and OMEMO’s lead developer, acknowledges the lack of standardisation and lack of specification of the Signal Protocol, which we noted in Chapter 2 (‘The underlying cryptography was not very well documented, and we were just basically making through the library’). However, Daniel was able to work with the library well enough to implement the Double Ratchet, the up-and-coming ‘golden standard’ of instant messaging promoted by the widespread acceptance of the Signal Protocol:

I personally don’t have a very strong cryptography background, I try to rely on what’s already there, what’s already popular right now. Like Signal protocol with double ratchet is quite widespread these days and seems to be well received by various cryptographers. So it makes sense to base OMEMO on something that’s similar (Daniel, Conversations/OMEMO lead developer).

OMEMO, being, in Daniel’s words, an ‘XMPP wrap around LibSignal’, brings Signal’s innovative features, such as future secrecy, to XMPP. In this sense, protocol design choices for Conversations and OMEMO are determined by the overall development and state of the art of modern cryptography (see Chapter 2: ‘Signal does it, WhatsApp does it’.). Instant messaging, over the development of OMEMO, is understood as a set of tools for the exchange of information that is intrinsically ‘temporary’, and users are likely to favour a feature such as future secrecy over the possibility of permanently accessing their archives. However, Conversations does not support the function that leads to the disappearing of messages, even though users, according to our interviews, have been asking for it. Instead, Conversations opts to entrust users with more choice, but also with the increased responsibility that comes with it:

If you are looking into data hygiene, not keeping around the history is something that you should do for yourself on your own device according to your own rules and Conversations has a setting that allows you to delete all messages both sent and received on your device and regulate intervals, for example a month or a week. It is a more honest solution. Because you can control when these messages are deleted. It is up to each individual user to decide what to do with the data (Daniel, Conversations/OMEMO lead developer).

Interestingly, this approach of entrusting users with both choice and responsibility differs from the automatic, or ‘opportunistic’ turn in encryption embraced by applications aimed at the general public (e.g. Signal), whose creators actively work on concealing a lot of options from users to make the application more immediate and comfortable to use. Conversations seems to be targeted more towards those users for whom freedom equates to having more control over the application and, in the words of one of our respondents, ‘see[ing] encryption happening’.9

The kind of ‘freedom’ that Conversations aims at giving users extends not only to the server, but also to the encryption scheme that they prefer or are more used to. The intention is to help attract more users, regardless of the encryption algorithms that their peers support, as Conversations can talk to OTR- and to OpenPGP-only clients. The language elements of ‘user choice’ return here: ‘They can choose Open PGP and will not have forward secrecy but will have some other features in return’. [Daniel, Conversations lead developer]

This freedom of choice is, as we have demonstrated in the section above, is mentioned as one of the advantages of federation. It also gives users the possibility to gain certain security, privacy or usability features that exist in some protocols but not in others. For example, OpenPGP offers archiving, which, for low-risk users, may sometimes be more important than future- and forward secrecy:

There are a couple of users who don’t want to move away from OpenPGP because all these modern encryption schemes that provide forward secrecy do not have the ability to retrieve your messages, so when you’re setting up a new client you can’t access the archive with all your messages. And OpenPGP allows you to do that. That’s arguably a very niche use case, less secure in some ways because it doesn’t have forward secrecy and stuff like that, but some users really prefer to have the ability to access the archive if they are not under high risk (Daniel, Conversations/OMEMO lead developer).

As the app’s developer explains it, Conversations is aimed at a specific user-group, that – if we were to go back to categories we questioned but found useful earlier in the book – could be defined as high-knowledge, low-risk and privacy-aware users, who strongly support XMPP, federation and open source, and opt for Google-free and privacy-preserving solutions such as the minimisation of data storage, with both technical and ideological components subtending their choices. While applications such as Signal, Telegram and Wire are arguably starting to be considered as mainstream, and are often covered in the media, in the case of Conversations, user enrolment happens via specific digital security training sessions, advice from tech-savvy friends, personal technical knowledge and interest in XMPP and federation. These users are, in turn, introducing their close network and peer groups to the app via word-of-mouth dynamics.

OMEMO is not yet a standardised protocol, though it has already been adopted by a number of XMPP clients (listed on a dedicated website).10 At the time of writing (16 September 2019), the website lists 18 XMPP clients fully supporting OMEMO and 33 clients that are currently working on being compatible with OMEMO. OMEMO has been submitted to the XMPP Foundation for standardisation and is currently at the first stage of the standardisation process.

However, our interviews with the developer teams of both Conversations and ChatSecure have revealed that these projects, though well known within the XMPP scene (developers mention that they regularly attend XMPP-related events), are almost invisible within more hybrid events aimed at privacy advocates and high-risk users and other stakeholders (Internet governance organisations, lawyers, researchers), such as, for instance, the Internet Freedom Festival or RightsCon. These applications could have had a wider adoption, especially given the strong modern-state cryptography implemented in both tools; however, their authors remain disconnected from the ‘high-risk, low-tech’ communities. Media coverage is also partly responsible for that disconnect: both applications are much less visible in non-tech-savvy oriented media, and cannot draw on the support of well-known public figures such as Edward Snowden, or organisations such as EFF, AccessNow or Tactical Tech. The latter are more eager to cover centralised applications (except for the Tor browser) and are de facto not involved in advocacy for technical decentralisation or federation.

Matrix.org: Facing the interoperability problem

Lyon, France, 25 May 2017: Ksenia attends the European Lab session on privacy-enhancing technologies and decentralised identity management systems. At some point, an interesting discussion takes place, which illustrates the state of the art in the field of encrypted messaging quite well. The panel moderator, himself a user of multiple encrypted messaging tools and protocols including PGP, Signal, Wire and Jabber, asks the audience: ‘How many messaging applications do you use on your mobile phone?’ After a brief round of answers from the public, he counts that among the forty people present, the average number of messaging applications is five per person, while several people say that they regularly use more than seven messaging applications. This question allows him to bring to the table the important problem of digital ‘silos’ (Kent 2019): how do people communicate in this ‘mess of messengers’, being separated by the walled gardens (Musiani 2016) of their favourite messaging clients, but also, more deeply, by various encryption protocols that are incompatible with each other.

While Conversations suggests a solution for interoperability between encryption protocols (OpenPGP/OTR/OMEMO), it still runs over XMPP and requires users to have an account on an XMPP server (or ‘even better, run [their] own XMPP server for [them] and [their] friends’, as OMEMO’s inventor puts it). However, interoperability remains a problem for users of centralised messaging applications (Kent 2019). Individual projects have attempted to solve the interoperability problem, such as by bridging Jabber – a free IM service based on XMPP – to centralised applications. For example, the Russian Pirate Party has developed a ‘Jabber bot’ for Telegram, that helps Pirate Party members who do not trust Telegram to continue communicating within their community using Jabber.11

Another project that addresses the interoperability problem is Matrix.org, which works on giving users the possibility to bridge various messaging applications and let users connect without laying on them the ‘burden’ of having to migrate from their favourite tools. The underlying idea of Matrix.org is meant to go beyond an instant messaging application; it is framed by its developers as an ecosystem that could be used for any kind of data sharing:

The model is very much inspired by the phone network, in terms of the phone network being a global way to exchange communication data. But in the end it’s closed, it’s not open, it’s quite centralised to the telcos. So we wanted to create a complementary network which has the openness and the decentralisation baked in (Matthew Hodgson, Matrix lead engineer).

The main goal of the project, as underlined in several articles, is to ‘create an architecture that tackles the interoperability problems that were not addressed by previous approaches’. This interoperability is meant to become a substantial comparative advantage and enrolment factor for users: ‘where IRC has a high barrier to entry, requiring you to know exactly what server you’re connecting to and configure accordingly, Matrix would let you associate with as many public identities as you’re willing to share (phone number, email address, Facebook, Google, and so on), as long as they support the Matrix standard. Otherwise, it requires no setup – it’s just like if you were using any consumer messaging service’ (Weinberger 2014).

Matrix is an open-source, non-profit project under Apache license, and was financed by Amdocs until 2017. Since then, the Matrix team has created its own foundation, called ‘New Vector’, that offers consulting services to those who want to use hosting services within Matrix or use Matrix for commercial purposes:

We offer help to build bridges between various messaging platforms. If I have an enterprise where everyone is using Slack, I can pay huge amounts of money to Slack to buy their corporate solutions, or I can pay a couple of bucks per month to Matrix to maintain bridges (Matthew Hodgson, Matrix lead engineer).

Recently, New Vector obtained funding from an Ethereum startup, and Matrix attracted interest from the French government that asked for support in deploying an internal messenger for civil servants, built on Matrix/Riot.12 As of 16 September 2019, the team counted sixteen members, eleven of them based in London and five in France. They support Android, iOS and Desktop versions. Currently there are 5000+ chat rooms registered on Matrix, focused mostly on ‘the techno-privacy aware community, computer scientists and normal developers’, in the words of Matrix’s lead developer.

Unlike LEAP (which will be addressed in the last part of this chapter) and Signal, the Matrix team does not take an explicitly political or ideological stand and does not aim at providing software for specific audiences with a political agenda or engaged in political arenas, such as activists. The creator of Matrix positions his team as ‘sort of moderate, really centrist’, and adds:

I am very sympathetic to the human rights issue and privacy but we haven’t set up with Matrix to build something like Tor or Signal or Ricochet or any of those tools which are optimized very specifically for privacy at all costs. Instead we’re trying to do the best we can and be very mindful of it, whilst also building an ecosystem that works and is practical (Matthew Hodgson, Matrix lead engineer).

Matrix’s creator identifies his position as a kind of ‘liberal pluralism’, which is reflected in the very architecture as well as the users of his system. From the point of view of the architecture, it is a federated system that bridges a great variety of different messaging tools, thus leaving a certain amount of freedom to users, allowing them to retain their usual interface, while making it possible for them to connect with others. As Matrix’s lead developer points it, Matrix is trying to respond to the problems of walled gardens, produced by the quick and somewhat ‘chaotic’ development of the messaging ecosystem, especially on mobile. As an illustration of his objective, during our interview, he showed us his mobile phone with around 10 different instant messaging applications (from Wire, Threema, WhatsApp and iMessage to Signal).

In terms of user pluralism, Matrix has a variety of rooms addressing a wide variety of subjects, from cryptography and open source, cryptocurrency and decentralisation to psychological help, furries, subcultures and fan communities, left-wing groups and alt-right Donald Trump supporter rooms. Two of the main lingering problems for Matrix are managing spam and maintaining a decentralised reputation system – issues that, according to Hodgson, are still open for research, and need to be supported by a ‘morally neutral’ positioning.

Within the ecosystem of mail and messaging applications, Matrix identifies itself as a compromise, in a positive sense, between centralised and completely decentralised systems, that seeks to provide satisfactory security solutions while running a partially decentralised system:

Signal is pretty much saying: we’ll run it [Signal] as a centralised service therefore we can guarantee its security. Email in the current state has no privacy and security but it’s being 100% decentralised. So we’re basically a middle-ground approach (Matthew Hodgson, Matrix lead engineer).

For the main developer of Matrix, the relation between decentralisation and security is a thorny issue: according to him, ‘the two things definitely pull against each other’. He sees email as an insecure system, because of the independence of email service providers. In this sense, an attempt to introduce a standardised, automatic mail encryption, that could be implemented by various Mail User Agents with relatively low resources, could be a possible step against many passive attacks. Due to the convergence of interests in this regard, Matrix was invited to present its current work at the Autocrypt hackathon in December 2016; this event gathered different projects that discussed not only email encryption but also decentralised reputation and identity systems, such as Scuttlebutt. Introducing encryption through headers also becomes a form of ‘governance’ via federation, between the multitude of mail service providers: this kind of governance, unlike Signal, is based on a very detailed specification, which could be approved by the galaxy of email service providers who take part in the Autocrypt effort.

For Matrix as a decentralised system, the frequency of passive attacks made the implementation of end-to-end encryption a crucial step; it was also a specific way to establish trust within federated infrastructures, where trust is spread across a large number of server administrators:

In decentralised systems, you end up with a large attack surface. If you were running a server and I am running a server, and I send a message, the message is on both of our servers that means that we have to trust a sysadmin of both of the servers. In a big room with 5000 people, and, say, 1000 servers, you have an even bigger problem. If you’re sending something sensitive or private, it will be shared across all of the servers. Getting end-to-end encryption is critical so that the servers get an encrypted copy of the message rather than the real message so that you don’t need to worry about system administrators spying on messages (Matthew Hodgson, Matrix lead engineer).

As a federated project, Matrix is deployed on a multitude of servers (according to its lead developer, more than 15,000 as of 21 December 2018) that are not under the control of the Matrix team. Moreover, as Hodgson explained in the interview, each server can have its own privacy settings and policies for collaborating (or not) with lawful interception. Thus, self-hosting is promoted by Matrix as a way to increase security, in addition to enabling encryption. In the case of Matrix, end-to-end encryption was adopted two years after the beginning of the project – while, as our research has shown, when a system has not been designed with end-to-end encryption from the very beginning, the transition is rather slow and difficult. In the case of Wire, originally built with no end-to-end encryption, the team had to remove part of the server-side code that still contained the possibility of a plain text message being sent before going fully open source. In the case of a decentralised system, the problem of implementation is even harder, as some of the older clients run with no encryption and additional steps must be taken in order not to block users who use older clients:

So by now it’s an opt-in on a room basis. But once we’re out of beta we’ll be turning e2e on by default by every private room, and we’ll have a proxy migration path for other clients so that simple clients that know nothing about cryptography can easily join and participate (Matthew Hodgson, Matrix lead engineer).

The protocol implemented for end-to-end encryption in Matrix is called Olm and is a version of the Signal Double Ratchet. Interestingly, while Wire had difficulties in implementing the Signal Protocol (see Chapter 2), Matrix did not encounter hostility or tensions from the Signal team,13 except for an explicit condition to avoid using names or references to Signal (or its predecessor, Axolotl). Hodgson attributes the cause of this relatively successful collaboration with Signal to the political economy of open source and to the very architecture and nature of Matrix, which opens the possibility of bridging a large number of other projects:

The difference between us and Wire is that Matrix.org initiative is non-profit and entirely open source. The Apache license that we use is aggressively permissive […] And I spoke to Moxie and explained what we were doing. And he said: you’re crazy, and if it works then go for it, it will be great, but you guys have fun doing that and I will keep doing Signal. He does not want to persecute us. […] Whereas other companies, which are doing proprietary commercial messaging solutions even if some parts of it are open source, he [Moxie] will see them as competition. We are more like idealistic altruistic hippies who should probably fail while building this white elephant of Matrix, and if we don’t it will be a good thing for everybody including him [Moxie]. So why not support us? (Matthew Hodgson, Matrix lead engineer).

Currently, Matrix.org14 is working on minimising the spread of disinformation and spam. Indeed, while centralised platforms such as Twitter or Facebook are increasingly subject to critique for enabling the spread of disinformation and hate speech, federated alternatives, such as Mastodon or Pleroma seem to offer some ways to counter or minimise the spread of disinformation, by a mix of social and technical moderation by server or instance administrators. The Matrix team hopes to address this problem by deploying a reputational system and seeks a way for users to filter content by developing a system of open and modulable filters. Furthermore, as a response to the increased risk of Internet shutdowns in politically unstable regions, such as Belarus, Iran, Kirghizstan and others, in June 2020 Matrix released an alpha peer-to-peer version of its software, which is not dependent on an Internet connection provided by telecom operators.

Autocrypt: Email encryption as a community-building effort

Email remains stubbornly unencrypted, due chiefly to problems with key management. Proprietary closed-source projects offering ‘encrypted email solutions’ exist; however, they are not managing to solve the interoperability and fragmentation problem. End-to-end encryption in Protonmail, for instance, works only if both users have Protonmail installed; this is reminiscent of how centralised instant messaging clients work: binding users to specific applications. Furthermore, users’ awareness of this constraint is unclear; our early-stage research showed that users do not always know about this particularity of Protonmail and think that all Protonmail emails are encrypted by default.

However, email ‘remains the largest open federated identity and messaging eco-system, anchors the web, mobiles and continues to relay sensitive information between people and organisations’.15 In the context of centralisation in the field of IM apps, with telephone numbers being massively used as unique identifiers, several initiatives have recently been launched to revive encrypted email, such as Autocrypt, pEp, the Google End-to-End project and LEAP/Pixelated. These efforts have not yet been finalised or have not reached widespread adoption; this process ‘in-the-making’ should be analysed, from an STS perspective, as a technosocial, community-building effort that may have important consequences for the whole encrypted messaging/mail ecosystem as it suggests a ‘(re)turn to federation’ and proposes alternative approaches to identity and key management.

Because of its decentralised architecture, automatic email encryption implementation demands a strong community effort and the enrolment of a multitude of actors (namely, Mail User Agents-MUAs, and email service providers). These actors need to agree on the protocol, its documentation and modalities of implementation, but also its UI/UX features, logo, funding sources and so on.

Unlike centralised mobile applications for instant messaging, that can impose their own protocols (often unstandardised) and try to ‘own’ or capture users who interact within the IM app, the federated email ecosystem remains largely open. It blurs the borders between users and service providers, as the barrier of running a privately-owned email service has become lower, involving more people in the ecosystem. Migration costs from one email server to another are also relatively low, and users can shift identities or have several ones. Thus, there is fundamentally no way (nor will) to control all of the MUAs and service providers at both the technical and ideological levels. However, there are several ongoing attempts to create a tool that can connect different actors without centralising the whole ecosystem – an artefact that Michel Callon would probably consider a ‘translation’ tool.

One of the most recent innovations in this field is Autocrypt, a project run by an international group of email program developers and crypto enthusiasts from the open-source privacy-aware community. An Autocrypt plugin was added to the Mozilla Thunderbird email client in August 2019, marking an important step for this young project towards greater user adoption. Autocrypt provides a possible answer to the problem of key discovery, exchange and key management, thus addressing two important challenges: usability and ‘re-decentralisation’. Instead of keeping public keys on a centralised public key server (which may create vulnerability), and proposing that users retrieve, exchange and verify keys by themselves (which may create confusion) Autocrypt puts key material in the header of the email.

Usability-wise, this automatic key discovery process helps to solve important problems related to key exchange, verification and management. The part of our research focused on users showed that they rarely verify keys or can even define what a key is. High-risk users tend to verify the authenticity of their contacts when they receive notifications on an IM app about the changes in the key material, using ‘real-life’ non-cryptographic solutions such as voice calls or contacts over social networks. However, this behaviour is rare. And when it comes to email, advanced key verification rarely happens. Moreover, as our interviews with trainers show, the general tendency in the trainer community is to avoid explaining keys during informational security seminars, as ‘the old metaphors of padlocks are not really clarifying what’s going on there, and we waste a lot of time on it’, as a French trainer from the hackerspace Le ReSet explains. The general turn to ‘automatic’ or opportunistic encryption makes the key discovery process invisible to the user, and this is seen by several trainers as a positive step towards the mass adoption of encryption; McLemon, a cryptotrainer from Austria, points out that ‘having encryption as a default mode means a user does not have to learn about all the math beyond the crypto [. This] is the key part in making encryption popular’.

The Autocrypt solution addresses the problem of centralised public key storage and proposes a new form of coordination or federation of the email app developer community, which has been for a long time rather dispersed and has not really had a place to ‘meet each other’, in the words of Autocrypt’s promoters. In this sense, email headers become instruments of ‘self-governance’, communication and coordination of MUAs, leaving a lot of freedom to MUAs while providing a standard that helps to keep encryption working across different agents. The usability and federation of MUAs are interconnected, as scalability is necessary in order for automatic encryption to work, which implies collaboration between the multitude of third-party projects.

In order to work and to be spread widely, Autocrypt relies on the joint efforts of professional communities – service providers in one case; mail client developers in the other. In short, it relies on the widespread enrolment of email app developers. This community-based approach is very different from the one offered by Signal-like centralised applications, where the authors of the protocol seem to have greater control over the implementations, and various implementations do not offer interoperability.

Until recently, Autocrypt was focused on passive attacks only, primarily targeting a low-risk audience. However, this has served as only the first step towards providing more sophisticated solutions against active attacks and targeted surveillance: indeed, the most recent development of Autocrypt includes a solution against the active attacks of a network adversary.16 Even though Autocrypt initially focused on low-risk users, the Autocrypt motto ‘email encryption for everyone’ implies in the longer term a benefit for high-risk users: mass adoption of email encryption makes both mass surveillance and targeted surveillance more expensive and harder. By now, Autocrypt has been supported by an important number of email app developers, and starting in June 2017, the Autocrypt specification has been adopted by a new project, Delta Chat, that brings the Autocrypt encryption scheme into the field of instant messaging, offering interoperability between email and the new instant messenger.

Delta Chat: Secure messaging over email as an Autocrypt offspring

The Delta Chat secure messaging application is the pioneer of what is now called the ‘messaging-over-email’ effort. Similar to Matrix, this project is driven by a push for social decentralisation aiming to unbind users from ‘messenger silos’, relying on the pre-existing email infrastructure to favour scalability to billions of email users. The general effort to reuse the interfaces of existing popular messaging apps (inspired by the Telegram and Signal UI) draws from the same core principle: avoid creating yet another silo and offer users something they already know and are familiar with, in order to minimise migration and to focus on protocol upcycling. In the words of Delta Chat’s lead developer, ‘Delta Chat’s take is not so much in designing protocols but using existing federation. But of course, this in turn, is based on protocols, SMTP/IMAP, OpenPGP and others’.

Delta Chat’s approach to social decentralisation includes specific approaches to teamwork and collaboration with other projects – from crypto libraries to decentralised file sharing solutions. While it originally started as the ‘lone wolf’ project of German developer Bjoern Petersen, Delta Chat soon joined other projects and has gradually become a collaborative effort drawing upon a galaxy of communities. Delta Chat claims a strong focus on usability and to that end interacts with user groups in various at-risk regions, from Ukraine to Cuba, Hong Kong, Taiwan and the MENA region.

Some of the sets of protocols used by Delta Chat are long-term standards (SMTP, IMAP, OpenPGP for instance), while others are in active development. In terms of protocol governance, one of the fundamental elements of Delta Chat that makes it ‘pluggable’ and interoperable with other applications is the Autocrypt specification, first released in December 2016 – a set of guidelines that ‘describe how e-mail programs negotiate encryption capabilities using regular emails’ (Holger Krekel, Delta Chat lead developer).

Several key contributors to Delta Chat have also been active in the Autocrypt community and both share a set of practices. Both have been quite ‘loosely coordinated’ with around a dozen active contributors, from developers and crypto library designers to UX/usability experts. These contributors, many of whom work on a voluntary basis, are mostly decentralisation or crypto enthusiasts, who have known each other from various offline hacker gatherings or online discussions and collaborations around email and IM encryption, decentralisation and certain politically engaged hacker circles, including ‘activist tech collectives’. Moreover, many contributors to both efforts use Internet-Relay-Chat (IRC) on freenode, a major gathering point for open-source developments. The #autocrypt and #deltachat rooms each have 60–70 participants, and in September 2018 Delta Chat had around 5500 posted chat lines. Both efforts also use the github.com site and the ‘git’ versioning tool to collaborate, and to discuss and review each other’s changes.

Even if the recent funding for Delta Chat provided by the Open Technology Fund since July 2018 has stabilised the core team working with Delta Chat, many regular and active contributors continue working without any official affiliation. Delta Chat seems to share a tacit agreement about certain modes of collaboration that avoid reproducing what is understood as the ‘startup way’, which attributes fixed roles to team members and establishes hierarchies within teams. Instead, the work is organised around a set of main components of Delta Chat, such as Core, Desktop, Android and iOS versions, legal and licensing efforts, as well as usability and need finding. Currently, Delta Chat operates more as a decentralised ‘ecosystem’ than as a messaging app: instead of offering a specific solution, it works towards bridging various solutions with the aforementioned components of Delta Chat. The priorities for development and collaboration are partly informed by fieldwork and constant informal communication with targeted user communities, mainly high-risk journalists and human rights activists and NGOs. Interestingly, while some of Delta Chat’s development and collaboration decisions are pushed forward by various Delta Chat team members out of their personal technical or political preferences, others are also driven by the design of the current funding proposal, supported by the Open Technology Fund.

Delta Chat is also working with email service provider communities, pushing for certain changes, namely, to identify Autocrypt-friendly providers who currently support Delta Chat. Indeed, one of the drawbacks of the Autocrypt solution is the spam problem, with headers often being read as junk by email providers. Currently, Delta Chat is deepening its collaboration with activist-oriented email providers to work on new features such as automatic account creation, tailored for specific use-cases, for example those involving field missions for journalists and activists with self-destroying temporary accounts.

While being essentially a non-for-profit and activist-inspired project, Delta Chat aims to be usable by larger user communities. Recently the team has gained a Mozilla Public Licence in order to open up collaborations with for-profit actors: ‘The move to MPL is meant to be more inviting for commercial collaborators as it is now easier to incorporate Delta Chat’s core chat/contact and IMAP/SMTP/Autocrypt implementations in all kinds of offerings’ (Holger Krekel, Delta Chat lead developer).

LEAP/Pixelated: An ‘encryption as a human right’ infrastructure for providers

As its website sums up, the LEAP project ‘fights for the right to whisper’.17 Indeed, in a less subdued way than several other projects analysed in this and previous chapters, the LEAP project is structured by a political vision, most of its members having previously been involved in so-called ‘radical tech collectifs’ (see Milan 2013). However, if LEAP’s initial target was high-risk users, the scope of the project gradually has come to include a wider audience of Internet users, as LEAP frames encryption as a human right:

Like free speech, the right to whisper is a necessary precondition for a free society. Without it, civil society and political freedom become impossible. As the importance of digital communication for civic participation increases, so does the importance of the ability to digitally whisper. LEAP is devoted to making the ability to whisper available to all Internet users.18

While Autocrypt engages email app developers and opts for an in-band approach, LEAP primarily addresses email service providers. The server-side part of LEAP, the LEAP Platform, is also called ‘provider in a box’ and is a ‘set of complementary packages and server recipes automated to lower the barriers of entry for aspiring secure service providers’. The client-side part is called Bitmask, a cross-platform application including a local proxy that a standard email client can connect to, and an easy one-click Virtual Private Network (VPN) service. Bitmask offers full end-to-end encryption, while public keys are automatically discovered and validated. The LEAP project was developed in response to both the crisis of email encryption infrastructure, and usability issues that make it difficult for users to use encryption without compromising their confidentiality and the confidentiality of the people they communicate with.

LEAP’s architecture and protocol design solutions have been forged through discussions with other tech collectives, questioning the ‘coherence’ between certain types of politics and architectural solutions, namely, anti-authoritarian leftist politics and peer-to-peer models. LEAP develops its own philosophy of decentralisation, that is far from being an apology for radical decentralisation or p2p, and quite clearly suggests that a third way is necessary:

There are three architectural models: centralised, federated and peer-to-peer. And LEAP came out of a shared understanding […] about the way in which people with certain type of politics, with anti-authoritarian politics, they bind their politics to a decentralised model and they believe very strongly that all of the technology must follow a decentralised model. And our critique of that was that there are a lot of technical problems with the decentralised model, and that you can’t actually… the politics and the tech architecture… there is some correlation but trying to [correlate them directly] does not work at all. So for all these reasons and many more we were upset with how people from anti-authoritarian politics were mapping this directly to a decentralised architecture which we felt had potential but there are a lot of hard research problems that are unsolved (Elijah Sparrow, LEAP founder).

In response to problems found in both p2p and centralised models, LEAP proposes to initiate a transition of the whole modern encryption ecosystem towards open federated protocols – these can also become an important turn in Internet governance, as they can become an instrument to redistribute power relations and re-decentralise infrastructures, nowadays owned by a minority of big actors:

We felt that we needed a revival of the 1990s. [The] 1990s were like before the craziness of the dotcoms, everything if you wanted to communicate you had to use an open protocol that was federated, that was the way everything worked. […] We felt that… the time was right to take some of the new innovations in the last 20 years and start to turn those into open protocols that can be federated and do not lock people… do not chain them to the monopoly powers of the Internet, Google, Amazon, Microsoft and Apple… (Elijah Sparrow, LEAP founder).

In this sense, LEAP refers to a specific vision of the history of the Internet(s), that postulates the existence of a ‘golden age’ of decentralised open protocols (Oram 2001) – a vision that is controversial within other communities, such as the one gathered around Signal. The same kind of ‘nostalgic’ turn to federation has been observed among Russian tech and privacy-aware user communities, from the growing interest in Matrix.org, to the revival of such formats as XMPP-based ‘microblogging’ as alternatives to Twitter. However, the early-stage federated protocols were accessible only to specific communities of tech-savvy users. Nowadays, as ChatSecure’s lead developer noted in a previously cited quote, setting up and maintaining federated infrastructures for larger segments of the online population is far from easy due to a number of infrastructural, financial and human constraints. In this context, one of the main goals of LEAP is to spread federation by deploying ‘kits’ of interlaced protocols, sets of packages necessary for a quick deployment of a secure infrastructure:

One reason that holds back the federated model is that properly hosting secure services on the web now is very difficult, beyond the reach of people who do not specialize in keeping their servers secure. So we want to be able to encapsulate all the skills and best practices for maintaining an infrastructure into an automated suite that allows people with moderate skill to be able to do it properly (Elijah Sparrow, LEAP founder).

LEAP is mostly built on existing open federated protocols;19 the contribution of the project is understood by its members as the combination of these protocols and their ‘translation’, in Callon’s sense, for easier deployment. LEAP is also interacting with other solutions, such as mixnets, in order to solve important ‘hard’ research problems, including how to keep keys up to date and reduce metadata leaks – problems that are, in fact, linked:

Initial key discovery is only half of the problem. The harder half is your keys up to date. You have to be constantly refreshing them and that potentially leaking a lot of information. That’s particularly where the metadata leaking becomes important. LEAP also works on it [to] build a mixnet infrastructure for different purposes – e-voting and email (Elijah Sparrow, LEAP founder).

As Conversations, LEAP aims at being ‘backwards compatible’, supporting older protocols and older clients without radical transition towards post-PGP protocols; it also aims at supporting different encryption protocols; however, currently, the only supported protocols are OpenPGP and S/MIME. As a consequence, LEAP-based solutions also lack important security properties, such as forward secrecy. However, this is not inherent to LEAP per se but is, more broadly, a problem of the actual state of the email encryption ecosystem; as Sparrow points out, it is ‘baked in the OpenPGP as a protocol itself’. LEAP proposes an alternative solution to the lack of forward secrecy in OpenPGP, which consists in discarding the encryption and signature information once the message is obtained and re-encrypting it in a new format. Forward secrecy is inherent to the specifics of mobile and instant communication, but the LEAP team argues that email usage is very different, including having a different attitude to time and archiving: users do need archives in email, whereas disappearing messages are suitable and needed for IM communication.

On the client side, LEAP contributes to the development of solutions such as Pixelated, an automated mail encryption client which aims at bridging the gap in user experience between existing mainstream proprietary solutions and open-source tools based on a federated infrastructure with a strong encryption dimension (‘that’s the goal. Same user experience’, says Sparrow). Indeed, Pixelated is aimed at a specific audience of users with low technical expertise. As our interviews showed, this tool has been tested inter alia with a community of Brazilian farmers, a radical collective fighting to keep their land.20 As Pixelated’s UI/UX designer notices, the client has been developed for conditions of low-quality Internet connection, and for a user group that has few interactions with email and online services in general.

In Pixelated, key verification is invisible for users and happens automatically. When we assisted at the Pixelated usability workshop at the Chaos Communication Congress in December 2017 (33c3), it was interesting to observe the reaction of its audience (tech-savvy people, frequent GPG users) to Pixelated UI/UX. A number of participants remarked that they did not feel their emails had been encrypted because they had ‘nothing to do’. To them, feeling secure meant the ability to ‘see encryption happening’, possibly with additional effort and user involvement; however, being a hosted/cloud solution, Pixelated is specifically built to place less trust on the client side. This solution turns out to be interesting for specific use-cases, such as journalism and situations of physical device threat/seizure:

Let’s say you’re a journalist […] If you are travelling and doing reporting and crossing borders, your situation changes dramatically. You probably don’t have a device that’s always in your presence that you may trust, and maybe you don’t want to have one. So suddenly it makes sense to have a hosted version and to be able to say may be only on a temporary basis or on a permanent basis, I am gonna move my trust, my most sensitive things like my private keys that unlock my universe of communication archive, I’d like to move that to the web. And the unique thing about what we’re doing with Pixelated and LEAP is that by moving that trust from your personal device to a server, you don’t have to change your trust relationship with your email provider (Elijah Sparrow, LEAP founder).

Conclusions: Community, compatibility, customisation and care – the four Cs of federation

Retracing recent debates on federation in encrypted messaging, this chapter has sought to analyse the shaping of federation as both an infrastructural and a social experiment. We have seen how, in the different examined projects, developers seek to achieve a compromise between high levels of security and better usability, in a constant dialogue with ‘ideological’ motivations such as distributing responsibilities onto a larger number of actors and offer particular versions of online freedom, such as giving users the choice of the level of autonomy they wish to achieve.

We suggest that a tentative systematisation and conceptualisation of what has been seen in this chapter can be attempted with what we will call the ‘four Cs of federation’: community, compatibility, customisation and care. We offer some conclusions about these four aspects below.

In terms of community, (self)-governance and advancement of federated projects implies an important community-driven effort and depends on engaging a variety of service providers and clients into accepting new open protocols or new libraries. Communication and consensus among various projects are needed in order to be able to advance in a federated environment. The transition towards next-generation encryption protocols within federated ecosystems is likely to be slow and difficult; however, our research quite clearly demonstrates the rise of a powerful and diverse community of interested actors involved in a co-production of elements (protocols, packages, libraries and others) necessary to prepare the ecosystem for adopting automatic encryption in federated environments. Autocrypt is one of the core examples of such community-based efforts, now collaborating with K9, Enigmail, Mailpile and other important MUAs and service providers. Conversations (with its underlying OMEMO protocol) is another federated project that undertakes important community-oriented efforts to move the secure messaging ecosystem forward. These efforts are recognised across projects: Elijah Sparrow, the leader of LEAP, remarked in our interview with him that ‘the guy who wrote Conversations… he has done a lot to adapt XMPP, wrote a good demonstration client, and encouraged the servers to support this set. It’s a good example of other “can-be-changed” protocols’.

Federation comes with challenges of ‘compatibility’, which we identify as its ‘second C’. One of the practical examples of compatibility is the so-called ‘backwards compatibility’ that makes a harmonious transition from older to more recent protocols possible, without blocking or boycotting ‘by design’ some of the clients. As seen previously, the field of end-to-end encrypted instant messaging applications is highly competitive, with important tensions happening among protocol and application developers, implementers and open-source community activists. Due to the very nature of centralised and non-interoperable encrypted IMs that ‘lock users’ (as Sparrow puts it) within a tool with specific interfaces and sets of features, IMs compete for users. Email being an open federated ecosystem, it is structured by a number of collaboration and coordination efforts. However, these are not exempt from tensions and points of controversy; besides the difference in the technical approaches of different projects, such debates also involve the necessity to enrol an important number of email app developers in order to implement and spread their solution and being able to secure users.

Federated messaging solutions are currently taking shape as attempts to solve several important challenges experienced by contemporary communication infrastructures: on the one hand, fragmentation of the web and lack of interoperability, concentration of power and aggregation of data by centralised applications and platforms, and on the other hand, the high sociotechnical entry barrier into p2p networks, which necessitates greater expertise and responsibility from users and better performance of their devices.

This is where the ‘third C’, customisation, comes in. Federation offers users the option of choosing among multiple service providers and migrating from one server to another without losing their social graphs. The ‘bigger/better’ paradigm is thus questioned by federated messengers, whose business models do not depend on the number of users or on collecting and aggregating their data. In federated projects, users move beyond the role of ‘data workers’, in the words of Spanish artist and media philosopher Manuel Beltran;21 smaller user groups appear to be easier to manage, and federated architectures make it simpler to customise and localise implementations, adapting them to the needs of a specific user community without losing the ability to interact with broader networks (by developing bridges, bots or other means to ‘plug’ systems to each other). Federation offers space for creativity; small projects proliferate, challenging researchers who fail to document all the various implementations of a given protocol.

At the same time, implementations of a federated protocol are harder to control, and this may create compatibility problems and security vulnerabilities across different instances or clients. A successful development of federated communication tools therefore necessitates new forms of organisation and decision-making, which is especially challenging for loose, decentralised networks. Federated forms of project governance take shape through the variety of ways in which protocol documentation is laid out and improved; constant negotiations across involved actors; physical, often informal, gatherings and new efforts at standardisation. Working standardised or quasi-standardised protocols function as instruments of self-governance, communication and coordination among actors of federated networks – what Yochai Benkler (2006) has called ‘coordination without hierarchy’.

However, federation adds a layer of complexity in the governance of IMs as sociotechnical networks by introducing new key players, notably the system administrators, responsible for the maintenance and growth – the ‘care’ (Denis and Pontille 2015) – of federated infrastructures, our fourth and final ‘C’ of federation. The stability of federated ecosystems depends, as well, on the successful enrolment of maintainers, which requires the development of good documentation and guides with ‘best practices’, and the dissemination of technical expertise through offline educational events for future sysadmins.

In federated systems, ‘caring about the plumbing’ (Musiani 2012) is especially important and acquires an architecture-specific meaning, as no single entity can be counted on to maintain the system as a functioning one, but the necessity of care is distributed across the multiple sysadmins and other actors that manage the different instances in the federation. The growth of federated platforms marks a turn towards community-managed ‘safe spaces’, with more power delegated to human moderators (administrators of email or XMPP servers in the case of Delta Chat or Jabber, or instances in the case of Matrix or Mastodon). This introduces new risks of the re-centralisation of power within federated networks (Raman et al. 2019), requiring more research on the role of infrastructure maintainers, administrators and moderators, besides the core-set of protocol designers.

Among the main challenges of federated messengers are spam and reputation systems, as well as the discoverability of contacts and content that becomes harder without a centralised registry. On federated social networks like Mastodon or Matrix, the absence of data aggregation and filtering algorithms is viewed as beneficial for users’ privacy. However, it is considered by some researchers as a challenge for wider user adoption, because it makes it harder for users to discover relevant topics or find other users (Trienes et al. 2018). At the same time, federated social networks are seen as a beacon of hope by those categories of users whom we call ‘disinformation refugees’ – users who abandon centralised social networks, such as Twitter, because they are tired of disinformation or hate speech.

At the end of this journey through architectural models in secure messaging and their impact on the configuration – social and economic as well as technical – of encrypted messaging tools, we now turn to examine the ways in which actors in the field have attempted to make sense of the ‘mess of messengers’ through initiatives of categorisation and classification. In a field at this level of maturity, these initiatives contribute to shaping and defining what constitutes ‘good’ privacy and security, and what constitutes a well-performing ‘concealing for freedom’ tool.

Notes