Matrix

Matrix is an open standard for interoperable, decentralised, real-time communication over IP. It can be used anywhere you need a standard HTTP API for publishing and subscribing to data whilst tracking the conversation history - matrix.org

It can be used to power Instant Messaging, VoIP/WebRTC signalling, or Internet of Things communication

Widgets are a deceptively simple idea: the ability to pin small form-factor webapps (called widgets) into a given Matrix room, letting admins build up a dashboard of functionality which is then in common and automatically available to everyone who views that room. You can think of it as being similar to installing an app onto a smartphone, but instead pulling it into a Matrix conversation.

This could be a Jitsi video conference, or a collaborative document editor, or a Grafana dashboard, or anything you can imagine really (assuming its security headers support embedding) - matrix.org

You can find us at the above address on the matrix :)

Here we list some ideas and ways we could build a decentralised federation using Matrix.

Matrix defines APIs for synchronising extensible JSON objects known as "events" between compatible clients, servers and services - matrix.org

Clients are typically messaging/VoIP applications or IoT devices/hubs and communicate by synchronising communication history with their "homeserver" using the "Client-Server API".

Each homeserver stores the communication history and account information for all of its clients, and shares data with the wider Matrix ecosystem by synchronising communication history with other homeservers and their clients.

Clients typically communicate with each other by emitting events in the context of a virtual "room". Room data is replicated across all of the homeservers whose users are participating in a given room.

As such, no single homeserver has control or ownership over a given room. Homeservers model communication history as a partially ordered graph of events known as the room's "event graph", which is synchronised with eventual consistency between the participating servers using the "Server-Server API".

This process of synchronising shared conversation history between homeservers run by different parties is called "Federation". Matrix optimises for the the Availability and Partition tolerance properties of CAP theorem at the expense of Consistency.

For example, for client A to send a message to client B, client A performs an HTTP PUT of the required JSON event on its homeserver (HS) using the client-server API.

A's HS appends this event to its copy of the room's event graph, signing the message in the context of the graph for integrity. A's HS then replicates the message to B's HS by performing an HTTP PUT using the server-server API.

B's HS authenticates the request, validates the event's signature, authorises the event's contents and then adds it to its copy of the room's event graph. Client B then receives the message from his homeserver via a long-lived GET request.

Matrix defines the standard, and provides open source reference implementations of Matrix-compatible Servers, Clients, Client SDKs and Application Services to help you create new communication solutions or extend the capabilities and reach of existing ones.

Matrix’s initial goal is to fix the problem of fragmented IP communications: letting users message and call each other without having to care what app the other user is on - making it as easy as sending an email.

The longer term goal is for Matrix to act as a generic HTTP messaging and data synchronisation system for the whole web - allowing people, services and devices to easily communicate with each other, empowering users to own and control their data and select the services and vendors they want to use.

The actual ecosystem and community of everyone running Matrix servers and services Loads of 3rd party contributions of clients, SDKs, servers and services.

You can find the full list of Matrix enabled projects at matrix.org

Federation allows separate deployments of a communication service to communicate with each other - for instance a mail server run by Google federates with a mail server run by Microsoft when you send email from @gmail.com to @hotmail.com.

Federation is different to interoperability, as interoperable clients may simply be running on the same deployment - whereas in federation the deployments themselves are exchanging data in a compatible manner.

Matrix provides open federation - meaning that anyone on the internet can join into the Matrix ecosystem by deploying their own server.

The aim is to provide an analogous ecosystem to email - one where you can communicate with pretty much anyone, without caring what app or server they are using, using whichever app & server you chose to use, and use a neutral identity system like an e-mail address or phone number to discover people to talk to.

Whatever the legal structure, we are committed to keeping the Matrix project open.

Most of the current core contributors to Matrix work at Amdocs, who have kindly given us permission to work on Matrix as an independent non-profit initiative. Other contributors are funded by their own employers or donate their own time to the project.

The core team is ~10 people with extensive experience in building custom VoIP and Messaging apps for mobile network operators. Most of us have day jobs at Amdocs or OpenMarket, but there are an increasing number of contributors from other companies and folks all over the internet.

We are called Matrix because we provide a structure in which all communication can be matrixed together. No, it’s nothing to do with the film (although you could go and build virtual worlds on top of Matrix if you wanted :)