Hey everyone! Guess what? Synapse 1.61 is out! Let's have a look at it.
If you are new to Matrix, you might have not heard of the feature referred to as
"groups" or "communities" (depending on the context). This feature allowed
grouping rooms and users to better represent a community, one of which being
+matrix:matrix.org
which used to represent the Matrix community. This may
sound similar to Matrix
Spaces, and it would
make sense since Spaces are meant to be a more powerful replacement for groups.
In Synapse 1.56, support for groups was deprecated, with a plan to fully remove it in a later release of Synapse. This has now been done as of Synapse 1.61, and most of the code supporting this feature has now been removed.
Note that this means that administrators of homeservers using workers can remove endpoints related to groups from their reverse proxy configuration. See the upgrade notes for more information.
A common issue we see homeserver administrators struggle with is managing the disk space used by Synapse. A non-negligible part of that disk space usage is dedicated to storing files uploaded by Matrix users, both local and remote.
Up until now Synapse would only provide administrators with limited, manual ways to manage the media store of their homeserver, via the admin API.
As of this release, Synapse now allows administrators to define retention lifetimes for local and remote media. This allows media that hasn't been accessed in a long time to be automatically deleted, therefore freeing up disk space. Server administrators wishing to control media retention more finely can also define different policies for remote and local media.
This feature can be enabled by configuring the media_retention
setting, see
the configuration
guide
for more information.
This release of Synapse introduces a change in the return value of the
check_event_for_spam
spam checker module callback, in order to allow modules
more flexibility in communicating to users why their messages are rejected. This
is part of ongoing improvement works around spam checker callbacks, watch this
space next time for more information!
See the full changelog for a complete list of changes in this release. Also please have a look at the upgrade notes for this version.
Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Beeper, Dirk Klimpel and Jacek Kuśnierz.
Hey all,
It’s another quarter and therefore another spec release! Matrix 1.2 was released back in February, and while a bit late in the quarter this time around we’ve still got some exciting additions coming to you in this release.
Like last time, the speed of these releases might feel a bit quick for developers: fret not if you’re still working on v1.1 or v1.2 implementations. We’re not expecting that implementations update as soon as a new spec release is published, but rather that the ecosystem gradually update over the course of the next few months. Implementations should be aiming for as close to realtime as they can get though, particularly considering v1.4 is expected to have some large features (more on that later on).
Matrix 1.3 sees 14 MSCs get merged, but we can’t possibly go into detail on them all here. We’ve picked some notable highlights and recommend the full changelog at the bottom for a complete idea of what’s been going on.
It’s no secret that MSC1849-style server-side aggregation of related messages have been in the review backlog for a while. We ended up splitting MSC1849 down into more reviewable chunks like MSC2675, allowing us to finally land the first pieces into Matrix 1.3 today.
In the spec there aren’t currently any defined relationships which make use of aggregations or even the rel_type
described by MSC2674, but we do expect that v1.4 of the spec will have support for at least threads (MSC3440) and edits (MSC2676), filling the gap. For now, we’ve decided that holding aggregations back until v1.4 doesn’t make a lot of sense, so we have launched them into the world as-is for custom relations or for clients & servers to prepare for what’s expected to be coming in v1.4 of the spec.
To further prepare for threads, we’ve also removed some restrictions of rich replies through MSC3676, thus allowing replies to be constructed with non-text messages like images. Check out the new rich replies module for more information.
When we launched restricted rooms in Matrix 1.2 we noted that we forgot to handle a case where someone might want to support both knocking and restricted rooms at the same time. We’ve fixed that with a stop-gap join rule from MSC3787 in room version 10.
The new knock_restricted
join rule allows the room to keep its desire to be restricted whilst also allowing members who do not meet the criteria to knock on the room instead. We’ll likely expand on this sort of mixing of join rules in proposals like MSC3386 down the line, however for now this should cover the gap in support. Next up: figuring out how to make encrypted room history available to these new joiners in a safe way.
Originally planned for this release, MSC3440-style threads are anticipated to be ready for v1.4 (next quarter) with support for notifications and, of course, a whole new way to communicate in a room.
Threads are one of the more complicated features we’ve tried to land in recent history as it has a large impact on a wide variety of the spec: everything from event relationships (fixed in this release) to read receipts to push notifications needs to be worked out to build a system that not only users can understand, but also the developers trying to build it. With this massive surface area we just weren’t comfortable with adding threads to v1.3 as-is, given problems like notifications aren’t yet fully solved.
Alongside threads, we also anticipate that MSC2676-style message editing will be landing in v1.4, finally specifying how to update an event’s contents without having to redact & re-send. Although message editing has been supported for a long time in some clients, we're excited that it will finally become part of the official specification, meaning it can be implemented more widely. Messaging clients are encouraged to give the proposal an early read and possibly even attempt implementation if not already done to help us ensure the system is in a reasonable state for inclusion in the spec, though we do note that feature requests for edits will likely be deferred to a future MSC.
Keep an eye on This Week In Matrix for updates on what v1.4 is expected to include, and how things are progressing.
MSCs are how the spec changes in the way it does - adding, fixing, and maintaining features for the whole ecosystem to use. The blog post can’t cover them all, but that doesn’t make them any less important! Check out the full changelog below, and the Spec Change Proposals page for more information on how these MSCs got merged (hint: they submitted a proposal, which anyone can do - take a look at the Matrix Live episode where Matthew covers the proposal process).
sender_key
and device_id
on m.megolm.v1.aes-sha2
events, and the sender_key
on m.room_key_request
to-device messages, as per MSC3700. (#1101)from
optional on GET /_matrix/client/v3/messages
to allow requesting events from the start or end of the room history, as per MSC3567. (#1002)knock_restricted
join rule in supported room versions, as per MSC3787. (#1099)m.room.avatar
events is not required. (#987)type
in user-interactive authentication can be omitted. (#989)Flow information
is explicitly defined when the client-server API is rendered. (#1003)invite
where it is not specified in an m.room.power_levels
event. (#1021)matrix-doc
github repository. (#1032)m.room.message.feedback
per MSC3582. (#1035)@
are in fact reserved. Regressed from #3658. (#1100)name
field of m.room.name
events. (#3669)room_id
field from examples of m.read
, m.typing
in /sync
and m.fully_read
in room account data. (#3679)event_match
in push rule conditions. (#3690)m.login.appservice
login identifier, instead using m.login.application_service
. (#3711)invite->knock
and external->leave
are valid transitions. (#3730)origin
field from PDUs. (#998)matrix-doc
github repository. (#1032)valid_until_ts
is in milliseconds, like other timestamps used in Matrix. (#1055)/send_join
response. (#3703)content
for X-Matrix
signature validation is the parsed JSON body. (#3727)No significant changes.
No significant changes.
knock_restricted
join rule supported by room version 10 as per MSC3787. (#1099)m.federate
to the authorization rules, as originally intended. (#1103)join_rule
is knock
. (#3737)No significant changes.
Synapse 1.59 is out! Let's see what's new in this version.
When Synapse instances are subject to high load, it can be useful to use workers to balance the load more effectively. Workers are separate processes that can take some of the load off the main Synapse process, and allow the homeserver to scale more effectively.
In the past, Synapse only provided a specific set of types of workers, each capable of handling a specific set of operations. For some time now we have been working on allowing more flexibility around worker configuration, which started all the way back in Synapse 1.12.0 with the introduction of a generic worker application type.
Synapse 1.59 furthers this work by deprecating the synapse.app.appservice
and
synapse.app.user_dir
worker application types. Homeserver administrators
should change the configuration of instances using these types to the generic
synapse.app.generic_worker
application type, and use the
notify_appservices_from_worker
and update_user_directory_from_worker
to
delegate application service and user directory work (respectively) to a worker.
See the upgrade notes for more information on this change.
Push rules allow Matrix clients to define notification rules on a homeserver. One often reported issue with notification in Matrix is the fact that notifications are sent out when server ACLs, which define which server(s) can and cannot interact in a room, change. This is especially annoying during big waves of abuse, as there might be multiple servers that need to be banned from rooms, thus causing a lot of unneeded notifications.
Synapse 1.59 now supports silencing server ACL updates, by implementing the new push rule documented in MSC3786. However, since this MSC hasn't been incorporated into the spec yet, this behaviour is disabled by default in Synapse: see the implementation pull request for more information on turning it on.
Synapse 1.59 also allows third-party modules to validate and change the actions associated with an existing push rule via the Module API. This is helpful for modules wishing to, for example, configuring specific notification settings when new users register.
As of Synapse 1.59, Synapse will not communicate the name of devices over federation (unless configured otherwise), in order to better preserve user privacy. See the upgrade notes for more information.
Also note that we have issued a patch release for 1.59 (1.59.1) which fixes a long-standing bug that started to bite a good amount of server administrators. Server admins that are looking into upgrading their instance to Synapse 1.59 are recommended to upgrade to 1.59.1 rather than 1.59.0.
See the full changelog for a complete list of changes in this release. Also please have a look at the upgrade notes for this version.
Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Beeper, Dirk Klimpel, Šimon Brandner, henryclw and Andrew Do.
Synapse 1.58 is out! Let's dive into this new release.
If you've been reading the past few Synapse release announcements, you might have already heard about our efforts to integrate Poetry into Synapse. Poetry is a tool which manages dependencies of a Python project. Its killer feature is its lockfile, which explicitly pins all dependencies (direct and transitive) to a fixed version, even across multiple Python versions and platforms. See more about why we choose Poetry here.
During the past few months, we've been hard at work converting Synapse and its CI to use Poetry. The goal is to make our Docker images and Debian packages more reproducible and to provide a fixed, known-good environment for CI. This will help us to ensure the stability and security of Synapse installations.
Synapse 1.57's Docker image was the first to use Poetry; after a successful
trial, this was extended to Synapse 1.58's Debian packages. Installations from
PyPI using pip
will not use the locked environment, though everyone is
welcome to install from source using our
lockfile.
Huge props to David from the Synapse team for leading the work on this front.
This release of Synapse also includes performance improvements around sharing device list updates, which should greatly improve login times for large Matrix accounts.
Synapse 1.58 also features the implementation of two MSCs:
MSC3383 to
include a destination
parameter in federation authentication headers, and
MSC2815 which
(if enabled) allows room moderators to see the content of a redacted event (as
long as it hasn't already been deleted by the homeserver).
See the full changelog for a complete list of changes in this release. Also please have a look at the upgrade notes for this version.
Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Beeper, Dirk Klimpel, Famedly and Sami Olmari.
We've released updates to matrix-appservice-irc and our forked node-irc that it depends on to patch a High security vulnerability. It's advised to update to 0.34.0 as soon as possible.
The vulnerability allows an attacker to manipulate a Matrix user into executing IRC commands by having them reply to a maliciously crafted message.
Incorrect handling of a CR character allowed for making part of the message be sent to the IRC server verbatim rather than as a message to the channel.
If you are currently a matrix-appservice-irc user, exercise caution when replying to messages from untrusted participants in IRC bridged rooms until your bridge instance has been upgraded.
The vulnerability has been patched in node-irc version 1.2.1 and matrix-appservice-irc 0.34.0. You can get the release on Github.
The bridges running on the Libera Chat, OFTC and other networks bridged by the Matrix.org Foundation have been patched.
The vulnerabilities are tracked as GHSA-37hr-348p-rmf4 and GHSA-52rh-5rpj-c3w6.
Thank you, Val Lorentz for reporting this vulnerability.
Hey everyone! Guess what? Synapse 1.57 has just been released! Let's see what's new in this version!
Application services are piece of software that have privileged access to some of the homeserver's features. For example, they can create and manage multiple users at the same time, which is especially useful for bridges.
This release of Synapse changes the way Synapse manually manages transaction identifiers when talking to application services (a transaction being a group of events the application service should know about). While this doesn't have much impact on the everyday life of a server administrator (besides fixing a bug and paving the way for future performance improvements), this change means server admins should take extra care when updating Synapse.
More specifically, if you are running a dedicated Synapse worker for handling traffic related to application services, this worker must be stopped when upgrading the main Synapse process to ensure the update is performed safely. See the upgrade notes for more information about this change, and instructions on recovering from an incorrect upgrade.
This release of Synapse also continues work on bringing end-to-end capabilities to application services, which I was already telling you about in the Synapse 1.50 release blog post. More specifically, Synapse now supports sending device list updates to applications services, as part of implementing MSC3202. This is still very experimental and definitely not production ready, but also very exciting!
Modules allow third-party developers to expand Synapse with extra features that wouldn't necessarily fit into the Matrix specification and/or ecosystem. In the past release of Synapse, we have been improving this system to add more functionality to it, and this one is no exception!
Synapse modules can now implement new callbacks to react to account data updates, as well as to react to new 3PID (email address, phone number) associations. On the latter, note that this callback will only be called after a 3PID has been validated on the homeserver, and does not trigger when the validation happens on an identity server (e.g. when publishing a 3PID so that other users can look it up).
The ModuleApi
(which is the Python class enabling modules to interact with
Synapse) has also been updated to allow module to read and write global account
data. This can be done by using the new
AccountDataManager
class, which can be accessed as api.account_data_manager
(where api
is an
instance of ModuleApi
).
The module API has also been updated with a new method, to allow modules to promote an existing user to server administrator (or demote a server administrator to a normal user). This follows up on an improvement introduced in Synapse 1.56 allowing modules to promote users to server administrators when registering them.
This release also includes a performance improvement for workers handling
/sync
requests. While this change makes starting this kind of workers slightly
more heavy performance-wise, it aims at improving the load associated with the
first /sync
requests hitting it right after starting. See this
comment
for more details.
Synapse 1.57 also now includes bundled aggregations in message search results by default, as MSC3666 has been accepted and has finished its final comment period.
See the full changelog for a complete list of changes in this release. Also please have a look at the upgrade notes for this version.
Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including (in no particular order) Beeper, Dirk Klimpel, Famedly and Jorge Florian.