Documentation

Find the user Documentation here → Documentation

How does it work

Matrix is an open standard for interoperable, decentralised, real-time communication over IP. It can be used to power Instant Messaging, VoIP / WebRTC signalling, Internet of Things communication - or anywhere you need a standard HTTP API for publishing and subscribing to data whilst tracking the conversation history. Matrix defines the standard, and provides open source reference implementations of Matrix-compatible Servers, Client SDKs and Application Services to help you create new communication solutions or extend the capabilities and reach of existing ones.  Want to know who is behind it and why they create such a useful project for the public for free? Read on in the offical matrix.org FAQ.

The webclient chat.ethz.ch is configured to use the Jitsi server of SWITCH for video conferences. Attention: we currently only guarantee that the webclient chat.ethz.ch is using SWITCH, any other clients may use a third party provider of a Jisti installation.

Terminology

• Homeserver: Each account in the Matrix federation is associated with a single homeserver. The software running at this server stores the history and account information for that user. Homeservers synchronise message history with other homeservers.
• Federation: Federation means that separate instances of a service communicate - the best example of this is email servers, in which it’s possible to send mail between difference service providers. For Matrix, this means that data about rooms and message history is shared between matrix servers of participating users.
• Riot/Element: Element, previously known as "Riot" is a popular matrix client developed by the core matrix.org team. It is also accessable via https://chat.ethz.ch. 
• MXID: Matrix user IDs (MXID) are unique user IDs. They are in the format @username:staffchat.ethz.ch.
• Sigil: Sigils refer the symbols uses at the beginning of many matrix identifiers. For example @ is used for users, # for rooms, and + for communities.
• Community: Communities (groups) are collections of rooms.
• Room: A room is a fundamental building bock of the matrix architecture: events are typically sent in the context of a room. A room is a conceptual place where users can send and receive events. Events are sent to a room, and all participants in that room with sufficient access will receive the event.
• Jitsi: A service used for video conferencing. 

Homeserver Synapse

We host a Synapse Matrix Homeserver for the domain staffchat.ethz.ch. It holds user account data, message history, media uploads, room aliases, communities and participates in the Matrix federation network.

Clients

To connect to the Matrix server, you will need to use a client. As as member of ETH, we recommend using Element. Other Matrix clients that are availalbe as of today can be found here. To get started using Matrix, see get started. Clients allow you to connect to a homeserver to send/receive messages. Your homeserver stores a copy of the message history of every room you participate in. Homeservers connect to other homeservers on the internet and synchronize the message history of federated rooms.

Federation

Federation is the process by which users on different servers can participate in the same room. As soon as a Matrix user from another homeserver joins your room (either via an invitation to a private room or by joining a public room), the corresponding homeservers will start to sync the message history of that room. If one of the participating homeservers is offline, the users on other homeservers can continue talking in that room. This is called decentralization. 

Users

Each client is associated with a user account, which is identified in Matrix using a unique user ID. This ID is namespaced to the homeserver which allocated the account and has the form:
@localpart:domain

Events

All data exchanged over Matrix is expressed as an event. Typically each client action (e.g. sending a message) correlates with exactly one event. Each event has a type which is used to differentiate different kinds of data. The special top-level namespace m. is reserved for events defined in the Matrix specification - for instance m.room.message is the event type for instant messages. Events are usually sent in the context of a Room.

Room

A room is a conceptual place where users can send and receive events. Events are sent to a room, and all participants in that room with sufficient access will receive the event.
Rooms are uniquely identified internally via Room IDs, which have the form: 

!unique_id:domain

There is exactly one room ID for each room. Whilst the room ID does contain a domain, it is simply for globally namespacing room IDs. The room does NOT reside on the domain specified.

Room Alias

Each room can also have multiple Room Aliases, which look like: 

#room_alias:domain

A room alias “points” to a room ID and is the human-readable label by which rooms are publicised and discovered.

Room Version

Rooms are central to how Matrix operates, and have strict rules for what is allowed to be contained within them. Rooms can also have various algorithms that handle different tasks.To allow rooms to be improved upon through new algorithms or rules, “room versions” are employed to manage a set of expectations for each room. New room versions are assigned as needed