Today we're exceptionally releasing Synapse
1.61.1, which comes
as a security release. Server administrators are encouraged to update as soon as
possible.
This release fixes a vulnerability with Synapse's URL preview feature. URL
previews of some web pages can lead to unbounded recursion, causing the request
to either fail, or in some cases crash the running Synapse process.
Homeservers with the url_preview_enabled configuration option set to false
(the default value) are unaffected. Instances with the enable_media_repo
configuration option set to false are also unaffected, as this also disables
the URL preview functionality.
Server administrators who are unable to update Synapse should disable URL
previews by setting url_preview_enabled: false in their configuration file.
They can also delegate URL preview to a separate, dedicated worker to ensure the
process crashing does not impact other functionality of Synapse.
Hey everyone! Guess what? Synapse
1.61 is out! Let's
have a look at it.
Farewell, groups
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.
Media retention
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.
Everything else
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.
Hi there! I'm Marco Melorio and I'm participating in this year's Google Summer of Code, under the GNOME Foundation. I'm working on Fractal, the GNOME matrix client, with the help of my mentor Julian Sparber. More specifically I'm working on implementing a media history viewer to the app.
To follow my progress on the project you can check out my blog here. I've already published a small introduction post about me and a first update post which includes a mockup and milestones about the project.
This week the team released Synapse 1.61, which main new feature is media retention. That's right, you can now control how long Synapse keeps media files around, which should help server admins manage Synapse's disk space usage more efficiently. On a different note, this release of Synapse removes support for groups/communities (which was deprecated back in Synapse 1.56), as it has now been replaced by Spaces. Farewell groups, you have served your users well.
See the full Synapse 1.61 release announcement on the matrix.org blog here: https://matrix.org/blog/2022/06/17/synapse-1-61-released
Aside from this, the team is as always hard at work on making Synapse better and more efficient.
New version of Quadrix (1.0.6) available on desktops and mobiles. Mainly bug fixes, plus the addition of a button to deactivate the account on the server (this apparently will be soon mandatory for iOS and MacOS messaging apps). The new desktop version should offer better support for Wayland (tested on Fedora 36, Ubuntu 22.04 and Mobian/Phosh). Repo at https://github.com/alariej/quadrix, project room at #quadrix:matrix.org :-)
Since I skipped the last update, this one is a bit longer :3
First of all there have been lots and lots of updates to the translations! Finnish is now at 100% thanks to the tireless work of Aminda and Lurkki.
Nheko now also shows a nice badge on Unity compatible desktops (like KDE) for unread messages (although that doesn't work properly for multiple profiles being open at the same time due to limitations in that desktop protocol. Thank you d42 for contributing this, may you role a natural 42 every dice throw!
Syldra fixed up the paste behaviour (which didn't properly tie into undo in some edge cases), cleaned up how we find some of our dependencies and made cusor movement more consistent across systems.
Finally we fixed our glare resolution when verifying other sessions, which will be especially noticeable when verifying Cinny, since that responds to verification requests in a different way than I tested before! This should get rid of a whole range of verification issues people might have experienced. As part of our stabilization for the next release, we also fixed a crash on logout because I fatfingered and deleted a return statement, we now send an Element Android compatible height attribute on emotes, properly compile when the C++ version is set to 20, we once again support the current version of the hidden read receipts MSC (so that others can't tell what you read), edits now properly update in replies again, you can close the image overlay again by clicking outside, cancelled uploads properly get removed again, logging out and back in now doesn't mess up your configuration anymore and pinned messages now properly refresh once the events are loaded.
Phew, that was a mouthful. And we are not even done yet!
I spent some time on making Nheko compilation a bit faster again as well as improve startup speed. This might order your room list a bit weirdly for a few days after updating, but should normalize when receiving a few messages in some rooms. With this we now don't need to load the last message in all rooms on startup. This makes Nheko startup now only take 7 seconds on my old laptop (when not doing something CPU heavy at the same time). The remaining startup time is 40% building up the font database and 40% loading the powerlevels for each room. So we do have the chance to speedup startup by probably another 60%. It is unlikely that is necessary though.
When I discovered Matrix, Element was still called Riot. At the time some of the big design changes started happening to make it the Element you know today. One of the sideeffects was that the roomlist was consistently taking up 20% of my CPU on my Laptop, which I used at the time (and am forced to use now again, since I broke my newer laptop). It also used a lot more RAM than it does today. So for that reason I started shopping around for what other clients there are and I found Nheko. Clearly because it isn't a webclient, it had to be faster and use less RAM. Well, it did maybe a bit, but frankly the difference wasn't that much. Especially since at the time it loaded and rendered ALL your messages on startup (kinda). It never removed messages from memory, so it would just continuously render more and more parts of your timeline, which clearly increased RAM usage. It did however never resort the full roomlist, which made it not use a lot of CPU.
Since I didn't know any web development at the time, but I knew some C++, I started contributing to Nheko. At some point I made the roomlist constantly resort, which used quite some amount of CPU, but I quickly fixed that. At the time the most noticeable difference was that my fans didn't spin when using Nheko, but Element did (because of the roomlist sorting, iirc). RAM usage was pretty bad though. So that was one of the next projects, removing all events from RAM and only pulling them from the database as needed. While this means some additional load when switching rooms, it did decrease RAM requirements by quite a bit. Some new features made us still require loading data for every room from the database on startup, which causes quite some noticeable startup delay. The latest changes however got rid of most of that. We now don't need to load the messages from the database anymore. The only thing we still load is a small info object with roomname, notification and member count as well as the power levels of the room.
Since I recently broke my new and fast laptop, I decided to checkout how things changed on my old and slow laptop. Nowadays I am not in 15 rooms anymore, but I am in 900 rooms, but Matrix, servers as well as clients, has also gotten a lot more performant. So in the end I decided to do a little benchmark of where things stand. DISCLAIMER: This is completely unscientific and unfair, so please take those numbers with a grain of salt. Almost no one runs such a slow laptop as I do, so likely your measurements will completely different. Even more, I was video recording the benchmark, which makes both clients a lot slower. Nonetheless it does somewhat mirror my personal experience.
I came to the conclusion that with 900 rooms, Nheko takes about 10-20 seconds to load and be ready for use on my system, while Element takes about 3 to 4 minutes. So basically Element handles 60 times as many rooms about 2x slower than it did back in the day, while Nheko got a bit faster or about the same speed on the same hardware (but still 60x as many rooms). I've attached a sped up video to this post, so that you can compare it for yourself. But since a lot of people ask, I guess the reason is that I wanted to see how fast you can make a Matrix client. I think I somewhat achieved that in the startup time department, but switching rooms still has a loooooong way to go. Also it is just fun to implement whatever you want in a client, since you are the maintainer and none can tell you how bad of an idea it is. That's probably the reason a lot of people start their own clients? (Although I didn't start Nheko, I just wrote too much code and people didn't want to review it anymore.)
That's it, I hope your eyes didn't glaze over with me babbling on about things. See you next time! :3
There have been many improvements to clickable texts in various parts of the application (e.g. when you see “Show more” in the UI) and many other UI tweaks (thank you luixxiul!). As well as UI improvements to colours and layouts in the settings dialog
Fixing a pagination regression because of a synapse update to conform the matrix spec. The fix will be included in the coming release 1.4.22.
Merged a selection of FTUE improvements, including simplifying login if you specify your server as part of your username. This work is not visible yet in the UI.
UnifiedPush is coming! Will be available in Element Android 1.4.22. In the meantime, you can test the feature using a nightly build . This technology will let F-Droid version of the app be able to receive Push and Element Android can stop polling your homeserver in the background, which was consuming lots of battery.
When you send a rageshake, screenshots will not be included by default any more
We also have set up Flipper in the app, to help developers to debug the application. Inspecting the Realm databases, or the network traffic will help a lot when developing new features or fixing issues.
As you can guess by the title, I've started Matrix Wrench one year ago.
Here are the most notable changes of today's birthday release v0.8.0 (2022-06-13):
Added: All pages have URLs to quickly navigate to.
Added: Bulk actions to invite and kick users
Added: The About page now shines some light on the application's features and security.
On other major news, the first UniFFI macro PR, submitted by our very own Jonas, was merged by Mozilla earlier this week 🎉. This is an important milestone as this PR is the opening gate for getting more and more macro-support into UniFFI, eventually replacing the entire UDL-in-between-action. Congrats for this major step forward
The there is a new release that avoids crashing of the bug when the synapse admin is not correctly exposed. For technical reasons (on layer 8) the bug fix is made in two releases. The latest version is now v1.1.7
Four days of Barcamp sessions, presentations, meeting others and Berlin culture!
The Matrix Summit 2022 brings people together who work with Matrix.
Thu, 25th to Sun, 28th August at the iconic hacker space c-base in Berlin.
This event is organised by the local Matrix Meetup community.
While people of every skill level are welcome on all days, we're going to highlight real world use cases of Matrix on Sunday. We're inviting newcomers and other communities to learn about decentralised communication software. In return we're learning how Matrix is already used by the German education and health sectors.
Our Call for Presentations starts next week. The event is going to be bilingual: English and German.
See the schedule:
https://summit2022.matrixmeetup.de/
UnifiedPush is an open protocol for push notifications on Android, independent from Google Services. It is currently supported by FluffyChat, SchildiChat, and now nightly builds of Element.
If you are new to UnifiedPush:
Installing the ntfy app (F-Droid, Play Store) is the easiest way to start receiving notifications for your matrix messages without Google Services.
And if you want to go one step further and self-host a ntfy server, the latest release makes it simpler than ever to set it up on your own server!
For persons already self-hosting ntfy:
The brand new version v1.26 of ntfy server includes a built-in matrix gateway: your homeserver can talk directly to ntfy. If you were self-hosting ntfy with a personal matrix gateway (common-proxies or with a Nginx setup), you can remove the gateway after upgrading to v1.26.
An early-stage home server prototype that communicates in a fully decentralized manner: every user runs their own server locally!
This is achieved with the libp2p library which provides decentralized node discovery, NAT traversal and gossip-based communication capabilities.
The server implements the Matrix API specifications (with many advanced features still missing, like client-side end-to-end encryption), but did little modification on federation side so that it doesn't rely on the centralized domain name system to setup and authenticate other nodes. On the other hand, this means it cannot federate with existing home servers yet, because of the different trust model (domain name/HTTPS vs self-owned cryptographic keys).
Try out the latest Webview client on windows, or on other OSs with Docker&Browser!
anarc.at published a long and thoughtful critique of Matrix over at https://anarc.at/blog/2022-06-17-matrix-notes/ - interesting reading, even if we don't agree with all the points.
Hey everyone! Thib is out today, so I'll be exceptionally hosting TWIM in his stead this week. Let's have a look at what's been going on in Matrix-land!
Open Tech Will Save Us #16 🎙
The 16th edition of our virtual meetup Open Tech Will Save Us happened this week! This edition featured a few very interesting projects:
Quentin and Maximilien from Deuxfleurs are creating Garage, a robust and distributed storage backend that can run on old computers. Who can use it? Why? And when should I not use it? Let's find out!
Nathan from the Guardian Project is working with wind, butter, and rasperries to provide applications and messaging to people in low-connectivity areas. A fascinating dive off the grid.
Matrix's Outreachy intern for this summer has been chosen! Usman is starting in early June, and will be working on experiments with Starring Messages! He will be blogging every two weeks, so look out for more updates.
Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://matrix.org/docs/spec/proposals.
A bite-size MSC which aims to clean up the definition of a widget state event... by moving the "title" field to the root of the state event, alongside the existing "name" field.
This MSC needs someone to write an implementation in at least one homeserver and client to move forwards. Perhaps that someone could be you?
Meanwhile work continues on fast room joins and testing Synapse with workers on Complement. We'd like to remind readers that the fast room joins feature is highly experimental right now and we do not recommend enabling it on production homeservers just yet.
Morning,
maybe it's useful for someone else, I just published my admin scripts for synapse. It's still WiP but it make some basic stuff that I needed in my organisation :
System notify users (all users/users from a list, specific user)
delete sessions/devices not seen for X days
purge the remote media cache
select rooms with various criteria (external/local/empty/created by/encrypted/cleartext)
purge history of theses rooms
shutdown rooms
https://git.fout.re/pi/matrixadminhelpers
It's my first python project, so the code may not structured as it should, I'm still learning, and it's early alpha :)
We added a way to edit permissions in Nheko now. It is an unconventional drag and drop dialog, where you drag users and permissions between different roles. We are hoping that this will make powerlevels easier to understand. Be careful when trying it, the wrong powerlevels might make your room unusable. Now... the bad part about that is, that powerlevels add around 50-100 new strings to translate... Help is appreciated! <3
Nheko now also supports fallback keys, which should make E2EE more reliable after long periods of being offline and you can send images by pressing enter again. The privacy screen is also now fixed for separate room windows and our flatpak supports more image formats.
On Element Web this week we’ve smashed some bugs including those around Threads.
Threads work continues as we’re aiming to improve the notifications and read receipts to improve the experience.
Continuing to make improvements to our automated tests.
The team is driving to complete the work needed to move our new search experience out of Beta. We think this new search is easier to use and helps folks to find what they’re looking for faster.
We’re also making improvements specifically for new users, this will include a new home screen, watch out for those!
In labs (you can enable labs features in settings on develop.element.io or on Nightly):
Video rooms; We’re ironing out some of the details to polish the experience
This week we added emoji14 support so if you want to hide 🫣 , salute 🫡 , or melt 🫠 for your friends, you’ll soon be able to! 🫶 (for Android 12 and above, or devices that support emoji14)
We’re getting ever nearer to a new sign up flow for new users. Our flow today can be confusing and complex, especially when all you want to do is chat with friends. We’ve been working on simplifying the flow and we’ll announce a community testing session very soon!
Also new this week, we’ve opened up a new layout of the app to a small selection of folks. These 15 people will trial the new layout for us, providing feedback along the way. We’ll be opening it up to more feedback soon.
Threads are still in progress as we continue to make progress on the notifications and sort/ordering work that remains.
In order for notifications to work better, we need read receipts to be updated. We’ve got several MSCs ongoing, along with a few Proof of Concepts (PoCs) to move us forward.
MSC3771: Read receipts for threads
MSC3772: Push rule for mutually related events
MSC3773: Notifications for threads
With that we’ve also updated some layouts and completed some bug fixes, on all platforms.
Trixnity 2.1.0 has been released. It includes support for Server-Server-API endpoints (client and server) and fetching missing TimelineEvents in client. The latter is used for fragmented timelines: If you want to show a timeline starting from any EventId and RoomId (e. g. from unread marker), Trixnity will try to fetch missing TimelineEvents from server. If you reach TimelineEvents, that are already saved in the local database, the timeline fragments are merged magically 🧙
A set of Rust library crates for working with the Matrix protocol. Ruma’s approach to Matrix emphasizes correctness, security, stability and performance.
Since our last update from about a month ago, we had two bugfix releases:
Ruma 0.6.2 added methods to get the current room powerlevels from a StrippedPowerLevelsEvent and to get a user's membership whether the state event is redacted or not, and added a missing export to track member changes.
Ruma 0.6.3 fixed the serialization and deserialization of events with a dynamic event_type and added convenience constructors for logging in with a UserIdentifier.
The majority of changes we've seen over the last week, where minor fixes in style, squashing of bugs and CI improvements as most work is currently happening in the background on Sliding Sync, mobile and UniFFI support. But there have been two additions worth mentioning: first, we've improved on the autojoin example for appservices, and secondly we've merged a community contribution to make resolving of room-alias more handy.
This week, we migrated to Matrix Api Lite 1.0.0, our simple wrapper around the matrix API endpoints and data models. This means we are now using the v1.2 Matrix spec 🎉.
Also, support for HiveCollections as Database provider was added now that our patches to hive were accepted upstream. And we now provide a way to dump and restore the client local database.
Finally, we fixed a bug with where reactions were not properly discarded from the cache and some bugs in our e2e tests.
Meet other matrix users, chat about Matrix, the rest, and everything else, discuss your Matrix ideas, sign each other in persona, and maybe spice the evening with a good mate or beer.
Also when the bbq is lit you may wish you brougth your favorite item :)
Every first Wednesday of the month in the c-base at 8pm ('til the next pandemic).
uhoreg shared with us a press release from Rocket.Chat announcing their work on interoperability with Matrix. It is super exciting to see another big player join the ecosystem. Watch this space next week for more announcements!
Dept of Ping 🏓
Thib is out this week, therefore so are the ping stats in TWIM (don't worry, they'll be back next week!).
Synapse 1.59 is
out! Let's see what's new in this version.
Generic worker types
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
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.
Everything else
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.
Poetry
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.
Everything else
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.
Hey everyone! Guess what? Synapse
1.57 has just been
released! Let's see what's new in this version!
Application services
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!
Improvements to the module system
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.
Everything else
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.
Happy release day everyone! Synapse
1.56 is out! Let's
have a look at what's new in this release.
Additional restrictions around registration
One common abuse scenario we have seen on Matrix over the years is attackers
making use of public homeservers with open registration to automatically create
multiple accounts in order to evade sanctions. Sometimes, this can lead to these
public homeservers being banned across multiple public rooms despite their
administrator(s) not being directly at fault.
In order to mitigate this, starting from this release, Synapse will refuse to
start by default if it is configured with open registration with no additional
verification. This means users wishing to register on these homeservers will
need to authenticate themselves, either via
email,
recaptcha or
registration
tokens.
Long-time users of Matrix might remember when, way back in
2017, we introduced
groups (also known as communities in some clients). Groups would let users
define a curated set of users and rooms to represent a given community that
others could refer to. We even used to have +matrix:matrix.org which was
the official group for the Matrix team and community.
If this sounds a bit familiar to you (and remind you of a certain other feature
of Matrix), that's no coincidence. Some time ago, we had already identified a
good amount of shortcomings with groups, and decided to redesign the feature
entirely and release it under the name "spaces". If you're curious about this,
then you may wish to read the spaces announcement
blogpost we released
at the time.
Now that spaces have been out of beta for some time, and have shown to be a very
useful feature to the ecosystem, we decided it was time to retire support for
groups from Synapse, after more than 4 years of good and loyal service. This
release of Synapse deprecates the feature, with a plan to disable it by default
in Synapse 1.58 (which is expected to be released next month).
Everything else
As of this version, Synapse will also refuse to start the if the Postgres
database it is running against has a non-C locale, in order to prevent
accidental database corruption. See the upgrade
notes
for more information.
This release also includes the ability for modules to register server
administrators through the register_user method, as well as a new
method
to allow modules to store external 3PID associations into Synapse's database.
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) Dirk Klimpel,
Beeper, Famedly,
IronTooch and
villepeh.
Hi all, Synapse
1.55 is out! Let's
see the main talking points of this new release.
Update: After the initial release of Synapse 1.55, the developers of a
third-party tool (Jinja, which is the tool Synapse uses to render email and
web templates) released a new version of their project which proved
incompatible with Synapse. To address this issue, we have released Synapse
1.55.2.
Deployments of Synapse using the matrixdotorg/synapse Docker image or Debian
packages from packages.matrix.org are not affected as they are already using
a compatible version of the tool.
It's worth noting that the work we are doing to integrate
Poetry into Synapse (more on that a bit further
in this post) will, once completed, prevent this kind of issues from
happening.
Removing support for Mjolnir 1.3.1 and older
Administrators of large homeservers and communities will already be familiar
with Mjolnir, which is a tool designed
to help them moderate a large number of rooms in an efficient way. It includes a
bot as well as a Synapse module to better interface with the homeserver.
Due to a change in how we manage some of Synapse's internal utilities, this
release of Synapse breaks compatibility with Mjolnir versions 1.3.1 and older.
Homeserver administrators using Mjolnir and upgrading to Synapse 1.55 should
make sure they're running Mjolnir version 1.3.2 or later.
synctl is a tool provided as part of Synapse to run and manage your instance
and its workers (if any).
As part of our work to integrate Poetry in Synapse
(which in turn will enable a lot of cool things, such as reproducible builds),
we have recently moved the way we package this tool. As of this release,
homeserver administrators should stop invoking it using its direct path (e.g.
/path/to/synctl start), but should instead call it directly, e.g. synctl start.
This means homeserver administrators using synctl must make sure that the tool
is in their PATH. This is automatically done when installing and upgrading
Synapse using the matrixdotorg/synapse Docker image or Debian packages from
packages.matrix.org. When installing from a wheel, sdist, or PyPI, an
executable is created in your Python installation's bin directory.
This release also introduces new module callbacks, allowing homeserver
administrators to more efficiently review which users are able to deactivate
users and shutdown rooms. More information on that in Synapse's
documentation.
We have also started experimenting with using the native Python asyncio event
loop in Synapse which, if successful, would make it easier to use building
blocks from the Python ecosystem when adding new features to Synapse.
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) Dirk Klimpel,
Beeper, and
~creme.
Synapse 1.54 is
out! Let's see what goodness is coming your way with this new release.
Improving URL previews
As part of the Matrix specification, Matrix clients have the option to rely on
the homeserver to generate URL previews. This means the homeserver (in this case
Synapse) needs to have a look at the content at that URL and extract data to
send back to the client.
In the past, Synapse has had issues with generating complete URL previews, and
some metadata (e.g. image, description) would be missing from the data that
Synapse sends to clients. Synapse 1.54 includes improvements to the generation
of URL previews, and while testing it we've been able to observe improvements to
previews generated for Twitter and Reddit.
New module callbacks
Synapse modules allow third-party developers to write extra features for
Synapse, that wouldn't necessarily be generic enough to fit within the Matrix
specification. This includes custom behaviours such as smarter event filters,
bespoke media storage providers, or spam checkers. Since we rewrote Synapse's
module system in Synapse
1.37,
we have been improving it by adding new callback functions that module can
implement, allowing them to interface better with Synapse.
Synapse 1.54 includes three new module callbacks. One of them,
get_displayname_for_registration,
allows modules to define the display name for newly registered users. Together
with the existing
get_username_for_registration
introduced in Synapse
1.52, they allow
modules a better control over the user registration process.
The two other module callbacks introduced in Synapse 1.54,
on_profile_update
and
on_user_deactivation_status_changed,
allow modules to react to profile changes, as well as the deactivation (or
reactivation) of users.
Everything else
This release of Synapse also includes more work to make joining large Matrix
rooms faster (I was telling you about that in the Synapse 1.53 release
announcement). While
it's still very experimental and not yet ready for show time, it's still very
exciting to see this work happening!
Synapse 1.54 also includes a change to the client-side versions
endpoint
to advertise Matrix 1.1 and 1.2. See the Matrix
1.2 release
announcement to read all about the changes this latest version of the
specification brings to the ecosystem.
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) Dirk Klimpel, Andrew
Ryan, and
lukasdenk.
