an open standard for interoperable, decentralised, real-time communication.
In this article weâll benefit from all three of these attributes:
interoperable: we'll see how Matrix can be made to interact with WhatsApp
decentralised: you can perform this on your own server while still enjoying the benefits of being connected to the rest of the Matrix federation
real-time communication: we'll see how to send and receive messages in real-time
Install your homeserver and install mautrix-whatsapp, the WhatsApp bridge
Firstly, you need to have a Matrix homeserver installed. If you donât currently have one, take a look at the instructions at Installing Synapse, and also in the Synapse README.
If you are starting from scratch, I suggest you take a look at matrix-docker-ansible-deploy, as this project will enable you to deploy Synapse, mautrix-whatsapp and other components easily.
For example, if you have an existing deployment using matrix-docker-ansible-deploy, you can add mautrix-whatsapp simply by adding the following line to your configuration file:
Either way, you will soon have a functioning Matrix Synapse homeserver and mautrix-whatsapp installed with it. Next, we will set up an Android VM.
Set up an Android VM
The best way to run an Android Virtual Machine is to use the Android Studio tools from Google. First, install Android Studio, making sure to follow the post-install steps, as they will install additional tools we need, including AVD Manager.
Once installed, run AVD manager by choosing Tools -> AVD Manager from the menu.
Follow the steps to create a new virtual machine, in this example I have a Nexus 5X running Android 9, but almost any configuration is fine here. Make sure that you give the device access to the Play Store.
Install WhatsApp and sign-in
Launch the Virtual Device, the open the Play Store and sign in. Now use the Play Store to install WhatsApp on the Virtual Device.
You will be asked to verify your phone number, use your number on another device to complete this step.
Setup mautrix-whatsapp bridge
Now that you have WhatsApp working in a VM, and Matrix working on your server, itâs time to bridge them together!
Per the instructions at mautrix-whatsapp/wiki, you must start a new chat with @whatsappbot:<yourdomain>. Type login to begin the authentication process.
mautrix-whatsapp operates by using the WhatsApp Web feature of WhatsApp - which means it uses a QR code that you must now scan on the device running WhatsApp - which in your case is the AVD. In order to scan the presented QR code, set your AVD camera to passthrough the camera device on your host machine - see the images below.
Once this is complete, you can type sync, to start bridging contacts, and sync âcreate to automatically create room invites.
And thatâs it! You may need to take a little time to watch the sync happen, particularly if you have a very large number of chats on the WhatsApp side, but there is no further configuration needed.
The remainder of 0.6.x is expected to be bug fixes. This includes bug fixes in mtxclient as well as nheko. 0.7.0 will be the next feature release. The end goal here is to add some of the capabilities that people have been requesting, and other things that people havenât been requesting. AFTER 0.7.0 releases, I will then focus on updating the encryption to include more than just text messages.
libQMatrixClient project, Quaternion
kitsune has been writing the codes this week, Quaternion now supports room upgrades and more:
Master branch of Quaternion can now store access token in your secure storage/keychain, better integrating into frameworks of GNOME and KDE, as well as macOS and Windows. Also, you can see the room version and upgrade rooms in Quaternion (just like Matthew said on FOSDEM ;) ) - this feature is enabled by libQMatrixClient, so other clients are welcome to support room versions/upgrades too!
All this is within the work on the upcoming release of libQMatrixClient 0.5 and Quaternion 0.0.9.4 - stay tuned!
Oh we will. Spectral support for these new features when?
Just tagged and pushed a new version (0.0.4) of the Ruby SDK, since Iâve completely forgotten to do that for a while now.
Whatâs new?
A whole bunch of small stuff I did, mostly just additional exposed methods and parameters, and some fixed issues as well. I did add support for HS URL discovery using both SRV and .well-known though, which I think is probably the largest new feature.
As if all this wasnât enough, a room on Matrix!
Created a discussion room for the Ruby SDK - since it seems like there are now people who have actually used it apart from me; #ruby-matrix-sdk:kittenface.studio
synapse-netcore-workers
A project rarely seen has received a lot of attention this week!
Iâve been working on a federation worker for synapse written in .NET to improve outgoing federation performance. Itâs still pretty barebones, but progress can be followed at https://github.com/turt2live/synapse-netcore-workers/pull/5
Iâm also working on my own netcore workers project by setting up an appservice sender. Itâs also very barebones (doesnât even send a transaction), but is being tracked here: https://github.com/turt2live/synapse-netcore-workers/pull/6 Also, if youâd like to follow along with the project from the comfort of Matrix, head on over to #synapse-netcore-workers:t2bot.io
Fix txnId generation that made sending messages unreliable. Work around a bug in OkHttp that crashed the dispatcher thread when the server certificate was not received in time.
Good thing to fix! Hereâs a screenshot of Continuum-desktop, the client from koma:
yuforia continues:
Fix text processing in the bot avecho, feel free to try it out in #koma-im:matrix.org
mxisdv1.3.1 is out. It is a maintenance release that fixes a set of regressions following the changes in v1.3.0 to massively improve performance. If you havenât updated to the v1.3 branch, now is the time!
Construct progresses toward Matrix 1.0 Spec
Over the past three weeks Construct has made rapid progress with covering the Matrix 1.0 specification! Last week we implemented room version 1 and room version 2 authentication rules. This week we implemented device support and management, and have nearly wrapped up successful End-To-End Encryption testing. The Construct is a community-driven server implementation written in C++ for maximum performance. To all experienced C++ developers out there: we need your contributions to accelerate and test the 1.0 release! Please check out https://github.com/matrix-construct/construct and stop by #test:zemos.net / #zemos-test:matrix.org today!
Make the c++ code less heavy, we should focus on speed
Offload js code to direct qml binding, with this i mean instead of having ablock if-else code that modifies qml object that runs on component load, we do this directly in qml: see 0a800fc and as an example for a cleaner code
Make all ui depended calls async, we should NEVER block ui
Offload heavy js logic to c++
Cleaner UI, with less crust
Async everything
Merge our WIP call support
Finish impl of call support (maybe move to a standalone webrtc module)
Slowly start moving to QQC2
Implement reply
Implement sending of media
Riot Android
Finalising version and delivery of Riot 0.8.23 on the Play Store.
RiotX: testing library to render events in the timeline.
matrix-archive-keyring (from last weekâs TWIM) is ready to be uploaded to Debian. Attempting to get it uploaded to unstable right now as I speak.
Riot breadcrumbs
We linked to the announcement last week, and have been using it for even longer, but somehow I missed a great labs feature that shipped with Riot 1.0: âroom breadcrumbsâ, which you can enable from the Labs page of Riot settings. This gives you a series of quick links with the history of rooms you were most recently in. So if youâre like me, clicking between rooms all day, you can get where youâre going a little faster.
mautrix-whatsapp
There is no big news about mautrix-whatsapp this week, other than that I installed it on my own server and found that it works really really well. Iâd love to switch to this as a main interface for my less-decentralised friends, but like others, Iâve been stung by this issue in an upstream project. If there are go-fans reading (and I know there are), I wonder if itâs an issue which can be fixed?
Around the Web
A tidy little article on ânon-centralisedâ applications. Article by Jontheniceguy helps pin down some of the terminology around decentralisation and the like. https://jon.sprig.gs/blog/post/1041
All good things must come to an end - and here we are!
Matrix is getting a lot of attention recently (has it been on the front page of HN every day this week? I remember that I used to be excited seeing that happen), and seeing a lot of growth as well.
If you have something to say here, something to add, come chat to us in #twim:matrix.org - I love that this is a supportive and engaged project ecosystem, so come share what you have!
Weâre very excited to officially welcome the KDE Community on to Matrix as they announce that KDE Community is officially adopting Matrix as a chat platform, and kde.org now has an official Matrix homeserver!
You can see the full announcement and explanation over at https://dot.kde.org/2019/02/20/kde-adding-matrix-its-im-framework. It is fantastic to see one of the largest Free Software communities out there proactively adopting Matrix as an open protocol, open network and FOSS project, rather than drifting into a proprietary centralised chat system. Itâs also really fun to see Riot 1.0 finally holding its own as a chat app against the proprietary alternatives!
This doesnât change the KDE rooms which exist in Matrix today or indeed the KDE Freenode IRC channels - so many of the KDE community were already using Matrix, all the rooms already exist and are already bridged to the right places. All it means is that thereâs now a shiny new homeserver (powered by Modular.im) on which KDE folk are welcome to grab an account if they want, rather than sharing the rather overloaded public matrix.org homeserver. The rooms have been set up on the server to match their equivalent IRC channels - for instance, #kde:kde.org is the same as #kde on Freenode; #kde-devel:kde.org is the same as #kde-devel etc. The rooms continue to retain their other aliases (#kde:matrix.org, #freenode_#kde:matrix.org etc) as before.
This is great news for the Matrix ecosystem in general - and should be particularly welcome for Qt client projects like Quaternion, Spectral and Nheko-Reborn, who may feel a certain affinity to KDE!
So: welcome, KDE! Hope you have a great time, and please let us know how you get on, so we can make sure Matrix kicks ass for you :)
We also have Synapse v0.99.1.1 available, as the race to Synapse v1.0 gets closer and closer and closer!
Brendan also said, regarding low-bandwidth:
Some of the week has been spent finalising the components used in the low-bandwidth demo we did at FOSDEM. This required polishing some internal developments, which are now almost ready to be published to the wide world! This should happen in the next few days so stay tuned :)
Riot 1.0.0, and hotfix 1.0.1
If youâre following Matrix much at all, you will surely have seen it by now: Riot, the most popular client, has announced the v1.0 milestone. I wonât reiterate the features and improvements here, but do check out the blog post, or just head over to https://riot.im/app and see for yourself!
Particularly exciting is the new encryption verification process, involving sharing a list of emojis out-of-band:
thank you @matrixdotorg@RiotChat - with the new update the office is full of people yelling names of emoji at each other
Since we havenât featured their work here at all I wanted to give some space to poljar. Theyâve been working on a Weechat-Matrix protocol script, but as part of this project they created a new Matrix client library, matrix-nio, âdesigned according to sans I/O principlesâ.
As if this wasnât enough! python-olm is a library providing Python bindings for Olm (enabling E2E encryption for Matrix.)
FluffyChat v11 preview
FluffyChat is a pure QML Matrix client, designed to be used on smartphones running Ubuntu Touch. Krille, the author is working on:
boring refactoring stuff :-( at the moment to prepare everything for e2e encryption work
. . .which seems to me not boring at all - we can expect, in the next few months, another Matrix Client with E2EE support, and on mobile!
In my role as editor of this particular blog post, I enjoy certain luxuries that others might envy. For example, today, I tried a new preview build of FluffyChat. This I installed on my barely-repaired OnePlus One running Ubuntu Touch 16.04.
Over the past week, Fractal has adapted its main view and room settings views for mobile phones, and implemented long-press for right-clicks on messages for touch devices. Itâs also received some changes in the backend to use the serde_derive Rust crate instead of parsing JSON by hand.
matrix-tag-manager
To celebrate tags being available again in riot-web, TravisR has created matrix-tag-manager:
If youâre a power user which uses room tagging to organize your rooms, Iâve made a web UI for you: https://tags.t2bot.io/
mxisdv1.3.0 is out! This release brings the massive performance improvements, bug fixes and enhancements. This release also marks the two years anniversary of the project. Thank you to all our users for your undying support!
a new bot avecho is created using the koma-library. Itâs a simple bot that echos text messages prefixed with avecho, but renders it into an image and include the senderâs avatar.
More improvements to the .NET sdk, to make it stable in this 0.4.0 world. To that end, Iâve written a room archiver app (for moving âoldâ rooms into a archive tag without removing them) and a simple caching project for bridges https://github.com/Half-Shot/matrix-cache. Progress as always can be followed in #dotnet:half-shot.uk
QMatrixClient project has been busy merging PRs from contributors (close to tray and middle-click in room list and user list, to mention a couple) and streamlining the translation process before the upcoming releases of libQMatrixClient 0.5 and Quaternion 0.0.9.4. At the same time the feature branch to support room versions and room upgrades is at an advanced stage; expect the features to land in master next week.
matrix-archive-keyring
Linda has been working on new Debian package called matrix-archive-keyring:
Iâve paused porting Synapse to OpenBSD this week, while I attempt to both fix and revert some security issues caused by sudo apt-key add for Matrix.org and Riot.im packages for Debian-based GNU/Linux distribution users. matrix-org/synapse PR #4609 was my first attempt to fix the problem, however I fell short this time in ease-of-use and my implementation had other issues. (Read: The repo-key.asc downloaded from Matrix.org Debian repository should go to /usr/share/keyrings, and must not be added by apt-key add or added to /etc/apt/trusted.gpg.d directly. I attempted the latter with my first PR; but that wouldâve allowed the Matrix.org signing key to also be used to verify packages from Debianâs main repositories. Yikes!) As my second attempt, Iâm now creating a new Debian package called matrix-archive-keyring. Thereâs multiple things this package intends to do:
A post-install script to remove any previously added Matrix.org package signing keys from /etc/apt/trusted.gpg. (This is the file apt-key add most commonly uses, and the most commonly found bad advice on the Internet.)
Convert repo-key.asc to a de-armorized .gpg format, understood better by apt(8). (Essentially, gpg --dearmor.)
Install the converted .gpg key to /usr/share/keyrings.
Make sure apt(8) uses the newly added key for Matrix.org repository only?
Deliver any updates to repo-key.asc directly to you via apt upgrade. Your operating system might then also do it automatically for you if unattended-upgrades(8) is installed on your system. ?
Make sure everything goes away when this keyring package is uninstalled. No more sudo sh -c 'apt-key del C35EB17E1EAE708E6603A9B3AD0592FE47F0DF61; rm /etc/apt/sources.list.d/matrix-org.list to get rid of the repository.
I have one more interesting enhancement to disclose. We can ask you with debconf if you want to install deb https://matrix.org/packages/debian $(lsb_release -cs) main to /etc/apt/sources.list.d/matrix-org.list while youâre installing the new keyring with apt install matrix-archive-keyring. Youâll most likely notice the difference in install instructions, as a result of this package. Before and after:
# After
sudo apt install matrix-archive-keyring
sudo sh -c 'apt update && apt install matrix-synapse-py3
If you are a Debian or Ubuntu user and Synapse homeserver operator using Matrix.org repositories, Iâll be towncrying when this package becomes available as much as I can. All you should need to do then is apt install matrix-archive-keyring and it should patch the security holes in your operating system if youâve formerly installed packages from Matrix.org or Riot.im! (The command may change a bit, because next Debian operating system release âBusterâ has entered soft-freeze just today (2019-02-12) and not accepting new packages into that release.) PS: Iâm at #debian-matrix:matrix.org, please come talk to us if Debian packaging interests you!
For the eager early testers not afraid of building from source, matrix-archive-keyring version 2015.12.09+debian0.10 is available for early testing (attached).
# Something like this!
sudo apt install devscripts
tar -xfvJ matrix-archive-keyring_2015.12.09+debian0.10.tar.xz
cd matrix-archive-keyring_2015.12.09+debian0.10
debuild -us -uc
sudo dpkg -i dpkg -i ../matrix-archive-keyring_2015.12.09+debian0.10_all
Please follow Debian Bug#922155 for updates. Debian binary packages will be available later sometime this/next week from Debianâs unstable distribution (contrib), if all goes well and there are no remaining Debian policy violations or serious bugs.
Gridepo, as a Matrix Homeserver, is gaining basic support for Matrix Client API. We have basic login, room creation, message sending and sync working! A little screen recording of the progress can be viewed here for live action with Riot. As a reminder, Gridepo is a clean rewrite of mxhsd.
This is not usable yet outside of a dev environment but we should have a first usable version with federation in a couple of weeks!
2019 is a big year for Matrix, in the next month we will have shipped:
Matrix spec 1.0 (including the first stable release of the Server to Server Spec)
Synapse 1.0
Riot 1.0
This is huge in itself, but is really only the beginning, and now we want to grow the ecosystem as quickly as possible. This means landing a mix of new features, enhancing existing ones, some big performance improvements as well as generally making life easier for our regular users, homeserver admins and community developers.
Today we are sharing the Matrix core teamâs backend roadmap. The idea is that this will make it easier for anyone to understand where the project is going, what we consider to be important, and why.
A roadmap is a set of high level projects that the team intend to work on and a rough sense of the relative priority. It is essential to focus on specific goals, which inevitably means consciously not working on other initiatives.
Our roadmap is not a delivery plan - there are explicitly no dates. The reason for this is that we know that other projects will emerge, developers will be needed to support other urgent initiatives, matrix.org use continues to grow exponentially and will require performance tweaking.
So simply, based on what we know now, this is the order we will work on our projects.
Why are we sharing it?
We already share our day to day todo list, and of course our commit history, but it can be difficult for a casual observer to see the bigger picture from such granular data. The purpose of sharing is that we want anyone from the community to understand where our priorities lie.
We are often asked âWhy are you not working on X, it is really importantâ where the answer is often âWe agree that X is really important, but A, B and C are more important and must come firstâ.
The point of sharing the roadmap is to make that priority trade off more transparent and consumable.
How did we build it?
The core contributors to Synapse and Dendrite are 6 people, of 5 nationalities spread across 3 locations. After shipping the r0 release of the Server to Server spec last month we took some time to step back and have a think about what to do after Synapse 1.0 lands. This meant getting everyone in one place to talk it through.
We also had Ben (benpa) contribute from a community perspective and took input from speaking to so many of you at FOSDEM.
In the end we filled a wall with post-its, each post-it representing a sizeable project. The position of the post-it was significant in that the vertical axis being a sense of how valuable we thought the task would be, and the horizontal axis being a rough guess on how complex we considered it to be.
We found this sort of grid approach to be really helpful in determining relative priority.
After many hours and plenty of blood, sweat and tears we ended up with something we could live with and wrote it up in the shared board.
And this is written in blood right?
Not at all (itâs written in board marker). This is simply a way to express our plan of action and we are likely to make changes to it dynamically. However, this means that at any given moment, if someone wants to know what we are working on then the roadmap is the place to go.
But wait I want to know more!
Here is a video of myself and Matthew to talk you through the projects
Interesting, but I have questions âŠ
Any feedback gratefully received, come and ask questions in #synapse or #dendrite or feel free to ping me direct at @neilj:matrix.org
Hey, everyone, today is the day we release Synapse 0.99.1.1
This release contains improved ACME support to make it even easier to get going with TLS certs on your federation end points, plus some tweaks to make the room version upgrade path easier.
Just as a reminder that the 0.99.x series is precursor for our 1.0 release (which will land in early March, exact date to be confirmed) - it is really important that all server admins are aware that self signed certificates on the Server to Server API will no longer be accepted by >= Synapse 1.0. If you have not already done so, now is the time to configure your certificate. For more info see our FAQÂ and if you get stuck come and join us in #Synapse.
Fix "TypeError: '>' not supported" when starting without an existing certificate.
Fix a bug where an existing certificate would be reprovisoned every day. (#4648)
Synapse 0.99.1 Changelog
Features
Include m.room.encryption on invites by default (#3902)
Federation OpenID listener resource can now be activated even if federation is disabled (#4420)
Synapse's ACME support will now correctly reprovision a certificate that approaches its expiry while Synapse is running. (#4522)
Riot-web new version coming out so soon. So soon! It looks and runs great, you can use it today at https://riot.im/develop. Includes a labs flag for displaying custom tags, which I love. Watch the vid.
FOSDEM 2019
FOSDEM happened.
two Matrix-themed packed-room talks
lots of people coming to chat at the stall to say things like "hi" or "I like Matrix" or "what is Matrix? ⊠wow that sounds amazing, how can I get involved?"
1000s of stickers decentralised out of my bag onto people's laptops
Synapse 1.0.0 will be compliant with r0.1 and the goal of Synapse 0.99.0 is to act as a stepping stone to Synapse 1.0. Synapse 0.99.0 supports the r0.1 release of the server to server specification, but is compatible with both the legacy Matrix federation behaviour (pre-r0.1) as well as post-r0.1 behaviour, in order to allow for a smooth upgrade across the federation. It is critical that all admins upgrade to 0.99.0 and configure a valid TLS certificate. Admins will have 1 month to do so, after which 1.0.0 will be released and those servers without a valid certificate will no longer be able to federate with >= 1.0.0 servers.
Cadair has been helping admin this yearâs GSOC application:
Matrix.org has applied to be a GSOC (Google Summer of Code) mentoring organisation. If your matrix project has a feature a summer student could tackle and you have the time to mentor them over the summer, why not add a project idea to our website by submitting a PR to this repo. Feel free to ask questions in #gsoc:matrix.org as well.
matrix-puppet-hangouts version 0.1.0 has been released! This release adds bidirectional (Hangouts -> Matrix and Matrix -> Hangouts) image support! It also bumps the version of matrix-puppet-bridge (the common core of matrix-puppet-bridge bridges, which handles most of the stuff thatâs the same between different third-party service bridges, and makes implementing new matrix-puppet-bridge bridges easier) required to 1.16.2, the current latest, for recent bugfixes that improve all matrix-puppet-bridge bridges. 0.1.0 also requires Python 3.5+, for async. Older versions of python3 wonât work. PRs getting python3 < 3.5 working again are welcome.
matrix-media-repo now supports .well-known server delegation (compatible with Synapse 0.99 and r0.1 of the server-server specification), among many other bug fixes and improvements. Actually validating the certificates presented by servers will be implemented alongside Synapse 1.0âs requirement for it.
Dimension from TravisR now supports .well-known server delegation
Dimension now supports .well-known server delegation (compatible with Synapse 0.99 and r0.1 of the server-server specification). Actually validating the certificates presented by servers will be implemented alongside Synapse 1.0âs requirement for it.
mxisdv1.3.0-rc.3 is out. This is hopefully the last RC before release, but we would like as much testing as possible! the v1.3 branch is a big enhancement on the previous release with big performance and privacy improvements. Itâs smaller, faster, stronger and protects you privacy even better than before! You know you want it!
matrix-docker-ansible-deploy now supports Synapse v0.99
matrix-docker-ansible-deploy now supports Synapse v0.99 and should be ready for Synapse v1.0. If youâre using the playbook to manage your Matrix server you should upgrade soon. Depending on how youâve customized your setup, you may not even have to do anything for the big Synapse v0.99/v1.0 transition, besides upgrading and re-running the playbook. A good place to start is the changelog entry: Synapse v0.99 support and preparation for Synapse v1.0
I have been using these playbooks to test my own homeserver deployment and am happy.
After seeing a demo at FOSDEM of Tchap, the app the French government uses to access their Matrix network, I decided to try to get it to work as a general-purpose Matrix client. The app uses email and password to log in, and infers the homeserver address from the homeserver name. So to get it to work, I had to patch the app and write a little proxy so it gets the proper homeserver (and optionally identity server) from an email address. A patched version of Tchap can be found at https://github.com/14mRh4X0r/tchap-android, code for the proxy at https://git.snt.utwente.nl/14mRh4X0r/tchap-proxy. At the moment itâs very crude, and images/files donât work since the virus scan API is unimplemented, but at least it can be used outside the French government. ?
Riot iOS
From the team:
Still iterating on key backup UX
Fix various share extension bugs (image sending failure, links share as text, etcâŠ)
Riot Android
Still iterating on the key backup UX, changes concern Riot and the Matrix SDK
Valere has worked on Riot Android Notifications, we intend to merge this work on develop at the beginning of the next Sprint.
RiotX: no update this week due to François being out of the office
I opened up the .NET SDK project for the first time in two years and revived it to just about work with a r0.4.0 home server. Its now based on .NET core 2.0.
Iâm porting Spectral to KDE Plasma Mobile with Kirigami framework. This provides full convergence and mobile support.
Some progress pictures below, desktop and mobile version.
Preparing for Synapse on OpenBSD
Linda has been making progress on a project to get Synapse running on OpenBSD, and to that end has been preparing and improving the dependencies that we take for granted on Linux. To summarise the current status:
This week Iâve been porting Synapseâs dependencies to OpenBSD -current distribution. There is no port yet for Synapse in OpenBSD.
Ports missing from OpenBSD 6.4 for Synapseâs dependencies were:
py-frozendict: ok'd, waitingâŠ
py-unpaddedbase64: TBD
py-canonicaljson: TBD
py-signedjson: TBD
py-treq: WIP (this will take a while, lots of dependencies)
py-daemonize: ok'd, waitingâŠ
py-pymacaroons: TBD
py-phonenumbers: 8.10.4 done, waiting to be importedâŠ
py-prometheus_client done, needs to be tested/importedâŠ
coturn: TBD, maybe?
waiting = usually waiting for an OpenBSD developer to "ok" and import
Of those, py-phonenumbers was added to OpenBSD -snapshots (-current) distribution. py-phonenumbers (?) and py-service_identity received updates to ports. py-prometheus_client, py-daemonize and py-frozendict are ported ready and waiting to be given âokâ at OpenBSDâs ports@ mailing list. There is an unofficial up-to-date Synapse port exists at GitHub maintained by someone else, which Iâve not yet tested. (At glance, I can take a guess the devel/tz port may not be required.) (coturn doesnât have a port yet, may have to look at it later.)
c u l8r
Phew! That was a lot! See you next week, and if you have a project youâd like to see featured in This Week in Matrix, come chat to us in #twim:matrix.org!
You may have heard that we recently published the first stable release of the Server to Server Spec (r0.1). The spec makes some changes which are not compatible with the protocol of the past - particularly, self-signed certificates are no longer valid for homeservers. Synapse 1.0.0 will be compliant with r0.1 and the goal of Synapse 0.99.0 is to act as a stepping stone to Synapse 1.0. Synapse 0.99.0 supports the r0.1 release of the server to server specification, but is compatible with both the legacy Matrix federation behaviour (pre-r0.1) as well as post-r0.1 behaviour, in order to allow for a smooth upgrade across the federation.
It is critical that all admins upgrade to 0.99.0 and configure a valid TLS certificate. Admins will have 1 month to do so, after which 1.0.0 will be released and those servers without a valid certificate will no longer be able to federate with >= 1.0.0 servers.
First of all, please donât panic :) We have taken steps to make this process as simple as possible - specifically implementing ACME support to allow servers to automatically generate free Letâs Encrypt certificates if you choose to. Whatâs more, it is not necessary to add the certificate right away, you have at least a month to get set up.
For more details on exactly what you need to do (and also why this change is essential), we have provided an extensive FAQÂ as well as the Upgrade notes for Synapse
This was a huge effort! Congratulations to all involved, especially those of you in the community who contributed to spec MSCs and tested our release candidates. Thank you for bearing with us as we move the whole public Matrix Federation onto r0.1 compliant servers.
Onwards!
Changelog
Synapse v0.99.x is a precursor to the upcoming Synapse v1.0 release. It contains foundational changes to room architecture and the federation security model necessary to support the upcoming r0 release of the Server to Server API.
Features
Synapse's cipher string has been updated to require ECDH key exchange. Configuring and generating dh_params is no longer required, and they will be ignored. (#4229)
Synapse can now automatically provision TLS certificates via ACME (the protocol used by CAs like Let's Encrypt). (#4384, #4492, #4525, #4572, #4564, #4566, #4547, #4557)
We just got back from braving the snow in Brussels at FOSDEM 2019 - Europeâs biggest Open Source conference. I think itâs fair to say we had an amazing time, with more people than ever before wanting to hang out and talk Matrix and discuss their favourite features (and bugs)!
The big news is that we released r0.1 of Matrixâs Server-Server API late on Friday night - our first ever formal stable release of Matrixâs Federation API, having addressed the core of the issues which have kept Federation in beta thus far. Weâll go into more detail on this in a dedicated blog post, but this marks the first ever time that all of Matrixâs APIs have had an official stable release. All that remains before we declare Matrix out of beta is to release updates of the CS API (0.5) and possibly the IS API (0.2) and then we can formally declare the overall combination as Matrix 1.0 :D
We spoke about SS API r0.1 at length in our main stage FOSDEM talk on Saturday - as well as showing off the Riot Redesign, the E2E Encryption Endgame and giving an update on the French Government deployment of Matrix and the focus itâs given us on finally shipping Matrix 1.0! For those who werenât there or missed the livestream, hereâs the talk!  Slides are available here.
Full house for @ara4n talking about @matrixdotorg and the French State @fosdem It was a packed presentation full of lots exciting progress demos. So sorry for practically yanking you offstage in the end! pic.twitter.com/idshDcSRhv
Then, on Sunday we had the opportunity to have a quick 20 minute talk in the Real Time Comms dev room, where we gave a tour of some of the work weâve been doing recently to scale Matrix down to working on incredibly low bandwidth networks (100bps or less). Itâs literally the opposite of the Matrix 1.0 / France talk in that itâs a quick deep dive into a very specific problem area in Matrix - so, if youâve been looking forward to Matrix finally having a better transport than HTTPS+JSON, here goes! Slides are available here.
Huge thanks to everyone who came to the talks, and everyone who came to the stand or grabbed us for a chat! FOSDEM is an amazing way to be reminded in person that folks care about Matrix, and weâve come away feeling more determined than ever to make Matrix as great as possible and provide a protocol+network which will replace the increasingly threatened proprietary communication silos. :)
r0, the first stable release of the Server-Server (Federation) Specification is extremely close! We of course will make a big splash and let you know when this comes!
Even apart from that, letâs take a look at the MSCs (Matrix Spec Changes) that are currently in progress.
Neil and the team have been working frantically on getting a new Synapse release out this week:
This week has been all about gearing up for v0.99.0 and if you would like to help us test it, our latest release candidate lives here Weâve taken the decision to bump up to v0.99.0 because it is very much a precursor to v1.0. When v1.0 lands it will contain a breaking change that means all homeservers will need a valid certificate for their server to server endpoint, self signing will no longer be possible. v0.99.0 contains support to help you do this, but once it lands all admins will need to upgrade, failure to do so will mean losing the ability to federate with > v1.0 servers. Weâll have detailed docs ready to go alongside the full v0.99.0 release, and we plan to leave at least 1 month between v0.99.0 and v1.0, but for now please be aware that the change is coming. Huge thanks to Rich, Erik, Hawkowl and Anoa for all their work in getting us to rc stage.
nheko_reborn
If you havenât already heard, then I envy that you get to learn about it now: there is a credible new project which forks nheko and seeks to maintain and continue the project.
I think Iâm getting pretty close to having another release ready. Need to clean up some things here and there and get the CI packages uploading correctly Itâd be good to have more community engagement
Iâm planning to start work on the component that will scrape blog content from a matrix room. This will most likely involve a dedicated bot that syncs new journal blog events, verifies the blog signature and then writes the blog content to a file on the blog server.
Iâll probably ramble about the details of that at some point.
The bridge is being re-written. I excluded the jabber server (still need to setup SRV records) and implementing the xmpp s2s api in the bridge.
Done:
rfc6120 in s2s part;
almost server dialback (XEP-0220);
Remaining:
MUC (XEP-0045);
stabilize.
New version will allow:
1:1 conversations between matrix and jabber users;
group chats by double-puppet mapping rooms to conferences;
additionally xmpp users can join directly to rooms via double-puppet bots.
Also I started breaking the bridge to modules. And the next module will be ActivityPub S2S module which allows communicate matrix servers with other fedivers.
mxisdv1.3.0-alpha.3 is out! This one works further towards protecting your privacy and we strongly recommend it if you already are using an alpha release. We have written our stance on privacy with how it affects mxisd here.
We also consider this release to be as stable as v1.2.2. Feel free to upgrade following the Upgrade notes and benefits from all the v1.3.0 work so far, especially the massive improvements on resources usage.
Purism working on Fractal integration
update on @gnome@matrixdotorg client for #PureOS: "I am pleased to announce that over the next week I will be working to make Fractal's UI adaptive for the Librem 5's launch. This contract began last week, and I already have some results to show off." pic.twitter.com/Hnr7ZVpYd1
What there mainly is is FOSDEM. A lot of Matrix-folk are currently near me as I write this, sat in a hotel bar in sunny Brussels. Matrix live is not available today, but will incorporate some of the event, which kicks of tomorrow.
If you will be attending, come /join us at the Matrix table, where there will be stickers and t-shirts and merriment, and definitely come and attend the talks:
