synapse

Synapse: Matrix homeserver written in Python/Twisted.

11,806

2,128

11,806

1,530

View on GitHub

Top Related Projects

element-web

11,133

A glossy Matrix collaboration client for the web.

1,300

A Matrix-Telegram hybrid puppeting/relaybot bridge

1,246

A Matrix-WhatsApp puppeting bridge

matrix-docker-ansible-deploy

4,812

🐳 Matrix (An open network for secure, decentralized communication) server setup using Ansible and Docker

bridge between mattermost, IRC, gitter, xmpp, slack, discord, telegram, rocketchat, twitch, ssh-chat, zulip, whatsapp, keybase, matrix, microsoft teams, nextcloud, mumble, vk and more with REST API (mattermost not required!)

dendrite

5,708

Dendrite is a second-generation Matrix homeserver written in Go!

Quick Overview

Synapse is the reference homeserver implementation for the Matrix protocol, an open standard for secure, decentralized, real-time communication. It provides the server-side functionality for Matrix-based applications, enabling features like instant messaging, VoIP, and IoT communication across a federated network.

Pros

Decentralized architecture, allowing for greater privacy and control over data
Supports end-to-end encryption for secure communications
Highly scalable and can handle large numbers of users and rooms
Extensive API for integration with other services and applications

Cons

Can be resource-intensive, especially for larger deployments
Setup and configuration can be complex for beginners
Federation can sometimes lead to performance issues or inconsistencies
Requires ongoing maintenance and updates to ensure security and stability

Getting Started

To set up a basic Synapse server:

Install Synapse:

pip install matrix-synapse

Generate a configuration file:

python -m synapse.app.homeserver \
    --server-name my.domain.name \
    --config-path homeserver.yaml \
    --generate-config \
    --report-stats=yes

Start the Synapse server:

synctl start

For a more detailed setup, including database configuration and reverse proxy setup, refer to the official Synapse documentation.

Competitor Comparisons

element-web

11,133

A glossy Matrix collaboration client for the web.

Pros of Element Web

User-friendly web interface for Matrix, making it more accessible to end-users
Supports a wide range of features including voice/video calls and end-to-end encryption
Highly customizable and themeable, allowing for branded deployments

Cons of Element Web

Dependent on a Matrix homeserver (like Synapse) to function
May have higher resource usage for end-users compared to native clients
Limited offline functionality compared to some native Matrix clients

Code Comparison

Synapse (Python):

class SynapseHomeServer(HomeServer):
    def _listen_http(self, listener_config):
        port = listener_config["port"]
        bind_addresses = listener_config["bind_addresses"]
        site_tag = listener_config.get("tag", port)

Element Web (JavaScript):

export default class MatrixClientPeg {
    public get matrixClient(): MatrixClient | null {
        return this.matrixClient;
    }
    public async start() {
        this.matrixClient = createClient(this.opts);
    }
}

This comparison highlights the different focus of each project: Synapse as a server implementation and Element Web as a client-side application. Synapse's code deals with server configuration and listening, while Element Web manages client-side Matrix interactions.

1,300

A Matrix-Telegram hybrid puppeting/relaybot bridge

Pros of Telegram

Specifically designed for bridging Matrix to Telegram, offering seamless integration
Lighter weight and more focused than Synapse, which is a full Matrix homeserver
Supports end-to-end encryption for Telegram Secret Chats

Cons of Telegram

Limited to Telegram integration, while Synapse supports multiple protocols
Requires a separate Matrix homeserver to function, unlike Synapse which is self-contained
May have fewer features and customization options compared to Synapse's extensive capabilities

Code Comparison

Telegram (Python):

@command_handler(needs_auth=True, needs_puppeting=True)
async def ping_portal(evt: CommandEvent) -> EventID:
    await evt.reply("Pong!")
    return evt.id

Synapse (Python):

class PingServlet(RestServlet):
    PATTERNS = client_patterns("/ping$")

    async def on_GET(self, request: SynapseRequest) -> Tuple[int, JsonDict]:
        return 200, {"ping": "OK"}

Both examples show simple ping functionality, but Telegram's implementation is more specific to its bridging purpose, while Synapse's is part of a broader REST API structure.

1,246

A Matrix-WhatsApp puppeting bridge

Pros of WhatsApp

Focused on WhatsApp integration, providing a bridge to the popular messaging platform
Lighter weight and more specialized than the full Matrix homeserver implementation
Easier setup and configuration for users primarily interested in WhatsApp bridging

Cons of WhatsApp

Limited to WhatsApp functionality, lacking the full feature set of a Matrix homeserver
Dependent on WhatsApp's API and policies, which may change or be restricted
Smaller community and potentially less frequent updates compared to Synapse

Code Comparison

Synapse (Python):

class HomeServer:
    def __init__(self, config):
        self.config = config
        self.datastore = DataStore(config)
        self.federation_sender = FederationSender(self)

WhatsApp (Python):

class WhatsAppBridge:
    def __init__(self, config):
        self.config = config
        self.client = WhatsAppClient()
        self.matrix_handler = MatrixHandler(self)

Both projects use Python, but Synapse focuses on implementing a full Matrix homeserver, while WhatsApp is specifically designed as a bridge for WhatsApp integration. Synapse's codebase is more extensive and complex, dealing with various Matrix protocols and features. WhatsApp's code is more streamlined, primarily handling the communication between Matrix and WhatsApp services.

matrix-docker-ansible-deploy

4,812

🐳 Matrix (An open network for secure, decentralized communication) server setup using Ansible and Docker

Pros of matrix-docker-ansible-deploy

Simplified deployment process using Docker and Ansible
Includes additional services and integrations out-of-the-box
Easier to manage and update multiple Matrix components

Cons of matrix-docker-ansible-deploy

Less flexibility for custom configurations compared to direct Synapse installation
Potential overhead from running in Docker containers
Requires familiarity with Ansible for deployment and management

Code Comparison

Synapse configuration (synapse):

listeners:
  - port: 8008
    tls: false
    type: http
    x_forwarded: true
    resources:
      - names: [client, federation]
        compress: false

Docker Compose configuration (matrix-docker-ansible-deploy):

version: '3'
services:
  synapse:
    image: matrixdotorg/synapse:latest
    volumes:
      - ./data:/data
    ports:
      - "8008:8008"

The Synapse repository provides a more direct configuration approach, while matrix-docker-ansible-deploy uses Docker Compose for containerized deployment. The latter simplifies the process but may require additional setup for advanced configurations.

matterbridge

6,551

Pros of Matterbridge

Supports a wider range of chat platforms and protocols
Lightweight and easy to set up
Can bridge multiple networks simultaneously

Cons of Matterbridge

Less scalable for large deployments
Fewer built-in features for user management and authentication
Limited support for end-to-end encryption

Code Comparison

Synapse (Python):

class HomeServer(object):
    def __init__(self, config: HomeServerConfig, version_string: str):
        self.config = config
        self.version_string = version_string

Matterbridge (Go):

type Bridge struct {
    Config    *config.Config
    Protocol  map[string]Protocol
    Gateways  map[string]*Gateway
    Channels  map[string]*config.ChannelInfo
    Rooms     map[string]*config.Room
}

Both projects use object-oriented programming, but Synapse focuses on a centralized server structure, while Matterbridge emphasizes bridging multiple protocols and platforms.

Synapse is designed as a full-featured Matrix homeserver, offering robust user management, room creation, and federation capabilities. Matterbridge, on the other hand, is a more specialized tool for connecting different chat platforms, prioritizing flexibility and ease of use over comprehensive server functionality.

dendrite

5,708

Dendrite is a second-generation Matrix homeserver written in Go!

Pros of Dendrite

Written in Go, offering better performance and lower resource usage
Designed with scalability in mind, suitable for large deployments
More modern codebase, potentially easier to maintain and contribute to

Cons of Dendrite

Less mature and feature-complete compared to Synapse
Smaller community and ecosystem support
May have fewer integrations and plugins available

Code Comparison

Synapse (Python):

class SynapseHomeServer(HomeServer):
    def _listen_http(self, config: HttpListenerConfig) -> None:
        site = SynapseSite(
            self,
            config.x_forwarded,
            config.resources,
            config.content_security_policy,
            config.additional_resources,
            config.worker_app,
        )

Dendrite (Go):

func (h *HomeserverHTTPAPI) SetupHTTPAPI(router *mux.Router) {
    router.Handle("/version", httputil.MakeJSONAPI(h.Version))
    router.Handle("/voip/turnServer", httputil.MakeJSONAPI(h.TurnServer))
    router.Handle("/_matrix/client/versions", httputil.MakeJSONAPI(h.Versions))
}

Both repositories are Matrix homeserver implementations, but Dendrite aims to be a more efficient and scalable alternative to Synapse. While Synapse is more mature and widely used, Dendrite offers potential performance benefits and a more modern codebase. The code comparison shows the difference in languages and API setup approaches between the two projects.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

========================================================================= Synapse |support| |development| |documentation| |license| |pypi| |python|

Synapse is now actively maintained at `element-hq/synapse <https://github.com/element-hq/synapse>`_

Synapse is an open-source Matrix <https://matrix.org/>_ 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 <https://github.com/element-hq/synapse>; additionally you have the choice of other Matrix homeservers <https://matrix.org/ecosystem/servers/>.

See The future of Synapse and Dendrite <https://matrix.org/blog/2023/11/06/future-of-synapse-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 <https://matrix.org/docs/guides/introduction>, and the formal specification <https://spec.matrix.org/> describes the technical details.

.. contents::

Installing and configuration

The Synapse documentation describes how to install Synapse <https://matrix-org.github.io/synapse/latest/setup/installation.html>. We recommend using Docker images <https://matrix-org.github.io/synapse/latest/setup/installation.html#docker-images-and-ansible-playbooks> or Debian packages from Matrix.org <https://matrix-org.github.io/synapse/latest/setup/installation.html#matrixorg-packages>_.

.. _federation:

Synapse has a variety of config options <https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html>_ which can be used to customise its behaviour after installation. There are additional details on how to configure Synapse for federation here <https://matrix-org.github.io/synapse/latest/federate.html>_.

.. _reverse-proxy:

Using a reverse proxy with Synapse

It is recommended to put a reverse proxy such as nginx <https://nginx.org/en/docs/http/ngx_http_proxy_module.html>, Apache <https://httpd.apache.org/docs/current/mod/mod_proxy_http.html>, Caddy <https://caddyserver.com/docs/quick-starts/reverse-proxy>, HAProxy <https://www.haproxy.org/> or relayd <https://man.openbsd.org/relayd.8>_ 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 <https://matrix-org.github.io/synapse/latest/reverse_proxy.html>_.

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.

.. _the upgrade notes: https://matrix-org.github.io/synapse/develop/upgrade.html

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 <https://matrix-org.github.io/synapse/latest/deprecation_policy.html>_ for more details.

Security note

Matrix serves raw, user-supplied data in some APIs -- specifically the content repository endpoints_.

.. _content repository endpoints: https://matrix.org/docs/spec/client_server/latest.html#get-matrix-media-r0-download-servername-mediaid

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.

.. _CSP: https://github.com/matrix-org/synapse/pull/1021

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.

.. _registered domain: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-2.3

.. _some attacks: https://en.wikipedia.org/wiki/Session_fixation#Attacks_using_cross-subdomain_cookie

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 <https://matrix-org.github.io/synapse/latest/setup/installation.html#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 <https://matrix.org/ecosystem/clients/>_.

If all goes well you should at least be able to log in, create a room, and start sending messages.

.. _client-user-reg:

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 <https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#registration>_ set enable_registration: true in homeserver.yaml.
Then either:

a. set up a CAPTCHA <https://matrix-org.github.io/synapse/latest/CAPTCHA_SETUP.html>_, or b. 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 <https://matrix-org.github.io/synapse/latest/usage/administration/admin_faq.html>_ includes tips on dealing with some common problems. For more details, see Synapse's wider documentation <https://matrix-org.github.io/synapse/latest/>_.

For additional support installing or managing Synapse, please ask in the community support room |room|_ (from a matrix.org account if necessary). We do not use GitHub issues for support requests, only for bug reports and feature requests.

.. |room| replace:: #synapse:matrix.org .. _room: https://matrix.to/#/#synapse:matrix.org

.. |docs| replace:: docs .. _docs: docs

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 credentials are stored - these live on home servers. Identity Servers are just for mapping 3rd party IDs to matrix IDs.

This process is very security-sensitive, as there is obvious risk of spam if it is too easy to sign up for Matrix accounts or harvest 3PID data. In the longer term, we hope to create a decentralised system to manage it (matrix-doc #712 <https://github.com/matrix-org/matrix-doc/issues/712>), but in the meantime, the role of managing trusted identity in the Matrix ecosystem is farmed out to a cluster of known trusted ecosystem partners, who run 'Matrix Identity Servers' such as Sydent <https://github.com/matrix-org/sydent>, whose role is purely to authenticate and track 3PID logins and publish end-user public keys.

You can host your own copy of Sydent, but this will prevent you reaching other users in the Matrix ecosystem via their email address, and prevent them finding you. We therefore recommend that you use one of the centralised identity servers at https://matrix.org or https://vector.im for now.

To reiterate: the Identity server will only be used if you choose to associate an email address with your account, or send an invite to another user via their email address.

Development

We welcome contributions to Synapse from the community! The best place to get started is our guide for contributors <https://matrix-org.github.io/synapse/latest/development/contributing_guide.html>. This is part of our larger documentation <https://matrix-org.github.io/synapse/latest>, which includes

information for Synapse developers as well as Synapse administrators. Developers might be particularly interested in:

Synapse's database schema <https://matrix-org.github.io/synapse/latest/development/database_schema.html>_,
notes on Synapse's implementation details <https://matrix-org.github.io/synapse/latest/development/internal_documentation/index.html>_, and
how we use git <https://matrix-org.github.io/synapse/latest/development/git.html>_.

Alongside all that, join our developer community on Matrix: #synapse-dev:matrix.org <https://matrix.to/#/#synapse-dev:matrix.org>_, featuring real humans!

.. |support| image:: https://img.shields.io/matrix/synapse:matrix.org?label=support&logo=matrix :alt: (get support on #synapse:matrix.org) :target: https://matrix.to/#/#synapse:matrix.org

.. |development| image:: https://img.shields.io/matrix/synapse-dev:matrix.org?label=development&logo=matrix :alt: (discuss development on #synapse-dev:matrix.org) :target: https://matrix.to/#/#synapse-dev:matrix.org

.. |documentation| image:: https://img.shields.io/badge/documentation-%E2%9C%93-success :alt: (Rendered documentation on GitHub Pages) :target: https://matrix-org.github.io/synapse/latest/

.. |license| image:: https://img.shields.io/github/license/matrix-org/synapse :alt: (check license in LICENSE file) :target: LICENSE

.. |pypi| image:: https://img.shields.io/pypi/v/matrix-synapse :alt: (latest version released on PyPi) :target: https://pypi.org/project/matrix-synapse

.. |python| image:: https://img.shields.io/pypi/pyversions/matrix-synapse :alt: (supported python versions) :target: https://pypi.org/project/matrix-synapse

Top Related Projects

element-web

11,133

A glossy Matrix collaboration client for the web.

1,300

A Matrix-Telegram hybrid puppeting/relaybot bridge

1,246

A Matrix-WhatsApp puppeting bridge

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

Top Related Projects

Quick Overview

Pros

Cons

Getting Started

Competitor Comparisons

Pros of Element Web

Cons of Element Web

Code Comparison

Pros of Telegram

Cons of Telegram

Code Comparison

Pros of WhatsApp

Cons of WhatsApp

Code Comparison

Pros of matrix-docker-ansible-deploy

Cons of matrix-docker-ansible-deploy

Code Comparison

Pros of Matterbridge

Cons of Matterbridge

Code Comparison

Pros of Dendrite

Cons of Dendrite

Code Comparison

Convert designs to code with AI

README

========================================================================= Synapse |support| |development| |documentation| |license| |pypi| |python|

Synapse is now actively maintained at element-hq/synapse <https://github.com/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

Top Related Projects

Convert designs to code with AI

Synapse is now actively maintained at `element-hq/synapse <https://github.com/element-hq/synapse>`_