TL;DR: we shipped a major update (v0.1.1) to https://p2p.riot.im - fire up a desktop Chrome or Firefox in not-private-browsing mode and give it a go!

Hi folks,

As many know by now, a few of us have been working away since mid-December on experimenting with running Matrix in a peer-to-peer architecture - one where every user has absolute total autonomy and ownership of their conversations, because the only place their conversations exist is on the devices they own.

In some ways this is the logical end goal of Matrix: our aim has always been to empower users to have full control over their communication rather than being beholden to any given service provider, and in a P2P world we completely return power over secure communication to the people.

🔗Why P2P?

P2P Matrix is about more than just letting users store their own conversations: it can also avoid dependencies on the Internet itself by working over local networks, mesh networks, or situations where the Internet has been cut off. Even more interestingly, without homeservers, there is nowhere for metadata to accumulate about who is talking to who, and when - which is a legitimate complaint about today’s Matrix network, given the homeservers of all users in a given conversation necessarily have to store that conversation’s metadata. P2P also lets us radically simplify signup for new users if they don’t have to pick a server to get going - and we avoid the unintentional centralisation of users piling onto public servers.

P2P also forces us to solve many of the hardest remaining problems in Matrix: e.g multi-homed accounts, given multi-device P2P requires your account to exist in multiple places. This in turn unlocks high availability and geo-redundancy for accounts on today’s Matrix network (imagine having a primary and backup homeserver that magically did the right thing!), as well as account portability, and thus also vhosting and load-balancing accounts between servers, and even improved GDPR compliance (for if your user IDs are ephemeral they are no longer personally identifying information baked into your Matrix rooms). We’ll also need better safety mechanisms to avoid folks exploiting the anonymous nature of the network for abuse, accelerating the work we’re already doing for today’s Matrix network.

The way we’ve been approaching P2P is the “hamfisted but genius” approach of taking homeservers and running them on the client, alongside or within your Matrix client - meaning that there are literally no changes required for any Matrix client to talk P2P Matrix, and so P2P Matrix can instantly benefit from all the work which has gone into Riot and other apps. As a result, P2P is also a huge motivator towards developing much smaller homeservers which can run efficiently clientside (e.g. Dendrite!) - which is of course great news for Matrix as a whole. It also forces us to develop more scalable routing algorithms (as you don’t want your client to have to talk to every other device in a room every time it sends a message!) and also spurs development of low bandwidth Matrix transports (as you don’t want the additional chatter of talking to multiple peers to consume all your bandwidth). Finally, it forces us to really ruggedize federation, given nodes are constantly appearing and disappearing, giving the federation much more of a stress test than we see with today’s relatively static homeservers.

🔗P2P in Practice

So, P2P has been acting as fuel for a lot of our longer term Matrix work over the last few months. There have been three main experiments so far: at FOSDEM we showed off running our next-gen Dendrite homeserver running clientside using HTTP over libp2p as the transport. We also highlighted Timothée Floure’s project at EPFL experimenting with Synapse talking P2P CoAP over yggdrasil as the transport via a proxy.

Most recently, however, we’ve been experimenting with compiling Dendrite down to Web Assembly and running it embedded in Riot Web as a Service Worker, using HTTP over libp2p’s websocket transport (coordinated via a websocket rendezvous server). Architecturally, it looks like this:

Today, we’re shipping a major new alpha (v0.1.1) of this P2P demo up at https://p2p.riot.im (requires desktop Chrome or Firefox in non-private-browsing mode) - which hopefully should give a really usable and concrete taste of the shape of things to come.

The main features are:

• Your conversations are now persisted in your browser storage (via IndexedDB), meaning that as long as all the browsers participating in a given conversation don’t clear their local storage, rooms on the P2P network are here to stay!
• Your room directory lists all the aliases for all the rooms published by active nodes on the network. Moreover, we now automatically publish a local room alias whenever you join a public room, so that others will be able to discover that room via you, even if the server who originally created the alias has disappeared.
• Lots and lots of federation improvements between the nodes - for instance, when a node comes online, others should now automatically detect and send scrollback to it. Invites should work, and there should no longer be any unexpectedly redacted messages.

Needless to say, all the code for this is open source under the Apache license, and if you’re feeling particularly adventurous you can embed your very own P2P Dendrite into Riot Web by using the Dockerfile at https://github.com/matrix-org/dendrite/blob/master/build/docker/DendriteJS.Dockerfile or following the instructions at https://github.com/matrix-org/dendrite/blob/master/docs/p2p.md.

Please report bugs to https://github.com/matrix-org/dendrite/issues!

Finally, please understand that the demo is very likely not what the final version of P2P Matrix will look like - this is just one step in a series of experiments as we investigate the best paths forward :)

🔗What’s next?

For the current demo, there’s still lots of stuff remaining, including:

• More federation debugging (and hooking in tardis and writing up everything we’ve learned about implementing federation in Dendrite!)
• Making the content repository work in-browser (gotta fill up those IndexedDBs with some GIFs!)
• Hooking up E2E Encryption APIs in Dendrite (not that it buys us much in a pure P2P world)
• WebRTC transports. Turns out that service workers aren’t allowed to speak WebRTC, so we’ll have to shim through to Riot to speak true peer-to-peer WebRTC data channels rather than relaying all the traffic through the websocket rendezvous server.
• Decentralised accounts for multidevice support - reviewing MSC1228 and getting Dendrite supporting multihoming accounts!
• Finishing all of Dendrite’s other remaining APIs.

Beyond this, there are some bigger picture questions left to be answered in future experiments.

Firstly: we do not yet have a solution for “store and forward” nodes which can relay messages on behalf of a room if all the participating devices are offline. A first cut will be to run a P2P-capable homeserver server-side for this, but then metadata will start to accumulate server-side for the conversations it hosts. A more interesting approach would be to use a store and forward system which obfuscates who is talking to who, such as a mixnet, and could even provide resistance to network traffic pattern analysis. This is very much an open area of research, but one we are getting into :D

Secondly: we want to experiment more with other transports, and find out which works best for Matrix. Libp2p has some really exciting new stuff in the form of Gossipsub v1.1 - a much smarter routing algorithm for pubsub traffic in libp2p, which David Dias gave us a VIP tour of at the first Open Tech Will Save Us meetup. So we’ll need to restructure our libp2p transport as pubsub to see how it works in practice. Separately, we also want to play with hooking up Yggdrasil (the encrypted overlay network) as a transport as a totally different approach - Yggdrasil will easily let us span different underlying network transports, but comes with different tradeoffs (e.g. no browser support yet). We also want to take a look at the DAT / hypercore / hyperswarm / Cabal ecosystem to see if there’s a match :)

Thirdly and finally: we obviously want to unify the new P2P Matrix network with today’s federated one. The ideal outcome here would be to have a hybrid model, where teams who want their users to have a dedicated homeserver (for availability, IT policies, etc) can continue to have one as they do today - but newbies who have just installed Riot would float around on P2P unless they decided to consciously put down roots on a server or two. Best of all, it would let us turn off the matrix.org homeserver: the best public homeserver is one you run yourself on your own phone ;) The approach we take for linking P2P and today’s Matrix will depend very much on the transport we select for P2P in the long run, but the likelihood is that today’s homeservers will sprout P2P gateways to link the networks.

🔗Conclusion

So, there you have it. P2P Matrix exists, and is developing at an alarming speed - and pushing Dendrite development along with it. Most excitingly, there have been no changes yet to the Matrix spec for P2P at all; we’ve just swapped https for http-over-libp2p as the transport. So all of the work we’ve been doing making Dendrite work in a P2P world has directly translated into making Dendrite work on today’s Matrix too You can now stand up a Dendrite and have it federate pretty reliably with the wider Matrix network, although we’re still rushing through implementing APIs (we’re up to 35% passing sytest coverage - although that 35% does contain most of the important tests :)

Finally, in case you’re worried about why the Matrix core team is off chasing P2P dreams rather than improving Riot’s UX, or implementing Communities, or Extensible Profiles, or working through the MSC backlog etc... in practice only two people (ignoring Matthew) have been working on P2P - Neil Alexander (author of the original FOSDEM demo, Dendrite wrangler and Yggdrasil co-maintainer) and Kegan Dougal (of the original Matrix dev team, one of the original authors of Dendrite, and now wrangling the WASM P2P work too). Huge thanks to Kegan & Neil for pushing P2P forwards - and huge thanks to everyone else on the core team and the wider community for keeping today’s Matrix advancing too!

Hope this has given a tempting glimpse of the shape of things to come. Honestly we never thought we’d get as far as P2P when we started Matrix back in 2014, but it’s really fun to be finally catching up with the future :D

-- Matthew

P.S. You can read more about this from Neil Alexander’s point of view over at his blog (including more thoughts on the potential Yggdrasil demo!)

P.P.S You can read the gory details of the P2P and WASM implementation from Kegan's point of view over at the Dendrite wiki.

P.P.P.S Comments over at HN

Hi all,

We’re very excited indeed to announce that Automattic, the creators of WordPress.com, are jumping head first into the Matrix ecosystem with a strategic investment of almost $5M into New Vector (the company which makes Riot and Modular.im, founded by the core Matrix team in 2017). More importantly, Matt Mullenweg (co-founder of WordPress and founder of Automattic) and the Automattic gang are committing to make the most of Matrix in their work going forwards!

This is huge news, not least because WordPress literally runs over 36% of the websites on today’s web - and the potential of bringing Matrix to all those users is incredible. Imagine if every WP site automatically came with its own Matrix room or community? Imagine if all content in WP automatically was published into Matrix as well as the Web? (This isn’t so far fetched an idea - turns out that Automattic already runs a XMPP bridge for wordpress.com over at im.wordpress.com!). Imagine there was an excellent Matrix client available as a WordPress plugin for embedding realtime chat into your site? Imagine if Tumblr (which is part of Automattic these days) became decentralised!?

In fact, if you’re a developer in either the Matrix or WordPress communities, now might be a good time to think about how to cross the streams.... not least because Automattic just opened up a role for a Matrix.org/WordPress Integrations Engineer! Quite aside from the investment, this shows Automattic is serious about Matrix - and we’d like to thank them for opening up jobs in these challenging times to further accelerate Matrix. Perhaps some day Matrix Engineer will be as common a career choice as Web Developer ;)

That said, it’s super early days for integration work, and there isn’t a concrete project to announce yet beyond the investment in New Vector (which is effectively an extension of the funding NV raised in October) and Automattic’s Job opening - but these are the sort of ideas we’ve been kicking around. And at the very least, we should expect to see Automattic’s communities migrating over to Matrix in the coming months.

It’s been loads of fun working with Matt and the team on this: we see a huge overlap in terms of a genuine love for the open web, open source and open standards. It’s also no coincidence that Matt (independently of Automattic) donated substantially to Matrix via Patreon back in 2017 when we needed it the most. We’re also looking forward to benefiting from Automattic’s experience in sustainably and responsibly funding and growing open source projects in general - WordPress.com is an excellent example of how one can support development of a project like WordPress without compromising its open source nature.

So, we’d like to formally welcome WordPress and the rest of the Automattic family into Matrix. It’s incredibly exciting times, and we can’t wait to see what will come of the partnership! And meanwhile, if any other massive open source organisations want to join Automattic and Mozilla in leaping into Matrix, you know where to find us… :D

Huge thanks go to Matt for believing in Matrix - watch this space for updates.

• Matthew, Amandine & the Matrix Team.

Hi all,

As of today, Matrix is end-to-end encrypted by default for private conversations.

Three years have passed since we first announced End-to-end Encryption in Matrix and started to beta test it in Riot - and after an enormous amount of polishing and refinement on its user experience, we are finally declaring it out of beta and enabling it by default for all new private conversations in Riot. As Riot is currently the most common Matrix client, this means that Matrix as a whole should now be considered end-to-end encrypted by default for DMs and invite-only rooms.

Work on E2EE in Matrix has progressed in waves since we first shipped it - including:

• adding keysharing (letting you share encryption keys between your devices to improve reliability)
• making Riot Web's encryption resilient to running concurrently in multiple tabs
• adding online key backup (so you don't lose all your history if you lose all your devices)
• making encryption resilient to restoring the app from a backup
• adding interactive key verification via emoji to make the verification process easier.

However, our goal was always to enable E2EE by default for all private rooms, which means having feature parity between unencrypted and E2EE Matrix so that we can enable encryption without any negative impact on usability. The high-level remaining items were significant:

• Cross-signing: verifying your own logins so others don’t have to.
• Adding QR codes for even better verification UX, to make cross-signing as painless as possible.
• Replacing the old prototype UI for E2EE with final polished UI/UX.
• Ability to support non-E2EE clients.
• Ability to search encrypted rooms.
• Ability to view file indexes in encrypted rooms.
• Fixing the remaining “Unable to decrypt” errors.

Over the last few months the Riot team has been almost entirely focused on implementing solutions to these items - and we're finally at the point where the switch can be flipped and as of Riot Web/Desktop 1.6, Riot iOS 0.11.1 and RiotX Android 0.19, all new private rooms will be encrypted by default; completing the transition we began at FOSDEM 2020 when we landed cross-signing E2E-by-default in the development branches of Riot.

For full details, please go check out the massive deep dive over at the Riot blog - also featuring all the other recent progress in Riot!

Heads up that encrypted traffic is slightly heavier on the server than unencrypted (due to exchanging keys, verification traffic, and keybackup traffic), and so there is a risk that the already-over-popular Matrix.org server instance may feel a little hugged to death. However, unprecedented Synapse performance breakthroughs are on the horizon in the coming weeks which will fix this - and, of course, you can (and should!) be using your own instance anyway.

Thanks everyone for helping us test encryption over the years and getting us to this point: cross-signing provides a more secure way of tracking device trust than almost any other comms system out there, and we hope that you'll agree the improved UX has been worth the wait.

Next stop: Synapse performance, and rebuilding Riot's first time user experience!

thanks,

Matthew, Amandine & the Matrix Team.

(Comments over at HN)

On April 14th, the Spec Core Team conducted a long-overdue retrospective about the things that were working in the Matrix Spec Proposal process, and those that were not.

The most glaring item on the list was the sluggish pace that many Matrix Spec Changes (MSCs) take throughout the proposal process, as well as the general lack of activity from the Spec Core Team members on proposals that have not yet started a Final Comment Period.

We deeply apologize for the frustration this has likely caused many MSC authors, and want to shed some light on the reasoning behind it, and what we plan to do to prevent leaving authors in the dark about why there may be no Spec Core Team activity on their proposal.

🔗Proposal Triaging

There are currently 136 open MSCs that have yet to undergo Final Comment Period (FCP), 75 of which are marked as proposal-in-review, and 20 that have a FCP proposed. Relative to the 65 MSCs that have ever been closed, this is a lot of outstanding ideas, features and maintenance changes.

The Spec Core Team itself is made up of 8 members, each of which have separate full-time jobs. All team members are well-placed to be on the team given their wide breadth of knowledge across the Matrix ecosystem, however the majority are some of the most busy pushing forward Matrix's reference implementations - without which, Matrix will unquestionably fail. This limits the amount of MSCs that the team can effectively work on at a given time.

The team understands that there are MSCs that provide incredibly useful features, such as support for LaTeX in messages or the ability to "knock" on rooms, and would undoubtedly like to see them land at some point.

But there is also a large backlog of MSCs that provide even more fundamental fixes and additions to the protocol that the team needs to prioritise. These include things like cross-signing devices, the communities rewrite and finally merging reactions and edits into the spec.

While we announce what MSCs we're focusing on during a given week during TWIM, it's not as clear which items we're looking to pull from the backlog next. To help tackle this, and to help keep us honest, we've begun putting each MSC into either "feature", "maintenance", or "core" buckets. This materialises in the form of github tags, which can be used to filter the list of MSCs like so: feature, maintenance, core. For a given timespan, we’ll pick a track and pull MSCs out of that category when possible. More information about MSC categories are now detailed on the proposals page.

As for the next 6 to 12 months, we plan to work on items from the “core” category. We need to get Matrix to a point where it can compete with other, proprietary chat protocols and items in "core" are decidedly the proposals that will take us the furthest in that direction. This doesn't mean we won't occasionally look at an MSC in a different category, but it will heavily influence our prioritisation.

🔗Future

We'll try this approach out over the next few months and see how it goes. The next Spec Core Team retro will occur in the middle of May, where we will review the process once again.

For now, if you have any feedback please come and chat with us in #matrix-spec:matrix.org :)

Hi all,

Over the last few weeks there's been huge increase in interest from folks wanting the security and autonomy of running their remote collaboration services, rather than being at the mercy of traditional proprietary centralised apps. Meanwhile, the Matrix.org homeserver has been very overloaded (although we're at last making excellent progress in radically improving Synapse's performance) - so it's particularly important right now to help folks run their own servers.

Therefore we're very happy to announce that it's easier than ever before now to self-host your own video conferencing alongside Riot & Synapse: as of Riot/Web 1.5.15 (released last week), it's now a single config option to point Riot at a specific Jitsi rather than needing to hook up to an integration manager!

Meanwhile, over the last 18 months, it's got easier and easier to run your own Matrix deployments: the Debian packages are unrecognisably better now, and with .well-known URL support it's trivial to set up federation without needing to worry about complicated DNS, TLS or load balancer configurations.

So, to try to show off just how smooth this has become, we thought we'd do a run-through video showing installing Synapse, Riot & Jitsi on a completely fresh Debian install. It's (almost) filmed in a single shot, and takes about 20 minutes from beginning to end.

Please note that this does assume you're pretty familiar with Linux system administration. If you're not, then we'd recommend using a Matrix hosting provider such as Modular.im (which directly supports development of the core team), Ungleich.ch, or StartupStack.

Finally, while the video shows how to install on Debian via Debian packages, there are many many other environments and architectures (e.g. installing under Docker) - this is just one relatively easy way to skin the cat. Perhaps there will be other 'speed-run' videos in future :)

If you want to follow along at home without listening to the video (and I can't blame you if you do ;) the high level steps are as follows:

🔗Debian & DNS

• Take one fresh Debian 10 install.
• Point the DNS for your domain to it. You should use separate subdomains for the various services as a hygiene measure to make cross-site scripting attacks less effective. In this example, we set up DNS for:
  • dangerousdemos.net (general website, and for hosting a .well-known path to advertise the Matrix service)
  • matrix.dangerousdemos.net (Synapse)
  • riot.dangerousdemos.net (Riot/Web)
  • jitsi.dangerousdemos.net (Jitsi video conferencing)
  • In practice, we used a *.dangerousdemos.net wildcard DNS record for the three subdomains in this instance.

🔗Nginx and LetsEncrypt

• Install nginx as a webserver: apt-get update && apt -y install nginx
• Go to /etc/nginx/sites-enabled and copy the vhost configuration block from the bottom of default to new files called dangerousdemos.net, matrix.dangerousdemos.net, and riot.dangerousdemos.net. We don't set up jitsi.dangerousdemos.net at this point as the jitsi installer handles it for us.
  • Rename the server_name field in the new files to match the hostname of each host, and point root to an appropriate location per domain (e.g. /var/www/dangerousdemos.net for the main domain, or /var/www/riot.dangerousdemos.net/riot for riot)
  • For the Synapse domain (matrix.dangerousdemos.net here), you should replace the contents of the location block with proxy_pass http://localhost:8008; - telling nginx to pass the traffic through to synapse, which listens by default for plaintext HTTP traffic on port 8008. (N.B. do not put a trailing slash on the URL here, otherwise nginx will mangle the forwarded URLs.)
• Enable TLS via LetsEncrypt on nginx, by: apt install -y python3-certbot-nginx && certbot --nginx -d dangerousdemos.net -d riot.dangerousdemos.net -d matrix.dangerousdemos.net (or whatever your domains are).
• You should be able to go to https://dangerousdemos.net at this point and see a page with valid HTTPS.

🔗Synapse

• Then, install Synapse via Debian packages using the instructions at https://github.com/matrix-org/synapse/blob/master/INSTALL.md#debianubuntu (see below). If you're not on Debian, keep an eye out for all the other OSes we support too!
  • You should specify the server name to be the domain you want in your matrix IDs - i.e. dangerousdemos.net in this example.
  • Please report anonymous aggregate stats to us so we can gauge uptake and help justify funding for Matrix!

sudo apt install -y lsb-release wget apt-transport-https
sudo wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" |
    sudo tee /etc/apt/sources.list.d/matrix-org.list
sudo apt update
sudo apt install matrix-synapse-py3

• You should now be able to go to https://matrix.dangerousdemos.net and see a valid "It works! Synapse is running" page.

• Then, you should enable registration on your synapse by switching enable_registration: true in /etc/matrix-synapse/homeserver.yaml and restarting synapse via systemctl restart matrix-synapse.

• Now you need to tell the rest of Matrix how to find your server. The easiest way to do this is to publish a file at https://dangerousdemos.net/.well-known/matrix/server which tells everyone the hostname and port where they can find the synapse for dangerousdemos.net - in this instance, it's matrix.dangerousdemos.net:443:

mkdir -p /var/www/dangerousdemos.net/.well-known/matrix
cd /var/www/dangerousdemos.net/.well-known/matrix
echo '{ "m.server": "matrix.dangerousdemos.net:443" }' > server

• Alternatively, you could advertise the server via DNS, if you don't have write access to /.well-known on your main domain. However, to prove you are allowed to host the Matrix traffic for dangerousdemos.net, you would have to configure nginx to use the dangerousdemos.net TLS certificate for the matrix.dangerousdemos.net vhost (i.e. the "wrong" one), and in general we think that /.well-known is much easier to reason about. In this case you would advertise the server with an SRV record like this:

_matrix._tcp.dangerousdemos.net. 300    IN  SRV 10 5 443 matrix.dangerousdemos.net.

🔗Riot/Web

• Then, install Riot/Web. Grab the latest .tgz release from https://github.com/vector-im/riot-web/releases. You should check its GnuPG signature too:

mkdir /var/www/riot.dangerousdemos.net
cd /var/www/riot.dangerousdemos.net
wget https://github.com/vector-im/riot-web/releases/download/v1.5.15/riot-v1.5.15.tar.gz

# check its GnuPG signature (particularly advisable, given Riot is what stores
# your end-to-end encryption keys)
apt install -y gnupg
wget https://github.com/vector-im/riot-web/releases/download/v1.5.15/riot-v1.5.15.tar.gz.asc

# grab the signing key for the riot releases repository, ideally from a keyserver...
gpg --keyserver keyserver.ubuntu.com --search-keys [email protected]

# ...and/or you can grab or cross-check the signing key from packages.riot.im
wget https://packages.riot.im/riot-release-key.asc
gpg --import riot-release-key.asc

gpg --verify riot-v1.5.15.tar.gz.asc
# hopefully this will report "Good signature", even though it won't know to trust the riot release key.

# you could also choose to explicitly trust the key by editing it, entering 'trust' and then '5' for ultimate trust.
gpg --edit-key 74692659bda3d940

tar -xzvf riot-v1.5.15.tar.gz
ln -s riot-v1.5.15 riot
chown www-data:www-data -R riot
cd riot
cp config.sample.json config.json

• You then tweak the config.json to change the base_url of the homeserver to be https://matrix.dangerousdemos.net (i.e. where to find the Client Server API for your server), and change the server_name to be dangerousdemos.net (i.e. the name of your server).
• You should then be able to go to https://riot.dangerousdemos.net, register for an account, sign in, and talk to the rest of Matrix!

🔗Jitsi

• Finally, we install Jitsi so you can run your own video conferencing. We take the instructions from Jitsi's quick install guide:

echo 'deb https://download.jitsi.org stable/' >> /etc/apt/sources.list.d/jitsi-stable.list
wget -qO -  https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add -
apt-get update
apt-get -y install jitsi-meet

• We give the installer the hostname jitsi.dangerousdemos.net. Make sure this DNS is already set up, otherwise the installer will fail!

• The installer magically detects you have nginx installed and adds in an appropriate vhost!

• We select a self-signed certificate for now, and then upgrade it to LetsEncrypt after the fact with /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh.

  • Alternatively, you could have specified manual certificates, and then used certbot alongside the rest of nginx to create a certificate for jitsi.dangerousdemos.net - both work.

• You should now be able to go to https://jitsi.dangerousdemos.net and use the Jitsi directly.

• Finally, and this is the cool new bit: you can now point Riot to use the new Jitsi by going to its config.json at /var/www/riot.dangerousdemos.net/riot/config.json and changing the preferredDomain of the jitsi block from https://jitsi.riot.im to your own self-hosted https://jitsi.dangerousdemos.net.

• You then refresh your Riot/Web, and you should be all set to use Jitsi from within your new Riot - as Riot/Web 1.5.15 and later has the ability to natively embed Jitsi straight into the app without needing to use an integration manager.

🔗Conclusion

Matrix nowadays provides an excellent alternative to the centralised solutions. It gives:

• Full autonomy over how to host and store your own conversations
• Full freedom to talk to anyone else on the wider global Matrix network (or indeed anyone else bridged into Matrix)
• Full privacy via full end-to-end-encryption for chats, file transfer and 1:1 voice/video calls (when enabled)
• Full transparency by being 100% open source (as well as benefiting from the overall open source community)

Hopefully this gives some confidence that it's pretty easy to run your own fully functional Matrix instance these days. If not, then hopefully someone will do a similar one to show off Docker! And if that's still too scary, please take a look at a hosting services like Modular.im.

(Comments over at HN and here too)

Hi all,

Synapse 1.11 landed on Friday (sorry for running late on blogging the release notes!)

The main change is to introduce an experimental API MSC2432 for managing aliases for rooms on your local server. In Synapse 1.10 we removed support for m.room.aliases events, which were a way to try to track which aliases a room had on the room itself (but were vulnerable to abuse). In this release we've re-added the ability to query which aliases a given server has for the room, giving visibility for managing aliases, without having them spray all over the room state itself. Riot/Web 1.5.10 supports the new API, giving a way to manage aliases on your local server while we finish off the remaining work to improve alias safety & maintenance.

We've also changed the default power levels for new rooms so that room upgrades and ACLs require you to be an Admin (PL100), and invites in public rooms now require you to be a moderator (PL50).

Get the new release from github or any of the sources mentioned at https://github.com/matrix-org/synapse/blob/master/INSTALL.md.

🔗Synapse 1.11.0 (2020-02-21)

🔗Improved Documentation

• Small grammatical fixes to the ACME v1 deprecation notice. (#6944)

🔗Synapse 1.11.0rc1 (2020-02-19)

🔗Features

• Admin API to add or modify threepids of user accounts. (#6769)
• Limit the number of events that can be requested by the backfill federation API to 100. (#6864)
• Add ability to run some group APIs on workers. (#6866)
• Reject device display names over 100 characters in length to prevent abuse. (#6882)
• Add ability to route federation user device queries to workers. (#6873)
• The result of a user directory search can now be filtered via the spam checker. (#6888)
• Implement new GET /_matrix/client/unstable/org.matrix.msc2432/rooms/{roomId}/aliases endpoint as per MSC2432. (#6939, #6948, #6949)
• Stop sending m.room.aliases events when adding / removing aliases. Check alt_aliases in the latest m.room.canonical_alias event when deleting an alias. (#6904)
• Change the default power levels of invites, tombstones and server ACLs for new rooms. (#6834)

🔗Bugfixes

• Fixed third party event rules function on_create_room's return value being ignored. (#6781)
• Allow URL-encoded User IDs on /_synapse/admin/v2/users/<user_id>[/admin] endpoints. Thanks to @NHAS for reporting. (#6825)
• Fix Synapse refusing to start if federation_certificate_verification_whitelist option is blank. (#6849)
• Fix errors from logging in the purge jobs related to the message retention policies support. (#6945)
• Return a 404 instead of 200 for querying information of a non-existent user through the admin API. (#6901)

🔗Updates to the Docker image

• The deprecated "generate-config-on-the-fly" mode is no longer supported. (#6918)

🔗Improved Documentation

• Add details of PR merge strategy to contributing docs. (#6846)
• Spell out that the last event sent to a room won't be deleted by a purge. (#6891)
• Update Synapse's documentation to warn about the deprecation of ACME v1. (#6905, #6907, #6909)
• Add documentation for the spam checker. (#6906)
• Fix worker docs to point /publicised_groups API correctly. (#6938)
• Clean up and update docs on setting up federation. (#6940)
• Add a warning about indentation to generated configuration files. (#6920)
• Databases created using the compose file in contrib/docker will now always have correct encoding and locale settings. Contributed by Fridtjof Mund. (#6921)
• Update pip install directions in readme to avoid error when using zsh. (#6855)

🔗Deprecations and Removals

• Remove m.lazy_load_members from unstable_features since lazy loading is in the stable Client-Server API version r0.5.0. (#6877)

🔗Internal Changes

• Add type hints to SyncHandler. (#6821)
• Refactoring work in preparation for changing the event redaction algorithm. (#6823, #6827, #6854, #6856, #6857, #6858)
• Fix stacktraces when using ObservableDeferred and async/await. (#6836)
• Port much of synapse.handlers.federation to async/await. (#6837, #6840)
• Populate rooms.room_version database column at startup, rather than in a background update. (#6847)
• Reduce amount we log at INFO level. (#6833, #6862)
• Remove unused get_room_stats_state method. (#6869)
• Add typing to synapse.federation.sender and port to async/await. (#6871)
• Refactor _EventInternalMetadata object to improve type safety. (#6872)
• Add an additional entry to the SyTest blacklist for worker mode. (#6883)
• Fix the use of sed in the linting scripts when using BSD sed. (#6887)
• Add type hints to the spam checker module. (#6915)
• Convert the directory handler tests to use HomeserverTestCase. (#6919)
• Increase DB/CPU perf of _is_server_still_joined check. (#6936)
• Tiny optimisation for incoming HTTP request dispatch. (#6950)

The whole Matrix project is racing towards enabling e2ee by default. Synapse is no different and v1.10.0 contains multiple e2ee UX improvements, as well as a bug fix that prevented cross signing requests over federation to work reliably.

If any of your users are on the bleeding edge and have already started using cross signing (by enabling labs flags in Riot), then it will be necessary for them to force Synapse to re-send device updates by renaming all of their devices.

We've also included a temporary fix to address alias abuse. The idea is that until #6898 lands, servers will refrain from sharing events of type m.room.aliases with clients. Most admins will not be affected, but if you are present in rooms subject to alias abuse, then upgrading provides a pragmatic short term solution.

Finally, as of this release Synapse validates client_secret parameters in the Client-Server API as per the spec. See #6766 for details.

Get the new release from github or any of the sources mentioned at https://github.com/matrix-org/synapse/blob/master/INSTALL.md.

Changelog since Synapse 1.9.0

🔗Synapse 1.10.0 (2020-02-12)

WARNING to client developers: As of this release Synapse validates client_secret parameters in the Client-Server API as per the spec. See #6766 for details.

🔗Updates to the Docker image

• Update the docker images to Alpine Linux 3.11. (#6897)

🔗Synapse 1.10.0rc5 (2020-02-11)

🔗Bugfixes

• Fix the filtering introduced in 1.10.0rc3 to also apply to the state blocks returned by /sync. (#6884)

🔗Synapse 1.10.0rc4 (2020-02-11)

This release candidate was built incorrectly and is superseded by 1.10.0rc5.

🔗Synapse 1.10.0rc3 (2020-02-10)

🔗Features

• Filter out m.room.aliases from the CS API to mitigate abuse while a better solution is specced. (#6878)

🔗Internal Changes

• Fix continuous integration failures with old versions of pip, which were introduced by a release of the zipp library. (#6880)

🔗Synapse 1.10.0rc2 (2020-02-06)

🔗Bugfixes

• Fix an issue with cross-signing where device signatures were not sent to remote servers. (#6844)
• Fix to the unknown remote device detection which was introduced in 1.10.rc1. (#6848)

🔗Internal Changes

• Detect unexpected sender keys on remote encrypted events and resync device lists. (#6850)

🔗Synapse 1.10.0rc1 (2020-01-31)

🔗Features

• Add experimental support for updated authorization rules for aliases events, from MSC2260. (#6787, #6790, #6794)

🔗Bugfixes

• Warn if postgres database has a non-C locale, as that can cause issues when upgrading locales (e.g. due to upgrading OS). (#6734)
• Minor fixes to PUT /_synapse/admin/v2/users admin api. (#6761)
• Validate client_secret parameter using the regex provided by the Client-Server API, temporarily allowing : characters for older clients. The : character will be removed in a future release. (#6767)
• Fix persisting redaction events that have been redacted (or otherwise don't have a redacts key). (#6771)
• Fix outbound federation request metrics. (#6795)
• Fix bug where querying a remote user's device keys that weren't cached resulted in only returning a single device. (#6796)
• Fix race in federation sender worker that delayed sending of device updates. (#6799, #6800)
• Fix bug where Synapse didn't invalidate cache of remote users' devices when Synapse left a room. (#6801)
• Fix waking up other workers when remote server is detected to have come back online. (#6811)

🔗Improved Documentation

• Clarify documentation related to user_dir and federation_reader workers. (#6775)

🔗Internal Changes

• Record room versions in the rooms table. (#6729, #6788, #6810)
• Propagate cache invalidates from workers to other workers. (#6748)
• Remove some unnecessary admin handler abstraction methods. (#6751)
• Add some debugging for media storage providers. (#6757)
• Detect unknown remote devices and mark cache as stale. (#6776, #6819)
• Attempt to resync remote users' devices when detected as stale. (#6786)
• Delete current state from the database when server leaves a room. (#6792)
• When a client asks for a remote user's device keys check if the local cache for that user has been marked as potentially stale. (#6797)
• Add background update to clean out left rooms from current state. (#6802, #6816)
• Refactoring work in preparation for changing the event redaction algorithm. (#6803, #6805, #6806, #6807, #6820)

Hi all,

Every year we do an annual wrap-up and retrospective of all the things happening in the Matrix core team - if you’re feeling particularly curious or bored you can check out the 2015, 2016, 2017 and 2018 editions for context. The idea is to look at the bigger picture trends in Matrix outside of the weekly TWIM posts to get an idea of the stuff which we made progress on, and the stuff which still remains.

That said, it’s hard to know where to start - Matrix accelerated more than ever before in 2019, and there’s been progress on pretty much all battlefronts. So as a different format, let’s take the stuff we said we had planned for 2019 from the end of last year’s update and see what we actually achieved...

Continue reading…

Hi all,

Over the course of today we've been made aware of folks port-scanning the general internet to discover private Matrix servers, looking for publicly visible room directories, and then trying to join rooms listed in them.

If you are running a Matrix server that is intended to be private, you must correctly configure your server to not expose its public room list to the general public - and also ensure that any sensitive rooms are invite-only (especially if the server is federated with the public Matrix network).

In Synapse, this means ensuring that the following options are set correctly in your homeserver.yaml:

# If set to 'false', requires authentication to access the server's public rooms
# directory through the client API. Defaults to 'true'.
#
#allow_public_rooms_without_auth: false

# If set to 'false', forbids any other homeserver to fetch the server's public
# rooms directory via federation. Defaults to 'true'.
#
#allow_public_rooms_over_federation: false

For private servers, you will almost certainly want to explicitly set these to false, meaning that the server's "public" room directory is hidden from the general internet and wider Matrix network.

You can test whether your room directory is visible to arbitrary Matrix clients on the general internet by viewing a URL like https://sandbox.modular.im/_matrix/client/r0/publicRooms (but for your server). If it gives a "Missing access token" error, you are okay.

You can test whether your room directory is visible to arbitrary Matrix servers on the general internet by loading Riot (or similar) on another server, and entering the target server's domain name into the room directory's server selection box. If you can't see any rooms, then are okay.

Relatedly, please ensure that any sensitive rooms are set to be "invite only" and room history is not world visible - particularly if your server is federated, or if it has public registration enabled. This stops random members of the public peeking into them (let alone joining them).

Relying on security-by-obscurity is a very bad idea: all it takes is for someone to scan the whole internet for Matrix servers, and then trying to join (say) #finance on each discovered domain (either by signing up on that server or by trying to join over federation) to cause problems.

Finally, if you don't want the general public reading your room directory, please also remember to turn off public registration on your homeserver. Otherwise even with the changes above, if randoms can sign up on your server to view & join rooms then all bets are off.

We'll be rethinking the security model of room directories in future (e.g. whether to default them to being only visible to registered users on the local server, or whether to replace per-server directories with per-community directories with finer grained access control, etc) - but until this is sorted, please heed this advice.

If you have concerns about randoms having managed to discover or join rooms which should have been private, please contact [email protected].

Hello Matrix enthusiasts! Yesterday we released matrix-appservice-slack 1.0. This marks a major milestone in bridge development for the Matrix.org team, being our first bridge to ever reach 1.0. The decision to release this version came after we decided that the bridge had gained enough features and reached a point of stability where it could be deployed in the wild with minimal risk.

For those not in the know, the Slack bridge is Node.JS based, and bridges slack channels & users into Matrix seamlessly. And for those wondering, yes it works with Mattermost too (since their API is compatible with Slack)! In previous versions only a limited subset of features were supported, making heavy usage of Slack’s webhook API. As of 1.0, the bridge now makes use of the newer Slack Events/RTM API which gives us all we need for a richer bridging experience. Everything from edits and reactions to typing notifications is supported in the 1.0 release.

Finally for those who are self hosting, we are pleased to offer the ability to "puppet" your Slack account using the bridge. Puppeting is the process in which the bridge will send messages as if you were sending them from the Slack client directly, when you talk using your Matrix account. This opens the door to seamless bridging and direct messaging support.

For those wishing to bridge their whole workspace across, picard exists as a tool to manage large scale Slack bridge deployments. This tool is provided by Cadair and SolarDrew

Threading & Reactions!

The bridge has undergone some pretty serious code surgery as well. The whole codebase has been rewritten in TypeScript to take advantage of type checking and generic types. The bridge is currently based upon the matrix-appservice-bridge library. The datastore interface now supports PostgreSQL, which allows for administrators to inspect and edit the database while the bridge is running, as well as offering helpful performance boost over the NeDB datastore format that was used previously. Finally, the codebase has proper Unit and Integration Tests to ensure new changes will not cause any regressions in behaviour. In short, now is an excellent time to get involved and hack on the bridge. There is already a crafted list of easy issues for new and experienced bridge devs.

Memory usage of the bridge comparison

CPU usage of the bridge comparison

In terms of how many users matrix.org is currently serving at the moment, we present to you some figures:

• 2562 bridged rooms
• 764 teams connected to the bridge
• 103711 events have passed through the bridge since the launch of 0.3.2

Of course, our work doesn’t stop at 1.0. The plan for the immediate future of the bridge is to continue adding support for other event types coming from Matrix and Slack to create an ever richer experience. Obvious features are things like topic changes, and syncing membership across the bridge. In the long term future we would also like to add community support to the bridge, so whole Slack workspaces can be bridged across with a single click.

That’s all from me, and I would like to say a massive thank you to Cadair and Ben for both their code and review work on the project and as always, thank you to the community for using the bridge and reporting issues. 🙂

Useful links:

• Matrix Room
• Project Home
• Docs