The admin APIs are at https://github.com/matrix-org/synapse/tree/develop/docs/admi... and are fairly comprehensive. Agreed it's a screw-up that we don't provide an official web UI for it (but https://github.com/Awesome-Technologies/synapse-admin is pretty good).
I have no idea why you think it'd be acceptable for your server to randomly delete old messages from under you by default - I'd go nuts if my IMAP server or filesystem decided to spontaneously expire old data by default.
However, it's easy enough to flip the bit in the config to do so: https://github.com/matrix-org/synapse/blob/ca2db5dd0c9fc430a.... If this is something that makes you hateful, I'm not sure it's Matrix's problem.
In terms of Element: yes, software has bugs, and we're working through them. weechat-matrix is very usable too, as is FluffyChat and a bunch of others.
In Using Matrix to replace proprietary and centralized chat appsmatrix-org
synapse
Python2015–2026
matrix-org / synapse · Archived
synapse
Synapse: Matrix homeserver written in Python/Twisted.
68Distinct people
116Mentions
1Explicit recommenders
12.1KGitHub stars
What to know before exploring
What it is
Synapse: Matrix homeserver written in Python/Twisted.
GitHub
Where it is used
The source check is incomplete. Verified examples will appear here.
What people are saying
I use AVENTER-UG's docker-matrix container for Synapse, and a separate VM for PostgreSQL. Element-web I currently upgrade straight from the tarballs. Upgrades are fairly…
snerbles used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- matrix-org/matrix-spec-proposals · linked in 10 of the same discussions
- element-hq/element-web · linked in 7 of the same discussions
- awesome-technologies/synapse-admin · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:02:05 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year116 dated mentions
Observed mentions: 2015-02-05 16:06:38 UTC to 2026-02-13 02:28:43 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 14 | 1 | 13 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 23 | 3 | 20 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 17 | 0 | 17 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 30 | 2 | 28 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Synapse
Synapse is now actively maintained at element-hq/synapse
Synapse is an open-source Matrix homeserver developed
from 2019 through 2023 as part of the Matrix.org Foundation. The Matrix.org
Foundation is not able to resource maintenance of Synapse and it
continues to be developed by Element;
additionally you have the choice of other Matrix homeservers.
See The future of Synapse and Dendrite
blog post for more information.
Briefly, Matrix is an open standard for communications on the internet, supporting
federation, encryption and VoIP. Matrix.org has more to say about the goals of the
Matrix project, and the formal specification describes the technical details.
Contents
Synapse is now actively maintained at element-hq/synapse
Installing and configuration
Using a reverse proxy with Synapse
Upgrading an existing Synapse
Platform dependencies
Security note
Testing a new installation
Registering a new user from a client
Troubleshooting and support
Identity Servers
Development
Installing and configuration
The Synapse documentation describes how to install Synapse. We recommend using
Docker images or Debian packages from Matrix.org.
Synapse has a variety of config options
which can be used to customise its behaviour after installation.
There are additional details on how to configure Synapse for federation here.
Using a reverse proxy with Synapse
It is recommended to put a reverse proxy such as
nginx,
Apache,
Caddy,
HAProxy or
relayd in front of Synapse. One advantage of
doing so is that it means that you can expose the default https port (443) to
Matrix clients without needing to run Synapse with root privileges.
For information on configuring one, see the reverse proxy docs.
Upgrading an existing Synapse
The instructions for upgrading Synapse are in the upgrade notes.
Please check these instructions as upgrading may require extra steps for some
versions of Synapse.
Platform dependencies
Synapse uses a number of platform dependencies such as Python and PostgreSQL,
and aims to follow supported upstream versions. See the
deprecation policy
for more details.
Security note
Matrix serves raw, user-supplied data in some APIs -- specifically the content
repository endpoints.
Whilst we make a reasonable effort to mitigate against XSS attacks (for
instance, by using CSP), a Matrix homeserver should not be hosted on a
domain hosting other web applications. This especially applies to sharing
the domain with Matrix web clients and other sensitive applications like
webmail. See
https://developer.github.com/changes/2014-04-25-user-content-security for more
information.
Ideally, the homeserver should not simply be on a different subdomain, but on
a completely different registered domain (also known as top-level site or
eTLD+1). This is because some attacks are still possible as long as the two
applications share the same registered domain.
To illustrate this with an example, if your Element Web or other sensitive web
application is hosted on A.example1.com, you should ideally host Synapse on
example2.com. Some amount of protection is offered by hosting on
B.example1.com instead, so this is also acceptable in some scenarios.
However, you should not host your Synapse on A.example1.com.
Note that all of the above refers exclusively to the domain used in Synapse's
public_baseurl setting. In particular, it has no bearing on the domain
mentioned in MXIDs hosted on that server.
Following this advice ensures that even if an XSS is found in Synapse, the
impact to other applications will be minimal.
Testing a new installation
The easiest way to try out your new Synapse installation is by connecting to it
from a web client.
Unless you are running a test instance of Synapse on your local machine, in
general, you will need to enable TLS support before you can successfully
connect from a client: see
TLS certificates.
An easy way to get started is to login or register via Element at
https://app.element.io/#/login or https://app.element.io/#/register respectively.
You will need to change the server you are logging into from matrix.org
and instead specify a Homeserver URL of https://<server_name>:8448
(or just https://<server_name> if you are using a reverse proxy).
If you prefer to use another client, refer to our
client breakdown.
If all goes well you should at least be able to log in, create a room, and
start sending messages.
Registering a new user from a client
By default, registration of new users via Matrix clients is disabled. To enable
it:
In the
registration config section
set enable_registration: true in homeserver.yaml.
Then either:
set up a CAPTCHA, or
set enable_registration_without_verification: true in homeserver.yaml.
We strongly recommend using a CAPTCHA, particularly if your homeserver is exposed to
the public internet. Without it, anyone can freely register accounts on your homeserver.
This can be exploited by attackers to create spambots targetting the rest of the Matrix
federation.
Your new user name will be formed partly from the server_name, and partly
from a localpart you specify when you create the account. Your name will take
the form of:
@localpart:my.domain.name
(pronounced "at localpart on my dot domain dot name").
As when logging in, you will need to specify a "Custom server". Specify your
desired localpart in the 'User name' box.
Troubleshooting and support
The Admin FAQ
includes tips on dealing with some common problems. For more details, see
Synapse's wider documentation.
For additional support installing or managing Synapse, please ask in the community
support room #synapse:matrix.org (from a matrix.org account if necessary). We do not use GitHub
issues for support requests, only for bug reports and feature requests.
Identity Servers
Identity servers have the job of mapping email addresses and other 3rd Party
IDs (3PIDs) to Matrix user IDs, as well as verifying the ownership of 3PIDs
before creating that mapping.
They are not where accounts or credenti
Read the full README on GitHubWhat Hacker News says
17 sources> meaning no data is accessible to third parties--unlike Matrix, which is federated
I acknowledge that this isn't an option for everyone but for the HN crowd, it's fairly easy to run your own homeserver. You just need to install Synapse [0] (which has a convenient Docker image [1]) and give your server a domain name.
If you do this, your metadata will only be accessible to yourself and the homeservers of your contacts (who could share your server or run their own).
Message contents are usually e2e encrypted, so the homeserver you use is irrelevant.
[0]: https://github.com/matrix-org/synapse
[1]: https://hub.docker.com/r/matrixdotorg/synapse/
In Matrix – An open network for secure, decentralized communicationThis bug is not generally a significant cause of disk space utilisation, unless you’re running a server the size of matrix.org (which is the only reason it’s marked P1).
I strongly suspect you’re thinking of a separate issue: the need to automatically expire old history and reclaim disk space in general, which was fixed a while back, as per https://github.com/matrix-org/synapse/blob/master/docs/messa...
In Matrix – An open network for secure, decentralized communicationPlease, Synapse isn’t production ready, at all. See this issue for example: https://github.com/matrix-org/synapse/issues/3364, reported back in 2018, labelled highest priority since then and still not fixed. This is indeed a huge problem, because if you don’t have shit tons of money to put in your database server’s storage you’ll quickly get stuck. Some workarounds mentioned are non-safe hacks and shouldn’t be necessary for a production ready messaging server.
In Matrix – An open network for secure, decentralized communicationThere's a lot of stale/wrong info here. I'd say that we have pretty healthy competition in homeserver implementation these days. The four options currently in active development are Synapse (Python), Dendrite (Go), Conduit (Rust) and Construct (C++).
In terms of Synapse (https://github.com/matrix-org/synapse): originally the initial prototype for Matrix, historically it had performance and architectural issues given we were frantically implementing features to prove Matrix rather focusing on perf. Since hitting 1.0 a year ago though things have improved massively. Almost all of Synapse scales horizontally; we've switched to Python 3 and have almost finished switching to asyncio (improving perf and maintenance massively); and lots of schema perf issues have been shaken out. Unsure what you're thinking about w.r.t. "restart its synchro
Read the rest
trons", but that just sounds like a bug that got shaken out years ago.
Dendrite (https://github.com/matrix-org/dendrite), meanwhile, is in very active dev by the core Matrix team - there was a long hiatus while we had to focus exclusively on Synapse, but since the beginning of this year there are folks working fulltime on it, and it's looking super promising as a very microservices-driven model, with each service scaling arbitrarily horizontally, connected via append-only logs. All the P2P Matrix work is built on it (running it clientside, as it's such small footprint). It's effectively in competition with Synapse, and worked on by different teams. It federates today and can be run as late alpha, but the CS API is missing some features that we're currently adding.
Conduit (https://conduit.rs) is the new kid on the block, written by the community in Rust, using a strictly monolithic structure for now, using Sled as a key value store for storage. It's incredibly fast, and has impressively good CS API coverage (including E2EE, whereas Dendrite's E2EE support is only landing this week), but federation work hasn't begun yet (which is a bit worrying, as you need to design/build with federation in mind from square 1). It has a great community though, and is entirely independent of the core Matrix team, and you could say it's in competition with Dendrite.
Construct (https://github.com/matrix-construct/construct) is a C++ server using rocksdb for storage. It's a community project entirely independent of the core Matrix team; it federates, and has extensive CS API coverage, but unfortunately the project's author has been incredibly antagonistic to the core Matrix team over the years, which makes it rather hard for us to comment further.
TL;DR: Matrix homeserver dev is in a good place right now :)
I installed my homeserver with this!
https://github.com/matrix-org/synapse/blob/master/INSTALL.md
In P2P MatrixJoining big rooms is still slow because you currently have to check the keys of every server in the room before you know whether to trust the events in that room; we're fixing this with MSC1228 (using keys as identifiers so you don't have to separately check the keys).
Once you're in, though, performance has improved 2-3x over the last year, and there's easily 10-100x more improvements to be made one way or another. We're also about to add active/active clustering in Synapse at last, which should make bigger servers zippy.
In terms of receiving traffic after you've torn down the server; this is equivalent to getting people trying to talk SMTP to you on port 25 years after you've taken down your MTA. You can mitigate it by explicitly leaving all the rooms on your server before you tear it down, though; i've just filed a bug at https://gi
Read the rest
thub.com/matrix-org/synapse/issues/7551 to track maintaining a script to do so.
Sorry you've had a crap time so far though :(
No, it looks like threads aren't (yet) supported in either Riot or the Matrix spec.
https://github.com/matrix-org/synapse/issues/2329
https://github.com/vector-im/riot-web/issues/2349
In Cross-signing and end-to-end encryption by defaultWell, if search didn't find the room, it sounds like a plain old bug. (Or was the room marked ex-directory?) If you can file details at https://github.com/matrix-org/synapse/issues we'll dig into it.
And noted, in terms of the version number being in the wrong place on Riot/Web.
In Zoom Acquires KeybaseThe GUI search should work fine these days. (It was broken about 6 months ago due to the room lists getting too big, but was fixed in https://github.com/matrix-org/synapse/pull/6019).
It's true you have to pick a server to use, but we try to provide decent defaults (although it's true matrix.org has been overloaded recently).
We're trying to simplify onboarding via P2P Matrix - by default, you'd start off entirely P2P, and only pick a server if you want to 'anchor' your account somewhere.
I have a feeling you may be going off outdated impressions here; we've been desperately trying to improve UI/UX (as per https://blog.riot.im/e2e-encryption-by-default-cross-signing... and https://blog.riot.im/e2e-encryption-by-default-cross-signing...).
In Zoom Acquires KeybaseWe've had per-room/per-message retention policies in Matrix for months now (although Riot hasn't exposed UX to configure them yet, as we were drowning in cross-signing work).
https://github.com/matrix-org/synapse/blob/master/docs/messa... has the details.
In Zoom Acquires KeybaseWhat you want is named delegation and there is a document about it in the synapse repository:
https://github.com/matrix-org/synapse/blob/master/docs/deleg...
Just in case you weren't already aware of it :)
In Running your own secure communication service with Matrix and JitsiTo be clear - Docker & Helm installations of course exist for Synapse:
* https://github.com/matrix-org/synapse/blob/master/INSTALL.md... is the official Docker instructions
* https://github.com/dacruz21/matrix-chart is a Helm one
etc
In Running your own secure communication service with Matrix and JitsiI installed Matrix behind Caddy, so I followed:
- The archlinux guide: https://wiki.archlinux.org/index.php/Matrix
- The official doc of running it behind a proxy: https://github.com/matrix-org/synapse/blob/master/docs/rever...
I couldn't really test if it worked as-is, so I needed to install Riot web, still behind a proxy. It was also going to be my client of choice. That's where things got fun:
- Installing the arch package doesn't do anything, it's just a bunch of static files, so you have to know how to serve them after that
- Riot needs to go to your matrix's /.well-known/matrix/client, so you need to redirect it to your synapse server (and the previous redirect is not enough, because the previous redirect only cares about _matrix, not the root level)
- It failed for me because a setting in the synapse config (server_name) wasn't set
Read the rest
, so I had to read the code of synapse to understand how this well-known endpoint is served.
All in all it was still doable, but took more manual steps than I expected.
> How much power is needed to comfortably join a massive room?
"At least 1GB of free RAM if you want to join large public rooms like #matrix:matrix.org" https://github.com/matrix-org/synapse/blob/master/INSTALL.md...
In Moznet IRC is dead; long live Mozilla MatrixShowing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.