matrix.org is a RESTful HTTP/JSON-based federation protocol for chat, telephony and device messaging (also known as 'Internet of Things').

The developers say they learned from design mistakes made with both IRC and XMPP and studied PSYC, PSYC2 and GNUnet. Let's look at what they came up with.

PROs

• Matrix seems to provide an implementation for distributed state like we always planned for PSYC and only got around doing in the PSYC2 implementation provided with the GNUnet codebase. Distributed state expands the horizon of messaging protocols enormously as it allows to properly model persistent aspects of chatrooms, user profiles and anything worth subscribing like forums, working groups, shared workspaces.
• The Matrix spec doesn't detail how data distribution for pubsub data such as presence and profiles is achieved, but the developers say that multicast strategies for the purpose of achieving scalability are planned.

The following features are cited directly from the spec without accurately checking if they have been met:

• Eventually-consistent cryptographically secure synchronisation of room state across a global open network of federated servers and services
• Sending and receiving extensible messages in a room with (optional) end-to-end encryption
• Extensible user management (inviting, joining, leaving, kicking, banning) mediated by a power-level based user privilege system.
• Extensible room state management (room naming, aliasing, topics, bans)
• Extensible user profile management (avatars, displaynames, etc)
• Use of 3rd Party IDs (3PIDs) such as email addresses, phone numbers, Facebook accounts to authenticate, identify and discover users on Matrix.

These are things that could have been done using PSYC federation, too, but it looks like picking JSON as a "simple" common denominator for all implementations was a priority choice. Given that developers have experimented with other interserver transport protocols, embedding Matrix content in PSYC2 or GNUnet is possible and would transform Matrix quickly from a federated into a distributed technology with its advantages. See below for details.

• Some message codes such as "m.login.oauth2" look like PSYC's keyword inheritance has somewhat been considered, although not explicitly required. Maybe it's worth taking that extra step for future extensibility.

CONs

1. Federation. Click to see the many reasons why we need to get away from it.
2. The spec lists the following as a feature: "Trusted federation of Identity servers for: Publishing user public keys for PKI, Mapping of 3PIDs to Matrix IDs." Why expect users to trust somebody else's identity servers if the public keys can and should themselves be the addressing mechanism? It is the best way to ensure there can be no men in the middle. The uniform concept was cool in the 90s, but it is not leading us to a safe infrastructure. A whole new breed of technologies such as Tor, I2P, RetroShare and secushare uses public-key routing instead of relying on anybody's authorities to identify people. If the public key itself is the identifier, you don't need to look it up anywhere. It is self-authenticating.
3. The provided Security Threat Model lists some very serious security threats. As far as we can tell, none of them apply to the architecture of PSYC2. Surprising.
4. Should multicast be later implemented over a federation architecture, anonymous subscription of content remains a difficult goal. Your server and possibly others in the network will know your private interests like having subscribed a teen star's fan group or the HIV emergency help line. secushare is working on a distributed multicast implementation which allows for anonymous subscriptions.
5. HTTPS is required for interserver communication. The inability to safely handle authentication failures automatically is not addressed in the spec but the developers suggest they intend to proactively distribute certificates around the network in a way akin to Perspectives. This may still fail when a new node behind a MITM enters the network. That's why PSYC2 doesn't use X.509 any longer.
6. JSON isn't as efficient as the PSYC syntax. This becomes relevant with large or encrypted payloads. Matrix is willing to extend to support binary friendly syntaxes.
7. HTTP introduces some overhead when used bidirectionally. Yet another reason to use a different method for inter-node exchange.
8. The syntax described in the spec is less extensible than PSYC as it does not provide inheritance on all levels (M_FORBIDDEN for example cannot be extended into M_FORBIDDEN_TODAY while defaulting to the original behavior).
9. User privilege levels such as required_power_level need not be hardcoded into the main protocol. They are a design detail of one out of many possible conference control implementations and can remain specific to only those nodes that need to use it.
10. The spec doesn't actually provide any examples of end-to-end encrypted content, but we assume this will be addressed.

Regarding point #6 about protocol syntax, here's an example from the spec itself. A message to ban a user from a channel looks like this:

{
  "user_id": "<user id to ban>"
  "reason": "string: <reason for the ban>"
}

This implies that all involved servers will see the possibly embarassing reason for the ban – given that it only takes one of these servers to be tapped, such embarassing reason will get stored into XKeyScore for all times. Cheap servers hosted by large VPS data centers are easy to tap. Only few people own servers that are actually secure from pervasive surveillance. Thus, the servers must not receive this kind of information – it must be end-to-end encrypted. We suggest to at least provide a generic syntax whereby any protocol element can be replaced with an encrypted protocol element. Update: The spec for end-to-end encryption is yet to come. It operates similarely to what this spec already has for "redactions": it somehow allows for random JSON elements to become encrypted. To us it isn't clear how that works and whether that is efficient, so we'll know better some other day.

Coming to a conclusion…

The spec cites the following goals for empowering the end-user:

1. The user should be able to choose the server and clients they use
2. The user should be control how private their communication is
3. The user should know precisely where their data is stored

Since the majority of users has no idea how to set up a server they are not able to freely choose a server – they need to pick somebody else's server and since they don't like that server to look over their shoulders they will rather pick a large company's offering over that of their own school, company or geek friends. By consequence they do not control how private their communication is nor do they really know where their data is stored. It is a good idea not to require accounts on servers at all, that's why instead of pursuing psyced and its federation architecture we moved on to PSYC2. A technology that throws third parties out of the equation, schools and companies alike. We do put data on the network, but in a way that only the user's software is in control of it.

But Matrix isn't in a bad position to migrate away from federation, or build a bridge between the two schools of thought. We have planned for a RESTful API in secushare as well, although it is intended to be a localhost or local network interface for web-based applications. Native applications would rather enjoy the speed and natural binary capabilities of the PSYC2 syntax.

Whereas in the exchange among nodes, which in secushare are technically similar to servers, but may run on personal devices or randomly in the backend of the Internet without the need of a hostname, PSYC2 or even JSON (aww!) payload may be passed around by the GNUnet backend. Although maximum efficiency is welcome since you never know how much battery power the user can provide for her node.

Having something like GNUnet for routing does not automatically mean anonymity but it currently means protection against falsifications, censorship and a few other things in the Matrix threat model. From our perspective it isn't very clear what use there still is in using a regular federation architecture.

Concerning the claim of having learnt from IRC, XMPP and PSYC… yes: If Matrix has a working universal distributed state implementation and is in process of coming up with a generic multicast for it, then this is similar to what PSYC intended to do and a lot more advanced than anything IRC and XMPP came up with. So Matrix is well positioned in the field of scalability – the next challenge is privacy which has proven to be impossible to achieve with the federation architecture.

The authors of Matrix like to conclude from this analysis that Matrix is a better choice if compatibility to legacy federated systems is more important to you than privacy. That is inaccurate. Any non-federation system can still operate gateways to legacy third party systems while delivering the best in privacy for its users. Even if you intend to integrate Facebook for its outreach or to integrate WebRTC for telephony, there is no requirement to combine such gateways with federation if anonymous routing among equal peers can be the answer.

All in all we still cannot find any valid excuse for doing yet another federated system that will not fulfil the promises of control and privacy stated above.