Matrix merch is some of the most sought-after apparel and adhesive labeling available in the world today. We supply discerning customers with t-shirts, hoodies and stickers which remind them which decentralised, federated, end-to-end encrypted communications protocol is the best choice.
This is all very well, but we wondered whether it would be possible to have a warm, hooded garment which promotes the wearers preference of chat system, and also has a zip on the front.
Today, we’re proud to announce a breakthrough in this area: Matrix Zipped Hoodies are available now from shop.matrix.org!
This week we put out Synapse 1.6.0, and 1.6.1 checkout all the juicy details in the blog post. Aside from that message retention and ephemeral message support continues and we expect the latter to merge early next week.
The next big thing we’ll be looking at is sharding out the Synapse master process so that instances running in worker mode can make full use of the CPU power available. This will make a big difference to matrix.org.
Several packaging projects have been updated to deploy the new version
Synapse 1.6.1 has been packaged for VoidLinux, FreeBSD and Alpine Linux, with NixOS waiting to have the PR updating it to 1.6.1 merged. Synapse 1.6.0 has been packaged for Debian Unstable and Ubuntu 20.04.
Timothée has been working on a university project to integrate the Yggdrasil library into the CoAP proxy, which allows Matrix homeservers to federate over a pure Yggdrasil connection instead of using IP. The Yggdrasil portion gives full reachability and traffic forwarding between nodes in the mesh even in complicated topologies, and end-to-end encryption as an additional benefit
As a reminder,
Yggdrasil is a proof-of-concept mesh network that is designed to avoid the scaling issues that we've seen in the past with existing mesh systems. It uses a spanning tree-based topology and aims to make all nodes in the mesh fully routable, even at massive scale
New Vector (the startup which the original Matrix team founded in order to hire folks to work on Matrix as their day job) are currently hiring people so if you ever wanted to work on Matrix full time get in touch.
You can read all about it here but we are particularly keen to speak to people who want to hack on Synapse or work in Operations.
We are remote friendly though find it easier to hire people in some territories than others, so if you have any questions just ask.
My fellow comrades, today we have released 0.14.0-rc1 of the IRC bridge. The changes are massive and vast, and frankly it probably could have been done in 2 or 3 releases. At any rate, this release contains support for PostgreSQL Datastores and Sentry monitoring, amongst other small quality of life changes. The bridge has also had a total refactor using Typescript, and it's a little bit nicer to look at now.
I spent the last few days building my Matrix client Nio 😄 Apple just approved a very early first alpha for TestFlight distribution. It really doesn't do a lot aside from account authentication and displaying recent chats and messages. It is able to handle e2e encryption, but unfortunately doesn't persist the encryption keys right now (meaning it loses them and re-requests them from other clients on being restarted). It's built on SwiftUI and runs on iOS (iPhone and iPad). The app will likely not run as-is on macOS in the future, but I'd love to also build a separate version of Nio for macOS once the iOS app is functional.
Continuum, desktop client based on koma, version 0.9.31:
Implement minimal XML parsing without adding additional dependencies to extract user ID and name from formatted_body used by Riot
Display mentioned users with highlight and avatar.
Synapse 1.6.0 has landed and is here to brighten your day!
1.6.0's most notable feature is that of label based filtering. It allows for messages to be tagged with a given label so that clients can filter on the label, this means that clients can subscribe to specific topics in a room, such as #lunch.
Completely separately, from here on in new rooms will be version 5 by default, all this means in practice is that servers will respect server signing key validity periods. This won't make a lot of difference in day to day operation, but it is an important security consideration and we now have sufficient penetration across the federation to make version 5 the default.
Aside from that there are a bunch of bug fixes and improvements, including fixing a bug that in some cases prevented messages being decrypted shortly after a restart (#6363) and generally improving the room upgrade experience (#6232, #6235).
Those following closely will know that the matrix.org home server has been having some problems with our hosting provider. This really came down to I/O provision and stability therein. It turns out that running a homeserver is harder when it can’t talk to the db.
We have now fully migrated to our new provider (with improved hardware specs) and you should notice everything feeling much much snappier.
I have been dismantling my habitat in Japan and will spend a couple of weeks in Moscow, Russia before moving further west to the Netherlands. Due to this, expect very low activity on Quotient front in December; but I still intend to release the first beta of libQuotient 0.6 in the remaining week, breaking the half-year span without releases.
This week released Synapse v1.6.0rc1 and will release the real deal next week. 1.6.0 contains a lot of ground work for e2ee cross signing, supporting multiple databases (to aid db sharing) as well as a bunch of bug fixes and perf improvements.
Aside from that we’ve been working on room retention support and ephemeral messages which should be ready to merge rsn.
Finally we’ve been working on improving config granularity for caching, such that individual caches can be configured via homeserver.yaml. Experimenting with this approach to caching has proved to be very powerful in tuning performance, expect to see it on mainline shortly. Further down the line we'd like to make it more dynamic so that manual tuning is unnecessary.
Facebook decided to break everything and switch from long polling to MQTT over websockets, but mautrix-facebook has already been updated with initial support for the new protocol. It's still a bit buggy though, e.g. reconnecting after a disconnection doesn't seem to work properly
We are almost done in our privacy work around integrations and integrations manager. While we were working on widgets, we made some improvements on them. They now have a menu with some actions (refresh, open in Browser, remove). The jitsi widget now displays the room name, user avatar and name.
The PR for matrix-react-sdk has finally landed, the PR for riot-web needed some documentation and is waiting for final review. Work on the UI for our indexer inside of riot has started and some more functionality to load events that are files has been added inside of Seshat as well.
Fixed some wonderful spelling errors in the algorithm code
Nothing has changed for the main Matrix Notepad repo, so there's no user difference. It just makes the core algorithm a bit easier to read.
My plan in the future is basically to work out rich text and JSON object collaboration (clearly, this is far away!) and create some kind of "universal client" that can load up web apps to use the algorithm in a single Matrix room. The result would be that it's much easier to create collaboration apps.
Obviously, that's a far-off goal, but my point in documenting the algo is to get ahead of the game a bit
mautrix-whatsapp now has basic relaybot support. Since WhatsApp doesn't have usable bots, relaybot in this case means using a normal account as a relay. To enable the relaybot in your bridge instance, copy this config block into your config, update is as needed, and simply log in normally in the configured relaybot management room.
RiotX: We are working on registration and login flow. Also spoiler are rendered and can even be sent using /spoiler command. It's also possible to block (ignore) and unblock users. Performance have been improved, and we are now using the new FragmentFactory. We are working on room detail screen, sticker rendering, and lots of other fun features. We schedule a release at the beginning of next week.
v0.4.0-beta.15 of the matrix-bot-sdk has been released. v0.4.0 final is a themed release for lightweight bridges, and so far much of the common functionality is there. Some of the more niche and large features have yet to land, but the final release is still on the horizon (see what's left here). Please give it a test (npm install [email protected]) and report any issues to #matrix-bot-sdk:t2bot.io.
Seshat got a new release 🎉. Seshat now supports transparent index encryption. The PRs for Riot-desktop have been updated and encryption has been enabled for the index. The PRs are currently awaiting review, encrypted search will come to a place near you really soon™.
Dept of Ops 🛠
New guide about installing Synapse using only free resources
Room Directory defaults in matrix-docker-ansible-deploy
Regarding the recent discussions about room security, Slavi has been thinking about default settings for his ansible playbooks:
I wasn't entirely convinced what we should do about it.
For my own personal (family & friends) homeserver, I have a few rooms published (this room being one of them), which are all public and OK to be published publicly.
I was okay with the old defaults.
Still, I can see how people may expect stricter defaults though.
I've leaned on following this advice and making it not publish by default.
I've made that change here.
Matrix-Alertmanager, a bot that relays Prometheus Alertmanager alerts to Matrix rooms, gets a new release v0.1.0. Thanks to "daniego" the messages are now HTML formatted. Also dependencies have been bumped, Matrix JS SDK by "Lyr" and all the other deps by me. For more info: https://git.feneas.org/jaywink/matrix-alertmanager
I've made a presentation about Matrix at the local 2600 meetup at Saint Petersburg, Russia recently. And now translated the text retelling into English too. It's an introduction presentation in general but (thanks to kitsune! :) it also contains good comments about the parts I've missed :) Would be happy to get feedback about the typos/etc. I hope it could be helpful to somebody who is willing to tell about Matrix in other local places :)
Not a part of the organizers, but syncing here for wider reach. There is a "FediConf 2020" conference being planned to happen in Barcelona sometime between May and September next year. It will be a conference for a wide audience of federated folk, so Matrix people might be interested in joining up. There is a poll for dates, a forum and also a Matrix room: #fediconf:matrix.libertalia.world
in a complete coincidence with aa13q, I also talked about Matrix at Tokyo LUG. Plenty of good discussion. TLUG folks are extremely interested in decentralised identities and data retention as next most important frontiers in Matrix evolution.
Over the course of today we've been made aware of folks port-scanning the
general internet to discover private Matrix servers, looking for publicly
visible room directories, and then trying to join rooms listed in them.
If you are running a Matrix server that is intended to be private, you must correctly
configure your server to not expose its public room list to the general public -
and also ensure that any sensitive rooms are invite-only (especially if the
server is federated with the public Matrix network).
In Synapse, this means ensuring that the following options are set correctly in
# If set to 'false', requires authentication to access the server's public rooms
# directory through the client API. Defaults to 'true'.
# If set to 'false', forbids any other homeserver to fetch the server's public
# rooms directory via federation. Defaults to 'true'.
For private servers, you will almost certainly want to explicitly set these to
false, meaning that the server's "public" room directory is hidden from the
general internet and wider Matrix network.
You can test whether your room directory is visible to arbitrary Matrix clients
on the general internet by viewing a URL like
https://sandbox.modular.im/_matrix/client/r0/publicRooms (but for your server).
If it gives a "Missing access token" error, you are okay.
You can test whether your room directory is visible to arbitrary Matrix servers
on the general internet by loading Riot (or similar) on another server, and
entering the target server's domain name into the room directory's server
selection box. If you can't see any rooms, then are okay.
Relatedly, please ensure that any sensitive rooms are set to be "invite only"
and room history is not world visible - particularly if your server is
federated, or if it has public registration enabled. This stops random
members of the public peeking into them (let alone joining them).
Relying on security-by-obscurity is a very bad idea: all it takes is for someone
to scan the whole internet for Matrix servers, and then trying to join (say)
#finance on each discovered domain (either by signing up on that
server or by trying to join over federation) to cause problems.
Finally, if you don't want the general public reading your room directory,
please also remember to turn off public registration on your homeserver.
Otherwise even with the changes above, if randoms can sign up on your server
to view & join rooms then all bets are off.
We'll be rethinking the security model of room directories in future (e.g.
whether to default them to being only visible to registered users on the local
server, or whether to replace per-server directories with per-community
directories with finer grained access control, etc) - but until this is sorted,
please heed this advice.
If you have concerns about randoms having managed to discover or join rooms
which should have been private, please contact [email protected].
If you've been waiting all this time to start implementing some of the privacy improvements the team has been making over the last few months, now's the best time to do it. Clients interacting with identity servers or 3rd party identifiers (3PIDs) have some changes to make, and identity servers themselves have a whole new authed API so they can expose terms of service requirements to users.
0.10.1 has been released on the app store. It includes minor improvements and bug fixes like the call issue. Full release descriptions can be found on respective repos: Riot, matrix-ios-kit and matrix-ios-sdk.
This release includes better logging to track app kills in background but it seems that iOS13.2.2 released by Apple yesterday fixes the issue. We are looking for more feedbacks on that topic.
On develop, the app can now use the integrations manager advertised by the homeserver.
We have finished implementing long click on a Room item, to configure notification settings of the room and to be able to leave the room. We can now ignore user (after a report of content only for the moment). The list of ignored users is displayed in the setting. Users can be un-ignored. We are also working on improving performance and improving code structure. As usual, we have also fixed some bugs. A release will be done at the beginning of next week, then we will try to work on the login flow and account creation flow.
The Riot gang landed 1.5.1 which contained the emoji picker (thanks Tulir!).
Additionally they have been working furiously to make some progress against e2ee device cross signing and have just merged the ability to authenticate via DMs. It's behind a labs flag and will only work if both parties are enabled, but this is big step towards our cross signing dreams. Watch this space for more cross signing features over the coming weeks.
I took time to port Quaternion from Qt Quick Controls 1 (deprecated upstream) to Qt Quick Controls 2, the lighter UI widgets kit that Spectral also uses. Most of regressions are fixed and the result is likely to land in the master branch sometime next week. The overall looks will remain the same, just a minor refresh of visuals. Aside from improving performance the porting should help to solve widget scaling issues on multi-monitor configurations.
Aside from that we’ve continued to work on sharding out the database which we’ll put live once we have migrated matrix.org onto new hardware (woo!) and finally we’ve been fixing some bugs affecting event auth rules.
Coming up on the horizon are ephemeral messages (the ability to send messages with a specific ttl), more io perf work and a bit further down the line we’ll dust off our attempts to shard out room processing from the master process, meaning Synapses running in worker mode will have much more CPU headroom.
another Synapse container image, but this one is new: If you had problems with LDAP in the official Synapse image, try this image: https://gitlab.com/famedly/container/synapse-ldap/container_registry. It's based on the official images, but updates the LDAP auth provider to the latest commit of the master branch. The official image comes with the latest version released to pypi.org, which is a bit older. Aside of that change, it's exactly the same, so you can use it as a drop in replacement.
Hey folks, I've released matrix-appservice-irc0.13.1 which fixes a critical bug in 0.13.0 where messages from matrix would crash the bridge. Users brave enough to be running develop do not need to do anything. https://github.com/matrix-org/matrix-appservice-irc/releases/tag/0.13.1. This would only have affected you if you tried to install or update the 0.13 bridge in the last two weeks.
For the last several months the team has been working on tightening up privacy in Matrix, and with the 1.4 release of Synapse and Riot quite a lot has been done in the area. One of the remaining pieces was to release all the specification changes to help other client/server implementations achieve the same goals, and now we've done that.
The Client-Server r0.6.0 and Identity Service r0.3.0 spec releases both cover the privacy improvements added through a number of MSCs in the last few months. Of particular note is that identity servers are now expected to support terms of service endpoints, which requires authentication that clients might need to worry about - check the spec changelogs for details.
The full changelog for the Client-Server r0.6.0 release is:
Add id_access_token as a required request parameter to a few
endpoints which require an id_server parameter as part of
Add POST /account/3pid/unbind for removing a 3PID from an identity
This morning (06:11 UTC) it became apparent through mails to [email protected] that a security researcher was working through the TLS Certificate Transparency logs for *.matrix.org,*.riot.im and *.modular.im to identify and try to access non-public services run by New Vector (the company formed by the original Matrix team, which hosts *.matrix.org on behalf of the Matrix.org Foundation, and develops Riot and runs the https://modular.im hosting service).
Certificate Transparency (CT) is a feature of the TLS ecosystem which lets you see which public certificates have been created and signed by given authorities - intended to help identify and mitigate against malicious certificates. This means that the DNS name of any host with a dedicated public TLS certificate (i.e. not using a wildcard certificate) is visible to the general public.
In practice, this revealed a handful of internal-facing services using dedicated public TLS certificates which were accessible to the general internet - some of which should have been locked to be accessible only from our internal network.
kibana.ap-southeast-1.k8s.i.modular.im - a Kibana deployment for a new experimental Modular cluster which is being set up in SE Asia. The Kibana is in the middle of being deployed, and was exposed without authentication during deployment due to a firewall & config error. However, it is not a production system and carries no production traffic or user data (it was just being used for experimentation for hypothetical geography-specific Modular deployments). We firewalled this off at 07:53 UTC, and are doing analysis to confirm there was no further compromise, and will then rebuild the cluster (having fixed the firewall config error from repeating).
AWX deployments used by our internal Modular platform, which were behind authentication but should not be exposed to the public net.
Various semi-internal dev and testing services which should be IP-locked to our internal network (but are all locked behind authentication too).
Additionally, certain historical Modular homeservers & Riots (from before we switched to using wildcard certs, or where we’ve created a custom LetsEncrypt certificate for the server) are named in the CT logs - thus leaking the server’s name (which is typically public anyway in that server’s matrix IDs if the server is federated).
We’re working through the services whose names were exposed checking for any other issues, but other than the non-production SE Asia Kibana instance we are not aware of problems resulting from this activity.
Meanwhile, we’ll be ensuring that semi-internal services are only exposed on our internal network in future, and that Modular server names are not exposed by CT logs where possible.
TL;DR: You can list all the public non-wildcard TLS certs for a given domain by looking somewhere like https://crt.sh/?q=%25.matrix.org. This lets you find internal-sounding services to try to attack. In practice no production services were compromised, and most of our internal services are correctly firewalled from the public internet. However, we’re reviewing the IP locking for ones in the grey zone (and preventing the bug which caused an experimental Kibana to be exposed without auth).
We’d like to thank Linda Lapinlampi for notifying us about this. We’d also like to remind everyone that we operate a Security Disclosure Policy (SDP) and Hall of Fame at https://matrix.org/security-disclosure-policy/ which is designed to protect innocent users from being hurt by security issues - everyone: please consider disclosing issues responsibly to us as per the SDP.
A couple of weeks ago I shouted here about a project I've been working on named Install Party, which provides tools for provisioning and managing servers for Matrix homeserver install workshops/parties.
Since then, I've been working on improving it, and today it's finally reached v1.0! This version includes configurable DNS and infrastructure providers, the ability to create multiple server in one run, user-defined post-install scripts, as well as codebase cleanups and a better documentation.
Parallelized file transfer: The bridge now has an option to use multiple telegram connections and a streaming connection to the Matrix media repo when copying files. This should make it much faster and use less ram for big files.
Matrix doesn't have native captions, so !tg caption <text> now exists to send the next image or file to telegram with <text> as the caption.
Animated sticker bridging and helm charts were merged into master.
Bridges-in-nodejs-fans, today we have released 0.4.1 of the matrix-appservice-node library. For those not aware (presumably most), this library is a barebones piece of kit that helps you to listen over the AS api for transactions, in a more barebones manner than matrix-appservice-bridge. The changes in this release are a total transformation of the library into Typescript, and updating dependency packages which had gotten out of date.
It's not as cool as it sounds. Basically you put all the titles and links in a config file and whenever someone says e.g "I really like S05E09", it'll give you the name of that episode and a link to it. You can also just mention an episode title and it'll give you the link.