TL;DR DON'T PANIC - Synapse 1.0 will support Postgres 9.4 and Python 2.7
Folks, this is an update to explain that we will be shortly deprecating Synapse support for Postgres 9.4 and Python 2.x.
What are we doing?
From the dates described below, we will no longer guarantee support for deprecated versions. This means that Synapse may continue to work with these versions but we will not make any attempt to ensure compatibility and will remove old library versions from our CI.
When is this happening?
Synapse 1.0 will continue to support both technologies, but subsequent releases may not:-
For Python, we shared that we would discontinue to Python 2.x support from April 1st 2019, so for the first release that follows 1.0 we do not guarantee Python 2.x support.
For Postgres, will give server admins 6 weeks to upgrade to a newer version, and will guarantee support up until 20th May 2019.
Why would you do this to us?
We have multiple reasons, but broadly:-
We want to make use of new language features not supported in old versions. This will enable us to continue to improve the performance and maintainability of Synapse.
Since very few server admins still use these technologies on the wild, providing support is costly and we want to reduce our overall maintenance load.
La la la I am ignoring you - what will happen?
You will be able to upgrade to Synapse 1.0, but will likely experience incompatibilities that prevent you upgrading further. Seriously, you really need to upgrade.
Okay, but I have questions, where should I go?
Come and say Hi in #synapse:matrix.org and we'll do our best to help you.
Last week we carried on with Synapse 1.0 work, in particular server key signing validity, a config option to verify federation certificates to support MSC1711 and support for 3PID unbinding APIs (MSC1915). Outside of that we've been thinking about how to improve room upgrades for private rooms and landed the preparatory work for a refactor of the room directory.
Coming up next, we'll continue to bash out 1.0 blockers, Hawkowl has started work on optimising for small hosted homeservers, and anoa will be working on the new super fast room directory. Finally Erik has started work on aggregations support so clients will be able to offer things like edits and reactions ?
Dockerfile for sytest running against Dendrite approved. Close to being able to run Dendrite against sytest. Also using sytest's new test white/blacklist functionality to include a list of tests that Dendrite is known to pass in the repo. When people make new PRs that allow Dendrite to pass new tests, they can also append the names of the tests to the testfile to help automatically track Dendrite's improving progress. Look forward to seeing further progress post Synapse 1.0.
libQMatrixClient 0.5.1 is out! This is a minor release with bugfixes and small improvements, a base for Quaternion 0.0.9.4, RC of which is coming this weekend. Full release notes here
and to follow up:
Quaternion 0.0.9.4 Release Candidate is available for all those who don't need a "release" seal of approval to use applications. Get out, grab it, report bugs that could still sneak in: https://github.com/QMatrixClient/Quaternion/releases/tag/0.0.9.4-rc. A separate call out to translators - it's a great moment to teach Quaternion a few more phrases in your language!
This weekend I took a brief pause from doing matrix work, and then went back into it by finishing the feature set for the .NET Core Synchrotron. It's "feature complete" meaning all specced features of sync are in this branch, excluding legacy endpoints. There are a few bugs logged against it and it's really only useful as a super early test, while I fix some of the p1 bugs.
The federation sender continues to be reliable and stable, and we are prepping for the release of synapse 0.99.3 which made a few changes to the replication stream. For more info, please see https://github.com/turt2live/synapse-netcore-workers
Pattle has now moved to Flutter
Wilko has officially discontinued the previous version of Pattle, and is focused on their Flutter SDK and new version of Pattle based on it:
After some silence here but a lot of development, Pattle has now moved to Flutter. The new app is available in the same F-droid repository, you can just update. Note that you will have to log in again. If there are issues with updating, try removing the old app and installing the new one.
Also note that this version is still very basic and does not have all features of the old Pattle unfortunately. The reason that I chose to already replace it on the repo is that the old app will not receive updates anymore.
The current features are logging in and an overview of all chats. What is new is that data is now stored locally, so you won't have to do an initial sync everytime you open the app (which was the case with old app). What's also new is that I've decided to use more red, because.. I like red.
There is still a lot to do! Please notify me of anything that you think is missing, even though some things may be obvious (sorting chats based on date, chat avatars), some may not be as obvious to me!
If you'd like to contribute, the new repo is here. Note that many contributions will probably start at the SDK level. Pattle uses my own Dart SDK, which you can find here.
There is at the moment a very specific bug in Flutter, where on Android 7.1 with release builds, the app crashes when building a list widget. If you use Android 7.1 (like me) and you crash after logging in, that's the reason. It seems I can't do anything about it, sorry.
Aqueous now comes with room categories and history messages support.
Also, a lot of code refactoring is going on to change the backend store from plain json file to sqlite, which should improve the performance a lot.
The room is at #libaqueous:encom.eu.org
Riot Web
Working towards bringing breadcrumbs out of labs
Adding image preview to file upload UX
Stability fixes for timeline
Defending against issues introduced when using Riot Web on a machine which is running out of disk space
Riot iOS
Grouped notifications are coming! We have added some logs to track why the notification setting is sometimes disables (#2348).
SAS device verification is still in progress but it should be released next week.
Riot Android
Three releases this week, to fix several bugs with the new EventStreamServiceX, and to fix issue with the Jitsi conference call (Riot.im 0.8.29). FDroid users should receive the upgrade soon.
Users are happy with the new notifications!
Valere is still working on SAS, we are reaching the end :).
RiotX (Android)
It's now possible to signout from RiotX.
The whole setting screen has been imported from Riot, as well as the Themes and some other small features (launcher icon, etc.).
Benoit is working on room creation, sdk side, and François is working on image upload.
We should start to integrate new design from Nad next week.
I'll be writing a Helm chart for 1.0 as well, just haven't had time to do so yet. I need to update all the references to TLS as well, as that's supposed to be left to kube-lego or cert-manager for a modern install
Following up on last week's effort, a number of issues on the Matrix federation tester, both on the backend and the frontend side, have been fixed, including fixing certificate validity checks, not following CNAME records in SRV records, fixing display of the SRV lookup in the UI, preventing some crashes, and a few more.
All outstanding issues on both the federation tester's backend and its frontend that could have preventing people to test efficiently how their server is performing in the context of Synapse's 1.0 release have now been fixed and deployed on https://matrix.org/federationtester/.
A few bounties have been added to Synapse and Riot recently to encourage community members to work on those projects. Although they aren't large enough to actually pay for development, I believe they can serve as a small push to help an already interested developer justify spending some time working on these projects.
pantalaimon has been seen in the wild, even appearing to run on Android. We'll get a little closer to the project and see how it's going in a future edition.
new, alpha quality, matrix python client for asyncio and with support for e2e encryption: https://github.com/SFTtech/aiomatrix Polishing is needed but the basics do work already :)
The big news in 0.99.3 is that the user directory has been completely re-written and should now be much more performant - this will benefit all installations, but especially those housing larger servers.
Aside from that we continue our 1.0 preparations and relatedly we've improved our docs, in particular to explain how .well-known works. On the perf side we've added rate limiting to login and register endpoints as well as now batching up read receipts to send over federation.
I've said it before, and I'll say it again:-
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.
The user directory has been rewritten to make it faster, with less chance of falling behind on a large server. (#4537, #4846, #4864, #4887, #4900, #4944)
Add configurable rate limiting to the /register endpoint. (#4735, #4804)
Move server key queries to federation reader. (#4757)
Add support for /account/3pid REST endpoint to client_reader worker. (#4759)
Add an endpoint to the admin API for querying the server version. Contributed by Joseph Weston. (#4772)
Include a default configuration file in the 'docs' directory. (#4791, #4801)
Synapse is now permissive about trailing slashes on some of its federation endpoints, allowing zero or more to be present. (#4793)
Add support for /keys/query and /keys/changes REST endpoints to client_reader worker. (#4796)
Add checks to incoming events over federation for events evading auth (aka "soft fail"). (#4814)
Add configurable rate limiting to the /login endpoint. (#4821, #4865)
Remove trailing slashes from certain outbound federation requests. Retry if receiving a 404. Context: #3622. (#4840)
Allow passing --daemonize flags to workers in the same way as with master. (#4853)
Batch up outgoing read-receipts to reduce federation traffic. (#4890, #4927)
Add option to disable searching the user directory. (#4895)
Add option to disable searching of local and remote public room lists. (#4896)
Add ability for password providers to login/register a user via 3PID (email, phone). (#4931)
Bugfixes
Fix a bug where media with spaces in the name would get a corrupted name. (#2090)
Fix attempting to paginate in rooms where server cannot see any events, to avoid unnecessarily pulling in lots of redacted events. (#4699)
'event_id' is now a required parameter in federated state requests, as per the matrix spec. (#4740)
Fix tightloop over connecting to replication server. (#4749)
Fix parsing of Content-Disposition headers on remote media requests and URL previews. (#4763)
Fix incorrect log about not persisting duplicate state event. (#4776)
Fix v4v6 option in HAProxy example config. Contributed by Flakebi. (#4790)
Handle batch updates in worker replication protocol. (#4792)
Fix bug where we didn't correctly throttle sending of USER_IP commands over replication. (#4818)
Fix potential race in handling missing updates in device list updates. (#4829)
Fix bug where synapse expected an un-specced prev_state field on state events. (#4837)
Transfer a user's notification settings (push rules) on room upgrade. (#4838)
Clarify what registration_shared_secret allows for. (#4844)
Correctly log expected errors when fetching server keys. (#4847)
Update install docs to explicitly state a full-chain (not just the top-level) TLS certificate must be provided to Synapse. This caused some people's Synapse ports to appear correct in a browser but still (rightfully so) upset the federation tester. (#4849)
Move client read-receipt processing to federation sender worker. (#4852)
The matrix.org homeserver will be down for essential database maintenance between 12:00 and 12:30 UTC on 2019-04-01
Synapse
Neil, Synapse overseer, reports on the acceleration towards 1.0:
We have much improved sytest support for Synapse worker mode, Hawkowl landed a brand new super fast super shiny user directory implementation, Brendan fixed a bunch of niggles in the federation tester and we finally got to the bottom of our sync caching bug that obscured accepting invites (thanks richvdh for sticking with it). Erik solved our presence spamming bug and anoa fixed some LDAP auth bugs and submitted a PR for certificate checking - one of our final blockers for Synapse 1.0. For all the latest checkout out our latest release candidate 0.99.3rc1.
Next week, we'll ship 0.99.3, we'll be looking at server key validity periods, adding a 3PID unbind API and starting work on tuning low powered Synapse installations. https://www.arewereadyyet.com/ is still rising so keep banging to everyone you know that they ensure their federation certificates are valid.
Pantalaimon is a new project that acts as a reverse proxy for clients to connect to. Once a client is connected Pantalaimon handles end to end encryption for the client transparently.
The project is only a week old but already at a working prototype phase. A demo can be found here: http://webmshare.com/play/Qn4wg
This is a huge gain! Use of this project, as you will see in the video, permits any Matrix client to support End-to-End encryption of messages, by handling encryption/decryption in a daemon rather than in the client.
The matrix Construct server has made significant progress this week implementing the 1.0 specification and is very close to a 1.0 release! Special thanks to our star tester Yan Minari and expert Matrix consultants Tulir and Max and C++ developers Jason of Zemos and Mujx of nheko for all their hard work to make this happen. The Construct now fully supports IPv6 and is ready to participate in fully end-to-to-end encrypted ipv6 networks like #yggdrasil:matrix.org and #cjdns:matrix.org. This week also saw additions for .well-known support, m.fully_read and even DNS caching inside a matrix room shared between servers (which is really cool if you ask me).
The Construct is written in C++ for maximum performance and scalability. It is the first fully federating server after the Synapse reference implementation. Your contributions in code and participation are essential to bring Construct to its upcoming release; get involved at https://github.com/matrix-construct/construct and in #zemos-test:matrix.org.
Riot Web
From the team:
We've been upgrading and optimising our Jitsi instance so people should see more reliable video conference calls, especially if they avoid connecting from Firefox over poor connections. We've been squashing scroll jumps (where the timeline pops out of position unexpectedly due to images loading, etc.). We've come up with a radical reimplementation of the timeline (which should be imperceptible, except it doesn't jump) - try it out on https://riot.im/develop now.
Bruno, who has been working on scroll functional for Riot deserves a call-out - scrolling in new Riot web works great, and he may now be the most qualified dev on scroll: anchor outside of Mozilla or Google…
You can now get all Riot updates from #riot-web-announcements:matrix.org, the official room of Riot web announcements! You can especially get this update, which was also featured on Twitter:
Attention Riot Web Admins! We reset Scalar tokens to address a potential security vuln. with some clients - if you run your own Riot instance please upgrade to at least v1.0.4 to keep using integrations (widgets, sticker picker, any bots and bridges configured through Scalar).
Another case of UTD (https://github.com/vector-im/riot-ios/issues/2320) has been fixed. Some logs have been added to track push notifications that disabled themselves. SAS verification implementation is still in progress.
UTD = "Unable to Decrypt", messages as seen in Riot
Riot Android
Rework of EventStreamService, to fix many issues (crash) reported by users. The feature is available on the develop branch.
Also we are trying to upgrade Jitsi library, to fix other errors reported by users.
SAS verification implementation is still in progress.
Also, you may have already seen the use of Android 9-style notifications, featuring "Mark as read" + "Quick reply" buttons. This addition has started to make Riot Android my client of choice for burning through notifying rooms.
RiotX (Android)
Phase 1 started!
Backporting RageShake feature, with better handshake detection.
We are still fighting bug on the timeline rendering.
Quick note that nheko (v 0.6.3) is now packaged for FreeBSD as well. The C++ code was fine (we use Clang, that does trip up some people) but I have Opinions about the CMake code (in particular that the find code for nlohmann/json.hpp, lmdb++.h and tweeny.h could use a lot of work -- if I feel perky I may come up with a PR). Thanks for the good work!
Dart SDKs
Black Hat has been using Dart and Flutter this week, and is making progress with an SDK and reference client:
I am trying to use libaqueous(Matrix Dart SDK) to create a cross-platform matrix client for Android and iOS. Almost nothing works except Already a significant number of client features are available: login/logout, room list, basic timeline and message posting
Flutter is quite good for rapidly building mobile apps. ? Strong-typed json serialization/deserialization in Dart is a bit difficult at first, but I managed to solve that. the repo is here, the SDK is here, and the room for discussion is at #libaqueous:encom.eu.org
I chatted with Kitsune, maintainer of libQMatrixClient, Quaternion and Spec Core Team member. We talked about the history and future of these projects, platform preferences, the importance of decentralisation and more.
Synapse and the road to 1.0
Neil, Synapse-dev wrangler #1:
Huge thanks to everyone who has helped increase the number of ‘1.0 ready' synapse installs. If you don't know what this means, see our blog. https://arewereadyyet.com reports > 60% adoption on a per server basis, and high 90s on a per user basis. We are now really close to being able to ship a 1.0 release candidate and start the 2 week countdown before releasing 1.0 proper.
This week we have focussed on performance, richvdh has been working on batching of outgoing read receipts and hawkowl shipped a much more performant implementation of user search. Erik has been putting the state compressor through its paces, he saw one room compress down to 1% of its original size. Andrew has been focusing on ensuring spec compliance on various Synapse endpoints and is currently looking at some bugs in the federation tester.
It's the most up to date version straight from the pipeline, so not necessarily stable.
You can now scroll up and load history
As part of the project, Wilko also announced the intention to create a Dart SDK:
I'm currently working on a Matrix SDK for Dart, which will be used for the Pattle rewrite in Flutter.
The reason for this is outlined here. To summarize: My goal for Pattle is to release for not only Android but also iOS and web, with a single code base. Other reasons include that Android native development is just bad, and the fact that I'm not too happy with the official Matrix Android SDK design and documentation.
I will maintain and also add some features to the current version of Pattle, to try things out. The Flutter version will replace the native one once the features are in sync.
Riot iOS
We've released a hotfix release 0.8.4 on App Store that fixes following issues:
Unable to open a file attachment of a room message.
Unable to share a file with whitespace in filename.
Click on the smiley face to the right of where you type messages then the Edit button in the top right.
Paste the URL of the sticker pack into the box and click "Add Stickerpack".
Start using your new stickers.
These instructions are also available at https://github.com/turt2live/matrix-dimension/blob/master/docs/custom_stickerpacks.md as is the admin/operator guide for running your own sticker bot (you're not stuck with using t2bot.io unless you want to be). Custom sticker packs are still beta while the proposals to share this with the wider Matrix ecosystem are still works in progress. This serves as a proof of concept to see how crazy of an idea it is to have stickerpacks-as-rooms (yes, they're just plain Matrix rooms under the hood) and what needs ironing out before moving ahead with the MSC.
matrix-notification-profile-manager
Brendan has created a notification profile manager:
Over the past few weeks, I grew a bit fed up of always having to turn on and off every notification rule each time I'm having a slight change in what I'm working on or depending on what mood I was in (e.g. want to focus only on work-related stuff and nothing else, don't want to hear about work at all, somewhere in the middle, etc.), so I built a notification profile manager for Matrix. It's available both as a command line interface or a Go package in case people want to build on top of it.
It allows one to take a snapshot of their current notifications settings and save that as a profile, so that this profile can be applied later. It also allows one to delete a profile or list the existing profiles (more features to be added as time goes by). In order to make the whole thing interoperable with other projects building on top of the Go package, it also uses the user's account data on the user's Matrix homeserver to store profiles.
neo v4: iris
F0x has recommenced development on the Matrix client Neo:
After discussion following https://cyberia.social/@foks/101785513826000032 I've resumed development on Neo. Suggestions are very much welcomed on the pad and mastodon thread I'm implementing components one by one now, with just mocked events. Actual Matrix integration will come when the gui components are ready.
Neo is now partly integrated with matrix-js-sdk because I grew tired of having to write my own mock events. There's a basic authentication flow, with 0 error handling, and parsing of m.text and m.image events
mautrix-telegram 0.5.0 was released after I finally fixed the bug that was causing the bridge database to lock up. It turned out to be a single line of ORM usage that I had missed while converting everything to use SQLAlchemy Core.
The full release notes are at https://github.com/tulir/mautrix-telegram/releases/tag/v0.5.0.
I also released v0.5.1 to fix a bug that made the DBMS migration script not work and Python 3.5 compatibility. I wouldn't recommend using Python 3.5 though, I'm going to drop support for it some time after Debian 10 is released
Shevski mentions Matrix on BBC Radio 4
Shevski from the #redecentralize organisation was interviewed on Radio 4, and mentioned Matrix:
I love that you've got Amazon with their Alexa messaging, Apple in their own bubble with iMessage, Facebook doing chat 3-ways and Google trying 50 ways to do chat. And that's before you even get into things like Slack, Discord, Telegram, Riot, Line, WeChat etc etc. And then the current hot way to chat is in a document...
I mean, how much money is being invested in trying to create the perfect chat solution?
For the record, we were chatting over Matrix…
That's all I know
That's the news, if you have something to say, or something to add, then you should go to #twim:matrix.org and share it. If you have other projects to discuss, come share them. If you'd prefer to come quietly, my door is always open: @benpa:matrix.org.
Folks, as you know we are now very close to achieving Matrix 1.0 and finally being in a position to shed our ‘beta' tag. It has been a long time coming and speaks to the huge effort from hundreds of people over the past 5 years.
A critical step towards this goal is the release of Synapse 1.0. We want to ship Synapse 1.0 as soon as possible but can't do so without your help!
We'd like to introduce AreWeReadyYet.com - a quick and easy way for everyone to track the progress and check if their federation is ready for Matrix 1.0!!
Synapse 1.0 is good news for anyone running a Synapse installation - it contains critical bug fixes, security patches, a new room algorithm version and dramatically improved user and room search. However, as part of the security work it also
contains a breaking change from previous Synapse versions. From 1.0 onwards it will necessary to ensure a valid TLS certificate on the federation API. Self signed certificates will no longer be accepted. Why would we do such a thing?
In anticipation for this, everyone currently running a homeserver must ensure that they have checked their federation certificate (check yours here). Failure to do so will mean being unable to federate with any Matrix 1.0 compliant server. If your server fails the check, our FAQ has all the details on what you need to do.
This post is a call to arms to try and get as many admins to upgrade their certificates as possible. We are tracking adoption at https://arewereadyyet.com - currently this sits at about 55% - we need this figure to be higher before we can pull the lever.
So what are you waiting for? Check that your server has valid certs - then tell all your admin pals to do the same.
Friends don't let friends miss out on Synapse 1.0, send them to arewereadyyet.com (or tweet here to remind them!) We really need the community to help us here because at some point soon, we will need to pull the lever and release.
Once we make more progress on adoption, we will announce an official release date and finally get Synapse out of beta!
This week you're stuck with me, but I'm chatting to Ryan, who works on Riot web. Having previously worked at Mozilla, Ryan has a LOT of interesting things to say about Firefox, the browser market, the importance of decentralisation, Matrix being GREAT, and more.
It's all about 1.0 for the Synapse gang this week. This means performance improvements across the board in the form of read receipt batching, user directory (room directory coming soon!) and rate limiting on log in and registration APIs.
Brendan shipped the low bandwidth CoAP proxy we demo'd at FOSDEM
As well as a bunch of spec implementation projects to ensure that Synapse (and Sydent) are ready for Synapse 1.0.
Synapse workers projects
Turn-of-phrase of the week from Half-Shot ("make it more performant and less crashy"):
synapse-netcore-workers is progressing as strongly as ever. This week has mainly been supporting a couple of users trying to use the fed sender, and also trying to make it more performant and less crashy. I've been using it solidly for two weeks now, and by and large it's been working nicely :)
Black Hat has been working on Cortex, a similar project in Rust:
Support for replication protocol in Cortex is mostly complete. A federation sender worker implementation is being worked on. If anyone is interested or wants to contribute, please go to #cortex:encom.eu.org
Construct
Lots of progress this week. I'd like to give a special thanks to Yan Minari for another great week of testing, bugfixes and feature requests.
We implemented features related to room directory lists, reporting content, ignoring users, VoIP turnServer, prev_content in state events.
Improving SSL: allowing configurable lists of ciphers, and sending/receiving SNI.
At the lower level: adding support for Linux AIO features that are present in newer kernels, giving a nice performance boost.
Wilko announced Pattle, a Matrix client for Android:
Hey all, I've been working on my Matrix Android app, Pattle! The goal of Pattle is to be an easy to use app for Matrix, with it's design inspired by popular apps such as WhatsApp and Telegram. Development happens here, and contributions are encouraged! The app is not currently suited for daily use, but some functionality is there, such as registering, logging in and viewing chats.
Currently it's an Android only app using the official Matrix Android SDK, but the plan is to support iOS and web too, in the future.
There's also a sort of design document available, stating how Pattle differs from standard Matrix apps and what it's goals are. The intent of the design document is to make development easier later on for other platforms
Quaternion 0.0.9.4 beta 2 (too many numbers? That too shall pass) is out, with bugfixes and translation updates. Notably, Quaternion won't crash on upgraded rooms in some cases, and won't cry in #gsoc:matrix.org and other v3 rooms. Translators are still strongly encouraged to push forward - due to all the features and fixes, there are many untranslated strings across the board! Also, some bugfixes are still in order before we can call the release RC, and some of them are really easy - so if you'd like to contribute, it's a great time to start!
Riot Web
Preparing for 1.0.4 release with lots of small polish fixes
Planning our roadmap for the next few quarters
Riot iOS
iOS released 2 times. Last release was to fix an issue with invalid scalar token.
Review of one PR from the community for iOS10 notifications.
Started implementing device verification with emoji.
Riot Android
We've released v0.8.25 on Thursday, containing refresh of invalid scalar token, and some bugfixes. Links on m.notice messages are now clickable again. Started implementing device verification with emoji.
RiotX (Android)
We started to setup build tools and CI configuration.
I just realized that I haven't had lazy loading activated by default in the Ruby SDK, despite having had lazy loading code in place since ages back, so now that's going to be the default value going forward.
Further:
I started hacking - just a couple of hours or so ago - on a notification sender for The Foreman, a server orchestration system. So it can forward notifications to Matrix. https://github.com/ananace/foreman_notification_send
If you're using, or considering using, The Foreman for orchestration this may be very useful.
matrix-appservice-bridge got a 1.8.0 release last night, featuring automatic handling of room upgrades for all your room upgrade needs. Providing your bridge uses the RoomStore as designed, it's literally a few lines to enable :). Changelog here
What is this? A matrix-appservice-irc release? No, it's a release candidate. Announcing that 0.12.0-rc1 is now out and about for folks to play with. More IRC updates to come in the future :)
I wrote a small bot that takes a kick/ban policy from room state from all rooms it's a member of and tries to enact that policy. In practice that means it applies a regex to all MXIDs and tries to kick/ban them based on that. It's been a request of TravisR , source code is available at https://gitlab.com/jcgruenhage/banhammer, documentation is still lacking but will hopefully soon be added
matrix-wug support for Navajo script
Continuing his theme of Native American languages, Dandellion added Navajo script to matrix-wug.
FreedomBox Tutorial: Setting Up a Chat Server with Matrix and Riot
It's been possible for some time to set up a Matrix server with FreedomBox, and they just recently released a video tutorial showing the process.
Around the Internets
There were a whole lot of outages for the big names this week - good time to think about self-hosting?
That's all I know
So that's all I have to say! I hope you enjoyed this edition of This Week in Matrix, and whether you did or you didn't, I'd love too hear from you in #twim:matrix.org. If you have Matrix news to share, that's the place to come and do so!
Last month at FOSDEM 2019 we gave a talk about a new experimental ultra-low-bandwidth transport for Matrix which swaps our baseline HTTPS+JSON transport for a custom one built on CoAP+CBOR+Noise+Flate+UDP. (CoAP is the RPC protocol; CBOR is the encoding; Noise powers the transport layer encryption; Flate compresses everything uses predefined compression maps).
The challenge here was to see if we could demonstrate Matrix working usably over networks running at around 100 bits per second of throughput (where it'd take 2 minutes to send a typical 1500 byte ethernet packet!!) and very high latencies. You can see the original FOSDEM talk below, or check out the slides here.
Now, it's taken us a little while to find time to tidy up the stuff we demo'd in the talk to be (relatively) suitable for public consumption, but we're happy to finally release the four projects which powered the demo:
https://github.com/matrix-org/meshsim - meshsim is the network simulator which provides an interactive web interface to draw a network topology and let you spin up dockerized homeservers on a simulated network with whatever preferred latency, jitter, packet loss etc.
https://github.com/matrix-org/coap-proxy - coap-proxy is the golang proxy which converts HTTPS+JSON into CoAP+CBOR+Noise+Flate and vice versa, letting you squish Matrix CS API and SS API traffic in & out of CoAP.
In order to get up and running, the meshsim README has all the details.
It's important to understand that this is very much a proof of concept, and shouldn't be used in production yet, and almost certainly has some glaring bugs. In fact, it currently assumes you are running on a trusted private network rather than the public Matrix network in order to get away with some of the bandwidth optimisations performed - see coap-proxy's Limitations section for details. Particularly, please note that the encryption is homemade and not audited or fully reviewed or tested yet. Also, we've released the code for the low-bandwidth transport, but we haven't released the "fan-out routing" implementation for Synapse as it needs a rethink to be applicable to the public Matrix network. You'll also want to run Riot/Web in low-bandwidth mode if you really wind down the bandwidth (suppressing avatars, read receipts, typing notifs and presence to avoid wasting precious bandwidth).
We also don't have an MSC for the CoAP-based transport yet, mainly due to lack of time whilst wanting to ensure the limitations are addressed first before we propose it as a formal alternative Matrix transport. (We also first need to define negotiation mechanisms for entirely alternative CS & SS transports!). However, the quick overview is:
JSON is converted directly into CBOR (with a few substitutions made to shrink common patterns down)
HTTP is converted directly into CoAP (mapping the verbose API endpoints down to single-byte endpoints)
TLS is swapped out for Noise Pipes (XX + IK noise handshakes). This gives us 1RTT setup (XX) for the first connection to a host, and 0RTT (IK) for all subsequent connections, and provides trust-on-first-use semantics when connecting to a server. You can see the Noise state machine we maintain in go-coap's noise.go.
The CoAP headers are hoisted up above the Noise payload, letting us use them for framing the noise pipes without having duplicated framing headers at the CoAP & Noise layers. We also frame the Noise handshake packets as CoAP with custom message types (250, 251 and 252). We might be better off using OSCORE for this, however, rather than hand-wrapping a custom encrypted transport...
The CoAP payload is compressed via Flate using preshared compression tables derived from compressing large chunks of representative Matrix traffic. This could be significantly improved in future with streaming compression and dynamic tables (albeit seeded from a common set of tables).
The end result is that you end up taking about 90 bytes (including ethernet headers!) to send a typical Matrix message (and about 70 bytes to receive the acknowledgement). This breaks down as as:
14 bytes of Ethernet headers
20 bytes of IP headers
8 bytes of UDP headers
16 bytes of Noise AEAD
6 bytes of CoAP headers
~26 bytes of compressed and encrypted CBOR
The Noise handshake on connection setup would take an additional 128 bytes (4x 32 byte Curve25519 DH values), either spread over 1RTT for initial setup or 0RTT for subsequent setups.
At 100bps, 90 bytes takes 90*8/100 = 7.2s to send... which is just about usable in an extreme life and death situation where you can only get 100bps of connectivity (e.g. someone at the bottom of a ravine trying to trickle data over one bar of GPRS to the emergency services). In practice, on a custom network, you could ditch the Ethernet and UDP/IP headers if on a point-to-point link for CS API, and ditch the encryption if the network physical layer was trusted - at which point we're talking ~32 bytes per request (2.5s to send at 100bps). Then, there's still a whole wave of additional work that could be investigated, including...
Smarter streaming compression (so that if a user says 'Hello?' three times in a row, the 2nd and 3rd messages are just references to the first pattern)
Hoisting Matrix transaction IDs up to the CoAP layer (reusing the CoAP msgId+token rather than passing around new Matrix transaction IDs, at the expense of requiring one Matrix txn per request)
Switching to CoAP OBSERVE for receiving data from the server (currently we long-poll /sync to receive data)
Switching access_tokens for PSKs or similar
...all of which could shrink the payload down even further. That said, even in its current state, it's a massive improvement - roughly ~65x better than the equivalent HTTPS+JSON traffic.
In practice, further work on low-bandwidth Matrix is dependent on finding a sponsor who's willing to fund the team to focus on this, as otherwise it's hard to justify spending time here in addition to all the less exotic business-as-usual Matrix work that we need to keep the core of Matrix evolving (finishing 1.0, finishing E2E encryption, speeding up Synapse, finishing Dendrite, rewriting Riot/Android etc). However, the benefits here should be pretty obvious: massively reduced bandwidth and battery-life; resilience to catastrophic network conditions; faster sync times; and even a protocol suitable for push notifications (Matrix as e2e encrypted, decentralised, push!). If you're interested in supporting this work, please contact support at matrix.org.
Folks, in the run up to Synapse 1.0, if you are running your own homeserver now would be an excellent time to check that your TLS certificates are up to date. Point your server name at https://matrix.org/federationtester/ and if there are errors check our handy FAQ on how to fix it. If you do not have valid TLS certificates Synapse 1.0 will refuse to federate with you.
benpa has put together a federation checker to quantify how many homeservers are 1.0 ready - https://www.arewereadyyet.com/ - It currently stands at 50.5% let's try and get that to 60% over the weekend.
Aside from all that, the team have been working on preparing for Synapse 1.0, you can track our progress here. We promise not to just land 1.0 out of the blue - we'll give everyone a 2 week warning to give stragglers a chance to get their certificates in order.
And this week we have Neil and Erik talking about this in more detail on Matrix Live
JeonServer and related project updates
ma1uta has been working on Jeon - Java interfaces to the various Matrix APIs - and is now getting ready to start work on a homeserver. He was previously asking for a name for this project, but might now have settled on "JeonServer".
First Release Candidate of the Jeon Project with upcoming Client-Server API 0.5, Server-Server API 0.1.1, Application API 0.1, Identity API 0.2 and Push API 0.1.
Also the RC of the jmsdk has been prepared with Java Matrix Client for Client-Server API 0.5.
Changes in the C2S: Added the m.push_rules event, removed presence list methods and other minor fixes.
Added S2S API of the 0.1.1 version.
I prepared a very simple page https://ma1uta.github.io/ with links to the swagger schemas (json and yaml) for all Matrix API which generated from the Jeon code.
There's a lot of progress, a few endpoints and features have been implemented this week such as Room Tags and all of the spec features for /createRoom. Most of the progress has been with testing and bugfixes thanks to Yan Minari, and tulir and mujx.
We've fixed several interactions with synapse such as invite accept/deny and synapse's ability to join and leave construct created rooms without any issues.
Lastly and most important, we've generated an official issues list thanks again to our star tester Yan Minari available here https://github.com/matrix-construct/construct/issues
pztrn has created a new mechanism for relaying apps that use Slack webhooks into Matrix:
To everyone who wonders how to connect his application to Matrix (at least for notifications of some kind) - use OpenSAPS! It just reached v0.1.0. OpenSAPS stands for Open Slack API Server and able to retransmit messages from applications (like Gitlab or everything that can send data to Slack) to somewhere else. Right now these "somewhere else" is a Telegram (with HTTP proxy support) and Matrix! Written in Golang to ensure minimal memory footprint. Take a look at https://gitlab.com/pztrn/opensaps Tested with Gitlab and Gitea but should work with almost any service. Join #opensaps:pztrn.name to talk with developers or get help. BTW, there is OpenSAPS instance in our room that transmits everything from gitlab.com into room! (almost) immediately after 0.1.0 comes 0.1.1, with fixed URLs parsing and fixed inability to login into servers which use .well-known for delegation. It should work [with other webhooks]. If something strange happens there is also a possibility to write own parser to make everything work :)‚ Tested with Gitlab and Gitea ATM. Share application names that work, I'll start to make a list of them. :D
matrix-puppet-bridge: matrix-puppet-slack and matrix-puppet-hangouts updates
Minivector, a minimalistic fork of riot-android had a new release last week, getting rid of a few more unused dependencies. This brings the final apk size down to 13mb vs riot android's 25mb. This work was done by @hrjet:matrix.org. The project room is here: #miniVectorAndroid:matrix.org
matrix-docker-ansible-deploy, now with Discord and email templates
The volume of discussion about installing/configuring Synapse and other Matrix-related components is like a subculture in itself. Standing tall within this is Slavi's matrix-docker-ansible-deploy collection of Ansible playbooks. They're a great way to quickly and reliably get a Synapse instance running.
between chasing bugs in Quaternion 0.0.9.4 beta (translators, your help is hugely needed to catch up with new and updated strings) there happens almost literal bikeshedding in #qmatrixclient:matrix.org, under an excuse of discussing The Universal Algorithm to Colour Usernames. Join the fun!
Bifrost is now starting to comfortably support gatewaying. For those that don't know, gateways allow a remote user to participate in the matrix network without prior bridging, it's very fancy. The latest changes are that XMPP clients can now ask for the public room list by querying the bridge component. There is a video on this using the Yaxim XMPP client on Android (Credit to Ge0rG). Come chat with us in #bifrost:half-shot.uk
You can check out the video of the bridge in operation here:
Spectral development now continues after a short break. The new "material design" has been merged into master, along with a few bug fixes. I plan to work on Kirigami port in the following two weeks.
I made a room for !pinging echo maubots: #ping:maunium.net. The room has a bunch of echo bots, currently on maunium.net, c.mau.dev and matrix.vgorcum.com. It also has a new maubot plugin called pingstat, which collects the pong data and makes a leaderboard website. The website is linked to the room as a widget.
Not much news to report on the netcore-workers other than it's maturing and we have nice things now like logging, metrics and a docker image you can run at home. I'm running the federation sender fulltime on half-shot.uk to dogfood it and will announce when I think it's good for general consumption :)
Related: Black Hat is investigating a similar project in Rust. Anyone interested in that please do go chat, and take a look at the repo they've created.
matrix-wug, IPA rendering bot, gets support for cherokee
This is "script" or written language has a very interesting story behind it, where the creator of it actually couldn't read and write. Regardless, he wanted to write down his language, and developed his own writing system. The characters look a lot like latin characters because he tried to imitate the characters of a bible. Just a fun history lesson!
since weechat-matrix is a bit involved to install, I create a dockerfile that takes care of it: https://github.com/poljar/weechat-matrix/pull/60 . And people allergic to docker can look inside to check the steps (just reading the readme doesn't give a full picture)
modular.im
Modular.im is a Matrix-as-a-SaaS offering. It's suitable for users who want the benefits of having their own Matrix homeserver, but don't want to host and run one.
There are some new announcements this week:
Today we are pleased to announce that you can now customise your Modular hosted Riot at the touch of a button, through the Modular host admin interface. Better yet, this is available to all Modular customers at no additional cost. Today we are also launching a proof of concept for purchasing additional content via the Modular integration manager. For the initial experiment we're offering a set of "snazzy", limited edition Matrix stickers for the princely sum of $0.50. These are digital versions of the Matrix and Riot hexagons that some of you may have seen in real life.
Still more!
decred.org are an organisation concerned with blockchain technology, and they also use Matrix for their communications! They now have a stickerpack available in Riot, so if you'd like to use their stickers you can add the pack and get going with blockchain-related memes.
If you have a stickerpack you'd like to see included, please let me know.
I've made a room for anyone interested in drums and percussion. Acoustic, Electronic, Played or Programmed, anything goes as long as it's rhytm related. The room is focused on both playing/programming drums and equipment.
There was a somewhat longstanding bug that affected a number of users: often manifesting as unexpected and frustrating "Unable to decrypt" messages - this has now been fixed, take a look at https://github.com/vector-im/riot-web/issues/6838
They think it's all over...
It is now! If you'd like to have your project included in this post, come chat to us in #twim:matrix.org!
Heads up that Modular.im (the paid hosting Matrix service provided by New Vector, the company who employs much of the Matrix core team) launched a pilot today for paid Matrix integrations in the form of paid sticker packs. Yes kids, it's true - for only $0.50 you can slap Matrix and Riot hex stickers all over your chatrooms. It's a toy example to test the payments infrastructure and demonstrate the concept - the proceeds go towards funding development work on Matrix.org :)
You can read more about over on Modular's blog.
We wanted to elaborate on this a bit from the Matrix.org perspective, specifically:
We are categorically not baking payments or financial incentives as a first class citizen into Matrix, and we're not going to start moving stuff behind paywalls or similar.
This demo is a proof-of-concept to illustrate how folks could do this sort of thing in general in Matrix - it's not a serious product in and of itself.
What it shows is that an Integration Manager like Modular can be used as a way to charge for services in Matrix - whether that's digital content within an integration, or bots/bridges/etc.
While Modular today gathers payments via credit-card (Stripe), it could certainly support other mechanisms (e.g. cryptocurrencies) in future.
The idea in future is for Modular to provide this as a mechanism that anyone can use to charge for content on Matrix - e.g. if you have your own sticker pack and want to sell it to people, you'll be able to upload it and charge people for it.
Meanwhile, there's a lot of interesting stuff on the horizon with integration managers in general - see MSC1236 and an upcoming MSC from TravisR (based around https://github.com/matrix-org/matrix-doc/issues/1286) proposing new integration capabilities. We're also hoping to implement inline widgets soon (e.g. chatbot buttons for voting and other semantic behaviour) which should make widgets even more interesting!
So, feel free to go stick some hex stickers on your rooms if you like and help test this out. In future there should be more useful things available :)
