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:
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.
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.
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
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!
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 https://github.com/uMatriks/uMatriksblob/0a800fcdc0af4fa2e08526dbff88e06bcb591779/uMatriks/componentsChatItem.qml 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)
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.
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?
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 :)
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 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.
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.
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.
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.
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.
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.
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)
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.
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. ?
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.
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.)
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.
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.
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 APIlate 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.
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.
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." https://t.co/iX47u1Bdb1pic.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:
