With the core team focusing on upcoming performance work and GDPR management tooling, v0.31.0 is most notable for improvements to system stats. Additionally, work continues on our py3 port and a host of small bug fixes and perf improvements.
Most notable change from v0.30.0 is to switch to python prometheus library to improve system stats reporting. WARNING this changes a number of prometheus metrics in a backwards-incompatible manner. For more details, seedocs/metrics-howto.rst
hawkowl is technically new to the Matrix Core team but is already integrated and storming the codebase like an old pro. She and notafile have been ramping up on work to the make the Synapse codebase work with Python 3.
🔗matrix-docker-ansible-deploy can now set up your homeserver using the official Matrix Synapse Docker image
Using this Ansible playbook is probably the easiest way to set up a fully-functioning Matrix homeserver on your own machine. The setup includes Matrix Synapse and some related services required to actually make it useful (automatically-managed HTTPS; STUN/TURN server for audio/video calls; Postgres database for Synapse; optionally riot-web; optionally Amazon S3 storage support)
my personal problem was:
i didn't want to open up registration for everyone
i didn't want to register every account manually and have to worry about seeing passwords etc
now i can just share a link, e.g:
https://zeratax.github.io/matrix-registration/demo.html?token=JargonGingerYankee
and my friends can register.
these token can be restricted as one time usable only or by an expiration date.
Last week dendrite was filtering events from user's into separate queues for each application service to eventually be given. Sending these events requires batching them up into transactions and then sending them to an HTTP endpoint on the application service. I'm happy to report that from today, that functionality is now implemented, along with graceful handling of both server and application service downtime.
Fractal got the beginning of a revamped directory (from one of our GSoC interns), as well as misc bugfixes and performance improvements. It has also been added to Damned lies, the GNOME platform for translations.
Riot is undergoing a visual redesign, thanks to Jouni Helminen. Take a look at the redesign work on the Riot blog. The changes are not radical, but will help standardise and modernise the Riot interface. Early feedback I've seen has been mostly positive.
The user can now change the following settings: Avatar, display name, add and remove email addresses and phone numbers. Also, they can see the homeserver and their own MXID. We will probably make some more small changes on the way to make the UX as good as we possibly can.
Fractal was featured in Fedora Magazine this week, just a little introduction. I notice the article barely introduces matrix: not sure if that's an oversight or a belief that the audience will already know it!
Still posting about spec proposals. To get involved in the spec development process, take a look at the Matrix Spec Change Proposals page to find out what's happening, read the proposals, then talk about it in #matrix-spec:matrix.org. One proposal looking for attention and a good place to start:
🔗Interactive Key Verification: Spec proposal from uhoreg
As mentioned in our last blog post on GDPR, to make sure that everyone has read and understood the important details about how their personal data is processed by the matrix.org homeserver, users who haven't yet agreed to the privacy notice and terms and conditions will be blocked from sending new messages until they have.
Users will continue to be able to receive messages, so they won't miss out on any messages sent to them before they've agreed to the terms.
The System Alerts room has already sent every user their unique link to review and agree, and if anyone missed that message, the latest Riot.im web and mobile will display a helpful error message guiding users who are yet to agree through the agreement process.
If you have any questions or difficulties, please let us know at [email protected].
If you've connected to the matrix.org homeserver today, you'll have noticed some activity in support of GDPR compliance. The most obvious of these is an invite from System Alerts (aka @server:matrix.org):
We've rolled out the System Alerts feature to communicate important platform information to all of a homeserver's users. Today, we're using it to communicate the arrival of our new (and much-improved) Privacy Notice and Terms and Conditions to users on matrix.org.
The System Alerts service takes the form of an (unrejectable) invite to a room. We took this approach to support maximum compatibility with the myriad Matrix clients (since all Matrix clients can support conversations in a room ?).
When we first rolled out System Alerts, we didn't allow users leave the System Alerts room. Sorry! We got a bit overexcited - we've fixed that now (though please do provide your agreement before you leave).
At some point today the System Alerts service will provide you with unique link, directing you to review the new terms and provide your agreement.
For us to process your personal data lawfully, it's really important that we know you understand and agree to our Privacy Notice and Terms and Conditions. For that reason, we will shortly be blocking any users who haven't indicated their acceptance, so please act quickly when you receive your link.
Once the block is enabled, users who haven't accepted the terms will see an error when they try and send a message, join a room, or send an invite. This message will also include the unique link to review and accept the terms, so users who haven't seen the message from System Alerts will know what to do.
Don't worry if you're reading this some time after May 25 - accepting the terms at any time will unblock message sending on your account, and you won't have missed any messages sent to you.
If you have any thoughts or suggestions on the legal documentation, you can provide comment via github.
Folks are already accepting the new policies - thanks.
We're going to start requiring acceptance to access the matrix.org server on Tuesday (May 29th).
We're already receiving our first GDPR requests… :|
Erasure and Right-to-be-forgotten work (Phase 2) is next up so we can action the requests in a timely manner.
It looks like we will go ahead on removing MXIDs on events as a Phase 3 (although for now we do warn people that this is effectively a technical limitation of Matrix, albeit one that we're working on).
Big E2E progress from mujx, developer of the nheko client on his project mtxclient. As of this week, mxtclient is able to decrypt group events. When writing (that is, sending encrypted messages) is complete, the idea is to migrate this work back to nheko, though mujx points out this library could be used in any client.
JonTheNiceGuy produced a helpful video describing how to use bridges for IRC, Slack and Telegram, showing the difference between the different bridges. I found this to be really clear and well-paced for following the many practical details of bridging. Watch here: https://www.youtube.com/watch?v=ZNEzgYRLj8g
"finished edit passing between Discord and Matrix, as well as support for discord's custom emojis (though UX is a bit manual until TravisR's proposal goes through ?)"
This small tool will take the local part of the room ID created by the Matrix<>Facebook Messenger bot once the friend has joined it, identify th friend, and grab their avatar and display name to set the room's.
betz runs the https://hackerspaces.be/ matrix server and has this week, inbetween repairing his Synapse install, been working on a project called matrixboard. This tool is used to output the last five messages from a given room to displayed as HTML, the idea being to display output from a specific room as a website widget. You can see an example using #matrix-devhere.
The idea of using the room state to encapsulate bot data per-room was well received, discussion in #TWIM:matrix.org suggests this is an estabilished practice for some developers.
No general GSOC round-up this week, &Adam shared the news that GSOC-student Zil0's first PR towards E2E in matrix-python-sdk landed on master. These PRs are working from efforts previously contributed by pik.
Work continues in the Ruma space. This week saw the release of
ruma-events0.10.0: ruma-events contains Serializable Rust types for the events in the Matrix specification. 0.10.0 sees a major update with code provided by mujx, and contains many breaking changes.
f0x has started work on a tool to help migrate accounts - including across homeservers. Right now he's working on the GUI, but check out progress at https://github.com/f0x52/matrix-migrate.
As part of my master's thesis, I wrote the DSN Traveller bot, which is crawling the matrix federation to measure the shape and size of the matrix network, and how distributed it currently is. The bot is already in a smaller number of rooms for testing, and will join the remaining rooms over the next days. All details at https://dsn-traveller.dsn.scc.kit.edu/, room at #dsn-traveller:dsn-traveller.dsn.scc.kit.edu.
Anoa is on the case, having joined the core team on Monday - Dendrite is already sending events to ASes! Meanwhile APwhitehat is hacking away on his GSoC projects!
Last week I promised an update on the state of the various GSOC projects in the Matrix Ecosystem. There is activity happening but other than what's been discussed above we'll wait a week or two for more detailed updates.
As always, if you have things to say, projects to advertise, or anything else, ping me or visit #TWIM:matrix.org. I'm keen to get everyone included and keep this community enthused about all the work going on in the Matrix ecosystem.
v0.30.0 sees the introduction of Server Notices, which provides a channel whereby server administrators can send messages to users on the server, as well as Consent Management for tracking whether users have agreed to the terms and conditions set by the administrator of a server - and blocking access to the server until they have.
In conjunction these features support GDPR compliance in the form of providing a client agnostic means to contact users and ask for consent/agreement to a Privacy Notice.
For more information about our approach to GDPR compliance take a look here (although be aware that our position has evolved a bit; see the upcoming new privacy policy for the Matrix.org homeserver for details).
Additionally there are a host of bug fixes and refactors as well as an enhancement to our Dockerfile.
'Server Notices' are a new feature introduced in Synapse 0.30. They provide a
channel whereby server administrators can send messages to users on the server.
They are used as part of communication of the server policies (see Consent Tracking),
however the intention is that they may also find a use for features such
as "Message of the day".
This feature is specific to Synapse, but uses standard Matrix communication mechanisms,
so should work with any Matrix client. For more details see here.
Further Server Notices/Consent Tracking Support:
Allow overriding the server_notices user's avatar (PR #3273)
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)
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.
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.
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
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!
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.
#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.
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
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 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.
I was surprised and excited to learn that a Russian translation of the Matrix FAQ has been produced by a group of Russian-language 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!)
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.
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.
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.
