Notes on Self-Hosted Chat Service

I tried Stoat (formerly Revolt), Tailchat and Matrix, and found that there is no perfect solution.

Background

When playing online games, for the sake of convenient communication, a chat software that supports the following features is needed:

• Support multi-platform clients including the Web client
• At least support voice chat
• Besides satisfying basic chat needs, the operation should be user-friendly without too much learning cost
• Be able to complete self-hosting quickly, with clean and simple software library dependencies, without frequent forks or destructive updates

Solution Selection

After searching, the following three open source projects were settled on:

• Stoat, formerly Revolt
• Tailchat
• Matrix

Evaluation and Assessment

All the projects were deployed with docker and tried out; in the end, the experience was hard to put into words.

In short, project forks or destructive updates mean that using a relatively complete older version makes you worry about future updates and migration issues, while the new version representing the future is missing a large number of basic features.

This is also the norm for large human engineering projects: the early design can hardly take all usage scenarios into account, the mid-term faces disagreements over various unforeseen problems, and in the end you either endure the stench of a big ball of mud, or start from scratch hoping to solve all the problems.

However, for open source projects that are already short of resources and rely entirely on the enthusiasm of developers, often one mess becomes two messes…

The following content is recorded as of 2026-07-01. Since all the projects are constantly being updated, please note the timeliness of this article.

Stoat

Its predecessor Revolt received an infringement notice and was renamed Stoat for that reason. Whether in terms of UI style or design philosophy, this is a platform benchmarked against Discord.

Judging from Revolt’s README.md, the last update was 9 months ago, so it is natural to prioritize deploying Stoat.

From the actual experience, although most of the experience has already been made similar to Discord, in March of this year I found that audio calls were not yet supported. Judging from the official roadmap, voice chat was already implemented by the end of 2025, maybe the problem lies in my deployment.

Speaking of deployment, I have to complain: its docker configuration depends on more than a dozen images and several configuration files. Perhaps it is necessary for medium and large communities to rely on this many images to improve scalability and availability, but for small communities of fewer than 20 people, the maintenance cost outweighs the return of use.

All in all, the UI design and user experience are quite mature, and the community maintenance effort is acceptable. The audio and video features are not quite complete, but they should improve in the foreseeable future. End-to-end encryption is on the roadmap; the official position is that this feature involves quite a lot of modifications, and rather than shipping a bad implementation, it is better to bring it out once it is done well. The future is promising.

Tailchat

Text chat is no problem, and audio/video chat can be supported through LiveKit. It is just that the UI design is still a bit immature, after all, there are not many core developers and energy is hard to spare.

It depends on a single-digit number of docker images. Although there are also many configuration files, as long as you follow the official documentation you can basically get it deployed quickly.

However, deploying LiveKit is rather troublesome. If you want to save yourself the trouble, you can directly use the service offered by LiveKit; the free plan is light enough for voice calls, but not enough if you stay connected for long periods.

Compared with Stoat’s complexity, Tailchat is more suitable for small and medium communities. Its author is Chinese, and the Chinese documentation is fairly complete. If you have no special requirements, it is sufficient for daily use.

Matrix

It is quite well known and used by EU governments as a platform for internal communication; it can be said to be one of the role models of open source projects.

Its docker configuration is the least, and the various configuration files are also concise; it is almost ready to use out of the box.

If you do not deploy your own audio/video service images, you can use their audio/video service with the Element web client and the classic Android version. Audio calls are acceptable, but video calls are very blurry.

The newly released X version of the Android client seems to only be able to use a self-deployed audio/video service.

The official seems to be pushing the switch of audio/video calls from LiveKit to its self-developed MatrixRTC. Element had an article in February: Exploring MatrixRTC: Real time communication in rooms

But Matrix is not perfect either; the fragmentation of the open source community is very evident here.

There is a wide variety of clients. Besides the mainstream Element, there are several clients with different philosophies on different platforms, each with different levels of protocol support, resulting in clients with good-looking UIs lacking features, and clients with relatively complete features having very traditional UIs. Here I would call out the difference between Element’s newly released X version Android client and the traditional version.

If client fragmentation only affects the user experience, then server-side fragmentation greatly affects operations work.

Different servers have different levels of protocol support and vastly different development resources, to the extent that you can see people online who, after using one server, want to migrate to another but have to understand the corresponding implementation themselves, manually write scripts to migrate the data, or even fail the migration.

Worse still, some servers are directly discontinued, with developers moving on to other development work, leaving orphaned servers.

If you have no special requirements, to avoid this situation it is recommended to follow the crowd and choose the implementation with the most users.

Summary

The “single responsibility” theory of the Unix design philosophy has proven itself time and again. Looking only at the open source community, the software with the best user experience is almost always software that does only one core thing; the more ambitious the software, the more it faces problems of resource allocation and catering to diverse tastes.

For complex needs, it is almost impossible to find software that fully satisfies them, and at the same time, given the development cost and development cycle, it is also difficult to implement one yourself.

Perhaps in the near future AI will really bring surprises; with the power of AI, you may be able to implement software that meets all your needs at controllable cost in manpower and time…