Introduction to Using the Matrix Chat Server
Translated content generated by a large language model.
What is Matrix
The official introduction from Matrix is: an open network for secure, decentralized communication. This sounds very abstract, but in more everyday terms, Matrix can be understood as the “email protocol of the instant messaging world.”
When using email, you do not need to register with the same email service as your friends. One person can use Gmail, another can use Outlook, and someone else can run their own mail server. As long as these servers follow the same mail protocol, they can send and receive mail to and from each other. Matrix is designed to solve a similar problem: chatting should not be inherently tied to a particular company, a particular app, or a particular closed account system.
So Matrix is not a standalone chat app first and foremost, but a set of open protocols and an ecosystem built around them. You can log in to a Matrix account with clients such as Element, FluffyChat, or Cinny; you can also choose a public homeserver like matrix.org, or deploy your own server implementation such as Synapse, Conduit, or Dendrite. Accounts usually look like @username:example.com, where the first part is the username and the second part is the domain name of the service, which is very similar to an email address.
Matrix’s core value comes from this: it separates the “communication protocol” from the “specific service provider.” In products like WeChat, QQ, WhatsApp, Telegram, and Signal, the protocol, server, client, account system, and operating rules are usually all controlled by the same company; Matrix is more like a public communication infrastructure that can be jointly operated by different people.
What a Matrix service looks like
A basic Matrix chat service is generally made up of three parts: client, homeserver, and federation communication.
The client is responsible for the interface users actually see: message lists, rooms, emojis, files, notifications, audio/video entry points, and verification prompts related to end-to-end encryption. The client itself usually does not directly communicate with the other party’s device, but connects to the homeserver that the account belongs to. For example, after @alice:example.com logs in to Element, Element interacts with the example.com homeserver through the Matrix Client-Server API.
The homeserver is responsible for storing accounts, room state, message events, device lists, the public part of key material, and synchronizing room history with other servers. Messages in Matrix are not simply database records, but individual events. Sending a message, changing an avatar, joining a room, retracting a message, or changing a room name are all, in essence, events. The homeserver organizes these events into room history and synchronizes them between other homeservers participating in the same room.
Federation communication is the most obvious difference between Matrix and ordinary centralized chat services. Suppose Alice’s account is on alice.com and Bob’s account is on bob.com. After both join the same room, a message sent by Alice first reaches the homeserver on alice.com, and then it is synchronized to bob.com via the Server-Server API. Bob’s client only needs to fetch updates from bob.com. To users, this feels like chatting in the same group; to servers, it means multiple servers jointly maintaining a room state.
The result of this architecture is that Matrix can naturally support cross-provider communication and can also support bridge services. A bridge is a connection between a Matrix room and external platforms such as IRC, Discord, Slack, and Telegram. A bridge is not always perfect, because different platforms have different permissions, message formats, and deletion semantics, but it reflects an important direction of Matrix: turning the chat system into an open, interconnected network.
Audio and video chats follow a similar idea. The simplest one-to-one call can use WebRTC to establish a media connection between two clients, while the Matrix room is responsible for passing call invitations, device information, and session state. Multi-person calls are much more complicated, because having each client connect directly to every other client quickly consumes bandwidth and CPU, so implementations such as Element Call typically use Matrix as the identity, room, and signaling layer, while working with dedicated media services or an SFU (Selective Forwarding Unit) to relay audio and video streams. In other words, Matrix is not only about “chat text”; it also includes open chat, where text messages, files, emoji reactions, and call entry points can all live within the same room model.
Compared with commercial chat services
If you only look at the onboarding experience, Matrix is not necessarily easier than WeChat, QQ, WhatsApp, Telegram, or Signal. The advantages of commercial chat services are very clear: download the official app, bind a phone number or account, automatically discover contacts, and start chatting directly. Most of the complexity is hidden by the platform, and users do not even need to know where the servers are.
But this convenience comes at a cost. Centralized platforms usually decide what clients you can use, where your messages and contact data are stored, whether your account can be banned, whether you can export your history, whether third-party clients are allowed, and whether users have any choice when the service stops or changes its rules. Even if some platforms provide end-to-end encryption, users still have to trust their client distribution, account system, metadata handling, and operating policies.
Matrix’s advantages are exactly in these areas. Its protocol and mainstream implementations are open source, the server can be self-hosted, clients can be replaced, and rooms can communicate across federated servers. You can choose public services, or place your account and rooms under your own domain; you can use official or third-party clients, or develop your own tools to integrate with it. For individuals, small teams, communities, and organizations that want to retain control over their infrastructure, this controllability is very important. Service hosts can also combine different features according to their own needs, retaining a great deal of independence and customization.
In terms of privacy, Matrix supports end-to-end encryption. When encryption is enabled, room message content is encrypted and decrypted by participants’ devices, and the homeserver can theoretically only see encrypted events, senders, receiving rooms, timestamps, and other necessary metadata, but cannot directly read the message body. End-to-end encryption downgrades the server from a “central database storing readable message content” to “an infrastructure that synchronizes encrypted events and state.”
That said, Matrix is not without costs. First, its usage logic differs from ordinary chat software. Users need to understand concepts such as homeservers, Matrix IDs, rooms, spaces, and device verification; cross-server communication can sometimes run into latency, avatar or attachment loading failures, and differences in public room directories. Second, self-hosting does not equal absolute security. You still need to trust the server software you deploy, the operating system, reverse proxy, database, backup strategy, and administrator actions. Finally, self-hosting also has real-world costs: domain names, servers, storage, email notifications, monitoring, upgrades, abuse handling, and backup recovery all require long-term maintenance.
So a more accurate statement is: Matrix gives choice back to users and communities, but choice is not free. It is suitable for people willing to bear extra complexity in exchange for openness, portability, and control, but not necessarily for all scenarios where people just want to “chat with family and friends right away.”
Compared with other open-source chat protocols
Matrix is not the first open chat protocol. IRC and XMPP both came earlier and have influenced internet communication for a long time.
IRC’s advantages are simplicity, lightness, and a long history. Many open-source communities still have IRC channels today. It is suitable for public rooms, text discussion, and bot integration. But IRC’s underlying model is relatively old; offline messages, multi-device synchronization, history, media attachments, end-to-end encryption, identity verification, and mobile push notifications are not its native strengths. Many capabilities can be added through server extensions, bouncers, or client conventions, but the overall experience is hard to compare with modern chat software, and it often feels like an ancient chat room from a bygone era.
XMPP is closer to Matrix’s goal: it is also an open, federated communication protocol, and it has many extension protocols to support group chats, file transfer, encryption, voice/video, and other functions. The problem is that XMPP’s ecosystem has long relied heavily on a combination of extensions, and different servers and clients do not fully support the same XEPs, so real interoperability often depends on the specific implementation. For technical users, this may be acceptable, but for ordinary users, whether a feature works often becomes a question of whether “client A, server B, and extension C all happen to support it.”
Matrix’s relative advantage is that it was designed from the start around the modern chat experience: room history, multi-device synchronization, images and files, message editing and retraction, emoji reactions, rich text, end-to-end encryption, bridges, space organization, and client/server APIs are all core issues in its ecosystem. It may not be lighter than IRC or XMPP, but it is more like an attempt to reproduce the modern experience that users have already grown accustomed to in commercial chat software, using an open protocol.
Of course, this also means Matrix is more complex. Homeservers such as Synapse have much higher resource requirements than traditional IRC services; encryption, multi-device support, federation state resolution, and media handling all add maintenance costs. Matrix’s direction is not “the smallest possible chat protocol,” but “an open modern communication network.” These two trade-offs are not the same.
End-to-end encryption and new device verification
The features that most often confuse new Matrix users are end-to-end encryption and device verification.
The goal of end-to-end encryption is straightforward: messages are encrypted on the sending device and decrypted on the receiving device, and the homeserver in the middle should not be able to read the plaintext. Matrix’s encryption implementation places great importance on “devices.” Logging into the same account on a phone, computer, or browser is usually treated as multiple devices, each with its own identity key and session key. The advantage is that a leak on one device does not automatically mean all devices are compromised; the downside is that users will see more verification steps than in ordinary chat software.
The most common scenario is logging in on a new device. For example, you are already logged in to Matrix on your phone, and then you log in again in a browser on your computer. When the new device first logs in, it has not yet been confirmed by other trusted devices. The client may prompt you to use another logged-in device to scan a code, or compare a set of emoji / numbers. This process is somewhat like two-factor authentication, and its purpose is to confirm that “this new device really belongs to me,” preventing someone who has obtained your account password from secretly joining your encrypted sessions.
After verification is complete, trusted devices can securely share the necessary room keys with the new device. Otherwise, the new device may only be able to see messages received after login, may not be able to see the history in encrypted rooms from before that, or may show prompts like “unable to decrypt this message.” This is the result of end-to-end encryption: without plaintext, the server cannot magically decrypt old messages for you.
Another common issue is the recovery key. Many clients will ask you to set a security phrase or save a recovery key, which is used to restore access to encrypted messages when no old device is available. This key is extremely important: if you forget it and all old devices are lost, you may truly be unable to recover historical encrypted messages; if it is leaked, someone else may be able to import your encrypted backup. So it is more like the master password of a password manager than an ordinary verification code.
Another easily misunderstood point is that end-to-end encryption protects message content, not all information. The homeserver still needs to know the account, room, event times, device list, some membership relationships, and traffic patterns, otherwise the system cannot synchronize messages and manage rooms. Matrix’s privacy protection is strong in its open protocol, optional server choice, auditable clients, and encrypted message content, but it is not an anonymous network, nor is it a tool that erases all traces of communication.
Summary
Matrix is suitable for people who think of chat as infrastructure. It is not like WeChat or WhatsApp, which wrap everything into a closed product, nor like IRC, which remains in a very lightweight text-only era. It is more like email: open protocol, optional services, replaceable clients, and it can be used with public services or self-hosted.
Its advantages are open source, federation, self-hosting, bridge support, and support for modern chat needs such as end-to-end encryption, multi-device synchronization, file transfer, and audio/video capabilities. Its disadvantages are also very real: more concepts, an experience that is sometimes less smooth than centralized platforms, and the need to take on server, trust, cost, and long-term maintenance responsibilities when self-hosting.
If you are only looking for a chat app that friends and family can start using immediately, Matrix may not be the most convenient choice. But if you care about the openness, portability, and data control of communication systems, Matrix is one of the few modern solutions that is truly worth trying seriously.
References:
评论系统尚未配置。请在 .env 中填写 giscus 所需的环境变量。