martinkrafft presented about Matrix at wossat a New Zealand Open Source show and tell meetup. His talk can be seen here, and focuses on the benefits of Matrix for users.
Spec Proposals
As you may have seen from the previous blog post, we have a new drive to advance the Matrix Specification itself. Part of this is https://matrix.org/docs/spec/proposals, which lists all the spec change proposals we’ve accumulated so far, and describes the flow for getting new proposals merged. There is a new room, #matrix-spec:matrix.org for discussion, please join if you want to get involved in this process. Check out the page and the blog post for more detail.
Next up: try to turn some of the many WIP proposals into Spec PRs…
A major topic at the Hackfest was a discussion of splitting the Fractal client into two UIs for the different behaviours of messaging apps. For anyone interested in product design thinking this is a genuinely fascinating topic. I encourage you to read “Banquets and Barbecues”, Tobias’ excellent coverage of the latest thinking. The different chat personas are very well explained and the post brings up some of the immediate technical challenges too.
Projects and Products
mxisd v1.1 RC1 available
Max reports on mxisd, a Federated Matrix Identity server for self-hosted Matrix infrastructures:
mxisd v1.1 RC1 is out, addressing various privacy issues and being more GDPR-friendly overall. Testing and feedback from the community is very much appreciated
Dimension
Dimension, an open source integrations manager for matrix clients from TravisR, now supports sticker packs.
Ruma
Rust-based Ruma has new activity, starting with the release of ruma-api-macros 0.2.0. This moves ruma-api-macros from dependency on hyper to using types from the http crate. This will give more flexibility about library and framework choices for ruma-client-api and ruma-client.
Lots of excitement at the variety of independent clients and servers able to interact over the matrix protocol. The images above show The Construct (server) and gomuks (client), and then mxhsd and Fractal. A fundamental part of matrix is to be an open protocol, so it’s great to see entirely independent implementations liaising together! While implementing mxhsd, Max has been documenting spec omissions in a branch of the spec – we’re hoping he will contribute these back!
Honourable mention for mujx, who was sending messages with nheko and Ruma a year ago!
Matrix Core team expansion
Stève – 17th May (yesterday)
Amber – 21st (Monday)
Anoa – 21st (Monday)
Hubert – 28th May
Half-Shot – 4th June
…and one more community member, hopefully (just sorting paperwork currently!)
Heads up that we’re consciously trying to hire a mix of folks from the Matrix community as well as those outside it – and avoid hiring the whole community, both to ensure diversity of viewpoint & experience in the core team, and also to avoid cannibalising folks who working on their own commercial projects on top of Matrix. We’d prefer Matrix to be as decentralised and heterogenous as possible, needless to say – and instead try to support folks in building on Matrix without hiring them into the core team (where we’d expect them to focus on the core project for everyone’s benefit). This may change once we have Matrix set up as a separate foundation, once we’ve got out of beta, of course.
New Rooms
#matrix-spec:matrix.org is a new room dedicated to discussions on specific matrix spec proposals, as part of the process we’re building around contributing to the matrix spec.
It’s release time people, not to be outdone by our friends on the Riot web team, Synapse v0.29.1 lands today.
v0.29.1 contains an officially supported docker image (many thanks to the contribution from @kaiyou), continued progress towards Python 3 (thanks to @NotAFile) – as well as a heap of refactorings and bug fixes.
Something worth noting is a potentially breaking change in the error code that /login returns in the Client Server API. Details follow, but the change closes a gap between Synapse behaviour and the spec.
We’d like to give huge thanks to Silvio Fricke and Andreas Peters for writing and maintaining Synapse’s first Dockerfile, as well as allmende, jcgruenhage, ptman, and ilianaw for theirs! The new Dockerfile from kaiyou has ended up being merged into the main synapse tree and we’re going to try to maintain it going forwards, but folks should use whichever one they prefer.
Make Client-Server API return 401 for invalid token (PR #3161).This changes the Client-server spec to return a 401 error code instead of 403 when the access token is unrecognised. This is the behaviour required by the specification, but some clients may be relying on the old, incorrect behaviour.Thanks to @NotAFile for fixing this.
Features:
Add a Dockerfile for synapse (PR #2846) Thanks to @kaiyou!
Changes – General:
nuke-room-from-db.sh: added postgresql option and help (PR #2337) Thanks to @rubo77!
Part user from rooms on account deactivate (PR #3201)
Make ‘unexpected logging context’ into warnings (PR #3007)
We’ve been able to start investing more time in advancing the Matrix Specification itself over the last month or so thanks to Ben joining the core team (and should be able to accelerate even more with uhoreg joining in a few weeks!) The first step in the new wave of work has been to provide much better infrastructure for the process of actually evolving the spec – whether that’s from changes proposed by the core team or the wider Matrix Community.
So, without further ado, we’d like to introduce https://matrix.org/docs/spec/proposals – a dashboard for all the spec change proposals we’ve accumulated so far (ignoring most of the ones which have already been merged), as well as a clearer workflow for how everyone can help improve the Matrix spec itself. Part of this is introducing a formal numbering system – e.g. MSC1228 stands for Matrix Spec Change 1228 (where 1228 is the ID of the Github issue on the github.com/matrix-org/matrix-doc/issues repository that tracks the proposal).
Please note that these are *NOT* like XEPs or RFCs – i.e. optional proposals or add-ons to the protocol; instead they are literally proposals for changes to the Matrix Spec itself. Once merged into the spec, they are only of historical interest.
We’ve also created a new room: #matrix-spec:matrix.org to discuss specific spec proposal changes – please join if you want to track how proposals are evolving! (Conversation is likely to fork off into per-proposal rooms or overflow into #matrix-dev:matrix.org or #matrix-architecture:matrix.org depending on traffic levels, however).
Feedback would be much appreciated on this – so please head over to #matrix-spec:matrix.org and let us know how it feels and how it could do better.
This is also a major step towards properly formalising Matrix.org’s governance model – hopefully the changes above are sufficient to improve the health of the evolution of the Spec as we work towards an initial stable release later this year, and then you should expect to see a spec proposal for formal governance once we’ve (at last!) exited beta :)
Huge thanks to Ben for putting this together, and thanks to everyone who’s contributed so far to the spec – we’re looking forward to working through the backlog of proposals and turning them all into merged spec PRs!!
The talk of the town in Strasbourg this week was the arrival of Fractal Hackfest 2018! Event is still ongoing, and I’m sure they will provide a report of the progress on https://wiki.gnome.org/Hackfests/Fractal2018, though Alexandre kindly sent us a photo of the group in action
Home Assistants
Wonderful things are happening and being discovered regarding IoT and Home Automation. uhoreg was the first to point us to tinloaf’s project to build a Matrix Chatbot component for Home Assistant:
This component allows you to send messages to matrix rooms, as well as to react to messages in matrix rooms. Reacting to commands is accomplished by firing an event when one of the configured commands is triggered.
Enthusiasm for this work led to jfred discussing his past adventures in Matrix, including a component for sibyl, ‘a python chatbot with a focus on XBMC’ allowing Matrix communication.
All this excitement led to Cadair creating #homeautomation:cadair.com, which has started a more thorough discussion. I’m eager to see more non-chat applications of Matrix, #twim:matrix.org came up with others with projects in progress.
It’s worth noting that we feel that GDPR is an excellent piece of legislation from the perspective of forcing us to think more seriously about our privacy – it has forced us to re-prioritise all sorts of long-term deficiencies in Matrix (e.g. dependence on DNS; improving User Interactive authentication; improving logout semantics etc). There’s obviously a lot of work to be done here, but hopefully it should all be worth it!
TravisR on GDPR
TravisR has also been thinking about GDPR, and how it relates to his Voyager bot. In his words:
TWIM: I’ve mostly been working on figuring out how GDPR affects t2bot.io for the last couple weeks. One of the things running on t2bot.io is Voyager – a bot that tries to join rooms it sees mentioned in people’s messages, graphing them on https://voyager.t2bot.io. With the increase in talk about GDPR and more bots starting to wander the federation, the recurring topic of whether Voyager should change its approach to finding and listing rooms.
With the current approach, Voyager reads messages and tries to find room aliases to try and join. Individual people can opt-out of this tracking to stop Voyager from reading/parsing their messages (opting back in at a later time, if desired). The room moderators can kick or ban the bot to completely remove their room from the graph, and can invoke a ‘soft kick’ if they’d like to have their room remain listed, but don’t want the bot in the room. Voyager will make sure to only show information for public rooms and will update the graph if the room flips between public and private.
If anyone has feedback on how this approach could be improved (or if it should be left as-is), please come by #voyager:t2bot.io on matrix to start the conversation.
Translations
I was surprised and excited to learn that a Russian translation of the Matrix FAQ has been produced by a group of Russian-lanugage users. ma1uta reported:
There are a several Russian-speaking users spontaneously decided to unite and help Matrix. We created a room where translated FAQ using the embedded etherpad widget. Some of us are here: Magnolia and Fenneko is a Good Girl for example. Anybody can join to us #perevodators:matrix.org and helps. We accept any help.
Preview: https://ma1uta.github.io/index.html
They’ve provided a PR which I will presently merge (though of course, as I don’t speak Russian I will need to trust that it’s really a translation of the FAQ!)
Projects and Updates
Matrix Ruby SDK
Ananace reports that work has begun on a Matrix SDK for Ruby ‘with a design based heavily on the Python one‘. Doing a lot of sysadmin work, Ananace has been working a lot with Ruby, and also wants to get going using the SDK to write bots.
Public catalog for matrix rooms announced: matrixstats.org. The place where you can find a lot of rooms and sort them by ratings or categories. Presented rooms are collected from different homeservers; some of rooms have detailed statistics. The homeservers itself can be explored without the registration. The project is currently in beta stage, so some features may be missing. We would be glad to receive any feedback and ideas for further improvement. Additional info available at https://matrixstats.org/about, related discussions at #matrixstats:matrix.org.
Lots of work implementing chunking for DAGs to properly solve the depth vulnerability
Spec Proposals
Much-needed work has begun to classify and present the spec proposals for the Matrix specification. We’ve tagged up the all the issues in GitHub, new page will appear on matrix.org at the start of next week if I can just stop preening the generator.
Around the Web (and more)
Another week, another article on the front page of Hacker News. The author is focused more on Riot than Matrix, still it’s great knowing how much interest there is in the wild.
Happily, I was at an unrelated event in London earlier in the week, and had my first IRL experience meeting someone who already knew (and then enthused) about the project. Feels good.
Do you have a suggestion for this series? What could we be doing more of? I have a nascent plan to do ‘deeper’ conversations with people or projects that aren’t necessarily in the normal run of things, but are interesting uses of Matrix. Does this sound like something you’d want to read on a Friday afternoon? Drop a line in #twim:matrix.org or ping benpa.
As the May 25th deadline looms, we’ve had lots and lots of questions about how GDPR (the EU’s new General Data Protection Regulation legislation) applies to Matrix and to folks running Matrix servers – and so we’ve written this blog post to try to spell out what we’re doing as part of maintaining the Matrix.org server (and bridges and hosted integrations etc), in case it helps folks running their own servers.
The main controversial point is how to handle Article 17 of the GDPR: ‘Right to Erasure’ (aka Right to be Forgotten). The question is particularly interesting for Matrix, because as a relatively new protocol with somewhat distinctive semantics it’s not always clear how the rules apply – and there’s no case law to seek inspiration from.
The key question boils down to whether Matrix should be considered more like email (where people would be horrified if senders could erase their messages from your mail spool), or should it be considered more like Facebook (where people would be horrified if their posts were visible anywhere after they avail themselves of their right to erasure).
Solving this requires making a judgement call, which we’ve approached from two directions: firstly, considering what the spirit of the GDPR is actually trying to achieve (in terms of empowering users to control their data and have the right to be forgotten if they regret saying something in a public setting) – and secondly, considering the concrete legal obligations which exist.
The conclusion we’ve ended up with is to (obviously) prioritise that Matrix can support all the core concrete legal obligations that GDPR imposes on it – whilst also having a detailed plan for the full ‘spirit of the GDPR’ where the legal obligations are ambiguous. The idea is to get as much of the longer term plan into place as soon as possible, but ensure that the core stuff is in place for May 25th.
Please note that we are still talking to GDPR lawyers, and we’d also very much appreciate feedback from the wider Matrix community – i.e. this plan is very much subject to change. We’re sharing it now to ensure everyone sees where our understanding stands today.
The current todo list breaks down into the following categories. Most of these issues have matching github IDs, which we’ll track in a progress dashboard.
Right to Erasure
We’re opting to follow the email model, where the act of sending an event (i.e. message) into a room shares a copy of that message to everyone who is currently in that room. This means that in the privacy policy (see Consent below) users will have to consent to agreeing that a copy of their messages will be transferred to whoever they are addressing. This is also the model followed by IM systems such as WhatsApp, Twitter DMs or (almost) Facebook Messenger.
This means that if a user invokes their right to erasure, we will need to ensure that their events will only ever be visible to users who already have a copy – and must never be served to new users or the general public. Meanwhile, data which is no longer accessible by any user must of course be deleted entirely.
In the email analogy: this is like saying that you cannot erase emails that you have sent other people; you cannot try to rewrite history as witnessed by others… but you can erase your emails from a public mail archive or search engine and stop them from being visible to anyone else.
It is important to note that GDPR Erasure is completely separate from the existing Matrix functionality of “redactions” which let users remove events from the room. A “redaction” today represents a request for the human-facing details of an event (message, join/leave, avatar change etc) to be removed. Technically, there is no way to enforce a redaction over federation, but there is a “gentlemen’s agreement” that this request will be honoured. The alternative to the ‘email-analogue’ approach would have been to facilitate users’ automatically applying the existing redact function to all of the events they have ever submitted to a public room. The problem here is that defining a ‘public room’ is subtle, especially to uninformed users: for instance, if a message was sent in a private room (and so didn’t get erased), what happens if that room is later made public? Conversely, if right-to-erasure removed messages from all rooms, it will end up destroying the history integrity of 1:1 conversations, which pretty much everyone agrees is abhorrent. Hence our conclusion to protect erased users from being visible to the general public (or anyone who comes snooping around after the fact) – but preserving their history from the perspective of the people they were talking to at the time.
In practice, our core to-do list for Right to Erasure is:
As a first cut, provide Article 17 right-to-erasure at a per-account granularity. The simplest UX for this will be an option when calling the account deactivation API to request erasure as well as deactivation. There will be a 30 day grace period, and (ideally) a 2FA confirmation (if available) to avoid the feature being abused.
Homeservers must delete events that nobody has access to any more (i.e. if all the users in a room have GDPR-erased themselves). If users have deactivated their accounts without GDPR-erasure, then the data will persist in case they reactivate in future.
Homeservers must delete media that nobody has access to any more. This is hard, as media is referenced by mxc:// URLs which may be shared across multiple events (e.g. stickers or forwarded events, including E2E encrypted events), and moreover mxc:// URLs aren’t currently authorized. As a first cut, we track which user uploaded the mxc:// content, and if they erase themselves then the content will also be erased.
Homeservers must not serve up unredacted events over federation to users who were not in the room at the time. This poses some interesting problems in terms of the privacy implications of sharing MXIDs of erased users over federation – see “GDPR erasure of MXIDs” below.
Matrix must specify a way of informing both servers and clients (especially bots and bridges) of GDPR erasures (as distinct from redactions), so that they can apply the appropriate erasure semantics.
GDPR erasure of Matrix IDs
One interesting edge case that comes out of GDPR erasure is that we need a way to stop GDPR-erased events from leaking out over federation – when in practice they are cryptographically signed into the event Directed Acyclic Graph (DAG) of a given room. Today, we can remove the message contents (and preserve the integrity of the room’s DAG) via redaction – but this still leaves personally identifying information in the form of the Matrix IDs (MXIDs) of the sender of these events.
In practice, this could be quite serious: imagine that you join a public chatroom for some sensitive subject (e.g. #hiv:example.com) and then later on decide that you want to erase yourself from the room. It would be very undesirable if any new homeserver joining that room received a copy of the DAG showing that your MXID had sent thousands of events into the room – especially if your MXID was clearly identifying (i.e. your real name).
Mitigating this is a hard problem, as MXIDs are baked into the DAG for a room in many places – not least to identify which servers are participating in a room. The problem is made even worse by the fact that in Matrix, server hostnames themselves are often personally identifying (for one-person homeservers sitting on a personal domain).
We’ve spent quite a lot time reasoning through how to fix this situation, and a full technical spec proposal for removing MXIDs from events can be found at https://docs.google.com/document/d/1ni4LnC_vafX4h4K4sYNpmccS7QeHEFpAcYcbLS-J21Q. The high level proposal is to switch to giving each user a different ID in the form of a cryptographic public key for every room it participates in, and maintaining a mapping of today’s MXIDs to these per-user-per-room keys. In the event of a GDPR erasure, these mappings can be discarded, pseudonymising the user and avoiding correlation across different rooms. We’d also switch to using cryptographic public keys as the identifiers for Rooms, Events and Users (for cross-room APIs like presence).
This is obviously a significant protocol change, and we’re not going to do it lightly – we’re still waiting for legal confirmation on whether we need it for May 25th (it may be covered as an intrinsic technical limitation of the system). However, the good news is that it paves the way towards many other desirable features: the ability to migrate accounts between homeservers; the ability to solve the problem of how to handle domain names being reused (or hijacked); the ability to decouple homeservers from DNS so that they can run clientside (for p2p matrix); etc. The chances are high that this proposal will land in the relatively near future (especially if mandated by GDPR), so input is very appreciated at this point!
Consent
GDPR describes six lawful bases for processing personal data. For those running Matrix servers, it seems the best route to compliance is the most explicit and active one: consent.
Consent requires that our users are fully informed as to exactly how their data will be used, where it will be stored, and (in our case) the specific caveats associated with a decentralised, federated communication system. They are then asked to provide their explicit approval before using (or continuing to use) the service.
In order to gather consent in a way that doesn’t break all of the assorted Matrix clients connecting to matrix.org today, we have identified both an immediate- and a long-term approach.
The (immediate-term) todo list for gathering consent is:
Modify Synapse to serve up a simple ‘consent tool’ static webapp to display the privacy notice/terms and conditions and gather consent to this API.
Add a ‘consent API’ to the CS API which lets a server track whether a given user has consented to the server’s privacy policy or not.
Send emails and push notifications to advise users of the upcoming change (and link through to the consent tool)
Develop a bot that automatically connects to all users (new and existing), posting a link to the consent tool. This bot can also be used in the future as a general ‘server notice channel’ for letting server admins inform users of privacy policy changes; planned downtime; security notices etc.
Modify synapse to reject message send requests for all users who have not yet provided consent
return a useful error message which contains a link to the consent tool
Making our anonymised user analytics for Riot.im ‘opt in’ rather than ‘opt out’ – this isn’t a requirement of GDPR (since our analytics are fully anonymised) but reflects our commitment to user data sovereignty
Long-term:
Add a User Interactive Auth flow for the /register API to gather consent at register
As an alternative to the bot:
Fix user authentication in general to distinguish between ‘need to reauthorize without destroying user data’ and ‘destroy user data and login again’, so we can use the re-authorize API to gather consent via /login without destroying user data on the client.
port the /login API to use User Interactive Auth and also use it to gather consent for existing users when logging in
Deactivation
Account deactivation (the ability to terminate your account on your homeserver) intersects with GDPR in a number of places.
Todo list for account deactivation:
Remove deactivated users from all rooms – this finally solves the problem where deactivated users leave zombie users around on bridged networks.
Remove deactivated users from the homeserver’s user directory
Remove all 3PID bindings associated with a deactivated user from the identity servers
Improve the account deactivation UX to make sure users understand the full consequences of account deactivation
Portability
GDPR states that users have a right to extract their data in a structured, commonly used and machine-readable format.
In the medium term we would like to develop this as a core feature of Matrix (i.e. an API for exporting your logs and other data, or for that matter account portability between Matrix servers), but in the immediate term we’ll be meeting our obligations by providing a manual service.
The immediate todo list for data portability is:
Expose a simple interface for people to request their data
Implement the necessary tooling to provide full message logs (as a csv) upon request. As a first cut this would be the result of manually running something like select * from events where user=?.
Other
GDPR mandates rules for all the personal data stored by a business, so there are some broader areas to bear in mind which aren’t really Matrix specific, including:
Making a clear statement as to how data is processed if you apply for a job
Ensuring you are seeking appropriate consent for cookies
Making sure all the appropriate documentation, processes and training materials are in place to meet GDPR obligations.
It’s worth noting that we feel that GDPR is an excellent piece of legislation from the perspective of forcing us to think more seriously about our privacy – it has forced us to re-prioritise all sorts of long-term deficiencies in Matrix (e.g. dependence on DNS; improving User Interactive authentication; improving logout semantics etc). There’s obviously a lot of work to be done here, but hopefully it should all be worth it!
Ever modest, tulir has been tearing through issues and fixes over on gomuks. I’m quite excited to have a matrix-native console client getting up to speed so fast.
One of the riot developers, luke has a fun side-project called Journal, this being a blogging platform built on matrix.
Says Luke:
The big news this week being that I’m going to redesign the interface to focus on the personal blog use-case, optimising for easy setup and easy blog post sharing.
And hopefully push a 1.0 release that I’d be happy to use as my own personal blog.
Worth noting that the linked project page (Journal) is itself a blog using journal (the url might give you a hint of this!)
There are several changes moving this project along, but checking out the change list I can see there were a bunch of contributors to thank, (eeeeeta, Sorunome, TravisR), which is super-cool to see.
This week kitsune has been focused on ‘GTAD (Generate Things from API Description)’, which is a code generator for C++, taking API description in Swagger/OpenAPI as it’s source. Now at version 0.5, apparently GTAD
can generate correct buildable (and runnable) code to convert data structures used in CS API between JSON and C++ – for the entirety of CS API calls. That basically means that libqmatrixclient gains (so far low-level) C++ CS API for all calls in The Spec and will follow updates to it.
This is super-exciting, especially as we are going to see discussion and progress on the spec…
Trying to work our way through the regressions which keep stacking up
Lots of work on improved UTs for Groups and Replies; discussion about flux stuff
Next up is E2E verification (at last).
Riot/Mobile
Replies
Sticker sending
Android is now Kotlin enabled!
Synapse
Handling abuse of the depth parameter; short-term fix deployed and longer term coming along shortly.
This destroyed progress on the algorithmic perf improvements.
Half-Shot PRs for negotiating size limits
Amber is inbound!
Dendrite
We’re behind on PRs – sorry Thibaut :(
Matrix.org Ops
Ansible stuff is being refactored based on our experiences trying to use it in the wild
status.matrix.org is coming soon!
Spec
Loads of work happening to build the Spec Proposals website, tracking workflow for all the proposals in flux and putting them into a formal RFC-style process. It should help community participation in the spec process massively whilst we finalise the longer term governance model for Matrix.org
Also looking at publishing formal roadmaps for Synapse, Dendrite and Riot (at last!) – we have them internally these days but need to just chuck them up on the web and maintain them.
Finally, GDPR work is in full swing.
New(ish) Rooms
This section is scraped manually from #newrooms:matrix.org, though there has not been much activity there this week. Meanwhile, there are a couple of rooms suggested by Creak which deserve some love:
Amber Brown of the Twisted project will be joining the Matrix core team in a few weeks. She’ll be focusing on Synapse implementation work, and will bring a lot of Python experience with her. Having someone working full time on synapse will increase others bandwidth for homeserver and spec work.
Matrix Live
Matrix Live is now available, where among other things you can see this blog post being written!
Many people will have noticed disruption in #matrix:matrix.org and #matrix-dev:matrix.org on Sunday, when a validation bug in Synapse was exploited which allowed a malicious event to be inserted into the room with ‘depth’ value that made the rooms temporarily unusable. Whilst a transient workaround was found at the time (thanks to /dev/ponies, kythyria and Po Shamil for the workaround and to Half-Shot for working on a proposed fix), we’re doing an urgent release of Synapse 0.28.1 to provide a temporary solution which will mitigate the attack across all rooms in upgraded servers and un-break affected ones. Meanwhile we have a full long-term fix on the horizon (hopefully) later this week.
This vulnerability has already been exploited in the wild; please upgrade as soon as possible.
The ‘depth’ parameter is used primarily as a way for servers to signal the intended cosmetic order of their events within a room (particularly when the room’s message graph has gaps in it due to the server being offline, or due to users backfilling old disconnected chunks of conversation). This means that affected rooms may experience message ordering problems until a full long-term fix is provided, which we’re working on currently (and tentatively involves no longer trusting ‘depth’ information from servers). For full details you can see the proposal documents for the temporary fix in 0.28.1 and the options for the imminent long-term fix.
We’d like to acknowledge jzk for identifying the vulnerability, and Max Dor for providing feedback on the fixes.
As a general reminder, Synapse is still beta (as is the Matrix spec) and the federation API particularly is still being debugged and refined and is pre-r0.0.0. For the benefit of the whole community, please disclose vulnerabilities and exploits responsibly by emailing [email protected] or DMing someone from +matrix:matrix.org. Thanks.
Changes in synapse v0.28.1 (2018-05-01)
SECURITY UPDATE
Clamp the allowed values of event depth received over federation to be [0, 2^63 – 1]. This mitigates an attack where malicious events injected with depth = 2^63 – 1 render rooms unusable. Depth is used to determine the cosmetic ordering of events within a room, and so the ordering of events in such a room will default to using stream_ordering rather than depth (topological_ordering). This is a temporary solution to mitigate abuse in the wild, whilst a long solution is being implemented to improve how the depth parameter is used.Full details at https://docs.google.com/document/d/1I3fi2S-XnpO45qrpCsowZv8P8dHcNZ4fsBsbOW7KABI
Pin Twisted to <18.4 until we stop using the private _OpenSSLECCurve API.
Fractal Hackfest 2018 will take place next month in Strasbourg, hosted by Epitech. They’ll be planning a roadmap for the year, and working on their current focus areas.
After the blog post on matrix.org yesterday, lots of attention developed around the news. Take a look at this Hacker News thread with lots of discussion, which has stayed on the front page for nearly 24 hours, and a megathread on Reddit/r/linux: nearly 1000 upvotes and growing.
Project Updates
Clients
libqmatrixclient
kitsune reports a new release of libqmatrixclient, v0.2.1, this is mostly a bugfix release, fully backwards-compatible with v0.2. Check out the release notes for details.
Staying in QMatrix-land, there is a pre-release of Quaternion available. Take a look at v0.0.9, improvements include “redactions, file downloading, room creation and settings editing, better timeline visualisation and much more”!
f0x has been beavering away on neo, and has announced that Alpha 0.01 is available now. neo is a webclient in React, it feels really light and fast. I asked f0x about the uptick in work, and he mentioned he got started with React recently, but likes it a lot.
Says TravisR: “I’ve whipped together a simple Trello notification bot for matrix: matrix-trello-bot. Future plans include the ability to create/update/delete cards and more granular control of what is notified about. Currently it acts very similar to how the Github notifications bot works.”
MTRNord is working on a “matrix DSL”, basically a config file language that generates a project Template in multiple languages. The project is just now at the discussion stage, so join #matrix_dsl:matrix.ffslfl.net to check out what’s going on. (DSL = Domain Specific Language.)
mxisd, the Identity Server from kamax, saw a v1.0.2 release, following the big one-point-zero last week. Changes include de-duplicated directory search results, plus bugfixes.
Missed this one last week, but matrix-stfu from xwiki is a message filtering tool released recently, it can “mass remove everything which was said by a particular user in a particular room”. XWiki use matrix as their internal chat system for the ~30 people at the company.
We’re committing to 2-weekly releases come what may, to avoid another massive gap like the one between 0.13 and 0.14.
RCs will get cut starting from Wednesday; actual release then happens on the Monday having given folks a chance to test the RC on /staging (and to iterate on the RCs).
Obviously this is flexible if we need to rush out fixes sooner.
On that note, 0.14.2-rc1 was cut on Wednesday! Please test it at riot.im/staging. It’s mainly bugfixes but also the full relayering between riot-web and matrix-react-sdk.
Dave’s working on finally hooking in Jitsi as the default conferencing system
t3chguy’s been working on Replies, which continue to look awesome
Next up: E2E cross-signing (at last!!!!)
Riot/Mobile
New releases are out! Mainly preparing for sticker viewing and trying to fix the Android push notification situation. PLEASE TELL US IF YOU ARE STILL HAVING ANDROID PUSH NOTIFICATION PROBLEMS!
Lots of review of Android by Benoit – adding in Kotlin support as of today and establishing a formal roadmap for Android work (we’ll show the blog post when we have it)
Lots of Matrix-for-French-Government stuff.
Synapse
Synapse 28.0 was released! A major bump mainly thanks to lots and lots of contributions from the wider community.
Massive experimental work on GDPR in progress – doing the thought experiment of pseudonymising MXIDs throughout Matrix on a per-room basis so that it’s possible to redact MXIDs in the event of a “right-to-erasure” GDPR event. Rich vdH is leading the work.
The good news is that introducing an MXID abstraction layer like this could help us enormously with some of Matrix’s longest-term architectural issues – i.e. account migration and portability; improving on PERSPECTIVEs for managing server identity; future support for P2P Matrix; solving the domain name reuse problem; etc.
The bad news is that it would obviously be a very significant change to the Matrix spec, although we’d be doing it in such a way which minimises impact to client implementers and keep the CS API looking as similar as possible.
We’re not sure whether we need to rush this through or not yet; still waiting for final GDPR clarification from lawyers, but it feels like this might be a good opportunity to force us to finally tackle some of these harder problems.
Meanwhile, Erik’s Delta State Resolution algorithm work is continuing well; we’re hoping to finish & merge it asap in order to get back headroom on the server.
Thankfully the matrix.org synapse itself has been relatively stable this week, other than being completely overloaded causing Freenode to be almost unusable.
We’ve started using Ansible in production, although the playbooks need some iteration before we’re fully happy to announce them & recommend folks use them as an official way of running Synapse in production.
try-matrix-now
There is a update out on try-matrix-now, matrix.org’s central listing of projects. Try filtering and see whether benpa mangled the metadata for your project. Submit any changes as markdown PRs on the repo.
Spec
benpa is currently working on a Proposals page for the Spec to properly stack spec proposal status, at last!
Articles around the web
Riot: A Distributed Way of Having IRC and VOIP Client and Home Server
Half-Shot shared an article he wrote, Service notifs with Matrix, about using Matrix and Riot to deliver automated notifications to different types of end-user at his company.
#matrix_dsl:matrix.ffslfl.net As mentioned above, MTRNord is looking at creating a DSL for matrix. In his words: “A room to discuss about making a Matrix DSL to allow non coders to write simple as and bots. I would love to see some people discussing about syntax with me as this is my very first DSL and very first time trying JetBrains MSP. Anyone with Ideas what it should allow to do and how to have the syntax a welcome to join (and people who want to follow of course too)”
#trellobot:t2bot.io (from above) TravisR: “a discussion/developer room for Matrix Trello Bot (https://github.com/turt2live/matrix-trello-bot). This is a bot that notifies rooms of changes to tracked Trello boards, similar to how the Github bot works. Future enhancements include being able to create, update, and delete cards from within Matrix.”
This Week in Matrix is printed fresh every week! There will be another post before you know it, so if you’d like to be included join us in #twim:matrix.org and let us know what you’ve been working on. See you next week!
Well now, today sees the release of Synapse 0.28.0!
This release is particularly exciting as it’s a major bump mainly thanks to lots and lots of contributions from the wider community – including support for running Synapse on PyPy (thanks Valodim) and lots of progress towards official Python3 support (thanks notafile)!! However, almost all the changes are under the hood (and some are quite major), so this is more a performance, bugfix and synapse internals release rather than adding many new APIs or features
We’re incredibly excited that the Government of France has confirmed it is in the process of deploying a huge private federation of Matrix homeservers spanning the whole government, and developing a fork of Riot.im for use as their official secure communications client! The goal is to replace usage of WhatsApp or Telegram for official purposes.
It’s a unbelievably wonderful situation that we’re living in a world where governments genuinely care about openness, open source and open-standard based communications – and Matrix’s decentralisation and end-to-end encryption is a perfect fit for intra- and inter-governmental communication. Congratulations to France for going decentralised and supporting FOSS! We understand the whole project is going to be released entirely open source (other than the operational bits) – development is well under way and an early proof of concept is already circulating within various government entities.
I’m sure there will be more details from their side as the project progresses, but meanwhile here’s the official press release, and an English translation too. We expect this will drive a lot of effort into maturing Synapse/Dendrite, E2E encryption and matrix-{react,ios,android}-sdk, which is great news for the whole Matrix ecosystem! The deployment is going to be speaking pure Matrix and should be fully compatible with other Matrix clients and projects in addition to the official client.
So: exciting times for Matrix. Needless to say, if you work on Open Government projects in other countries, please get in touch – we’re seeing that Matrix really is a sweet spot for these sort of use cases and we’d love to help get other deployments up and running. We’re also hoping it’s going to help iron out many of the UX kinks we have in Riot.im today as we merge stuff back. We’d like to thank DINSIC (the Department responsible for the project) for choosing Matrix, and can’t wait to see how the project progresses!
English Translation:
The French State creates its own secure instant messenger
By the summer of 2018, the French State will have its own instant messenger, an alternative to WhatsApp and Telegram.
It will guarantee secure, end-to-end encrypted conversations without degradation of the user experience. It will be compatible with any mobile device or desktop, state or personal. In fact until now the installation of applications like WhatsApp or Telegram was not possible on professional mobile phones, which hindered easy sharing of information and documents.
Led by the Interministerial Department of State Digital, Information and Communication Systems (DINSIC), the project is receiving contributions from the National Agency for Information System Security (ANSSI), the IT Directorship (DSI) of the Armed Forces and the Ministry of Europe and Foreign Affairs.
The tool developed is based on open source software (Riot) that implements an open standard (Matrix). Powered by a Franco-British startup (New Vector), and benefiting from many contributions, this communication standard has already caught the attention of other states such as the Netherlands and Canada, with whom DINSIC collaborates closely.
The Matrix standard and its open source software are also used by private companies such as Thales, which has driven the teams to come together to ensure the interoperability of their tools and cooperate in the development of free and open source software.
After 3 months of development for a very limited cost, this tool is currently being tested in the State Secretary for Digital, DINSIC and in the IT departments of different ministries. It should be rolled out during the summer in administrations and cabinets.
“With this new French solution, the state is demonstrating its ability to work in an agile manner to meet concrete needs by using open source tools and very low development costs. Sharing information in a secure way is essential not only for companies but also for a more fluid dialogue within administrations.” – Mounir Mahjoubi, Secretary of State to the Prime Minister, in charge of Digital.
Recent Comments