Hey folks, welcome to a new edition of This Week In Matrix! Thib is offline this week and next so I'll be taking over while he's away.
Matrix Live 🎙
This week Thib (is he ever really away?) shows us how to host Synapse with Docker Compose.
Dept of Status of Matrix 🌡️
Matthew shared with us the Matrix Summer Special 2022! Come read all about what's happened in Matrix-land so far this year, and what's coming up next, right here: https://matrix.org/blog/2022/08/15/the-matrix-summer-special-2022
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.
This week the Spec Core Team focused on improvements to the spec source itself. richvdh opened a PR for edit events, and yours truly did a small PR to clarify the required state of the response to /_matrix/client/v3/login/.
There's a lot more open issues available for people to tackle however, so feel free to get involved and help out if you have some spare time!
Finally other than the usual rounds of review by the team, I've been working on a spec process document that aims to explain the practical portions of the text found at https://spec.matrix.org/proposals/, but in a easily scannable manner. Look out for a PR with that in the near future.
Historically, widgets have laid outside of the spec and have only been implemented in a small subset of clients - mainly Element. As of recent weeks though, there's now a team at Element backing the feature. So exciting times ahead!
Regardless, let's highlight this MSC! It solves a crucial problem with a simple solution. Widgets can ask the client they're embedded in to do certain things (if granted certain capabilities), and the client, potentially after asking the user for permission, can allow or deny those actions. This MSC adds the machinery for a further step: the client will tell the widget what capabilities they requested were allowed, and which were denied.
I believe this spec is non-contentious, but is blocked on widgets entering the spec as a whole. Regardless, if this particular piece of the puzzle interests you, or you'd like to read all about widgets in general, the see either the MSC above or this widget spec tracking PR: https://github.com/matrix-org/matrix.org/pull/825.
It's the last days of summer here and we are toiling away at making Synapse faster and leaner! In addition to continued work on faster joins, we released Synapse v1.65.0, with new features such as support for stable prefixes for private read receipts and a new module API method for creating a room (plus some other features!), as well as a host of bugfixes and internal changes to make Synapse faster and more stable.
Make sure to check it out!
This week we released Dendrite 0.9.4, containing primarily bug fixes:
A bug in the roomserver around handling rejected outliers has been fixed
Backfilled events will now use the correct history visibility where possible
The device list updater backoff has been fixed, which should reduce the number of outbound HTTP requests and Failed to query device keys for some users log entries for dead servers
The /sync endpoint will no longer incorrectly return room entries for retired invites which could cause some rooms to show up in the client "Historical" section
The /createRoom endpoint will now correctly populate is_direct in invite membership events, which may help clients to classify direct messages correctly
The create-account tool will now log an error if the shared secret is not set in the Dendrite config
A couple of minor bugs have been fixed in the membership lazy-loading
Queued EDUs in the federation API are now cached properly
As always, please feel free to join us in #dendrite:matrix.org for more Dendrite-related discussion.
This week has seen a quite a few Helm Chart updates; element-web got updated to 1.11.3, matrix-media-repo got a Redis usage fix, and matrix-synapse got updated to 1.65.0
Nheko now has some very dirty hack to render spoilers on desktop platforms. This does not show the reason and not work in mobile mode, doesn't hide it from notifications or from the sidebar. But it is at least something. Similarly we tightened what tags we allow when validating the incoming html again. Also, as a small fix, DMs should now also properly start with encryption enabled when started from a profile and there were a few crash fixes when searching for direct chat partners and closing the window too quickly or when a user uploads a device with invalid keys.
Bug fixes and final polishing has been taking place for our “Start DM on first message” project. This is where the user receiving a new room invite as a DM will not get the notification until you’ve sent a message.
The team is testing embedding Element Call in Element Web, as well as working on other improvements to Video rooms.
The new user’s checklist is live in product. It’s our first version so let us know what you think!
In labs (you can enable labs features in settings on develop.element.io or on Nightly):
Notifications improvements to Threads are underway. The team has been testing the new MSC and related Proof of Concept (POC) which we think will solve most of the issues with Threads right now.
We did the AppStore review dance and version 1.8.27 is now available. We even got better usage strings out of it.
We now have UI integration and performance tests in ElementX. Even more, they’re joined by some really nice Screenshot UI tests. Test all the things!
We’ve fixed some small bugs and some not so small ones, coming to an Element close to you early next week. The way things are laid out, you might even see a new feature land 😉
The new app layout testing session went well and we are looking for more iOS testers for future sessions. If you’d like to help out in future sessions, please join #element-community-testing:matrix.org
We had a very successful testing session with the all new app layout. If you’d like to take part in a future session, join us over at #element-community-testing:matrix.org
This week we’ve been working on fixing some FTUE crashes and covering some edge cases. Thanks to the community members submitting bugs and more info - keep it coming!
We’re investigating reports of missing messages, as well as a bug with the Threads beta where not all 'threaded messages' are showing up in the right place…
Just pushed another version (2.8.0) of the Ruby Matrix SDK, which drops support for the EoL Ruby 2.6 (and drops a bunch of workarounds for it) in order to support much improved caching of room state data, along with more helper methods and a fix for a floating accessor that didn't get hooked up correctly.
The Matrix Rust SDK team has been busy this week, too. Progress has been made on Siding Sync in particular, the types have been finalised and merged into mainline ruma, and more API has been made accessible via FFI. The new reactive Timeline API has been progressed, it, too, has some FFI definitions now, allowing mobile client to start playing with it. Crypto-JS, too, has progressed, adding support for de/encrypting attachments in an memory efficient fashion. On the crypto-side, the longer on-going refactor and improvements have yielded another few PRs, too, that have successfully merged, while others are still pending reviews. Other than that, we've seen quite a few smaller fixes and improvements, around logging, docs and the examples.
👉️ Wanna hack on matrix rust? Go check out our help wanted tagged issues and join our matrix channel at Matrix Rust SDK.
This week in the dart SDK we mostly fixed bugs. Many of those are related to call negotiations where streams were closed in the wrong order, not closed at all or in group calls the call never learned about new members or the call_ids would not match. There were also a few fixes to the background thumbnailing support added in 0.11.1, helper methods were added to easily send the right message corresponding to the mimetype of some media and fetching a timeline for some event id should work properly again.
We have some support to mark a room as either a dm or a group using slashcommands now, you have more flexibility when implementing the SSSS Bootstrap now (using the extra Bootstrap parameter in onUpdate() and to round it all off, we now have nice coverage numbers as well as coverage display on merge request diffs.
For more info, check the release notes for 0.11.2, 0.12.0, 0.12.1 and 0.12.2: https://pub.dev/packages/matrix/changelog ;-)
Six days until Matrix Community Summit Berlin 2022
In less than a week the Matrix Community Summit Berlin is taking place at c-base.
Join us early on Thursday (25th August) for a Barcamp where we will brainstorm, draft and prototype new ideas.
The main conference days are Friday and Saturday (26th and 27th August). We have a schedule all about Matrix hosting, clients and development.
With three simultaneous tracks there sure is something for you to listen to. It's also the perfect place to get to know other community members.
Look forward to talks, workshops, a signing party, a Matrix P2P live test, dinner and barbecue!
We're not planing to stream or record the event. Our focus lies on providing a great in-person activities.
If attendees want to blog or toot/tweet about it, please use the hashtag #MatrixCommunitySummit.
Also, German-speaking folks can look forward to more coverage from the event on my podcast.
https://chrpaul.de/podcast/
Because we've heard about some confusion:
The event is NOT organised by the Matrix Foundation. To minimize the misconception, we've renamed it to the Matrix Community Summit Berlin.
This is an event initiated by Yan, jaller94 and other Matrix enthusiasts. We also organise the Matrix Meetup Berlin.
Have you ever felt lost in the Matrix world? Too many rooms and spaces to manage? Well, back by popular demand (with Timo's blessing), I present, The Room of the Week! Every week we strive to highlight a room or a space that we believe deserves attention for discussing interesting going on across the Matrix Network.
Last week, we were serving coffee, this week, it's tea! Specifically, tea at
Do you prefer sheng or shu puerh? Maybe bit more into lapsang, liuan or perhaps cliff oolongs? Greens or whites? Sencha? Having mood to discuss impact of varios clays and pot shapes? Is it better warm up water in bofura, tetsubin or electric kettle? Simply everything about the tea.
Come join us while the kettle is whistling.
If you have a room you wish to see highlighted, join us at:
https://matrix.to/#/!bIyiUUnriVoHtYzuPS:fachschaften.org?via=chat.shawnsorbom.net&via=matrix.org&via=fachschaften.org
To get your favorite room of the week highlighted.
Hey everyone! We've just released Synapse
1.65! Let's have a
peek at what's inside.
Private read receipts
A feature that the more privacy-focused users of Matrix have been missing was
the ability to hide read receipts from other users. Read receipts in rooms can
tell a user which messages another user has read in a room. However, they can
also be an unwelcome indicator that a user is currently reading a certain room,
thus giving away the user's activity on Matrix at a given time.
Hiding one's read receipts from other Matrix users is unfortunately not as
straightforward as simply preventing a client from sharing read receipts with
the server. This is because read receipts are also used by Matrix homeservers to
calculate how much of a room a user has read, and generate notification counts
for rooms accordingly.
Synapse 1.65 introduces stable support for private read receipts. This feature,
described by
MSC2285, allows
clients to send a different type of read receipt to the server. This then tells
the homeserver to use this piece of information to update the user's
notification counts, but not to share it with other users.
Improved room management APIs for modules
This version of Synapse includes two new module API methods to help Synapse
modules interact and manage rooms. The first one,
lookup_room_alias,
allows modules to retrieve the room ID corresponding to a given room alias. This
works both for local and remote aliases. The second one,
create_room,
allows modules to create new rooms on behalf of an existing user.
The
update_room_membership
method has also been updated in this release of Synapse to allow modules to join
a room the server is not already in via federation. This can be done by using
the new remote_room_hosts argument, which takes a list of homeservers to try
to join via.
Everything else
Synapse 1.65 stabilises the implementation of
MSC3827, which
allows filtering public room searches on room types. This means it is now
possible to search specifically for public spaces. For more information on this
feature, see the Synapse 1.63
announcement.
Additionally, Synapse 1.65 implements the new experimental error codes
documented by
MSC3848. Once
stabilised, these error codes will allow clients to show more specific errors to
their users about why an event could not be sent.
See the full
changelog for a
complete list of changes in this release.
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,
andrewdoh, Julian-Samuel
Gebühr and Dirk
Klimpel, as well as anyone helping us make Synapse
better by sharing their feedback and reporting issues.
At the end of each year it’s been traditional to do a big review of everything that the Matrix core team got up to that year, and announcing our predictions for the next. You can see the last edition in 2021 here - and if you’re feeling nostalgic you can head down memory lane with the 2020, 2019, 2018 ones etc too.
This year is turning out to be slightly different, however. Our plans for 2022 are particularly ambitious: to force a step change in improving Matrix’s performance and usability so that we firmly transition from our historical “make it work” and “make it work right” phases into “making it fast”. Specifically: to succeed, Matrix has to succeed in powering apps which punch their weight in terms of performance and usability against the proprietary centralised alternatives of WhatsApp, Discord, Slack and friends.
We’ve seen an absolute tonne of work happening on this so far this year… and somehow the end results all seem to be taking concrete shape at roughly the same time, despite summer traditionally being the quietest point of the year. The progress is super exciting and we don’t want to wait until things are ready to enthuse about them, and so we thought it’d be fun to do a spontaneous Summer Special gala blog post so that everyone can follow along and see how things are going!
Making it fast
We have always focused on first making Matrix “work right” before we make it “work fast” - sometimes to a fault. After all: the longer you build on a given architecture the harder it becomes to swap it out down the line, and the core architecture of Matrix has remained essentially the same since we began in 2014 - frankly it’s amazing that the initial design has lasted for as long as it has.
Over the years we’ve done a lot of optimisation work on the core team implementations of that original architecture - whether that’s Synapse or matrix-{js,react,ios,android}-sdk and friends: for instance Synapse uses 5-10x less RAM than it used to (my personal federated server is only using 145MB of RAM atm! 🤯) and it continues to speed up in pretty much every new release (this PR looks to give a 1000x speedup on calculating push notification actions, for instance!). However, there are some places where Matrix’s architecture itself ends up being an embarrassingly slow bottleneck: most notably when rapidly syncing data to clients, and when joining rooms for the first time over federation. We’re addressing these as follows…
Sliding Sync (aka Sync v3)
Historically, /sync always assumed that the client would typically want to know about all the conversations its user is in - much as an IRC client or XMPP client is aware of all your current conversations. This provided some nice properties - such as automatically enabling perfect offline support, simplifying client and server development, and making features like “jump to room” and “tab complete” work instantly given the data is all client-side. In the early days of Matrix, when nobody was yet a power user, this wasn’t really a problem - but as users join more conversations and join bigger rooms, it’s become one of Matrix’s biggest performance bottlenecks. In practice, logging into a large account (~4000 rooms) can take ~10 minutes and hundreds of megabytes of network traffic, which is clearly ridiculous. Worse: if you go offline for a day or so, the incremental sync to catch back up can take minutes to calculate (and can even end up being worse than an initial sync).
To fix this, we started work on Sliding Sync (MSC3575) in 2021: a complete reimagining of the /sync API used by Matrix clients to receive data from their homeserver. In Sliding Sync, we only send the client the data it needs to render its UI. Most importantly, we only tell it about the subset of rooms which it is visible in the scroll window of its room list (or that it needs to display notifications about). As the user scrolls around the room list, they slide the window up and down - hence the name “sliding sync”. Sliding Sync was originally called Sync v3, given it’s our 3rd iteration of the sync API - it got renamed Sliding Sync given the current sync API confusingly ended up with a prefix of /v3.
Back in December our work on Sliding Sync was still pretty early: we had the initial MSC, an experimental proxy that converted the existing sync v2 API into Sliding Sync, and a simple proof-of-concept web client to exercise it. Since then, however, there has been spectacular progress:
MSC3575 has undergone some bigiterations as we converge on the optimal API shape.
The sliding-sync proxy has matured to be something which we’re now running in stealth against matrix.org for those dogfooding the API
We added the concept of extensions to split out how to sync particular classes of data (to avoid the API becoming a monolithic monster) - specifically:
Account Data
End-to-end Encryption
To-device messages
Ephemeral events (to be done)
Presence (to be done)
We added support for spaces!
We implemented it in matrix-js-sdk (which merged a few weeks ago!)
But most importantly, we’ve also been busy implementing Sliding Sync in Element Web itself so we can start using it for real. Now, this is still a work in progress, but as of today it’s just getting to the point where one can experiment with it as a daily driver (although it’s definitely alpha and we’re still squishing bugs like crazy!) - and we can see just how well it really performs in real life.
For instance, here’s a video of my account (4055 rooms, redacted for privacy) logging in on an entirely fresh browser via Sliding Sync - the actual sync takes roughly 1 second (at 00:18 in the video). And if we’d started the sync operation while the user is setting up E2E encryption, it would have completed in the background before they even got to the main screen, giving instant login(!). Given my account typically takes ~10 minutes to initial sync (plus even more time for encryption to sync up), this is at least a real-life 600x improvement. Moreover, the sync response is only 20KB (a ~5000x improvement) - a huge win for low-bandwidth Matrix situations.
Then, having logged in, the client subsequently launches pretty much instantly, no matter how long you’ve been offline. Total launch time is roughly 4 seconds, most of which is loading the app’s assets - which in turn could well be improved by progressively loading the app. It could also be sped up even more if we cached state locally - currently the implementation simply reloads from the server every time the app launches rather than maintaining a local cache.
As you can see, this is palpably coming together, but there’s still a bunch of work to be done before we can encourage folks to try it, including:
Switching the RoomList to be fully backed by sliding sync (currently the v2 roomlist is jury-rigged up to the sliding sync API, causing some flakey bugs such as duplicate rooms)
Spec and hook up typing / receipts / presence extensions
Hook up favourites, low_priority, knocked and historical rooms
Adding back in loading room members
Apply quality-of-service to to-device messages so we prioritise ones relevant to the current sliding window
Sync encrypted rooms in the background to search for notifications (and for indexing).
More local caching to speed up operations which now require checking the server (e.g. Ctrl/Cmd-K room switching)
We also need to determine whether it’s viable to run the sliding-sync proxy against matrix.org for general production use, or whether we’ll need native support in Synapse before we can turn it on by default for everyone. But these are good problems to have!!
matrix-rust-sdk and Element X
Meanwhile, over in the land of Rust, we’ve been making huge progress in maturing and stabilising matrix-rust-sdk and exercising it in Element X: the codename for the next generation of native Element mobile apps. Most excitingly, we literally just got the first (very alpha) cut of Sliding Sync working in matrix-rust-sdk and hooked up to Element X on iOS - you can see Ștefan’s demo from last week here:
matrix-rust-sdk itself is now getting a steady stream of releases - including long-awaited official node bindings, providing excellent and performant encryption support via the newly audited vodozemac Rust implementation of Olm. It’s also great to see loads of major contributions to matrix-rust-sdk from across the wider Matrix community - particularly from Ruma, Fractal, Famedly and others - thank you!! As a result the SDK is shaping up to be much more healthy and heterogeneous than the original matrix-{js,ios,android}-sdk projects.
On Element X itself: matrix-rust-sdk is being used first on iOS in Element X iOS - aiming first for launching a stable “barbecue” feature set (i.e. personal messaging) asap, followed by adding on “banquet” features (i.e. team collaboration) such as spaces and threads afterwards. We’ve shamelessly misappropriated the barbecue & banquet terminology from Tobias Bernard’s excellent blog post “Banquets and Barbecues” - although, ironically, unlike the post, our plan is still to have a single app which incrementally discloses the banquet functionality as the user’s barbecue starts to sprawl. We’ve just published the brand new development roadmap for Element X from the rust-sdk perspective on GitHub. Above all else, the goal of Element X is to be the fastest mobile messenger out there in terms of launch and sync time, thanks to Sliding Sync. Not just for Matrix - but the fastest messenger, full stop :D Watch this space to see how we do!
Finally: Element is getting a major redesign of the core UI on both iOS and Android - both for today’s Element and Element X. I’m not going to spoil the final result (which is looking amazing) given it’ll have a proper glossy launch in a few weeks, but you can get a rough idea based on the earlier design previewed by Amsha back in June:
In addition to the upcoming overall redesign, Element also landed a complete rework of the login and registration flows last week on iOS and Android - you can see all about it over on the Element blog.
Fast Remote Joins
In terms of performance, the other area that we’re reworking at the protocol level is room joins.
One of the most glaring shortcomings of Matrix happens when a new server admin excitedly decides to join the network, installs a homeserver, tries to join a large room like #matrix:matrix.org, and then looks on in horror as it takes 10+ minutes to join the room, promptly despairs of Matrix being slow and complains bitterly about it all over HN and Reddit :)
The reason for the current behaviour is that the Matrix rooms are replicated between the servers who participate in them - and in the initial design of the protocol we made that replication atomic. In other words, a new server joining a room picks a server from which to acquire the room (typically the one in the room’s alias), and gets sent a copy of all the state events (i.e. structural data) about the room, as well as the last 20 or so messages. For a big room like Matrix HQ, this can be massive - right now, there are 79,969 state events in the room - and 126,510 auth_chain events (i.e. the events used to justify the existence of the state events). The reason there are so many is typically that the act of a user joining or parting the room is described by a state event - and in the naive implementation, the server needs to know all current state events in the room (e.g. including parted users), in order to keep in sync with the other servers in the room and faithfully authorise each new event which they receive for that room.
However, each event is typically around 500 bytes in size, and so the act of joining a big room could require generating, transmitting, receiving, authenticating and storing up to 100MB of JSON 😱. This is why joining big rooms for the first time is so painfully slow.
Happily, there is an answer: much as Sliding Sync lets clients synchronise with the bare minimum of data required to render their UI, we’ve created MSC3706 (and its precursor MSC2775) in order to rework the protocol to let servers receive the bare minimum of state needed to join a room in order to participate. Practically speaking, we only really care about events relevant to the users who are currently participating in the room; the 40,000 other lurkers can be incrementally synced in the background so that our membership list is accurate - but it shouldn’t block us from being able to join or read (or peek) the room. We already have membership lazyloading in the client-server API to support incrementally loaded membership data, after all.
The problem with this change is that Synapse was written from the outset to assume that each room’s state should be atomically complete: in other words, room state shouldn’t incrementally load in the background. So the work for Faster Joins has been an exercise in auditing the entirety of Synapse for this assumption, and generally reviewing and hardening the whole state management system. This has been loads of work that has been going on since the end of last year - but the end is in sight: you can see the remaining issues here.
As of right now, faster joins work (although aren’t enabled by default) - with the main proviso that you can’t speak in the room yet until the background sync has completed, and the new implementation has not yet been optimised. However, thanks to all the preparation work, this should be relatively straightforward, so the end is in sight on this one too.
In terms of performance: right now, joining Matrix HQ via the unoptimised implementation of faster joins completes on a fresh server in roughly 30 seconds - so a ~25x improvement over the ~12 minutes we’ve seen previously. However, the really exciting news is that this only requires synchronising 45 state events and 107 auth_chain events to the new server - a ~1400x improvement! So there should be significant scope for further optimising the calculation of these 152 events, given 30 seconds to come up with 152 events is definitely on the high side. In our ideal world, we’d be getting joins down to sub-second performance, no matter how big the room is - once again, watch this space to see how we do.
Finally, alongside faster remote joins, we’re also working on faster local joins. This work overlaps a bit with the optimisation needed to speed up the faster remote join logic - given we are seeing relatively simple operations unexpectedly taking tens of seconds in both instances. Some of this is needing to batch database activity more intelligently, but we also have some unknown pauses which we’re currently tracking down. Profiling is afoot, as well as copious Jaeger and OpenTracing instrumentation - the hunt is on!
Ratcheting up testing
All the work above describes some pretty bold changes to speed up Matrix and improve usability - but in order to land these changes with confidence, avoiding regressions both now and in future, we have really levelled up our testing this year.
Looking at matrix-react-sdk as used by Element Web/Desktop: all PRs made to matrix-js-sdk must now pass 80% unit test coverage for new code (measured using Sonarqube, enforced as a GitHub PR check). All matrix-react-sdk PRs must be accompanied by a mix of unit tests, end-to-end tests (via Cypress) and screenshot tests (via percy.io). All regressions (in both nightly and stable) are retro’d to ensure fixed things stay fixed (usually via writing new tests), and we have converted fully to typescript for full type safety.
Concretely, since May, we’ve increased js-sdk unit test coverage by ~10% globally, increased react-sdk coverage by ~17%, and added ever more Cypress integration tests to cover the broad strokes. Cypress now completely replaces our old Puppeteer-based end-to-end tests, and Sliding Sync work in matrix-react-sdk is being extensively tested by Cypress from the outset (the Sliding Sync PR literally comes with a Cypress test suite).
In mobile land, the situation is more complex given our long-term strategy is to deprecate matrix-ios-sdk and matrix-android-sdk2 in favour of matrix-rust-sdk. matrix-rust-sdk has always had excellent coverage, and in particular, adopting the crypto module in the current matrix-{js,ios,android}-sdk will represent a night and day improvement for quality (not to mention perf!). We’ll also be adopting PR checks, and screenshot testing for the mobile SDKs.
On the backend, we continue to build out test cases for our new integration tester Complement (in Golang), alongside the original sytest integration test suite (in Perl). In particular, we can now test Synapse in worker mode. The intention with Complement is that it should be homeserver agnostic so that any homeserver implementation can benefit. Indeed the project was initiated by Kegan wearing his Dendrite hat.
Finally, we’ve had a huge breakthrough with true multi-client end-to-end testing in the form of Michael Kaye’s brand new Traffic Light project. For the first time, we can fully test things like cross signing and verification and VoIP calls end-to-end across completely different platforms and different clients. It’s early days yet, but this really will be a game changer, especially for crypto and VoIP.
Next up, we will turn our attention to a performance testing framework so that we can reliably track performance improvements and regressions in an automated fashion - heavily inspired by Safari’s Page Load Test approach. This will be essential as we build out new clients like Element X.
A whole new world
All the stuff above is focused on improving the core performance and usability of Matrix - but in parallel we have also been making enormous progress on entirely new features and capabilities. The following isn’t a comprehensive list, but we wanted to highlight a few of the areas where new development is progressing at a terrifying rate…
Native VoIP Conferencing
2022 is turning out to be the year that Matrix finally gets fully native voice/video conferencing. After speccing MSC3401 at the end of last year, Element Call Beta 1 launched as a reference implementation back in March, followed by enabling E2EE, spatial audio and walkie-talkie mode in Element Call Beta 2 in June.
However, the catch was that Element Call beta 1 and 2 only ever implemented “full mesh” conferencing - where every participant calls every other participant simultaneously, limiting the size of the conference to ~7 participants on typical hardware, and wasting lots of bandwidth (given you end up sending the same upstream multiple times over for all the other participants). Element Call has been working surprisingly well in spite of this, but the design of MSC3401 was always to have “foci” (the plural of ‘focus’ - i.e. conference servers) to optionally sit alongside homeservers in order to aggregate the participating calls, a bit like this:
With foci, clients only need to send their upstream to their local focus, rather than replicating it across all the other participants - and the focus can then fan it out to other foci or clients as required. In fact, if no other clients are even watching your upstream, then your client can skip sending an upstream to its focus entirely!
Most importantly, foci are decentralised, just like Matrix: there is no single conference server as a single point of control or failure responsible for powering the group call - users connect to whichever focus is closest to them, and so you automatically get a standards-based heterogeneous network-split-resilient geographically distributed cascading conferencing system with end-to-end-encryption, powered by a potentially infinite number of different implementations. To the best of our knowledge, this is the first time someone’s proposed an approach like this for decentralised group calling (watch out, Zoom, we’re coming for you!)
Now, the VoIP team have been busy polishing Element Call (e.g. chasing down end-to-end encryption edge cases and reliability), and also figuring out how to embed it into Element and other Matrix clients as a quick way to get excellent group VoIP (more on that later). As a result, work on building out foci for scalable conferencing had to be pushed down the line.
But in the last few months this completely changed, thanks to an amazing open source contribution from Sean DuBois, project lead over at Pion - the excellent Golang WebRTC implementation. Inspired by our initial talk about MSC3401 at CommCon, Sean independently decided to see how hard it’d be to build a Selective Forwarding Unit (SFU) focus that implemented MSC3401 semantics using Pion - and published it at https://github.com/sean-der/sfu-to-sfu (subsequently donated to github.com/matrix-org). In many ways this was a flag day for Matrix: it’s the first time that a core MSC from the core team has been first implemented from outside the core team (let alone outside the Matrix community!). It’s the VoIP equivalent of Synapse starting off life as a community contribution rather than being written by the core team.
Either way: Sean’s SFU work has opened the floodgates to making native Matrix conferencing actually scale, with Šimon Brandner and I jumping in to implement SFU support in matrix-js-sdk… and as of a few weeks ago we did the first ever SFU-powered Matrix call - which worked impressively well for 12 participants!
Now, this isn’t released yet, and there is still work to be done, including:
We actually need to select the subset of streams we care about from the focus
We need to support thumbnail streams as well as high-res streams
We need rate control to ensure clients on bad connections don’t get swamped
We need to hook up cascading between foci (although the SFU already supports it!)
We need E2EE via insertable streams
Faster signalling for switching between streams
You can see the full todo list for basic and future features over on GitHub. However, we’re making good progress thanks to Šimon’s work and Sean’s help - but with any luck beta 3 of Element Call might showcase SFU support!
Meanwhile it’s worth noting that Element Call is not the only MSC3401 implementation out there - the Hydrogen team has added native support to Hydrogen SDK too (skipping over the old 1:1 calling), so expect to see Element <-> Hydrogen calling in the near future. The Hydrogen implementation is also what powers Third Room (see below…)
Matryoshka VoIP Embedding
Elsewhere on VoIP, we’ve also been hard at work figuring out how to embed Element Call into Matrix clients in general, starting with Element Web, iOS & Android. Given MSC3401 is effectively a superset of native 1:1 Matrix VoIP calling, we’d ideally like to replace the current 1:1-only VoIP implementation in Element with an embedded instance of Element Call (not least so we don’t have to maintain it in triplicate over Web/iOS/Android, and because WebRTC-in-a-webview really isn’t very different to native WebRTC). To do this efficiently however, the embedded Element Call needs to share the same underlying Matrix client as the parent Element client (otherwise you end up wasting resources and devices and E2EE overhead between the two). Effectively Element Call ends up needing to parasite off the parent’s client. We call this approach “matryoshka embedding”, given it resembles nested Russian dolls. 🪆
In practice, we do this by extending the Widget API to let Matrix clients within the widget share the parent’s Matrix client for operations such as sending and receiving to-device messages and accessing TURN servers (c.f. MSC3819 and MSC3846). This in turn has been implemented in the matrix-widget-api helper library for widget implementers - and then a few days ago Robin demonstrated the world’s first ever matryoshka embedded Element Call call, looking like this:
Note that the MSC3401 events are happening in the actual room where the widget has been added, sent by the right users from Element Web rather than from Element Call, and so are subject to all the normal Matrix access control and encryption semantics. This is a huge step forwards from embedding Jitsi widgets, where the subsequent call membership and signalling happens in an entirely separate system (XMPP via Prosody, ironically) - instead: this is proper native Matrix calling at last.
Moreover, the same trick could be used to efficiently embed other exotic Matrix clients such as Third Room or TheBoard - giving the user the choice either to use the app standalone or within the context of their existing Matrix client. Another approach could be to use OIDC scopes to transparently log the embedded client in using the parent’s identity; this has the advantage of no code changes being needed on the embedded client - but has the disadvantage that you needlessly end up running two Matrix clients for the same account side by side, and adding another device to your account, which isn’t ideal for a performance sensitive app like Element Call or Third Room.
Matryoshka embedding isn’t live yet, but between scalable calls via SFU and native Element Call in Element Web/iOS/Android, the future is looking incredibly exciting for native Matrix VoIP. We hope to finish embedding Element Call in Element Web/iOS/Android in Sept/Oct - and if we get lucky perhaps the SFU will be ready too and then Element Call can exit beta!
Finally, we also added Video Rooms to Element Web - adding the user interface for an “always on” video room that you can hop into whenever you want. You can read about it over on the Element blog - the initial implementation uses Jitsi, but once Element Call and Matryoshka embedding is ready, we’ll switch over to using Element Call instead (and add Voice Rooms too!)
Third Room
Just as MSC3401 and Element Call natively adds decentralised voice/video conferences to boring old textual Matrix chatrooms, MSC3815 and Third Room go the whole enchilada and adds a full decentralised 3D spatial collaboration environment into your Matrix room - letting you turn your Matrix rooms into a full blown interconnected virtual world.
I can’t overstate how exciting this is: one of the key origins of Matrix was back in Oct 2013 when Amandine and myself found ourselves in Berlin after TechCrunch Disrupt, debating why Second Life hadn’t been more successful - and wondering what you’d have to do to build an immersive 3D social environment which would be as positive and successful as a wildly popular chat network. Our conclusion was that the first key ingredient you’d need would be a kick-ass open decentralised communication protocol to build it on - providing truly open communication primitives that anyone could build on, much like the open web… and that was what got us thinking about how to build Matrix.
Fast forward 9 years, and Third Room is making spectacular progress in building out this dream, thanks to the incredibly hard work of Robert, Nate and Ajay. The goal of Third Room is to be an open platform layered directly on Matrix for spatial collaboration of any kind: effectively a blank canvas to let folks create freeform collaborative 3D (and in future 2D, VR or AR) experiences, either by using existing assets or building their own user-generated content and functionality. Just like the open web itself, this unlocks a literally infinite range of possibilities, but some of the obvious uses include: spatial telepresence, social VR, 3D visualisation of GIS or weather data, 3D simulated environments, search and rescue and disaster response operations (imagine streaming LIDAR from a drone surveying hurricane devastation into Third Room, where you can then overlay and collaborate on GIS data in realtime), and of course 3D gaming in all its various forms.
Now, we’re hoping to give Third Room a proper launch in a few weeks, so I’m not going to spoil too much right now - but the final pieces which are currently coming together include:
Finalising the initial version of Manifold, the multi-threaded game engine which powers Third Room (built on Three.JS, bitECS and Rapier), using SharedArrayBuffers as triple-buffers to synchronise between the various threads. See this update for a bit more detail on how the engine works.
Finalising the Matrix client interface itself, powered by Hydrogen SDK in order to be as lightweight as possible
Adding in full spatial audio and game networking via MSC3401 and Hydrogen SDK (currently full mesh, but will go SFU as soon as SFUs land!)
Adding in animated avatars (currently using Mixamo animations)
Adding in name tags and object labels
Adding in 3D Tile support in order to incrementally load 3D map tiles à la Google Earth
Building an asset pipeline from Unity and Blender through to the glTF assets which Third Room uses.
Initial framework for an in-world direct-manipulation editor
Lightmap support for beautiful high-performance static lighting and shadows
Full post-processing pipeline (bloom, depth-of-field, anti-aliasing etc)
Integrating with OIDC for login, registration, and account management (see OIDC below)
As a quick teaser - here’s an example of a Unity asset exported into Third Room, showing off lightmaps (check out the light and shadows cast by the strip lighting inside, or the shadow on the ground outside). Ignore the blurry HDR environment map of Venice in the background, which is just there to give the metals something to reflect. Check out the stats on the right-hand side: on Robert’s M1 Macbook Pro we’re getting a solid 60fps at 2000x1244px, with 13.12ms of unused gametime available for every 16.67ms frame, despite already showing a relatively complicated asset!
Meanwhile, here are some shots of Robert and Nate chasing each other around the UK City demo environment (also exported from Unity), showing off blended Mixamo animations and throwing around crates thanks to the Rapier physics engine.
And don't forget, it's just a Matrix client - with no infrastructure required other than a normal Matrix server:
As you can see, we are rapidly approaching the point where we’ll need support from technical artists to help create beautiful scenes and avatars and assets in order to make it all come to life - especially once the Blender and Unity pipelines, and/or the Third Room editor are finished. If you’re interested in getting involved come chat at #thirdroom:matrix.org!
WYSIWYG
Back in the real world, a recent new project that we haven’t spoken about much yet is adding consistent WYSIWYG (What You See Is What You Get) editing to the message composer in matrix-{react,ios,android}-sdk as used by Element Web/iOS/Android - as well as publishing the resulting WYSIWYG editor for the greater glory of the wider ecosystem.
This is a bit of a contentious area, because we’ve tried several times over the years to add a rich text editor to matrix-react-sdk - firstly with the Draft.jsimplementation by Aviral (which we abandoned after Facebook de-staffed Draft), and then later with a Slateimplementation by me (which we abandoned thanks to the maintenance burden of keeping up with Slate’s API changes). Finally, burnt by the experience with third party solutions, Bruno wrote his own editor called CIDER, which was a great success and is what Element Web uses today to author messages including ‘pills’ for structured rooms/users etc… but this deliberately didn’t provide full WYSIWYG functionality. Meanwhile, Slack added WYSIWYG, forced it on, and screwed it up - and apps like WhatsApp and Discord seem to get by fine without WYSIWYG.
However, given that users are now used to WYSIWYG in Teams and Slack, we’ve now decided to have another go at it, inspired by CIDER’s success - and with the novel twist that the heavy lifting of modelling and versioning the document and handling Unicode + CJK voodoo will be provided by a cross-platform native library written in Rust, ensuring that matrix-{react,ios,android}-sdk (and in future matrix-rust-sdk-based apps like Element X) all have precisely the same consistent semantics, and we don’t spend our lives fixing per-platform WYSIWYG bugs unless it really is a platform-specific issue with the user interface provided on that particular platform.
The project is fairly young but developing fast, and lives over at https://github.com/matrix-org/matrix-wysiwyg (better name suggestions welcome ;) - we’re aiming to get it into clients by the end of October. The editor itself is not Matrix specific at all, so it’ll be interesting to see if other projects pick it up at all - and meanwhile, if we’ve done a good job, it’ll be interesting to see if this can be used to power Matrix-backed collaborative-editing solutions in future…
Update: we should have mentioned that the WYSIWYG editor project is being built out by staff at Element, who very kindly have been sponsored to work on it by one of Element's Big Public Sector Customers in order to get to parity with Teams. Thank you!!
Are We OIDC Yet?
On the other hand, a project we recently yelled about a lot is Matrix’s transition to Open ID Connect for standards-based authentication and account management. We announced this at the end of the year and the project has built up huge momentum subsequently, culminating with the release of https://areweoidcyet.com last week to track the progress and remaining work.
Our plan is to use native OIDC in production for the first time to provide all the login, registration and account management for Third Room when it launches in a few weeks (using a branded Keycloak instance as the identity provider, for convenience). After all, the last thing we wanted to do was to waste time building fiddly Matrix-specific login/registration UI in Third Room when we’re about to move to OIDC! This will be an excellent case study to see how it works, and how it feels, and inform the rest of the great OIDC experiment and proposed migration.
Dendrite + P2P
Meanwhile, the Next Generation team has continued to focus on their mission to make Dendrite as efficient and usable as possible. Within recent months, Dendrite has matured dramatically, with a considerable list of bugs fixed, performance significantly improved and new features added - push notifications, history visibility and presence to name a few notable additions.
Neil Alexander, Kegan and Till have continued to streamline the Dendrite architecture and to refactor areas of the codebase which have long needed attention, as well as moving from Kafka to NATS JetStream, an all-new caching model and some other fairly major architectural changes. We’ve also seen an increase of code contributions from the community and outside organisations, which is exciting, and the gomatrixserverlib library which underpins much of Dendrite is also seeing more active development and attention thanks to its use in the Complement integration testing suite.
With the most recent 0.9.3 release, we are proud to announce that Dendrite nowpasses 90% of Client-Server API tests and 95% of Server-Server API tests and has support for all specced room versions in use today. We have a growing community of users who are (quite successfully) trialling using Dendrite homeservers day-to-day, as well as our own public dendrite.matrix.org homeserver, which is open to the public for registration for anyone who wants to experiment with Dendrite without running their own deployment.
Dendrite plays an important role in our future strategy as it is also the homeserver implementation used for embedded homeservers, P2P development and experimentation. In addition to being able to scale up, we have also successfully scaled down, with the Element P2P demos proving that an embedded Dendrite homeserver can run comfortably on an iOS or Android device.
Research on the Pinecone overlay network for P2P Matrix has also continued, with Devon and Neil having experimented with a number of protocol iterations and spent considerable time bringing the Pinecone Simulator up to scratch to help us to test our designs more rapidly. Our work in this area is helping us to form a better direction and strategy for P2P Matrix as a whole, which is moving more towards a hybridised model with the current Matrix federation — a little different to our original vision, but will hopefully result in a much smoother transition path for existing users whilst solving some potential scaling problems. The arewep2pyet.com site is a living page which contains a high level overview of our goals and all the progress being made.
What’s left?
Comparing all of the above with the predictions for 2022 section of the end-of-year blog post, we’re making very strong progress in a tonne of areas - and the list above isn’t comprehensive. For instance, we haven’t called out all the work that the Trust & Safety team are doing to roll out advanced moderation features by default to all communities - or the work that Eric has been doing to close the remaining gap between Gitter and Matrix by creating new static archives throughout Matrix. Hydrogen has also been beavering away to provide a tiny but perfectly formed web client suitable for embedding, including the new embeddable Hydrogen SDK. We haven’t spoken about the work that the Cryptography team have been doing to adopt vodozemac and matrix-rust-sdk-crypto throughout matrix-{js,ios,android}-sdk, or improve encryption stability and security throughout. We’ve also not spoken about the new initiative to fix long-term chronic bugs (outside of the work above) in general - or all the work being done around Digital Markets Act interoperability…
Other things left on the menu for this year include getting Threads out of beta: we’ve had a bit of an adventure here figuring out how to get the right semantics for notification badges and unread state in rooms with threads (especially if you use a mix of clients which support and don’t support threads), and once that’s done we’ll be returning to Spaces (performance, group permissions etc).
Matrix 2.0?
Looking through this post (and congratulations if you’re still reading it at this point ;P), it really feels that Matrix is on the verge of shifting into a new phase. Much as MacOS X started off as a promising but distinctly unoptimised operating system, and then subsequently got unrecognisably faster year by year (even on the same hardware!) as Apple diligently worked away optimising the kernel… similarly: we are now landing the architectural changes to completely transform how Matrix performs.
Between protocol changes like Sliding Sync, Faster Joins, native OIDC and native VoIP conferencing all landing at roughly the same time - and alongside new implementations like matrix-rust-sdk and vodozemac, let alone Third Room - it feels unquestionably like we have an unrecognisable step change on the horizon. Our aim is to land as much of this as possible by the end of the year, and if we pull it off, I’m tempted to suggest we call the end result Matrix 2.0.
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://spec.matrix.org/proposals/.
The Spec Core Team had another retro this week, and part of what we talked about was how most of the spec PR writing falls to just a few people. Starting this week, we're going to try and diversify that work across the Spec Core Team, both for reducing bus factor and increasing bandwidth of spec PRs. Hopefully the results of that will be noticeable!
For those that don't know, "SAS verification" refers to the act of two devices verifying each other through the use of Short Authentication Strings (SAS). This is the backbone of emoji verification when you verify with another user or one of your own devices.
It turns out that libolm, the olm and megolm encryption library, originally incorrectly encoded the base64 output of the message authentication code (MAC) calculation, which is a values that's passed between devices. Due to trying to maintain backwards-compatibility with older clients, this has not been fixed in newer clients yet.
This MSC proposes bumping the MAC algorithm identifier (which is agreed upon between devices when verifying) to a something new, which allows newer clients to know when to use the new or old (and incorrect) method of calculating the base64 encoding of MAC values.
As far as I can tell, this has no security implications. It's just unfortunate to have incorrect base64 encoding when interfacing with other, non-libolm, implementations of olm and megolm.
The Synapse team is hard at work making Synapse faster and leaner. Work continues
apace on faster room joins over federation, and it seems that the work might land
sooner rather than later, although there are no solid dates yet.
In other news, profiling work is being done to determine ways to hopefully increase
the speed of local room joins and DM creation. Stay tuned for more information in the future on that.
Finally, it was an RC release week. Synapse 1.65.0rc2 was released, and it contains some fun features and bugfixes. Check it out!
This week we released Dendrite 0.9.2 which contains the following updates:
Dendrite now supports history visibility on the /sync, /messages and /context endpoints
It should now be possible to view the history of a room in more cases (as opposed to limiting scrollback to the join event or defaulting to the restrictive "join" visibility rule as before)
The default room version for newly created rooms is now room version 9
New admin endpoint /_dendrite/admin/resetPassword/{userID} has been added, which replaces the -reset-password flag in create-account
The create-account binary now uses shared secret registration over HTTP to create new accounts, which fixes a number of problems with account data and push rules not being configured correctly for new accounts
The internal HTTP APIs for polylith deployments have been refactored for correctness and consistency
The federation API will now automatically clean up some EDUs that have failed to send within a certain period of time
The /hierarchy endpoint will now return potentially joinable rooms (contributed by texuf)
The user directory will now show or hide users correctly
Send-to-device messages should no longer be incorrectly duplicated in /sync
The federation sender will no longer create unnecessary destination queues as a result of a logic error
A bug where database migrations may not execute properly when upgrading from older versions has been fixed
A crash when failing to update user account data has been fixed
A race condition when generating notification counts has been fixed
A race condition when setting up NATS has been fixed (contributed by brianathere)
Stale cache data for membership lazy-loading is now correctly invalidated when doing a complete sync
Data races within user-interactive authentication have been fixed (contributed by tak-hntlabs)
This brings our current test compliance figures to:
Client-server APIs: 90%
Server-server APIs: 95%
As always, please feel free to join us in #dendrite:matrix.org for Dendrite-related discussion.
What? Another week, another major release?
Yes, we want to make breaking changes obvious, and the bridge now requires Node.js 16+.
The release fixes the outdated yarn.lock file. Thanks to the package maintainers of NixOS to point this out! 👋
Furthermore, mentioning Matrix users in Discord got fixed.
And, for the fans of containers, we've re-added the release of Docker images. 🐳
The URL changed and we don't plan to update halfshot/matrix-appservice-discord on Docker Hub.
The image can be pulled from ghcr.io/matrix-org/matrix-appservice-discord:v3.0.0.
Nheko now shows you a pretty preview for rooms you are trying to join. This uses MSC3266, which you might need to enable in your synapse config, if you want to see more than the roomid of the room you are trying to join. It tries to fall back to the /hierarchy endpoint, but that won't work over federation.
Similarly you can now somewhat edit what rooms are in a space. I grew up with Windows 98, so this is a very nested right click menu. We are still discussing some of the wording choices for the options there, so if you have any opinions about it, feel free to give feedback about it! This is part of the bigger goal to be able to manage your communities from within Nheko, so stay tuned for more features coming in that area.
red_sky (nheko.im) also improved our notifications code on macOS. You can now disable the notification sound in the system settings, which for some reason requires badge permissions to show that option... macOS will always remain a mystery to us! Similarly we fixed the source text for notifications on Windows, which should now not show a stray %1 anymore as well as a few other cleanups.
Ever started a DM with someone, only to get distracted and leave them staring into an empty timeline wondering who you are and what you want. Well, it is no more! In this update new DMs will only notify the person you’re messaging once you’ve sent your first message.
That’s not the only exciting update in EleWeb/Desktop this week, including the newly extended voice messages! Instead of voice messages capped at 2 minutes, users are now able to send a voice note of up to 15 minutes long. Go forth and record 🎤
In upcoming releases we’re also looking at how to improve a user’s first few days in Element. We know that it can be daunting to stare at an empty screen and wonder how to get going, which is why we’ve designed and built a checklist for new users. This checklist will help them to get off the ground and messaging friends in no time.
In labs (you can enable labs features in settings on develop.element.io or on Nightly):
Threads improvements are still very much underway. We have a proof of concept (PoC) for improving notifications that we’re testing to ensure scalability and performance.
Our release this week was rejected by Apple. Their feedback? Our info.plist comments do not provide enough context as to why we’re asking for access to things like the camera, photos, or contacts. Never fear! We’ve updated our copy and we’re confident that it’s clearer than ever.
Also in the upcoming release:
Fixing the crashes that some users were running into when switching space.
The new in-app notifications now also appear in the notification centre
And a bug fix for the rare issue of sending duplicate images to a timeline when sending multiple photos
We’re also working on changing the layout of our mobile apps, and work is well underway on iOS. We’re excited to share these big changes with you so keep your eyes peeled on our socials and in other TWIM notes.
Join us over at #element-community-testing:matrix.org on Tuesday 16th August at 12:00 BST to try out the new app layout on iOS! There’s a little bit of setup required so check out the room ahead of time for instructions :)
In the upcoming Android release we’ve fixed some crashes; including where the app would crash if a user attempted putting non-ASCII characters in their MXID during account creation.
Biometric login is now disabled if the device you’re on does not support biometrics.
We’ve also been working hard on adding unit tests to increase coverage.
There’s work being done on the modularisation of languages that may help decrease the complexity of translation and move us towards a set of common strings between platforms.
Join us over at #element-community-testing:matrix.org on Tuesday 16th August at 15:00 BST to try out the new app layout on Android! There’s a little bit of setup needed so check out the room ahead of time for instructions 🙂
v2.1: Custom emojis and stickers (Birthday edition)
Hello everyone,
On July 28 project marked its one-year milestone. During this time it has grown at an unexpected rate, both in terms of development as well as popularity. This is great news, so let's celebrate that with this birthday edition.
In this update, we have added Custom emoji and sticker support to Cinny. Custom emoji and stickers were not in our roadmap but that's the surprise. Aren't they cool?
Apart from the emoji and stickers, there are tons of other features such as Blurhash, Mark entire space as read, user pills, and bug fixes. Check out the releasepage for a detailed changelog.
In the case of the roadmap, we are still on that, work on the "Rich input editor" is in progress and will come as the next release. Stay tuned for that!
A new version of the Ruby Matrix SDK has now been released, adding a new abstraction in the form of a Sinatra-inspired bot DSL, as well as general fixes and improvements. Making a Ruby-based Matrix bot can now be as simple as;
#!/usr/bin/env ruby
require 'matrix_sdk/bot'
command(:praise, desc: 'Gives you praise', only: -> { room.user_can_send? client.mxid, 'm.reaction' }) do
room.send_notice "#{sender}, you tha' man!"
room.send_event 'm.reaction', {
'm.relates_to': {
rel_type: 'm.annotation',
event_id: event[:event_id],
key: '👍️'
}
}
end
Next weekend, Sat 20th and Sun 21st, FrOSCon will be taking place. It's a conference about open source software near Bonn, Germany.
There will be some program around Matrix, though I'm still looking for volunteers to help me with a stand and DevRoom.
For the stand we want a small group to explain Matrix to others. For the DevRoom we want some talks and workshops. Anyone's welcome to ask me for more info or to get involved.
Announcing matrix-locust, a new tool for load testing Matrix homeservers, based on the Python load testing framework Locust. It's very early days for this project, but we're already discovering some interesting results. There isn't an official tagged "release" yet, but anyone interested in this topic is encouraged to stop by #load-testing:matrix.org and say hello.
Have you ever felt lost in the Matrix world? Too many rooms and spaces to manage? Well, back by popular demand (with Timo's blessing), I present, The Room of the Week! Every week we strive to highlight a room or a space that we believe deserves attention for discussing interesting going on across the Matrix Network.
A place to discuss buying, brewing, and drinking everyone's favorite morning beverage of choice! I had no idea there was so much Nuance to this topic until I joined this room . For example, did you know there was a correct way to distribute coffee grounds when you first pour to ensure maximum flavor? Neither did I! Whether you are new to the world of coffee drinking, or a seasoned connoisseur of morning Joe, this room has something for everyone who loves coffee.
If you have a room you wish to see highlighted, join us at:
https://matrix.to/#/!bIyiUUnriVoHtYzuPS:fachschaften.org?via=chat.shawnsorbom.net&via=matrix.org&via=fachschaften.org
to get your favorite room of the week highlighted.
That's all I know 🏁
See you next week, and be sure to stop by #twim:matrix.org with your updates!
TL;DR: we’ve just launched areweoidcyet.com to track the project to adopt OpenID Connect (OIDC) as the authentication method used by Matrix. It has a load of useful resources (FAQs, status etc.) so do please check it out!
Hey folks,
As you may know, there is a proposal and project afoot to change the way authentication is done in Matrix…
Currently Matrix uses a custom authentication protocol baked into the Matrix spec. This poses a number of drawbacks. To overcome these drawbacks the project proposes migrating to use the industry standard authentication protocol OpenID Connect (OIDC) instead.
In terms of why this is a good idea: MSC3861 has all the details - please check it out!
The bottom line is that Matrix should focus on being a decentralised communication protocol - not an authentication protocol… and by adopting a dedicated authentication protocol we can benefit from all sorts of goodies such as easy 2FA and MFA, passwordless-auth via WebAuthn, Login via QR-code, alternative CAPTCHAs and so much more.
In support of this the proposal extends to the Matrix.org Foundation joining the OpenID Foundation as a non-profit member to support the work that the OpenID Foundation is doing to build a robust and audited ecosystem for open authentication.
Whilst this project proposes a significant change to the Matrix ecosystem that would take some time to migrate to, we believe that it will better support the continued growth and adoption of Matrix in the years to come.
Today we are launching the areweoidcyet.com website which is packed with information and resources on the project:
What? Why? When?
MSC proposals
Status of homeservers, clients, auth servers (OIDC Providers/OPs)
A client implementation guide
Links to the Matrix OIDC Playground environment where you can try out the latest progress
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.
This week saw the merge of three MSCs from first-time MSC authors! MSC3818 (Copy room type on upgrade) from @Mikaela and both MSC3786 (Add a default push rule to ignore m.room.server_acl events) and MSC3827 (Filtering of /publicRooms by room type) from @SimonBrandner. Nice work to both of them!
A bundle of small quality-of-life changes to the .well-known server and client endpoints. Removing some ambiguities, replacing old and deprecated endpoints as well as a potential size cap suggestion.
Looks like a good contender for one to push over the line given a bit of review and response!
TWIM: someone in #matrix:matrix.org complained that the image in the spec section is always the same, so I made this gif (actually webp) out of all those images:
We've started work on our HG HomeServer written in pure TypeScript, compilable as a single JS file, with no dependencies except NodeJS. It's intended for a special use cases when Matrix is used as a backbone for custom apps. It's lightweight, minimal and for the moment isn't even planned to support full Matrix spec. We might make it possible to run it on browser later. https://github.com/heusalagroup/hghs
Another week, another release! Synapse 1.64.0 was released this week, featuring
a host of new features, bugfixes, and internal changes aimed at reducing memory usage,
increasing performance, and improving the developer experience. Check out the full list of changes
here. In addition, work continues on faster room joins. The goal gets closer every day!
This week we released Dendrite 0.9.0 and Dendrite 0.9.1. There are quite a few big changes, including an all-new caching model and several optimisations. This release also moves our baseline supported Go version up to Go 1.18.
The following changes are included across both releases:
Dendrite now uses Ristretto for managing in-memory caches
Should improve cache utilisation considerably over time by more intelligently selecting and managing cache entries compared to the previous LRU-based cache
Defaults to a 1GB cache size if not configured otherwise
The estimated cache size in memory and maximum age can now be configured with new configuration options to prevent unbounded cache growth
Added support for serving the /.well-known/matrix/client hint directly from Dendrite
Refactored membership updater, which should eliminate some bugs caused by the membership table getting out of sync with the room state
The User API is now responsible for sending account data updates to other components, which may fix some races and duplicate account data events
Optimised database query for checking whether a remote server is allowed to request an event over federation without using anywhere near as much CPU time (PostgreSQL only)
Database migrations have been refactored to eliminate some problems that were present with goose and upgrading from older Dendrite versions
Media fetching will now use the /v3 endpoints for downloading media from remote homeservers
HTTP 404 and HTTP 405 errors from the client-facing APIs should now be returned with CORS headers so that web-based clients do not produce incorrect access control warnings for unknown endpoints
Some preparation work for full history visibility support
Upgrades a dependency which caused issues building Dendrite with Go 1.19
The roomserver will no longer give up prematurely after failing to call /state_ids
Removes the faulty room info cache, which caused of a number of race conditions and occasional bugs (including when creating and joining rooms)
The media endpoint now sets the Cache-Control header correctly to prevent web-based clients from hitting media endpoints excessively
The sync API will now advance the PDU stream position correctly in all cases (contributed by sergekh2)
The sync API will now delete the correct range of send-to-device messages when advancing the stream position
The device list changed key in the /sync response should now return the correct users
A data race when looking up missing state has been fixed
The /send_join API is now applying stronger validation to the received membership event
Fixes a crash that could occur during event redaction
The /members endpoint will no longer incorrectly return HTTP 500 as a result of some invite events
Send-to-device messages should now be ordered more reliably and the last position in the stream updated correctly
Parsing of appservice configuration files is now less strict (contributed by Kab1r)
The sync API should now identify shared users correctly when waking up for E2EE key changes
The federation /state endpoint will now return a HTTP 403 when the state before an event isn't known instead of a HTTP 500
Presence timestamps should now be calculated with the correct precision
A race condition in the roomserver's room info has been fixed
A race condition in the sync API has been fixed
As always, please feel free to join us in #dendrite:matrix.org for more Dendrite-related discussion.
This week has seen the usual updates to my Helm Charts - with element-web being updated to 1.11.2 and matrix-synapse to 1.64.0.
Additionally, the matrix-synapse chart now also allows for adding entirely custom .well-known data - along with an example on how to use that for MSC1929.
This bridge connects users on Matrix and Discord – or other platforms, if combined with other bridges.
Earlier this year the community bridge has been adopted by the Matrix.org bridge team to give it some attention.
Its most recent update dated back to December 2020 and some fixes waited for a new release.
Well, here it is! v2.0.0
Its breaking changes are the requirement of NodeJS 14 or newer and the usage of yarn instead of npm install.
Furthermore, the update introduces a changelog and rolls out the guidelines we use for developing other matrix.org bridges.
„Start DM only on first message“ has landed on develop. Changing the DM flow from invite → message to message & invite at the same time. If you want to see it live, join our testing session at 12:00 BST on Tuesday
Version 1.8.24 is available on the App Store with our new Sign Up and Sign In flows. The update is rolling out slowly and should be available to everyone by Monday.
The work on our new app layout is coming along nicely with much of it merged into the repo (but disabled behind a build flag).
In-app notifications will now also be delivered to Notification Centre.
Continuous improvements are being made to the Live Location sharing feature.
Integration tests are now run for every PR on matrix-ios-sdk more than doubling the reported test coverage!
1.4.31 is rolling out which includes the new and improved FTUE onboarding experience along with fixes for markdown lists no longer always starting from 1 and html entities showing up in messages.
The new app layout is starting to materialise with PRs available on github for anyone interested in having a sneak peek!
We’re continuing to make improvements to Live Location sharing and cross signing verification as well as investigating performance issues.
📰 You want updates more frequently and close to when they actually happen? Join our Effektio Matrix News room, discuss general aspect in our foyer or hang out with the devs in our tech channel.
After a short vacation, I've done some new work on populus-viewer. Most of this has been UX and bugfixes, but I've added one new feature that I wanted to share. MSC3775: Markup Locations for Audiovisual Media gives a spec for annotating audio and video on matrix, but it also allows you to annotate images. So, for completeness sake, I've added support for annotating image files in Populus! This might be useful for discussing publication layouts, product designs, or for teaching art history. So populus can now annotate: video, audio, images and pdfs.
As always, if you want to learn more, follow populus development, or discuss the future of decentralized social annotation on Matrix, come join us at #opentower:matrix.org.
matrix-widget-api v1.0.0 was released yesterday, reflecting the fact that we're not expecting any big changes to the library's architecture for the foreseeable future, and that it's more or less ready for wider use.
It also comes with a couple of new features ✨ for widget authors: Sending and receiving to-device messages with MSC3819, and getting TURN servers from the client with MSC3846. Together, these features enable some new complex use-cases, such as doing VoIP from inside a widget. See Matrix Live for a preview of what that looks like with Element Call! 📹️
This is as good a time as any to mention that matrix-widget-api doesn't have to just be for web-based apps. If you're building mobile apps with Matrix and want to make use of widgets, running matrix-widget-api inside a web view to liaison with the actual widget can make it a lot simpler to start supporting widget API features. If you're curious, watch Element iOS+Android for upcoming examples of this.
This week we've been building on the initial work on the pion call server (SFU) from Sean, and have made our very first call through it with Element Call! It's still very early and there's still lots of work to do, but this will allow Element Call to scale up to much higher numbers of people.
The VoIP team are also looking after widgets now, and in our quest to embed Element Call into the Element apps, we've hit the milestone of releasing matrix-widget-api 1.0.0. We're also making great progress towards embedding into Element Web.
This was also a week of fighting the ci. After the integration tests landed, coverage reporting broke and an investigation was kicked off to check whether llvm-cov is in a usable state for us by now (it is not), but a fix was found. We've also started regretting adding npm-based workflows in our repo, as we've found ourselves at the end of an upgrade bug and the saw CI failing without us changing anything :shakes_fist_at_sky: . A fix was found quickly by pinning a sub-dependency. On a similar note, we've postponed merging the kotlin bindings until the android team is back on it and available to answer some questions we have, and the wasm-js bindings showed build failures on CI, which the original author will have to take a look at after coming back from vacation - thus delaying crypto-js a bit further.
👉️ Wanna hack on matrix rust? Go check out our help wanted tagged issues and join our matrix channel at Matrix Rust SDK.
It's been a while since I've made an update on Polyjuice Client Test. Since the last update:
several more tests have been added
there have been some some front-end improvements
I've also improved the documentation, done some refactoring, and added some helper/utility modules to make things clearer. My goal is to make it easier for people who don't know Elixir to be able to read and write tests without running away screaming.
compatibility with some Matrix clients has been improved
added some functions to make it easy for tests to completely override Matrix endpoints
I'm also happy to say that Polyjuice Client Test has helped find bugs in some clients, which have since been fixed.
This week I'm showing off an early look at the Matrix public archive. As the name suggests, it acts as an archive of history for your world-readable Matrix rooms. This allows you to view historical content day-by-day and jump back years ago to see what your Matrix room was up to.
More importantly, it also allows Google to do the same thing so you’ll probably start finding Matrix content from your favorite search engine and be able to harness the massive knowledge base stored in Matrix. Imagine seeing Matrix logs instead of Stack Overflow answers when googling questions! The new portal into the Matrix ecosystem 🌌
Under the hood, we use the MSC3030 /timestamp_to_event endpoint to fetch the messages for a given day and then we sever-side render the events with the Hydrogen SDK. Re-using Hydrogen gets us pretty and native(to Element) looking UI and keeps the maintenance burden of supporting new event types in Hydrogen.
If you want to follow what’s going on and see how it's coming along, you can checkout the project on GitHub, https://github.com/matrix-org/matrix-public-archive
I was able to to host a matrix-synapse server on termux app on an android device. I documented the process on termux-synapse github repo And started working on a script that automates the process (final commit is being currently tested before pushing).
It was a "for fun" type of thing. But I can see it being useful for people who do not have access to a raspberry pi (such as myself at the moment) to use as a small homeserver. It can hold up in 1 to 1 Direct Messages and in small rooms.
Have you ever felt lost in the Matrix world? Too many rooms and spaces to manage? Well, back by popular demand (with Timo's blessing), I present, The Room of the Week! Every week we strive to highlight a room or a space that we believe deserves attention for discussing interesting goings on across the Matrix Network.
A matrix space dedicated to finding all of the free open source games, engines, and assets in the Matrix world so that you don't have to. Helpfully organized, and well maintained, it is the Premier stop for open source gaming on The Matrix Network!
If you know of a room that you would like to see highlighted, please visit
https://matrix.to/#/!bIyiUUnriVoHtYzuPS:fachschaften.org to let us know of the room that you would like to spotlight.
That's all I know 🏁
See you next week, and be sure to stop by #twim:matrix.org with your updates!
It's that time again: there's a new Synapse release, fresh out of the oven!
Let's take a look at what's inside Synapse
1.64.
Delegating email verification is now deprecated
Synapse 1.4.0
introduced a configuration option (account_threepid_delegates.email) to allow
homeservers to delegate validating the ownership of email addresses to an
external identity server. This validation is used by Synapse when adding an
email address to a Matrix account, or before performing a password reset.
As of Synapse 1.64, this option is deprecated, and Synapse will print a warning
if it is used. This is because this option relies on old API endpoints that have
since been
removed from the
Matrix specification.
Synapse can do this validation internally provided it is configured with details
of an SMTP server. Administrators currently relying on
account_threepid_delegates.email should therefore ensure that an SMTP server
is correctly configured, and remove the account_threepid_delegates.email
option. See the configuration
guide
for more information.
We plan to fully remove this configuration option in Synapse 1.66, which is
expected to be released on August 30th.
Note that the equivalent option to validate the ownership of phone numbers
(account_threepid_delegates.msisdn) can still be used, though we expect to
deprecate it in a future release of Synapse.
Improved TLS support for sending emails
When configuring an SMTP server to use to send out emails to users, server
administrators can configure Synapse to use TLS to communicate to that server.
Until now, only STARTTLS was
supported in this case.
Synapse 1.64 introduces a new force_tls configuration option in the email
section of the configuration file. If this new setting is set to true Synapse
will use TLS for the initial connection rather than upgrading via STARTTLS.
A couple of weeks ago, we
identified a
memory leak within frozendict, which is
a library that Synapse relies on. This would in turn cause Synapse instances to
slowly leak memory when processing /sync requests.
We highly encourage server administrators who installed Synapse via pip to
upgrade their local version of frozendict to version 2.3.3 or later, which
includes a fix to this issue. The Docker image matrixdotorg/synapse and the
Debian packages from packages.matrix.org already include the updated library.
Everything else
This version of Synapse introduces support for room version 10! This new room
version enables support for the new knock_restricted join rule, to allow
knocking into rooms which are otherwise restricted to members of a specific room
(or space). See the Matrix specification about room version
10 for more information.
Additionally, Synapse 1.64 features a new rate limiter to limit the rate of joins to the same
room. It is intended as a mitigation against abuse scenarios involving joining a
lot of users from different homeservers to a room to then send spam across it.
See the configuration
guide
for more information.
This release of Synapse also extends the List
Rooms
and Room
Details
admin APIs to include the type of a room in responses, allowing server
administrators to differentiate spaces from other rooms.
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,
andrewdoh, Thomas
Weston, jejo86,
villepeh, Jörg
Behrmann and Jacek
Kuśnierz, as well as anyone helping us make Synapse
better by sharing their feedback and reporting issues.
Hello everyone! For this week's spec update you get me, Travis, instead of anoa (sorry). The heart of Matrix is the specification, modified by Matrix Spec Change (MSC) proposals - learn more at https://spec.matrix.org/unstable/proposals/
Be sure to read the Spec Core Team (SCT) section in today's update for some exciting news about Matrix though - this has a good chance of affecting how the MSC process works in the future.
The SCT has been powering through MSCs for the second week in a row, using a new internal process to encourage activity and hopefully keep momentum going. If there's an MSC you think should be on the agenda, please visit the #sct-office:matrix.org and raise it for consideration 🙂
We've also been at IETF 114 to talk about MIMI - an initiative to define a standard for messaging interoperability inspired by the DMA. Matrix appears to fit perfectly into this use-case, so we've been talking with various folks involved to ensure Matrix is on the radar, including preparing our own Internet-Draft to demonstrate how it could work. MIMI is not currently a working group within the IETF, but the expectation is that it will be soon - we look forward to this happening, and are eager to contribute to the process here - or proposing Matrix itself to IETF as an initiative in its own right.
This MSC covers an Extensible Events (MSC1767) schema definition for translatable text! This would allow a client to send a message in multiple languages, with the receiver able to choose which language they're prefer to see the message in (ideally falling back to a default or machine translation if their preferred language was not available).
Like other MSCs that rely on Extensible Events, MSC1767 will need to land before this MSC can. But until then, it's great to see all of the wonderful things this feature will allow Matrix to do!
Greetings! We have been hard at work on Synapse this week. Work on faster room joins continues. In addition, Synapse 1.64.0rc2 was released. Notable features include:
support for room version 10
per-room rate limiting for room joins
support for Implicit TLS for sending emails
and much more, as well as a number of bugfixes, improvements to the documentation, and other changes to make Synapse leaner, faster, and generally more awesome.
This week The Construct server runs on Alpine Linux using freshly cut docker images building on the 0.7 release announced last week. A few images are available for preview while a more complete matrix is filled out. I am proud to announce to TWIM that Construct offers the most compact docker image for a Matrix server at just under 15 MiB; the only caveat is that media
thumbnailing won't be available.
There's still a lot of room for optimization and docker experts to critique! Feel free to join the discussion at #construct:zemos.net and check out https://github.com/matrix-construct/construct today!
It’s holiday season but that won’t slow us down! We’ve been hard at work fixing defects and improving features.
Our recently released new search experience is continuing to be improved. This week we’ve added more accessibility, so it can be helpful to all.
We’ve completely finished the migration of our tests.
There’s a new “use case” screen for users who sign up, it asks folks who they'll talk to the most on Element and, in the future, that will help us to tailor the experience.
In labs (you can enable labs features in settings on develop.element.io or on Nightly):
It’s an exciting week for both our mobile teams as we’re ready to release our new authentication flow! If you’ve been reading TWIM for a while you’ll know that we’ve been working hard, across all Element teams, to improve our onboarding experience. Part of this work on iOS was a new Create Account flow.
We’re rolling the changes out slowly, so don’t panic if you don’t see the new experience yet!
In even more exciting news, our test coverage has increased with a big bump. We’ve gone from 12% to 51%!
We’ve also continued to make updates and improvements to our location sharing feature.
On the ElementX front we have our first proof of concept for sliding sync (sync v3) working and we’ve almost finished setting up snapshot and integration testing. We also have Rust logs, a new authentication service and performance tests incoming.
Finally, the account deactivation button has had a change of copy - this keeps us inline with Apple guidelines around deleting and deactivating accounts.
Our new Nightly releases are now available and allowing us to catch any bugs or regressions even faster - exciting!
It will soon be easier than ever to create an account on Element, so if you’ve been waiting for an update before you recommend us to others, it’s nearly time! We’ll be rolling these changes out slowly over the next week or so.
Alongside the new create account flow will be an updated sign in and reset password experience. Check it out and let us know what you think.
Also in this release we’ve added a “match system settings” to the Font size screen.
Mac builds are enabled, which means, that olm is bundled into macOS and iOS builds too. So no need to build olm yourself anymore.
trixnity-crypto has been introduced, which contains the matrix e2e-encryption stuff and was previously located in trixnity-client. The relocation allows you to possibly use this in e. g. appservices. Key trust level calculation, key backup, key verification will be moved into it too.
client: basic event relation support has been added to be prepared for the next matrix spec
It's been a week of quite, constant progress on many fronts, most not that visible to the outside observer. For once, the progress on integration sliding sync into element-x for iOS has taken up speed, with many smaller bug fixes and additional features exposed through the FFI being added and performance optimisations. After the internal jack-in testing tool, this is the first actual trial of sliding sync for rust (and after the js-implementation, only the second client to actually use sliding sync overall)—and it has been tremendous. Latest tests put the loading time to first view on the first 20-ish rooms at a 150ms range 🎉.
Note: this is a new Discord bridge. The playbook still retains Discord bridging via matrix-appservice-discord and mx-puppet-discord. You're free too use the bridge that serves you better, or even all three of them (for different users and use-cases).
By the end of last week we received a bunch of proposal for talks and workshops for the conference.
It were all together 32 proposals and we accepted almost all of them.
We released already multiple versions of our schedule. The current version is 0.5 htmljson
There is even some space left for late comers. In case you decide spontaneously to come and want to talk let us know, we will find a way.
Tickets
You now get tickets for the summit for the fantastic price of 0 euro. We like to know in advance how many people will come.
If you have already a ticket and can’t come please let us know. So we can give them to people on the waiting list.
Sharing is caring
I case you have a room or ride to share or you are looking for transport or accommodation please visit our #matrix-summit-sharing:c-base.org.
If you'd rather listen to Yan and me talking about the Matrix Summit and its schedule, we recorded a podcast episode for you to get informed on the go.
The team of effektio, the mobile-first organizing app build on matrix, is happy to announce the new website. Aside from the revamped team section, we are particularly excited about the new product progress page, as the questions "what are you building exactly, and how far are you with the progress" are commonplace. With the product page we hope to provide more clarity what we mean, in actual features, when we say "organize yourself, your friends, family, clubs and all other communities from the palm of your hand". Each feature also links right into the specific section of the Github project, so you can get an unobstructed view of the actual progress happening—and contribute, if you like.
Dept of Ping 🏓
Here we reveal, rank, and applaud the homeservers with the lowest ping, as measured by pingbot, a maubot that you can host on your own server.
An episode with the maintainers of Threematrix, the 100% Rust bridge between Matrix and Threema!
In addition to that, Open Tech Will Save Us will be back on Wednesday 27 at 16:00 UTC! The topic will be "what makes a platform", or more specifically: "are Linux or the web platforms". There are many fascinating topics to discuss, such as "is it possible to create an app for Linux" (it's not as simple as it sounds), "why are some people against theming?", or "why do developers want to use platforms".
And to answer that, who other than the Linux desktop most advanced projects GNOME and KDE, and people working on Matrix, the protocol that wants to become as unmissable as the web itself, and more specifically on a deeper integration of widgets with Matrix clients?
You can join #otwsu:matrix.org to ask your questions on July 27 during the live show, and bookmark either https://stream.matrix.org or the YouTube stream.
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.
Lots of MSCs moving through the pipeline in the last couple weeks! As always, be sure to take a look at those in Final Comment Period above - only a few days left to comment on them before they merge/close!
Otherwise the Spec Core Team is looking to try and get a handle on the current MSC backlog - this means taking a look at all of the open MSCs, triaging them and organising them into a loose priority queue. This is likely to take quite a while to do and may not ever be complete - but should give us and everyone else an idea of what's expected to land in upcoming Matrix spec versions.
The idea this MSC proposes is to add a possible m.softkick field to room membership events of type "leave", which if present will inform clients that the user has only been kicked temporarily, and they are welcome to rejoin.
This helps with the IRC bridging use case laid out in the MSC.
I use Zeal – an offline documentation browser using the same docsets as Dash for MacOS.
It allows me to browse MDN, ExpressJS docs, NodeJS docs and other languages and formats while not relying on the Internet when traveling.
They have "208 awesome docsets", and I guess you know which one I'm missing – or used to miss, until I packaged it myself.
If you use Dash or Zeal, give it a try. Let me know, if you find pages that are not working.
I hope that Matrix will be included in their list of user-contributed docsets.
Note, this is not an official release distribution of the Matrix Spec. Enjoy at your own risk of this breaking or not getting updated.
Construct server has been refurbished to support the Ubuntu 22.04+ platform. I am happy to
report that Construct performs faster and more reliably than ever before. It's been
a long time since the last update due to COVID-related health problems, but development
has picked up again. I'd like to thank @manu_kamath:matrix.org and @uis246 for their
contributions, and of course Yan Minari for keeping things together over the past year.
Additional work implementing the latest MSC's will continue in the coming weeks so I
encourage everyone to show support in #construct:zemos.net and contribute if possible.
Several enhancements have taken place this release, so I'd just like to highlight one
here: The media database has been eliminated and has been integrated into the main
events database. Construct did always store media in rooms by splitting files
into blocks, but it offloaded the content block to separate storage leaving just a
hash of the content in the matrix event. Construct now stores blocks directly in event
content via hardware-accelerated base64 encoding. The result performs better because
there's only one database query instead of two, and the room can be shared between
servers in a Construct Cluster.
Construct is a performant and robust Matrix Server and Natural Language Processor.
Please be mindful of any laws in your country which require registering your instance
for commercial use.
This week we've released Synapse 1.63! This release includes a few features such as better rate limiting for invites, as well as experimental support for MSC3827 which allows filtering public room search results by room type. The latter will, once stabilised, allow for better discoverability of public spaces since it will allow clients to specifically look for them. Read all about this new release on the matrix.org blog: https://matrix.org/blog/2022/07/20/synapse-1-63-released
We've also spent some time clarifying documentation and prompts about the usage statistics Synapse automatically reports if configured with report_stats set to true. The new documentation page lists exactly what is reported and how this reporting works. This clarification work included removing the use of "anonymised" when referring to this feature to make it clearer that, even though Synapse does not report identifiable information about users and rooms, it does report the homeserver's name (i.e. the value of the server_name configuration setting).
Since people seemed to like seeing updates on my Helm Charts; matrix-synapse got bumped to 1.63.0 and then 1.63.1, as well as receiving some expanded handling of workers - all worker instances now come with both startup- and liveness probes attached by default.
Say hello to a new bridge in Matrix universe (or rather fediverse): Threematrix. As you might've guessed from the name: It's a bridge between the Threema messenger and Matrix. Threema is a very popular messenger in europe, especially in German speaking countries (it's a swiss company). We've just released our very first alpha version – it's a very simple bot bridge for now, but we have quite a lot of improvements on our todo list. Currently, it only works with the (paid) Threema Gateway API product, but we're trying to talk to Threema to come up with a more affordable hobbyist pricing model for bridge use. Feel free to follow our releases in the GitHub repo, follow our Mastodon account and join our Matrix room to stay up to date or ask any questions.
P.S.: We're two freelance developers and we're being funded by the German Prototype Fund program. If you're an OSS developer in Germany, check them out!
Hello all -- since our last TWIM announcement, Hookshot has been updated from 1.7.2 to 1.8.1. Aside from usability fixes and documentation improvements, there have been some notable changes to generic webhook support:
XML webhook payloads are now decoded instead of being treated as blobs of text. This means they render more nicely as room messages, and more importantly, it allows them to work with custom JavaScript transformations. (#410)
GET requests for generic webhooks are no longer supported by default. For details, refer to the documentation. (#397)
Quadrix v1.2.2 is now available for Linux (https://snapcraft.io/quadrix, https://flathub.org/apps/details/chat.quadrix.Quadrix) and Android (https://play.google.com/store/apps/details?id=chat.quadrix.android). Other platforms will soon follow.
New in this release:
Spanish translation!!!
Fix for the Jitsi Meet link displayed to non-Quadrix users (thanks to @alpabrz:matrix.org)
Please leave feedback/comments at #quadrix:matrix.org or in the issues at https://github.com/alariej/quadrix (stars welcome :-)
I got a fantastic release for you to day and it won't fit inside a normal sized update so without further ado, here are the highlights:
Notification counts 💯 (LorenDB, d42)
You can now see notification counts in more spaces, like your task bar or in
the community sidebar.
For better work-life balance you can hide the notification counts on a per
space basis.
For notification counts in the task bar your desktop environment needs to
support the Unity protocol.
Notifications are also preserved across restarts now.
Moderation 👮♀️
You can now change the permissions and aliases of a room.
Permissions are shown in the Memberlist
A new /redact command to redact an event or all messages by a user.
You can now provide a reason when inviting, knocking, kicking and banning
users.
Faster startup ⚡
On at least some systems startup should now be instant even with thousands
of rooms.
Encryption improvements 🛡️
Support for the most recent changes to Matrix E2EE including fallback keys,
no longer relying on the sender_key.
Compatibility and stability improvements when dealing with different base64
encodings and when verifying users and devices.
Fetch the whole online key backup at the click of a button.
Integration with external apps 🗺️ (LorenDB)
Nheko now has a D-Bus API, which you can enable in the settings menu.
This allows applications like KRunner or Rofi to list and switch between
rooms.
If you are reading this a bit early, the release builds might still be cooking, but they should be available in the next few hours. There about 40 more features and at least 30 bugfixes waiting for you, so checkout the release here: https://github.com/Nheko-Reborn/nheko/releases/tag/v0.10.0 . I'd like to thank as always everyone who contributed to this release, it has been a pleasure to work with you folks and I hope I will see a few of you in the next release as well.
As you might be able to tell, moderation features were a big topic this release. But they are clearly not done yet and I expect more of those to land in the future now that Nheko is fairly mature. There are also a few other cool features planned, so while this release is exciting, there will always be more! Same bad client, same bad... wait, this is not my outro!
Please give this release a whirl and tell us how you like it in #nheko:nheko.im!
Release 1.4.28 has been dropped, to give us time to fix the regression and performance issue added when key share history was worked on. The next RC 1.4.30 will be done next week as usual.
We have started to work on using the new Realm Kotlin SDK (we are using the legacy Java SDK at the moment): it should improve the stability of the app (and so the crash free session) and improve devX. Nearly all the possible blocking points have been handled. This will force us to use suspend methods, which will be useful for ElementX.
Latest tweaks on FTUE have been merged on develop. We will iterate on a few things, but we are close to releasing the feature! New wordings for FTUE are waiting for translations on Weblate. Thanks to all the contributors!
We have set up a nightly build using Firebase app distribution. We keep it internal for the moment, we will see in the future if we want to open it to the community.
New project! open-super-dapp-android is a fully open source, open standard, decentralized "super app" including a secure, encrypted Matrix compatible messenger based off of the Element Messenger, and an Ethereum crypto wallet and web3 browser based off of Alpha Wallet. Our mission is to foster, and provide access to, a decentralized and secure digital commons for all. Github repo: https://github.com/2gatherproject/open-super-dapp-android
OSD is a downstream project of Element, aiming to provide the functionalities of a "super app" like WeChat, just as an open, distributed and not-for-profit app instead of a proprietary, closed and for-profit one.
This software is pre-alpha, actively seeking contributors, donors and maintainers/leaders. Get in on the ground floor and help build something amazing!
Currently, Open Super dApp builds and runs with full functionality of the Element messenger and Alpha Wallet in the same Android app, with all existing tests passing. Efforts to further integrate their functionalities are just beginning.
Next steps include:
Demonstrate easy to use person to person Ethereum payment functionality between Matrix users.
Provide a powerful and easy to use messaging and payment javascript API for use by web3 applications accessed through the Open Super dApp. Produce sample web dApps using this API.
Centralize cryptographic secrets between the wallet and the messenger.
Build a parallel iOS version for iPhones using Element iOS and Alpha Wallet iOS.
This week has seen an merges of many minor, partially longer-pending PRs into the mainline code base: among them a fix for a longer pending CI problem with Apply builds, an update to latest ruma and many minor fixes and style improvements. We've also gotten the Crypto-bindings for the JS in web using WASM a lot further, the only thing remaining for a release are some last minute PRs and fixes in the release infrastructure. But the most changes to the code base this week have been coming from the appservice department, who've submitted, reviewed and merged a whopping seven PRs this week, fixing various problems and adding a bunch of appservice specific features.
Beyond purely code changes this week has seen a lot of project starts, too: For ones, with the help of the rust team, the iOS Team has started integrating the Sliding-Sync/Sync V3 into the upcoming Element-X-Series; the team has put up the first PR to add integration tests against an actual synapse server (some issues pending); a workshop set out the first ideas for the new upcoming timeline API; and a very interesting draft PR was brought in from community member docweirdo proposing a new API on top of the existing SDK to have futures wait for actual completion - no more sending a message and observing sync for the appropriate response yourself.
Synapse Maintenance Container – Docker container with tools for synapse & postgres database maintenance
A lot of things added and changed, and I'm sure I missed something, so I will go with a release candidate this time
New in v0.4.1-RC1
enable PGPASSFILE support for better database password handling
add tools to detect and maybe fix synapse issue 12507 and 13026 (No state group for unknown or outlier event)
internal: added an extension for mautrix-go to serve synapse admin api requests
lots of iternal changes
stui is a typical golang binary, it's also available as stand alone version from the release page
Tools for No state group for unknown or outlier event
[docker run -it --rm registry.gitlab.com/mb-saces/synatainer:0.4.1-RC1] stui 12507 --help
[docker run -it --rm registry.gitlab.com/mb-saces/synatainer:0.4.1-RC1] stui 13026 --help
The tools scan the database for the issues and tells you which rooms are affected. Adding the --fix option, it ~~destroys your database~~deletes the bogus extremeties. Use at your own risc. And make a backup.
The doc have still a lot of space for improvements…
Start the container without command and let do its magic :)
What it does by default:
daily:
purge all rooms without local members
run the state autocompressor (500/100)
weekly:
delete old remote media (>90 days)
delete old message history from public joinable rooms (>180 days)
Because I don't like having to change my display name to tell coworkers when I'm away, I've written a maubot plugin for an auto-responder bot.
It allows me to signal when I'm away, at which point anyone who sends a message in an existing DM will be sent an automated reply so they know that I'm away, when I'll be back, and how to reach out to me in case of emergencies (it does this once per DM until I come back). When I'm back, I just need to tell the bot and it will automatically turn off the auto-responder and give me a summary of the DMs in which I've missed messages while I was away.
The source code and package for this plugin are available right here: https://github.com/babolivier/maubot-autoreply 🙂
I just created a simple bot that generates a MSC url from the specified MSC id.
The source code for the project can be found at https://mau.dev/minecraftchest1/mscbot/. And example instance can be found at @maubottest1:synapse1.arsrobotics.org Demo and use the bot in #msc-bot:synapse1.arsrobotics.org
My release tracking bot received a bunch more work since the last update. It now supports tracking repos, groups, and user stars on GitHub, GitLab (both .com and self-hosted), as well as Gitea (though Gitea requires a token for reading stars). And also tracking "releases" - a.k.a. tags - on bare Git repos, at least as long as they don't require SSH key authorization. Things are getting ever closer to a 1.0 release, with only really some missing bang commands and error reporting being the remaining pieces.
The Matrix Summit 2022 is a community event taking place Thu, 25th to Sun, 28th Aug
at c-base in Berlin. Today's the last day to propose presentations and workshop. The exact deadline is 22:22 (Europe/Berlin).
Will you be in Berlin and have a Matrix project to talk about? Can you organise a workshop about how to use Matrix? How does your community or workplace use Matrix?
Submit your proposal now!
FrOSCon is a conference that takes place in Siegburg/Bonn, Germany on 21st and 22nd August. Most presentations will be German, but there are some in English as well. It's all about free, open source software.
And, best of all, we'll have an entire DevRoom track for a day – full of Matrix. Furthermore, you can come by the Matrix stand for that famous hallway track. ✨ I know I'll be there. 👋
Hey all, it's time for another Synapse release! That's right, Synapse
1.63 is out,
let's have a look at it.
Clarifications on "anonymised" server statistics
Synapse has the ability to report usage statistics to the Matrix.org Foundation
(or to another location, if configured to do so). These statistics, such as
number of users, number of rooms joined by the server, etc. (they don't feature
any identifiable information about users and rooms) help us monitor the health
of the public federation.
In this release of Synapse, we have updated our public documentation about this
feature to clarify how it works and what exactly is being reported. This
documentation can be found right
here.
Note that previous documentation and prompts surrounding this feature called it
"anonymised" server statistics. This could easily be misinterpreted, as while
per-user statistics are not reported, homeserver server names are. We have
therefore changed said documentation and prompts to be clearer about
what is actually reported.
Note that your homeserver will never report any statistics if the report_stats
configuration option is set to false. Server admins who are curious about
which software is used by the Matrix.org Foundation to record server statistics
can check out panopticon.
Improved filtering for public room search
This version of Synapse ships with an experimental implementation of
MSC3827 which
allows filtering public room search results by room type. This feature will
enable better discoverability for Matrix Spaces (which are rooms with a specific
type, under the hood), as it will enable clients to search specifically for
public spaces.
This feature is still experimental as its
MSC hasn't
completed the MSC process yet, though it is in its final comment period at the
time this post is being written. This means a stable implementation will be
coming to Synapse very soon, so watch this space!
Everything else
Synapse 1.63 also includes a new rate limiter to limit invites per issuer. This
rate limiter can be configured using the new rc_invites.per_issuer
configuration setting, see the
documentation
for more information.
See the full
changelog for a
complete list of changes in this release.
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,
villepeh and Petr
Vaněk, as well as anyone helping us make Synapse
better by sharing their feedback and reporting issues.
