Category – In the News
15 posts tagged with "In the News" (See all categories)

Moznet IRC is dead; long live Mozilla Matrix!

2020-03-03 — In the News — Matthew Hodgson

Hi all,

Heads up that yesterday at 12:00 ET, the Mozilla IRC network was switched off after over 22 years of valiant service, and the Matrix instance is now in full production. You can get at it via the Riot instance at, by pointing your client at, or by joining rooms on the server over federation via its room directory.

We'd like to thank Mozilla again for putting their faith in Matrix, and are determined to do everything we can to ensure we're a more than worthy successor to IRC; we have big boots to fill :)

We've been gathering a huge amount of invaluable FTUE (first time user experience) feedback from the commentary in - and we're in the process of implementing it over the coming weeks. In particular, we've already implemented alphabetic room ordering, custom theming support, and done a bunch more SSO work.

The immediate priorities include:

  • Fixing a regression in jumps/jank when scrolling (fix PRed to develop today)
  • Enabling Mozilla IAM SSO authentication on remaining "interactive user auth" flows (e.g. managing devices)
  • Fixing the UX around selecting server when browsing the room directory.
  • Fixing notification defaults, behaviour and settings UX
  • Better educating users to connect to the if using a random app.

Finally, it's worth noting that the matrix-ircd project is seeing some commits again, many thanks to jplatte from the Ruma project - so if you are currently despairing the demise of moznet, never fear: you may yet be able to connect to the Mozilla matrix server via IRC (authing via Mozilla IAM, of course) and pretend that none of this newfangled Matrix stuff exists :D

Please keep the feedback coming in - we're gathering it all up into Github (under the mozilla label) as well as a high level Google Doc to help collate everything.


- The Matrix Core Team.

(Comments over at HN)

Welcoming Mozilla to Matrix!

2019-12-19 — In the News — Matthew Hodgson

Hi all,

We’re incredibly excited that Mozilla just announced that they’ve selected Matrix as the successor to IRC as the communication platform for the public Mozilla community!! This comes off the back of a formal 1-month trial in September to evaluate various options side by side, and now New Vector will be helping Mozilla get their homeserver up and running on the hosting platform over the coming weeks - and federating openly with the rest of the open global Matrix network! :)

We have always been massive fans of Mozilla: they have been an excellent role model as champions of the open web, open standards, not to mention open source - and it’s fair to say that Mozilla has been a major inspiration to how Matrix has evolved (Riot aspires to be to Matrix what Firefox is to the Web: a flagship open source app which provides an accessible friendly interface into an open standard network). It’s very reassuring to see that Mozillians from the trial recognise the alignment and have converged on Matrix as the way forward - it’s a massive win for the open web and standards-based communication in general.

It’s worth noting that we’ve also always been massive fans of IRC, and Matrix is unashamedly derivative of IRC in capabilities and culture, while broadening the scope to decentralised synchronisation and relaying of any kind of data. For context, the genesis of the team which eventually spawned Matrix was on a student IRC server ~20 years ago - and subsequently everything we’ve worked on (up to Matrix) was coordinated exclusively through IRC. We even used to give conference talks on how to run your project/company off IRC. I can’t really overstate how fundamental IRC is to our history - and we still keep our private IRC network online for old time’s sake (albeit bridged to Matrix). The very first protocol bridge we built for Matrix back in 2015 was for IRC - and Moznet and Freenode were the first public bridges we turned on. As of right now, /stats u on Moznet says that there are 4950 connected users, of which 1724 (so 35%) are actually Matrix users connected via the Moznet bridge - effectively using Matrix as a big decentralised IRC bouncer in the sky.

All of this is to say is that we deeply understand how dependent Mozilla has been on IRC over the years, and that we built Matrix to be a worthy successor which tries to capture all the best bits of IRC while providing much richer primitives (E2E encryption, openly federated decentralised chatrooms, arbitrary data sync, HTTP API, VoIP, etc). It’s also worth noting that even though Moznet is being turned off, matrix-ircd exists as a very promising project that exposes any Matrix homeserver as an ircd - so for all you IRC die-hards, Moznet can absolutely live on in the afterlife! (matrix-ircd is still alpha right now, but it’s a relatively modest amount of Rust and PRs are very welcome - if you grok IRC it should be a really really fun project to contribute to).

In other news, the trial in September was an amazing opportunity to gather feedback first-hand from a wide range of Mozillians as they gave Riot and Matrix a spin, often for the first time - and it was a lot of fun to take that feedback and rapidly act on it to improve the app. For instance, having direct expert feedback on our screenreader support meant that we were able to radically improve our accessibility, and we’ve kept up the momentum on this since the trial (regardless of the outcome) with Mozilla & Riot devs hacking together with the aim of making Riot the most accessible communication app out there without exception. Huge thanks to Marco Zehe for all his guidance (and PRs), as well as the rest of!

Meanwhile, Riot’s UX continues to mature in general. One of our two primary projects right now is to improve First Time User Experience (FTUE) - i.e. making our UX as smooth and polished and predictable as possible, especially as seen by new users. This project had just kicked off in September as the Mozilla trial began, and some of the major improvements to the Room Directory and Room Creation flow which subsequently landed in Riot/Web 1.5 were prioritised directly based on Mozillian feedback. Since the trial we’ve been focusing more on our other primary project (getting E2E Encryption enabled by default), but we will be back on FTUE asap - particularly to incorporate all the feedback we anticipate as Mozilla goes live! We are absolutely determined for Riot to have as good if not better UX than the likes of Slack or Discord. New Vector is also actively hiring more designers to come work fulltime on Riot’s UI and UX as we shift Riot’s focus from being developer-led to design-led - if this sounds interesting, please get in touch! And finally, everything is of course open source and PRs are genuinely appreciated to keep Riot heading in the right direction (please just check first if they change the UI/UX).

Finally, in case you’re dreading having to use a graphical chat client like Riot, the Mozilla instance will of course be accessible to any Matrix client that floats your boat - for instance, weechat-matrix also got a spurt of development to support Mozilla IAM single-sign-on so that commandline junkies can get their fix too. (It’s worth noting that weechat-matrix really is an incredibly fully featured and usable client - complete with full end-to-end encryption support. If you haven’t tried it, you’re missing out).

So, to conclude: it has been indescribably valuable to have the expertise and enthusiasm of the Mozilla community in contributing feedback and fixes to Riot (and even building new Matrix bots!). Huge thanks to everyone who invested their time and energy participating in the trial and for their trust in concluding that Matrix was the way forward. We see this as a massive responsibility and honour to help power the wider Mozilla community, and we will do everything we can to make it as successful as conceivably possible :)

To the future of an open web, with even more open communications!

Matthew, Amandine & the whole Matrix & Riot team :)

P.S. we’ve come a long way since Matrix was first proposed for Mozilla :D

New Vector raises $8.5M to accelerate Matrix/Riot/Modular

2019-10-10 — In the News — Matthew Hodgson

Hi all,

Massive news for the Matrix ecosystem today: New Vector (the startup which the Matrix core team formed to fund development in 2017) has raised an additional $8.5M of funding in order to speed up Riot/Matrix development and expand Matrix hosting via!

The new funding comes in the form of a Series-A equity investment in New Vector from three of the top venture capital funds in London. The round is led by Notion - a fund set up by the founders of MessageLabs, who many will know as one of the leaders in secure hosted email services. Notion's long history with email means they immediately clocked the potential of Matrix's mission to build a new open global communication network - after all, Matrix aims to provide a worthy replacement to email (and the phone network, for that matter!). Joining Notion in the round is First Minute - a fund set up by the founders of (arguably the UK's most famous original dotcom), and Dawn - one of the largest SaaS tech specialist funds in Europe (famous for backing iZettle, Mimecast, Neo4J and many more).

The last funding round in Jan 2017 from Status was instrumental in stabilising the big 1.0 release of Matrix and exiting beta in June; creating the Foundation as a neutral custodian for the standard; stabilising and optimising Synapse; redesigning Riot’s user interface; bringing in a full-time professional UI/UX designer to the team; supporting the huge amount of encryption work required to turn on E2EE by default (cross-signing, key backups, device verification, e2e search, the pantalaimon e2e daemon etc); creating RiotX/Android; and launching the hosting platform.

With today’s new funding, the priorities for Matrix will be:

  • Turning on end-to-end encryption by default for DMs

  • Much better support for grouping rooms into Communities

  • More anti-abuse/anti-spam mechanisms

  • Shrinking Synapse (and/or finishing Dendrite)

  • Canonical DMs (having one DM per user, and have them feel clearly distinct from ‘rooms’)

  • Extensible Profiles

  • Decentralised accounts

  • Threading

  • ...and furthering development on P2P Matrix, so users can have full control of their communications without having to run or trust a server.

On the New Vector side, this funding will support:

  • A whole new wave of UX improvements to Riot (particularly around onboarding and first time user experience).

  • Making Modular hosting as polished and powerful as possible.

  • Creating a whole new set of next-generation Modular integrations.

While New Vector’s contributions to the Matrix ecosystem can’t be ignored, it’s important to remember that the Matrix protocol and specification itself is governed and controlled by the independent and neutral Foundation and its extensive governance processes. We set up the Foundation very deliberately to enforce the protocol's neutrality, formalise the project's mission, goals and values and hold true to them no matter what - specifically to protect the project from conflicts of interest with commercial Matrix endeavours, including New Vector.

That said, New Vector would not be taking money from any investors if they did not believe their goals are aligned with Matrix's. To clarify:

  • Matrix exists to create an open secure decentralised communication network and protocol for the benefit of all.
  • New Vector exists to help grow Matrix and be one of many successful companies in the Matrix ecosystem.
  • Tech VCs exist to invest their money in growing companies in order to get a return when the company IPOs or gets bought.

It turns out that these goals are not incompatible if one understands that the potential of the Matrix ecosystem is directly linked to its openness and size (hint: funding sources who didn’t understand this self-selected out ;). By funding Matrix development and helping the open ecosystem and public network grow, New Vector can go provide more Matrix hosting via and more Government & Enterprise deployments via Critically, other companies can and do build on top of Matrix too - and frankly the more players there are, the more valuable the network, and the more value to be shared for everyone (including New Vector). This model worked relatively well for the Web, and we believe it'll work for Matrix too.

Update: the best way to gauge the investment in New Vector is to hear it first hand from the investors. Jos from Notion is leading the round, and has a fascinating blog post (written with zero input from Matrix or New Vector folks) to explain where the investors are coming from.

Update 2: More excellend first-hand analysis from Dan at Dawn Capital, who does a really deep dive into how they see Matrix and New Vector. Another must read.

In this case, all of New Vector's new investors have a background as respected tech entrepreneurs, and everyone involved categorically understands that Matrix itself is a neutral open source project, and the mission is to help build up the whole network to be as successful as possible rather than sabotage it by constraining it in any way.

All in all, it’s great news for the ecosystem: Matrix is 5 years old now, and while the project is growing faster than ever (over 300% more active users in the last year!) - it's fair to say that we haven't moved as fast as our mainstream competition - for instance, Slack is only a year older, and Discord is a year younger(!) Obviously much of this is due to Matrix being a completely different proposition: we've been creating an open spec; multiple client codebases; multiple server codebases; the bridges; a fault tolerant decentralised network - not to mention the complexities of decentralised E2E encryption. Based on comparing with our endeavours prior to Matrix, we estimate building this stuff in an open and decentralised manner takes roughly 6 times longer.

But the project is now in a position where the foundations are solid: the protocol is out of beta, reference servers and clients are production ready, and it’s more than time to make all of this mainstream. We have to redouble our focus on user experience and ensure that we compare favourably to today’s established alternatives while staying true to Matrix’s principles. Making sure there are Matrix apps out there which provide a credible alternative to with the likes of Slack and WhatsApp (until they eventually join Matrix, of course) is what will make the difference between Matrix being a cliquey FOSS curiosity versus really being the natural successor to today’s instant messaging, email and phone networks.

In the end; Matrix needs full-time contributors in order to continue to grow, and keeping New Vector funded is a very good way to achieve that (New Vector is hiring!). (That said, if any philanthropic billionaires are reading this, the Foundation is actively soliciting donations to improve Matrix independently of New Vector's efforts - particularly around the areas of countering online abuse and disinformation).

In the meantime, huge thanks to Jos at Notion for believing in Matrix and leading this funding round in New Vector - and huge thanks to the other investors who saw the potential! And most of all, thank you to all those supporting Matrix, whether by donating to the Foundation, promoting and using the protocol, or contributing code to the ecosystem. You are the ones keeping the dream alive :)

You can read things from the NV angle over at We hope you’re as excited as we are to open a whole new chapter as Matrix picks up yet more momentum :D

-- Matthew, Amandine, and the whole Matrix team

5-user Matrix homeserver hosting now available from Modular

2019-07-17 — General, In the News —

Hi all,

If you’ve been looking for a way to have you own Matrix homeserver without having to run it yourself, you may be interested to hear that Modular (the Matrix hosting provider run by New Vector, the startup which hires many of the Matrix core team) is now offering a personal-sized small homeserver hosting service, supporting a minimum size of 5 user servers.

A lot of recent performance work on Synapse has been driven by the need to make smaller dedicated servers more efficient to run - and so if you run your own homeserver you’ll be benefiting from all this work too :) Meanwhile, if you choose to outsource your server hosting to Modular, you’ll be indirectly supporting core Matrix and Synapse development, given most of the core Matrix team work for New Vector - it’s through buying services like this which lets us keep folks able to hack on Matrix as their day job.

See more details over at the Modular blog post!

Synapse 1.0.0 released

2019-06-11 — General, Releases, In the News — Neil Johnson

Well here it is: Synapse 1.0.

Synapse 1.0 is the reference implementation of the Matrix 1.0 spec. The goal of the release overall has been to focus on security and stability, such that we can officially declare Synapse (and Matrix) out of beta and recommended for production use. This means changing the default room protocol version used for new rooms to be v4, which includes the new state resolution algorithm, as well as collision-resistant event IDs, which are now formatted to be URL safe.

Synapse 1.0 also ships with support for the upcoming v5 room protocol (which enforces honouring server key validity periods), but this will not be used as the default for new rooms until a sufficient number of servers support it.

Please note that Synapse 1.0 does not include significant performance work or new features - our focus has been almost exclusively on providing a reference implementation of the Matrix 1.0 protocol. But having cleared our backlog on security/stability issues we will finally be now unblocked to pursue work around reducing RAM footprint, eliminating forward-extremity build up, and shipping new features like Edits, Reactions & E2E cross-signing support.

As part of the security work, Synapse 1.0 contains a breaking change that requires a valid TLS certificate on the federation API endpoint. Servers that do not configure their certificate will no longer be able to federate post 1.0.

It is also worth noting that Synapse 1.0.0 is the last release that will support Python 2.x and Postgres 9.4. For more information see here but the TL;DR is that you should upgrade asap.

This release has been a long time coming. Many thanks indeed to everyone who helped test the release candidates and provided feedback along the way.

Synapse 1.0 is just one component of a larger Matrix 1.0 release, which you can read all about here.

As ever, you can get the new update here or any of the sources mentioned at Note, Synapse is now available from PyPI, pick it up here. Also, check out our Synapse installation guide page

The changelog since 0.99.5 follows:

Synapse 1.0.0 (2019-06-11)


  • Fix bug where attempting to send transactions with large number of EDUs can fail. (#5418)

Improved Documentation

  • Expand the federation guide to include relevant content from the MSC1711 FAQ (#5419)

Internal Changes

  • Move password reset links to /_matrix/client/unstable namespace. (#5424)

Synapse 1.0.0rc3 (2019-06-10)

Security: Fix authentication bug introduced in 1.0.0rc1. Please upgrade to rc3 immediately

Synapse 1.0.0rc2 (2019-06-10)


  • Remove redundant warning about key server response validation. (#5392)
  • Fix bug where old keys stored in the database with a null valid until timestamp caused all verification requests for that key to fail. (#5415)
  • Fix excessive memory using with default federation_verify_certificates: true configuration. (#5417)

Synapse 1.0.0rc1 (2019-06-07)


  • Synapse now more efficiently collates room statistics. (#4338, #5260, #5324)
  • Add experimental support for relations (aka reactions and edits). (#5220)
  • Ability to configure default room version. (#5223, #5249)
  • Allow configuring a range for the account validity startup job. (#5276)
  • CAS login will now hit the r0 API, not the deprecated v1 one. (#5286)
  • Validate federation server TLS certificates by default (implements MSC1711). (#5359)
  • Update /_matrix/client/versions to reference support for r0.5.0. (#5360)
  • Add a script to generate new signing-key files. (#5361)
  • Update upgrade and installation guides ahead of 1.0. (#5371)
  • Replace the perspectives configuration section with trusted_key_servers, and make validating the signatures on responses optional (since TLS will do this job for us). (#5374)
  • Add ability to perform password reset via email without trusting the identity server. (#5377)
  • Set default room version to v4. (#5379)


  • Fixes client-server API not sending "m.heroes" to lazy-load /sync requests when a rooms name or its canonical alias are empty. Thanks to @dnaf for this work! (#5089)
  • Prevent federation device list updates breaking when processing multiple updates at once. (#5156)
  • Fix worker registration bug caused by ClientReaderSlavedStore being unable to see get_profileinfo. (#5200)
  • Fix race when backfilling in rooms with worker mode. (#5221)
  • Fix appservice timestamp massaging. (#5233)
  • Ensure that server_keys fetched via a notary server are correctly signed. (#5251)
  • Show the correct error when logging out and access token is missing. (#5256)
  • Fix error code when there is an invalid parameter on /_matrix/client/r0/publicRooms (#5257)
  • Fix error when downloading thumbnail with missing width/height parameter. (#5258)
  • Fix schema update for account validity. (#5268)
  • Fix bug where we leaked extremities when we soft failed events, leading to performance degradation. (#5274, #5278, #5291)
  • Fix "db txn 'update_presence' from sentinel context" log messages. (#5275)
  • Fix dropped logcontexts during high outbound traffic. (#5277)
  • Fix a bug where it is not possible to get events in the federation format with the request GET /_matrix/client/r0/rooms/{roomId}/messages. (#5293)
  • Fix performance problems with the rooms stats background update. (#5294)
  • Fix noisy 'no key for server' logs. (#5300)
  • Fix bug where a notary server would sometimes forget old keys. (#5307)
  • Prevent users from setting huge displaynames and avatar URLs. (#5309)
  • Fix handling of failures when processing incoming events where calling /event_auth on remote server fails. (#5317)
  • Ensure that we have an up-to-date copy of the signing key when validating incoming federation requests. (#5321)
  • Fix various problems which made the signing-key notary server time out for some requests. (#5333)
  • Fix bug which would make certain operations (such as room joins) block for 20 minutes while attemoting to fetch verification keys. (#5334)
  • Fix a bug where we could rapidly mark a server as unreachable even though it was only down for a few minutes. (#5335, #5340)
  • Fix a bug where account validity renewal emails could only be sent when email notifs were enabled. (#5341)
  • Fix failure when fetching batches of events during backfill, etc. (#5342)
  • Add a new room version where the timestamps on events are checked against the validity periods on signing keys. (#5348, #5354)
  • Fix room stats and presence background updates to correctly handle missing events. (#5352)
  • Include left members in room summaries' heroes. (#5355)
  • Fix federation_custom_ca_list configuration option. (#5362)
  • Fix missing logcontext warnings on shutdown. (#5369)

Improved Documentation

  • Fix docs on resetting the user directory. (#5282)
  • Fix notes about ACME in the MSC1711 faq. (#5357)

Internal Changes

  • Synapse will now serve the experimental "room complexity" API endpoint. (#5216)
  • The base classes for the v1 and v2_alpha REST APIs have been unified. (#5226, #5328)
  • Simplifications and comments in do_auth. (#5227)
  • Remove urllib3 pin as requests 2.22.0 has been released supporting urllib3 1.25.2. (#5230)
  • Preparatory work for key-validity features. (#5232, #5234, #5235, #5236, #5237, #5244, #5250, #5296, #5299, #5343, #5347, #5356)
  • Specify the type of reCAPTCHA key to use. (#5283)
  • Improve sample config for monthly active user blocking. (#5284)
  • Remove spurious debug from MatrixFederationHttpClient.get_json. (#5287)
  • Improve logging for logcontext leaks. (#5288)
  • Clarify that the admin change password API logs the user out. (#5303)
  • New installs will now use the v54 full schema, rather than the full schema v14 and applying incremental updates to v54. (#5320)
  • Improve docstrings on MatrixFederationClient. (#5332)
  • Clean up FederationClient.get_events for clarity. (#5344)
  • Various improvements to debug logging. (#5353)
  • Don't run CI build checks until sample config check has passed. (#5370)
  • Automatically retry buildkite builds (max twice) when an agent is lost. (#5380)

Breaking the 100bps barrier with Matrix, meshsim & coap-proxy

2019-03-12 — In the News — Matthew Hodgson

Hi all,

Last month at FOSDEM 2019 we gave a talk about a new experimental ultra-low-bandwidth transport for Matrix which swaps our baseline HTTPS+JSON transport for a custom one built on CoAP+CBOR+Noise+Flate+UDP.  (CoAP is the RPC protocol; CBOR is the encoding; Noise powers the transport layer encryption; Flate compresses everything uses predefined compression maps).

The challenge here was to see if we could demonstrate Matrix working usably over networks running at around 100 bits per second of throughput (where it'd take 2 minutes to send a typical 1500 byte ethernet packet!!) and very high latencies.  You can see the original FOSDEM talk below, or check out the slides here.

Now, it's taken us a little while to find time to tidy up the stuff we demo'd in the talk to be (relatively) suitable for public consumption, but we're happy to finally release the four projects which powered the demo:

In order to get up and running, the meshsim README has all the details.

It's important to understand that this is very much a proof of concept, and shouldn't be used in production yet, and almost certainly has some glaring bugs.  In fact, it currently assumes you are running on a trusted private network rather than the public Matrix network in order to get away with some of the bandwidth optimisations performed - see coap-proxy's Limitations section for details.  Particularly, please note that the encryption is homemade and not audited or fully reviewed or tested yet.  Also, we've released the code for the low-bandwidth transport, but we haven't released the "fan-out routing" implementation for Synapse as it needs a rethink to be applicable to the public Matrix network.  You'll also want to run Riot/Web in low-bandwidth mode if you really wind down the bandwidth (suppressing avatars, read receipts, typing notifs and presence to avoid wasting precious bandwidth).

We also don't have an MSC for the CoAP-based transport yet, mainly due to lack of time whilst wanting to ensure the limitations are addressed first before we propose it as a formal alternative Matrix transport.  (We also first need to define negotiation mechanisms for entirely alternative CS & SS transports!).  However, the quick overview is:

  • JSON is converted directly into CBOR (with a few substitutions made to shrink common patterns down)
  • HTTP is converted directly into CoAP (mapping the verbose API endpoints down to single-byte endpoints)
  • TLS is swapped out for Noise Pipes (XX + IK noise handshakes).  This gives us 1RTT setup (XX) for the first connection to a host, and 0RTT (IK) for all subsequent connections, and provides trust-on-first-use semantics when connecting to a server.  You can see the Noise state machine we maintain in go-coap's noise.go.
  • The CoAP headers are hoisted up above the Noise payload, letting us use them for framing the noise pipes without having duplicated framing headers at the CoAP & Noise layers.  We also frame the Noise handshake packets as CoAP with custom message types (250, 251 and 252).  We might be better off using OSCORE for this, however, rather than hand-wrapping a custom encrypted transport...
  • The CoAP payload is compressed via Flate using preshared compression tables derived from compressing large chunks of representative Matrix traffic. This could be significantly improved in future with streaming compression and dynamic tables (albeit seeded from a common set of tables).
The end result is that you end up taking about 90 bytes (including ethernet headers!) to send a typical Matrix message (and about 70 bytes to receive the acknowledgement).  This breaks down as as:
  • 14 bytes of Ethernet headers
  • 20 bytes of IP headers
  • 8 bytes of UDP headers
  • 16 bytes of Noise AEAD
  • 6 bytes of CoAP headers
  • ~26 bytes of compressed and encrypted CBOR
The Noise handshake on connection setup would take an additional 128 bytes (4x 32 byte Curve25519 DH values), either spread over 1RTT for initial setup or 0RTT for subsequent setups.

At 100bps, 90 bytes takes 90*8/100 = 7.2s to send... which is just about usable in an extreme life and death situation where you can only get 100bps of connectivity (e.g. someone at the bottom of a ravine trying to trickle data over one bar of GPRS to the emergency services).  In practice, on a custom network, you could ditch the Ethernet and UDP/IP headers if on a point-to-point link for CS API, and ditch the encryption if the network physical layer was trusted - at which point we're talking ~32 bytes per request (2.5s to send at 100bps).  Then, there's still a whole wave of additional work that could be investigated, including...

  • Smarter streaming compression (so that if a user says 'Hello?' three times in a row, the 2nd and 3rd messages are just references to the first pattern)
  • Hoisting Matrix transaction IDs up to the CoAP layer (reusing the CoAP msgId+token rather than passing around new Matrix transaction IDs, at the expense of requiring one Matrix txn per request)
  • Switching to CoAP OBSERVE for receiving data from the server (currently we long-poll /sync to receive data)
  • Switching access_tokens for PSKs or similar
...all of which could shrink the payload down even further.  That said, even in its current state, it's a massive improvement - roughly ~65x better than the equivalent HTTPS+JSON traffic.

In practice, further work on low-bandwidth Matrix is dependent on finding a sponsor who's willing to fund the team to focus on this, as otherwise it's hard to justify spending time here in addition to all the less exotic business-as-usual Matrix work that we need to keep the core of Matrix evolving (finishing 1.0, finishing E2E encryption, speeding up Synapse, finishing Dendrite, rewriting Riot/Android etc).  However, the benefits here should be pretty obvious: massively reduced bandwidth and battery-life; resilience to catastrophic network conditions; faster sync times; and even a protocol suitable for push notifications (Matrix as e2e encrypted, decentralised, push!).  If you're interested in supporting this work, please contact support at

NextPage 2