HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
matrix-org
synapse
Python2015–2026
matrix-org / synapse · Archived

synapse

Synapse: Matrix homeserver written in Python/Twisted.

Communication & Social
Explore on GitHubRead Hacker News discussions
68Distinct people
116Mentions
1Explicit recommenders
12.1KGitHub stars
REPOSITORY AT A GLANCE

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

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, 7:02:26 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.

01020302015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 14 mentions; 1 submissions, 13 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 23 mentions; 3 submissions, 20 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 17 mentions; 0 submissions, 17 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 30 mentions; 2 submissions, 28 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 9 mentions; 1 submissions, 8 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* 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
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC211
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC707
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC14113
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC23320
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC17017
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC30228
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC707
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC918
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

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 GitHub

What Hacker News says

23 sources
dngray·Jul 26, 2019
and yes.. I agree with nearly everything you said in your post mikekchar. The one thing I would keep in mind is elevating a person's opinion because: "recognized security expert". Their comments should be taken at face value and not given any extra special value because of "who they come from". I purposely leave my background, education and employment out of my comments for that reason. I would not want my opinions to be judged more highly because of where I work. > He doesn't care that it doesn't do the things that it doesn't do because he thinks those things are less important. Just because he doesn't care doesn't make them any less of an issue. On that note Matrix also offers a similar method with the phone number (it's optional to use a phone number) and if you do use it, the identity server can link you with other people that use it.
Read the rest
https://matrix.org/docs/projects/other/sydent (that's also optional, you can run a matrix server without it). Ideally the best usage would be to have two accounts, an account with your phone number you use with people that know you, (family, work etc) and one you use for random people on the internet that does not. Signal laid a lot of the ground work with https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm hopefully now Matrix can take it to the next level (next generation), like email. Their cross-signing stuff looks to be particularly interesting. https://github.com/matrix-org/synapse/issues/4110
In PGP habits could be better
Arathorn·Jun 24, 2019
Matrix project lead here; we've been making steady progress on performance issues, and since we exited beta a few weeks ago (https://matrix.org/blog/2019/06/11/introducing-matrix-1-0-an...) we now have much more bandwidth to improve it. We were consciously following a "make it work, make it work right, make it work fast" philosophy. For instance, as of a few days ago we have a tentative fix for one of the biggest causes of high RAM usage in Synapse (the reference server implementation): https://github.com/matrix-org/synapse/pull/5480. If this tests out okay in the wild it should land in the next release. Meanwhile, my personal server idles at around 600MB of RAM (across a few hundred conversations, some in quite large rooms), although there's room for us to reduce that by at least a factor of 10. It's important to understand that Matrix
Read the rest
is effectively a system for replicating chat history - it's more like USENET or Git than (say) XMPP or IRC. As a result, the resource utilisation depends entirely on the complexity/size of the rooms you participate in. A single person server where that user joins thousands of public chatrooms with hundreds of thousands of users is going to use a lot more RAM than a 10,000 person server where everyone is in small private chats. Finally, a lot of Matrix's reputation for bad performance comes from the fact that the default sqlite database is not remotely optimised at all, and performs horrifically badly as soon as you start federating with the rest of Matrix. You have to use Postgres these days. Also, if you do end up with a heavily used server, you have to manually increase the cache sizing in the config; it doesn't autotune the caches yet. So to conclude: * Run Python3 * Run PostgreSQL * If your users are joining lots of large rooms, you'll need to manually increase the cache factor to avoid hammering the DB. Alternatively, you can now cap the size of rooms your server is allowed to participate in (https://github.com/matrix-org/synapse/issues/5069) ...and you should be relatively fine.
In Ask HN: Preferred chat program compromise between security and UX?
cyphar·Jun 12, 2019
> Can you empower individual... is there essentially a tor mode there? Not at the moment really. There is a tracking bug for it[1] (which includes the idea of supporting .onion homeservers). The main issue I found when digging into it is that Twisted doesn't appear to have a way to set a SOCKS proxy for requests (there are several open bug reports about it) -- meaning that you couldn't get the hidden homeserver to proxy all their connections through Tor nor could you get the other servers to use Tor to contact the hidden homeserver. But I am hoping this could be done eventually. [1]: https://github.com/matrix-org/synapse/issues/5152
In Matrix 1.0 and the Matrix.org Foundation
Arathorn·Apr 30, 2019
Speaking as the project lead for Matrix; we are continuing to work on Synapse's RAM use, and it will only get better over time. One big misconception is that somehow RAM usage is related to the number of users on your server - instead, it's related to the size & complexity of the rooms your users are participating in. In other words, one person who joins thousands of rooms with thousands of users in them will use a lot more RAM than a server with a thousand users who use it only for small group chats. The things to check if your Synapse RAM is high are: * Make sure you're running postgres. Sqlite is not currently usable in production. * Make sure you're running Python 3.7 * Increase the synapse cache factor a bit. * Check for and prune extremities (https://github.com/matrix-org/synapse/issues/1760), which will soon be a thing of the pas
Read the rest
t, but we're not there quite yet. If it's still overloaded, then you need to look at splitting the synapse master process off into workers (https://github.com/matrix-org/synapse/blob/master/docs/worke...) or disabling presence. In terms of whether you get response in the support rooms - whilst the core team has been preoccupied with infrastructure security over the last few weeks, the rest of the community is generally happy to help with synapse tuning and the rooms are far from idle...
In Librem One – A growing bundle of ethical services
Arathorn·Apr 5, 2019
I'm not aware of a bug in how synapse signs events, and whilst it's possible there's a bug there, we can't fix stuff which we're unaware of which hasn't been disclosed. (Max would probably claim he can't disclose because he's been banned from our Github for consistently being obstructive; unfortunately this is a case in point). Edit: he might be talking about https://github.com/matrix-org/synapse/issues/4787? Except that was fixed a month ago... In terms of "don't blindly believe what a for-profit is saying, especially one that is in full control of the said protocol", I'd agree, were it true. However: * These days the protocol is controlled entirely by the non-profit Matrix Foundation. * The majority (3 out of 5) of the Foundation's directors have zero affiliation to New Vector, the company that the core Matrix set up to try to keep the
Read the rest
project funded. * The governance of the foundation & protocol is entirely open, as per https://github.com/matrix-org/matrix-doc/blob/matthew/msc177... * We're announcing the final board once formally appointed; due in the next few weeks. Meanwhile, it's also true to say that you shouldn't believe the skewed perspective of a disgruntled ex-community member with a chip on their shoulder, who is trying to plug their hostile fork: https://news.ycombinator.com/item?id=19473694.
In Matrix 1.0 – Are We Ready Yet?

Showing the 15 most recent of 23 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.