Well now, what have we here? Synapse 0.99.2 is the latest in the 0.99.x series as we step ever closer to 1.0.
0.99.2 is an incremental release including a bunch of performance improvements, enhancements to room upgrades and generally a plethora of bug fixes.
The most important thing that admins should know is that prior to 1.0 landing later this month, it is essential that the federation API has a valid TLS certificate - self signed certificates will no longer be accepted. For more details see our handy guide. Failure to do this will result in being unable to federate with other 1.0 servers.
No Ben this week, apparently he is allowed to go on holiday from time to time. Also no Matrix Live because we are terrible people - bring back Ben, that's what I say.
Quaternion (master branch, and upcoming v0.0.9.4) can now open rooms by their aliases or ids upon pressing Ctrl+O, as long as those rooms are already in your room list (opening arbitrary public rooms will come in later versions). You can even paste matrix.to URIs for users (will open direct chat) and rooms in the same dialog. Navigation to known rooms inside Quaternion also works.
weechat-matrix's e2e support is really impressive (via matrix-nio and python-olm). It can only read rather than send right now, but otherwise looks to be massively on the right track. It even does fingerprint-based verification!
Synapse
We shipped 0.99.2 this week, it's a point release containing all the usual bug fixes and perf improvements. We have also been taking a look at our docs and trying to improve where we can.
Hawkowl has spent some time improving CI so that we don't get queued up for hours waiting for builds (woo).
Admins - your weekly reminder that if you've not already done so, you must ensure the TLS certificate on your federation endpoints is no longer self signed - see our handy guide for all the details.
Sets rooms invite-only when they're touched, instead of relying on others not knowing the room ID (thanks to https://matrix.to/#/@AndrewJDR:matrix.org , from all of us who federate on the homeservers we use to bridge!)
Matrix rooms representing remote rooms being joinable by anyone who knows the room ID (which is generated, at least in part, from the remote room ID in all the matrix-puppet-bridge applications) was a big deficiency, and it's finally resolved. It wasn't known whether or not we could do this, and have our ghost users still be able to join the rooms (they need to be invited instead of just joining themselves), until it was attempted and tested in a few of the bridge applications. Because it is a big deal, new minor versions of matrix-puppet-slack, matrix-puppet-facebook, matrix-puppet-hangouts, matrix-puppet-signal, matrix-puppet-imessage and matrix-puppet-groupme, bumping the matrix-puppet-bridge version to 1.17.0, have been released.
Riot iOS
Support .well-known data from login response
Create right permalinks for room v3
Fix builder to Xcode 10.1 in order to still be able to release
matrix-media-repo has alpha-quality support for s3 (and s3-like services) on the travis/s3 branch. Intrepid testers are encouraged to give it a shot, and report bugs. Caution: may upload your cat.
Scylla
It's been a little while since we saw any news about Scylla, a web-based client written in Elm. VaNilLa said:
Scylla, the Elm-based Matrix client, has received a few improvements. Included in this update:
Files that are uploaded now keep their original name (as opposed to being called File)
Sent messages are displayed right away, instead of when they are delivered to the server
Usernames are only shown once per several consecutive messages, to avoid clutter Some CSS changes have been made to keep the interface looking clean
Implementation of .well-known support (SDK and Riot)
Minor change on some colors of the themes (link, home badges)
Many issue will be fixed regarding linkification
KeysBackup: improvement on recovery process: importing keys step is 8 times faster, and user get more feedback during the process which can take several seconds
We will prepare a new release for the beginning of next week.
PlayStore new descriptions have been updated for the following languages: Bulgarian, German, English (US), French, Hungarian, Russian and Chinese (Taiwan).
RiotX (Android)
Timeline:
HTML formatting
Implementation of pills (need optimization)
Many Github issues have been created to track parity with the Riot Android
Riotic: new fork with updates
Aaron Raimist has made some updates to Riotic, which was a good chance for me to revisit it. It works nicely and is a great alternative to the Electron version of Riot. I also like being able to use https://riot.im/develop as an app.
I've slightly tweaked Joakim Ahlen's Riot wrapper for macOS, riotic, which uses the native WKWebView instead of Electron. I updated the app to be sandboxed so it has very limited access to your system. I also updated the interface to follow macOS conventions and updated it to use the latest version of Swift.
riotic does have some limitations though. Riot doesn't support VoIP on Safari so riotic can't support VoIP either and WKWebView doesn't support notifications as far as I can tell. Right now it uses a really old Riot icon, maybe I'll ask about using one of these community made icons https://github.com/vector-im/riot-web/pull/4474.
It does have some advantages over the official Riot Electron app though. The app is only ~12 MB compared to Riot which is ~180 MB, it also uses significantly less RAM. riotic also allows you to pick what Riot URL to use so you can run /develop as a desktop app.
The synapse-netcore-worker project has continued to evolve. You can now federate with other servers using the federation sender implementation. It supports everything except device lists at the moment, so it supports PDUs/EDUs and can just be connected up to one of your existing synapse instances. It's not been battletested enough yet to be put in production (hence no dockerfile), but it's very fast. Oh and for those of you who don't know, "synapse-netcore-worker" is Travis's .NET implementation of synapse workers, the room can be found at #synapse-netcore-workers:t2bot.io.
If you're as uninitiated as I was three days ago, this project is a replaceable worker component for Synapse, which just happens to be written in .NET.
To give an update to the earlier exploits of synapse-netcore-worker's federation sender, we've still got a few more things to iron out before we can suggest people use it actively. The hit list of remaining things to fix is in https://github.com/turt2live/synapse-netcore-workers/pull/5
Mautrix Whatsapp
That Ben guy eh? When he's not swanning off on holiday and having fun, he's writing super groovy guides to getting whatsapp bridging up and running. You don't even need a real device. Check it out.
Just merged the protocol split branch I've been working on for the Ruby SDK, including a first PoC for an application service base. Not tested in any actual use as of yet, but expect Things TM in the next release.
in project koma, a new bot picsay is created. It like the classic easter-egg program cowsay, but it uses actual photos instead of ASCII art. It configured to use any image just by editing a json file. So you can run your own version for fun.
I took some time to hack on Tchap again. This time I disabled virus scanning of thumbnails and downloads in Tchap to be able to see avatars. I also wrote a non-scanning virus scanner API implementation to be able to see files, pictures and videos that are sent. The updated Tchap can be found at https://github.com/14mRh4X0r/tchap-android, the virus scanner API implementation at https://git.snt.utwente.nl/14mRh4X0r/tchap-media-scanner.
Unless things get seriously on fire in the coming months, Debian buster will have Synapse 0.99.2 plus something newer in backports
Matrix WUG
Dandellion'sWug now supports Inuktitut Syllabics and Iñupiatun Orthography. In the bot's own words.
Hi I can help you translate X-SAMPA, Z-SAMPA to IPA, and transcribe into proto-indo european notation! Use (x/z/p) together with either / or [] as delimiters x/"hEloU/ z[or` 5aIk DIz] p/mreghnom/
I also can transcribe to Inuktitut Syllabics like this: i[tusaumaqattautijjutinik aulattijiit]. Find my source at https://github.com/Dali99/matrix-wug
New Rooms
Aaron Raimist has created a new room for Formula 1 fans:
Now that the Formula 1 season is getting underway it's probably a good time to announce @CIA:matrix.org's new(ish) room: #f1:matrix.org When this blog post is released there will be 16 days left before the first race of the 2019 season There was previously a Formula 1 room but it was merged with Snoonet's IRC channel which tends to be extremely busy. This is a matrix only room.
That's it folks, your normal Ben orientated programming will continue next week. Bring back Ben, bring back Ben.
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!
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 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)
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)
Ananace
yuforia
Willem
andrewsh
