As you may know, for the last few months anoa (Andrew) and APWhiteHat have been working on Dendrite, the next generation Matrix homeserver, written in Go. We asked for an update on their progress, and Andrew provided the blog post below. Serious progress has been made on Dendrite this summer!

---

Hey everyone, my name is Andrew Morgan and I've been working full-time over the summer on Dendrite, our next-generation Matrix homeserver. Over the last two months, I've seen the project transform from a somewhat functioning toy server to a near-production-ready homeserver that is working towards complete feature support. I've appreciated the thought put into the project since day one, and enjoy the elegance of the multi-component design. Documentation is fairly decent at the moment, but comments are plentiful throughout the codebase, while the code itself tends towards simple and maintainable rather than complex and unmanageable.

🔗Application Service Integration

The main focus of my time here has been on the implementation of application service support for Dendrite. Application services are external programs that act as privileged extensions to a homeserver, allowing such functionality as bots in rooms and bridges to third-party networks. Supporting application services requires a few different bits and pieces to be set up. Currently all planned features have a PR for them, with the bold items already merged:

• Sending events to application services
• Support user masquerading for events
• Support editing event timestamps
• Support room alias querying
• Support user ID querying
• Support third party lookup proxying

As you can see a decent portion of the functionality is already in master! The rest will hopefully follow after some further back and forth.

🔗Google Summer of Code

I certainly haven't been going at this all on my own. Alongside extensive help from Erik, who's been mentoring me, our resident Google Summer of Code student, APWhiteHat, has been tackling feature after feature in Dendrite wherever he can find them. Application services received a good deal of help on client-server endpoint authentication side, however, APWhiteHat has mostly been focusing on federation and some other very useful pieces. While his GSoC period still has a week or so before its conclusion, he has so far implemented:

• Idempotency to roomserver event processing to prevent duplication
• Username auto generation
• Tokens library based on macaroons
• Lots of left-over federation stuff: state API & get missing events being the major ones
• AS support to clientapi auth
• Typing server: handling of PUT /typing by clientapi
• More typing server stuff on its way

From my perspective, APWhiteHat was an excellent developer to work with. He asked good questions and was quick to answer any myself or the community had as well. His code reviews were also very comprehensive. I learned a lot from working with him and everyone else :)

🔗OpenTracing and Prometheus Monitoring

Placing any large server into a production environment requires extensive monitoring capabilities in order to ensure operations are running smoothly. To that effect, Dendrite has been both the addition of OpenTracing and Prometheus support. Prometheus, also used heavily in Synapse, allows a homeserver operator to track a wide range of data including endpoint usage, resource management as well as user statistics over any given range of time.

In Dendrite, we are taking this one step further by introducing OpenTracing, a language and platform-agnostic framework for tracking the journey of an endpoint call from incoming request to outgoing response, with every method, hierarchy change and database call in between. It will be immensely useful in tracking down performance issues, as well as providing insight into the most critical paths throughout the codebase and where we should focus most of our optimization efforts on. It also comes with a lovely dashboard courtesy of Jaeger:

🔗Community

We've also seen some encouraging interest and development work from the community in the past couple months. While PR review from our own side is admittedly slow due to our focus on getting the foundational work in place, that hasn't stopped both old and new developers from sending in PRs and performing code reviews. A huge thank you to everyone involved! From this we've gotten API implementations and application service fixes from @turt2live, an end-to-end encryption implementation from @fadeAce, filtering support from @CromFr, and some PRs and numerous helpful review comments from @krombel.

We've also started to see some people running Dendrite in live environments, which is incredibly exciting for us to see! While Dendrite is not considered production-ready yet (though it moves closer every day), if you are interested in giving it a go please consult the quickstart installation guide. We look forward to any feedback you may have!

🔗mautrix-telegram now supports double puppeting

tulir has been working away on mautrix-telegram, and has a major breakthrough:

It means you can log in to the bridge with your Matrix account to make messages you send from other Telegram clients appear from your Matrix account.

It can also be used to enable bridging of ephemeral events, which synapse doesn't send to appservices (read receipts, typing notifications, presence).

Also, the bridge has a new HTML parser which should be much better than the old one. It might have caused some new bugs though (like m.emote bridging breaking)

🔗Coffee and the FAQBot

I've been slowly working on matrix.org the last couple of months, updating the FAQ, updating content and UI/appearance of try-matrix-now. As you may know, the FAQBot, created and maintained by Coffee, uses try-matrix-now for it's data, so Coffee updated the bot to start to use some of the new fields.

The final puzzle piece needed for FAQBot has been put into place: https://gitlab.com/Matrixcoffee/extract-web-to-org
This is the bit that grabs "Try Matrix Now!" and turns it into questions that FAQBot can use.
While I was working on that bit of code anyway, I also added support for the new 'home', 'repo', 'room' and 'language' fields. FAQBot will now give more and better information accordingly. For example, it is now possible to ask, "where is the Riot Android source code?" although it is generally better to just ask "where can I find Riot Android?" which combines several fields into a single answer.
4 of 7 items are now completed: https://gitlab.com/Matrixcoffee/FAQBot/issues/2
and the remaining 3 items before FAQBot's release are just the final review and integration tests.

🔗New Discord Bridge Maintainer

Half-Shot has been working stridently on the Discord Bridge lately, and the project has now attracted a second maintainer:

We've got a new member of the maintainer crew in discord bridge land (bringing the total count to 2.) I'd like to welcome Sorunome :). They are going to be helping review the influx of PRs, chew some issues and be a point of contact in the community. They've already filled my PR queue up and it's going to help us move even faster!

In other Bridge news, matrix-appservice-bridge 1.5.0 is out now, uses the latest matrix-js-sdk and matrix-appservice-node, and contains a lot of changes.

🔗Bruno unit tests

Bruno, the latest and greatest addition to the [riot-web] team, has been working on configuring end to end unit tests. His scripts now install synapse from the metal, install riot and then run a test suite. Take a look at the animation below to get the idea!

🔗Fractal 3.29.5

Alexandre Franke tells us about new features in Fractal 3.29.5, and how the project has benefited from GSOC 2018 contributors:

Fractal got a big new release 3.29.5, which includes Eisha's multi-line input (with markdown syntax highlighting) and Julian's room details redesign, as well as his refactor on avatar code which leads to a perf boost.

🔗Ananace: Grafana webhook for Matrix notifications

Ananace, always working on sysadmin tooling with matrix, comes back with a new tool: Grafana webhook for Matrix notifications. This release is described as "the very first 'It doesn't crash instantly' version", but this is surely a useful project.

🔗Quaternion / libQMatrixClient support local echo

kitsune had a surprising week while working on his QMatrix projects:

/me accidentally found a year-old feature branch in his Git and thought of rebasing it in order to eventually continue working on it. As a result, libQMatrixClient and Quaternion master branches support local echo from today. Too bad the same trick doesn't work for E2EE.

Too bad indeed!

🔗Riot/Web

• Cut the release candidate for 0.16-RC1
• Lots of final polishing on Jitsi; all bugs fixed now
• Likewise all Slate bugs fixed - many thanks to t3chguy for finishing them off
• Lazy Loading Members implementation progressing well
• Release due on Monday
• On crypto: uhoreg has also been progressing on hooking up incremental key backup

🔗Riot/Mobile

• Room version upgrade support!
• Replies UI implemented on iOS and working well
• Lazy Loading Members is done and working on iOS - speeds up launch by a minimum of 3x

🔗Synapse

• Hawkowl is running the first ever Python 3.6 synapse! RAM usage looks to be 2-3x less than on Python 2.7. Still work to be done to merge all the PRs though.
• Landing all the Lazy Loading patches; 3 down, 3 to go
• Gathering feedback on the state res prop - thanks to uhoreg for wading through it!
• Catching up Lots and lots of PRs
• Implementing room versioning and gathering feedback on the MSC
• Perf fixes - optimising current state res a bit & fixing sync performance
• => End-to-end message latency on matrix.org has been improved by 3-5x over the last few days(!!!)

🔗Dendrite

• Super-exciting to see E2E working thanks to fadeAce's PR: https://twitter.com/matrixdotorg/status/1022887733931520001

Super-exciting to see end-to-end encryption working with Dendrite thanks to a massive PR from first-time contributor fadeAce!! https://t.co/SLIPvgYGAm pic.twitter.com/s47SWjY46o

— Matrix (@matrixdotorg) July 27, 2018

• OpenTracing support has been dusted off and is working again cross-service
• See the community update for much more!

🔗Spec

• Travis continues to blitz through the S2S spec, PRs are flying around everywhere (and even landing!)
• Uhoreg continues to work on the E2E spec merges with Zil0

🔗We'll meet again…

See you next week, and don't forget to watch Matrix Live below!

🔗Spec Updates!

First of all: we've just released the first draft of the proposal for our next generation State Resolution algorithm as MSC1442 (State Resolution: Reloaded).  This is the result of a massive amount of work from Erik - if you are at all interested in the problems that state resets have plagued us with, then you will want to read the proposal and please comment on it!

The next step on State Resolution: Reloaded (once approved) is to be able to actually roll it out - and to this end, richvdh has proposed MSC1425 (Room Versioning proposal). This was published at the beginning of the week but we haven't had any feedback yet - again, please read & give feedback as the intention is to start working on this as soon as possible!  Matthew's also been updating the Lazy Loading proposal (MSC1227).

Meanwhile, the Matrix Spec is now awash with activity, lots of work from TravisR, Cadair and others to accelerate progress. Take a look at the proposals list to stay up to date, or straight to the matrix-doc repo and #matrix-spec:matrix.org room to get the raw activity.

Finally, discussions relating to the spec proposal process itself have attracted attention: MSC1426 and MSC1421, and we're already trialling the new process (using Github PRs rather than Google Docs) in MSC1442 (State Resolution: Reloaded) already.

🔗nheko 0.5.x

nheko 0.5.1 is out, and it's great! Get a version for your platform from bintray.com. I've been using it for the last week or so (on macOS) and found it very stable and usable. mujx commented that "highlights were encryption support & desktop notifications on all platforms", but you can get much more thorough notes from the release notes.

🔗Plasma

It's been several weeks since we mentioned Plasma, but work on the C2S parts of the spec implementation have been happening quietly behind the scenes. Project lead Nico said recently:

I've updated the CI test server with the latest snapshot version of plasma. createRoom and invite C2S endpoints are fully implemented and should work as expected.

You can find the full list of implemented endpoints in the readme, and also read the architecture overview.

🔗kitsune, live on stage

kitsune presented an introduction to Matrix (for a technical audience) at the Tokyo Linux Users Group - you'll need to skip to 1h41m16s into the video.

🔗GTAD pulls in description and summary fields from the API

kitsune continues working on GTAD, and this week has started automatically including docs in libQMatrixClient:

GTAD is now aware of description and summary fields in API descriptions so you can use them with Javadoc/Doxygen. As a result, libQMatrixClient master branch now enjoys doc-comments throughout its CS API layer - the rest of the library builds in envy.

🔗SimpleMatrix

MTRNord introduced us to SimpleMatrix:

SimpleMatrix is my approach on making an Android App that is more easy to use than the official one in Terms of UX and UI. Planned is also a Android Wear App within this App for mostly Notifications.

SimpleMatrix is planning to use matrix-java-sdk, but for now is a visual mockup, it doesn't currently connect to Matrix.

Room: #SimpleMatrix:matrix.ffslfl.net Git: https://git.nordgedanken.de/Nordgedanken/SimpleMatrix

🔗Tales of Half-Shot and his many Bridges

🔗Arrival of the Discord DMs

After lots of begging, frustration and eventually an offer of a free lunch (thanks Anoa): I give you Discord DMs.
This first cut bridges over existing regular and group DMs to Matrix. In the future we will also allow you to create DMs from Matrix so that you can contact users without even logging into Discord. With thanks to the #discord:half-shot.uk community for helping shape this feature!

Currently this is in PR form but is very likely to make it into the 0.3 release of matrix-appservice-discord.

🔗Half-Shot fixes the Foonetic IRC bridge

For those who (want to) use Foonetic IRC channels, Half-Shot is here for you! Previously this bridge had been down due to invalid certificates, but this is now resolved.

🔗Synapse

Synapse 0.33 landed on Thursday, boasting 2x speed-ups for /sync and (briefly) meaning that the matrix.org homeserver felt impressively snappy and fast!  Ironically traffic levels promptly grew again such that the synapse master process is now the bottleneck once more, but between incremental state res, python 3 and upcoming room-sharding work we should see the performance fixes continuing to come!  Meanwhile, lots of PRs in the queue for Synapse 0.34 - including Lazy Loading support as per (MSC1227), and a whole new set of stats functionality for tracking per-room and per-user stats.

🔗Riot

Lots of activity in the build up to Riot/Web 0.16 - merging the new Slate rich text editor to /develop (try it now!), upgrading Jitsi and turning it on by default (at last!! - again, try it on /develop, although you'll have to enable it in Labs).  We'd be particularly interested in how Jitsi is behaving, as so far for us it's been unrecognisably improved over the previous deployment.

Meanwhile, lots of work on Lazy Loading members on Riot/Web and Riot/iOS, and lots of stability perf work in general across mobile.

🔗State Resolution Special... Matrix Live!

And finally, all you could ever want to hear about the new State Resolution algorithm on a special edition of Matrix Live, starring Erik & Matthew!

Hi all,

We've just released Synapse 0.33.0!  This is a major performance upgrade which speeds up /sync (i.e. receiving messages) by a factor of almost 2x!  This has already made a massive difference to the CPU usage and snappiness of the matrix.org homeserver since we rolled it out a few days ago - you can see the drop in sync worker CPU just before midday on July 17th; previously we were regularly hitting the CPU ceiling (at which point everything grinds to a halt) - now we're back down hovering between 40% and 60% CPU (at the current load).  This is actually fixing a bug which crept in around Synapse 0.31, so please upgrade - especially if Synapse has been feeling slower than usual recently, and especially if you are still on Synapse 0.31.

Meanwhile we have a lot of new stuff coming on the horizon - a whole new algorithm for state resolution (watch this space for details); incremental state resolution (at last!) to massively speed up state resolution and mitigate extremities build up (and speed up the synapse master process, which is now the bottleneck again on the matrix.org homeserver); better admin tools for managing resource usage, and all the Python3 porting work (with associated speedups and RAM & GC improvements).  Fun times ahead!

The full changelog follows below; as always you can grab Synapse from https://github.com/matrix-org/synapse.   Thanks for flying Matrix!

🔗Synapse 0.33.0 (2018-07-19)

🔗Bugfixes

• Disable a noisy warning about logcontexts. (#3561)

🔗Synapse 0.33.0rc1 (2018-07-18)

🔗Features

• Enforce the specified API for report_event. (#3316)
• Include CPU time from database threads in request/block metrics. (#3496, #3501)
• Add CPU metrics for _fetch_event_list. (#3497)
• Optimisation to make handling incoming federation requests more efficient. (#3541)

🔗Bugfixes

• Fix a significant performance regression in /sync. (#3505, #3521, #3530, #3544)
• Use more portable syntax in our use of the attrs package, widening the supported versions. (#3498)
• Fix queued federation requests being processed in the wrong order. (#3533)
• Ensure that erasure requests are correctly honoured for publicly accessible rooms when accessed over federation. (#3546)

🔗Misc

• Refactoring to improve testability. (#3351, #3499)
• Use isort to sort imports. (#3463, #3464, #3540)
• Use parse and asserts from http.servlet. (#3534, #3535).

Welcome to TWIM for Friday the 13th! Nothing too scary, but lots of client updates and news.

🔗Quaternion

kitsune:

Quaternion has gained a new /html command that allows one to send raw HTML. Note that an actually displayed HTML subset entirely depends on the receiving client; no HTML validation or sanitation is done; a plaintext version is automatically created by stripping all the HTML tags.

🔗neo

f0x is working on Neo again:

added emotes, working localecho and /rainbow

rainbows :D

🔗matrix-logger

A useful tool from CromFr for anyone who wants to archive logs of rooms.

I wrote a small matrix "client" for logging messages in joined rooms, and store them in a format very similar to Weechat logs. Source code (Rust) Binary release (x86_64 windows & linux) Please open issues if encounter any bug or need specific features.\nAlso I'm new to rust, so any review / advice would be appreciated :)

🔗Matrique client progress

Black Hat has been working on Matrique, and it's looking really good! Screenshot below.

Matrique now has support for sending/receiving messages (plaintext, markdown, HTML, rainbow), emotes and notices. It also supports receiving images, videos, files and states. I am still working on file receiving functions.

I love that all clients include rainbow messages.

🔗fluffychat for Ubuntu Touch

New to me, fluffychat is a "Simple Matrix Messenger for Ubuntu Touch". The design philosophy for this app is focused on simplicity, and the hope is for it to complement uMatriks, another Ubuntu Touch client.

Why are you not just contributing to uMatriks? uMatriks is great and it's superb, that someone has created a Matrix Client for Ubuntu Touch. But sometimes you have a so detailed vision of a user interface, which you want to implement, that you can not just contribute to an existing project. However, I would like to work with the uMatriks developers together. We could use the same push gateway for example.

🔗Riot/Web

• Welcomed Bruno onto the Riot/Web team! (and said farewell to Luke)
• Lots of bug blitzing
• Riot 0.16 due next week, with Jitsi-everywhere (at last) and Slate for composer.
• We now have an end-to-end test harness (via puppeteer!) at last - being applied at first to fix onboarding bugs.
• Lazy loading members in progress

🔗Riot/Mobile

• Major perf work ongoing
• Decoupling members from state…
• …and then lazyloading members.

🔗Synapse 0.32.2 available

v0.32.2 is now available, which includes the m.room.server_acl security feature discussed in a previous blog post.

• If you're not running 0.32, please upgrade!!
• Python 3 progresses!
• Quite a lot of ops work to keep matrix.org alive. Status page coming soon! (We promise!!)
• Looking at metrics and quotas for better experiences on limited-resource homeservers.

🔗Spec

• State res fix
• Version bump
• Lots of omission PRs landing
• TravisR S2S work
• Work on both IS & AS API too
• Uhoreg work - .well-known, and 3pid logins
• Some internal discussions about improving the proposal process; particularly having a 5 day 'final comment period' similar to Rust's. Once we've got alignment within the core spec team we'll MSC it.

🔗Dendrite

• Anoa & APwhitehat continue to blitz onwards on AS and federation
• thirdparty protocol support for application services in the works.
• continued progress on getting the AS query APIs supported. PR for /alias still being reviewed, PR for /users happened this week and now being reviewed
• Timestamp massaging for application services ready and in review
• APWhiteHat did a good chunk on federation, now migrating to supporting the various EDUs, starting with m.typing events.
• …running out of low hanging fruit…

🔗AS

• matrix-appservice-irc 0.9.1 is here with perf improvements!
• Lots of work on trying to make it start up sooner

🔗E2E

• UISI stats
• Device list syncing
• Encrypted backup

🔗Debian Packages

andrewsh has packaged synapse 0.32.2 for Debian

uhoreg has packaged quaternion 0.0.9.2 for Debian

🔗That's all folks

Watch Matrix Live below, and see you next week!

Folks, Synapse 0.32.0 is an important security update: please upgrade as soon as you can.

The release focuses on security; fixing several federation bugs and adding new features for countering abuse. Notably it includes the ability to blacklist & whitelist servers allowed to send events to a room on a per-room basis via the new m.room.server_acl state event: see MSC1383 for details.  This also closes out https://github.com/matrix-org/matrix-doc/issues/709 - one of our oldest feature requests from users who wish to be able to limit the servers allowed to participate in a given room.

It's important to understand that server ACLs only work if all the servers participating in the room honour them.  In future this will be handled better (as part of ongoing work in making it easier to incrementally version and upgrade the federation protocol).  This means that for the ACLs to work, any servers which don't yet implement ACLs (e.g. older Synapses) have to be ACL'd from the room for the access control to work.   Therefore please upgrade as soon as possible to avoid this problem.

This ongoing flurry of security work is in general all part of moving towards the long-awaited stable release of the Server-Server API. In parallel we've been working on the other main outstanding point: State Resets (i.e. scenarios where you get unexpected results when resolving conflicts between different servers' copies of a room).  There will be a few more major changes and upgrades on the horizon as we fix these, but then we'll finally be able to cut an r0 release of the Server-Server API and Matrix will be one massive step closer to being out of beta!

As always, you can get the new update from https://github.com/matrix-org/synapse/releases/tag/v0.32.1  or any of the sources mentioned at https://github.com/matrix-org/synapse.

🔗Changes in synapse v0.32.0 (2018-07-06)

No changes since 0.32.0rc1

🔗Synapse 0.32.0rc1 (2018-07-05)

🔗Features

• Add blacklist & whitelist of servers allowed to send events to a room via m.room.server_acl event. (merge)
• Cache factor override system for specific caches (#3334)
• Add metrics to track appservice transactions (#3344)
• Try to log more helpful info when a sig verification fails (#3372)
• Synapse now uses the best performing JSON encoder/decoder according to your runtime (simplejson on CPython, stdlib json on PyPy). (#3462)
• Add optional ip_range_whitelist param to AS registration files to lock AS IP access (#3465)
• Reject invalid server names in federation requests (#3480)
• Reject invalid server names in homeserver.yaml (#3483)

🔗Bugfixes

• Strip access_token from outgoing requests (#3327)
• Redact AS tokens in logs (#3349)
• Fix federation backfill from SQLite servers (#3355)
• Fix event-purge-by-ts admin API (#3363)
• Fix event filtering in get_missing_events handler (#3371)
• Synapse is now stricter regarding accepting events which it cannot retrieve the prev_events for. (#3456)
• Fix bug where synapse would explode when receiving unicode in HTTP User-Agent header (#3470)
• Invalidate cache on correct thread to avoid race (#3473)

🔗Improved Documentation

• doc/postgres.rst: fix display of the last command block. Thanks to @ArchangeGabriel! (#3340)

🔗Deprecations and Removals

• Remove was_forgotten_at (#3324)

🔗Misc

• #3332 #3341 #3347 #3348 #3356 #3385 #3446 #3447 #3467 #3474

🔗matrix-synapse for Docker and k8s

Ananace has been working on configuration files for Synapse:

So now the K8s stuff has configuration examples for Synapse + Riot + mxisd + coturn, all runnable on your very own Kubernetes cluster - though with some manual tinkering required at the moment.
I've updated the Kubernetes configuration examples to include everything you need for a full Matrix stack; Synapse + Riot + mxisd - using the built-in K8s ingress
And + coturn of course, not to forget

Take a look: https://github.com/ananace/matrix-synapse

🔗mautrix-telegram is now the primary Telegram bridge on t2bot.io

TravisR:

t2bot.io is now running mautrix-telegram as the primary Telegram bridge. Feel free to join the other 10k users on the bridge and bridge your own Telegram group to your room: https://t2bot.io/telegram/.

We should give a big shout of thanks to tulir for his consistent and continued work on mautrix-telegram.

🔗Debian packaging

andrewsh:

I'm packaging Circle IRC/Matrix client for Debian and backporting synapse to stable.

🔗Google Summer of Code

The second evaluation for GSOC 2018 is nearly here, so we have some updates from the student participants:

🔗apwhitehat is working on Dendrite

Dendrite updates for TWIM (before GSoC 2nd eval): This month we've got most of the federation APIs working on Dendrite. These are:

• State APIs #486
• Get missing events API #516
• Query user devices #498

We still need to figure out pagination for backfill API.

On applications services, we've got a lot of APIs working, thanks to anoa. Authentication now acknowledges App services, though lot of other stuff is under review. I am eagerly waiting for it to land.

On the same topic, anoa says:

We've had a PR from fadeAce/dirichlet_zby for the server-side implementation of end-to-end encryption support in Dendrite. Will be looking forward to seeing that land as well.

There is an explanation of the endpoints required for this in the CS API docs.

🔗Zil0 is working on E2E in the Python SDK

Sounds like Zil0 has been going great guns on the matrix-python-sdk:

Encryption in matrix-python-sdk should now work fairly well.
The biggest parts to write were device tracking and key persistence. All the PRs are now opened, and the code is fully tested and documented.
It is possible to try out the implementation before it lands by referring to instructions written here.
Also a special thanks to poljar for some great work on new Olm bindings, which allowed the project not to get stuck with packaging issues.
Further work include encrypted attachments, device verification and key sharing.

🔗koma, kotlin client

Last week I mistakenly referred to Koma as being written in Rust, then Java. This was all incorrect, though being written in Kotlin, Koma does run on the JVM and use JavaFx.

sideboat:

This week in koma, we are improving the room info window used for viewing and editing the name, icon, and aliases of a room. In the upcoming release, user power levels will be taken into account, so that editing options will only be shown when the user has enough power.

🔗Synapse

Neil says:

We've just cut the next release candidate for Synapse: 0.32.0rc1.
The upcoming release focuses almost entirely on security; fixing federation bugs and adding new features for countering abuse.

🔗Riot

This week we welcome Bruno to the Riot team, he's off and away working on getting integration tests set up.

Otherwise:

• More work on the Jitsi integration
• More work troubleshooting E2E failures
• v0.15.6 and v0.15.7-rc.1 now available

🔗Self-reference

This week was only six days long, but to make up for it we'll have a bumper eight day edition next time! Come join us in #TWIM:matrix.org and share what you've made.

🔗Welcome

Welcome to This Week in Matrix, let's see what updates the community has to offer this week!

🔗koma

Announcing his update nearly a week ago, radicus released v0.7.3 of koma.

There have been quite some changes since updates of the project were last posted, but the major ones are:

• Upgrade to JavaFx 9
• Experimental support for infinite scroll on message list
• Rewrite ListView to improve performance and reduce jar file size

🔗dialogflow connector

vurpo has released matrix-dialogflow, which allow the use of DialogFlow agents as chatbots:

I've written a little bot for connecting a DialogFlow agent to Matrix as a chatbot. I did this for my own personal purposes but I know someone else might find this handy as well.

🔗mautrix-telegram

tulir:

New stuff in mautrix-telegram:

• A basic telematrix database import script
• Improved config for relaybot message formatting, including the option to use Matrix displaynames (instead of just mxid localparts) I've also been planning an improved Matrix->Telegram formatting converter and a provisioning API for integration managers like Dimension.

🔗jmsdk

ma1uta has been working on a matrix client this week. To that end, he has implemented jmsdk, a "very early version of the matrix sdk and common classes (client, bot, …)"

Currently implemented the matrix client on the java with full support of the C2S API. It still under development and contains bugs.

He has also been working on a "bot sdk with core classes to write custom bots and appservices."

🔗matrix-appservice-voip

Max has been working on VoIP bridging between Matrix and regular phones using Freeswitch:

We have successful VoIP bridging between Matrix and regular phones using Freeswitch, for 1:1, both directions! a v0.1 is scheduled in a few days once configuration is possible and a getting started doc is written.

Next steps:

• more voice backends (think Jitsi, etc.)
• SMS support with Twilio and/or OVH initially
• mxisd integration to automatically invite bridge users if needed and suggest bridge users
• mxgwd integration to auto-join HS regular users if a VoIP bridge user invites them, so > calls are directly seen
• And much more in later releases

Join #matrix-appservice-voip:kamax.io for more info, or visit the Github repo

🔗transform

A wild bettiah appeared, announced a completely new homeserver implementation in TypeScript:

I have been working on a homeserver implementation over at https://github.com/bettiah/transform . It is fairly basic at the moment, but the development experience is straight-forward and even fun.

I'm interested to see a TypeScript backend running, and of course it's great to have more homeserver implementations! Some highlights from the readme:

Transform is a matrix homeserver built using Typescript and Redis. It is not fully functional yet. Status: Register, Login, CreateRoom, Invite & Join seem to be functional with riot web client. But quite a lot of functionality is missing and the software is definitely not ready for deployment in a public facing role. Design: A lot of the code is auto-generated from the excellent swagger specs for the client-server api. Contributing: It is early days yet. However, Typescript has enabled safe & rapid progress. Redis streams too seem to have a very well thought out api and the whole thing has been a fun experience so far. Contributions are very welcome.

🔗dsn-traveller source code released!

Good news for those following the progress of dsn-traveller, the source is now publicly available!

From Florian:

I received permission to publish the source code of the DSN Traveller bot (https://dsn-traveller.dsn.scc.kit.edu/) prior to handing in my thesis: You can find it at https://github.com/florianjacob/dsn-traveller, it's written with ruma-client and Rust async/await.

Room remains at #dsn-traveller:dsn-traveller.dsn.scc.kit.edu.

🔗E2E for Python SDK

Late breaking, but not itself broken, &Adam has news from matrix-python-sdk:

first olm-centered E2E PR for the python sdk merged to master (finally). Lots of great work from Zil0 still to be merged waiting on PR review. https://github.com/matrix-org/matrix-python-sdk/pull/224

🔗Fractal

From Tobias:

No new Fractal release this week. Development was quite active nevertheless, with Jordan's new inline audio player landing in master, Julian getting close to landing the first part of the new room settings, and Eisha working on improving the image viewer.

🔗Riot

• New Release! v15.6 - https://github.com/vector-im/riot-web/releases/tag/v0.15.6
• Jitsi by default for Video calls
• Replies to messages
• New room sharing feature

🔗New Rooms

• #matrix.fi:matrix.org - a room for Finnish speakers

🔗And so…

All good things must come to an end, so it is with this blog post! Watch this week's Matrix Live (hosted by yours truly) below, and come see us in #twim:matrix.org!

[Ben is away today, so this week's edition is compiled again by Matthew]

🔗libQMatrixClient 0.3.0.2 and Quaternion 0.0.9.2

kitsune writes:

libQMatrixClient 0.3.0.2 has been released - no new features, just small fixes including one for an unlucky typo preventing 0.3.0.1 from generating .cpp files with GTAD.

Quaternion 0.0.9.2 is out, another step towards 0.1. Aside from bugfixes and using the latest libQMatrixClient, it features an entirely new timeline layout similar to that of Riot (the old one is still around too). Also, you can now change some settings through the menu rather than by editing a configuration file or registry - including switching timeline layouts on the fly!

🔗Loading Artist sticker packs!

TravisR says:

The Official Loading Artist sticker pack got added to Dimension ?

It also got added to Modular (aka Scalar), the default integration manager for Riot :)

🔗releasetracker

Ananace writes:

Decided to actually start pushing code I've been slowly prodding at for the last while, ever since starting the Ruby Matrix SDK in fact. Working on a Sibbell like system that tracks new releases on GitHub projects, posting them into a specified Matrix room.

The release tracker now tracks both full releases and just regular tags, though only one or the other at the moment.

Spun up a proper room for the release tracker, in case people want to help development / feel like using hosted alpha-level software more than running it themselves. #releasetracker:kittenface.studio

🔗jeon and jmsdk updates

ma1uta writes about his jeon Java HS, jmsdk and Matrix spec work:

I reorganized my projects and extracted the sdk from the api. So, today I have one project for the api (https://github.com/ma1uta/jeon), another for the sdk (https://github.com/ma1uta/jmsdk) but last is very early and non-usable.
Also I covered the code with the swagger-annotation and now I can generate the swagger schema from the code. There is an example: https://github.com/ma1uta/jeon/blob/master/client-api/generated/swagger-ui/swagger.json
And there is an example of the spec was generated from swagger: https://ma1uta.github.io/matrix-api.html (plain and without sorting or grouping, I'll maybe fix it).
Everyone can ask me in the #jeon:matrix.org (matrix api) or #mxtoot:matrix.org (matrix-mastodon bridge).
Then I want to cover the remaining api (appservice, push, identity but not federation because it isn't completed yet), write sdk (client, bot). And publish api and sdk on the maven central repository.

🔗CI/CD for Plasma!

Nico gives updates on Plasma, the new Scala/Akka homeserver:

I've setup CI/CD for plasma HS. Now every time a push occur on the repo, the pipeline builds and deploys a plasma HS instance on a test server.
This test instance is reachable at http://matrix.beerfactory.org:9000. For now it is very modest and can only reply to a few C2S endpoints like GET /_matrix/client/versions. POST /_matrix/client/r0/login and POST /_matrix/client/r0/register are also available for testing registration and login flow. POST /_matrix/client/r0/createRoom is also available with the TEST_TOKEN auth token value, but it's only a mock.
I'm now working on implementing the concept of room servers: each room will be managed by a dedicated room server (an actor), so they get fault tolerance and scalability by default (through akka clustering).
There's also a dedicated room for this project : #plasma:beerfactory.org

🔗matrix-python-sdk 0.3.2

&Adam says:

v0.3.2 of matrix-python-sdk released. See the github release for list of changes. (v0.3.0 and v0.3.1 are substantially the same with small formatting errors). There are a lot of hugely annoying bugs fixed in this one, so upgrading soon is recommended.

There's also been a lot of work on adding E2E to the python-sdk from Zil0 and his GSoC project!

🔗gomatrixclient

Black Hat writes:

I am currently writing a high-level API on top of gomatrix. As gomatrix is suitable for bots but not for clients, I decided to write a layer above it. (The motivation is to provide a backend for Matrique) It will have similar API as libqmatrixclient, but in Golang. It is currently under heavy development, and API breaking changes are frequent. Sources are available in Gitlab: https://gitlab.com/b0/gomatrixclientP.s. It is a library for writing clients in Golang. But it also provides useful APIs for basic functions, e.g. getting avatars.

🔗Fractal 3.29.1

Tobias says: New Fractal release 3.29.1, which includes a Eisha's new image viewer [implemented as part of GSoC]!

It looks like this (screenshot being a screenshot of, uh, last week's screenshot, for maximum fractalception...)

🔗Terraform Provider

TravisR writes:

I've been working on a Terraform provider for matrix. It is still a work in progress, however I plan to have the basics completed in the coming days. The provider gives you the opportunity to create users, rooms, and other objects on your homeserver, making your homeserver part of your infrastructure. This could be useful for people who want to set up a monitoring room, or for setting up default rooms on a homeserver instance. In particular, this provider will be used by the monitor bot (see last week's post) to set up the test homeservers for seeing how the bot scales with increased server counts. Source and information available on Github: https://github.com/turt2live/terraform-provider-matrix

🔗mxtoot 0.4.3

ma1uta says:

I've fixed a few bugs and added some new commands (show status by id and show n-last statuses), and now mxtoot 0.4.3 (Matrix-Mastodon bridge) can send public, private, unlisted and direct messages. There are 4 features left to go:

• show, add and remove follows;
• show threads;
• show notification, public and federated lines (and optionally merge them with the home timeline);
• show account info by id.

Also I think to implement a bridge Matrix-ActivityPub as S2S. For example, a room - is a ActivityPub's actor. Room participants is a bot corresponds to actors you follow to. Room timeline is a Inbox+Outbox. Reactions is a likes/favorites. Pinning message is a boost. Replies will be very useful.

🔗mautrix-telegram now puppets via user-specific relay bots!

tulir sneaks in at the last minute with:

mautrix-telegram now supports logging in with your own bot. It means that you can look almost like a real user and even use direct messages without logging in with your real Telegram account!

🔗And finally...

On the core team it's been an irregular week; as mentioned in last TWIM we spent most of it in workshops working through spec issues as part of the mission to finally get to an 'r0' stable release of the spec across all APIs - not just the Client/Server API.  The majority of this was spent making up for lost time on the S2S API, analysing its various holes and designing solutions to them.  Things are looking promising - we're keeping the work under wraps though given the potential for abuse, although we should see more gaps being fixed in the coming days.  Meanwhile we're aiming to get the r0 stable release out by the end of August.  We also unblocked a few longstanding MSCs (.well-known URIs and media limits), although in the end the S2S stuff took priority.  On the client side we did a lot of design sessions on Riot/Mobile (working out how the new app design should work on Mobile - watch this space for details!) and also how to speed up app launch (the concept of Hybrid Sync; somewhere between an initial sync and an incremental sync - basically an initial sync which can be interrupted in order to let the user use the app whilst the initial sync is still ongoing) - we'll write up the notes and publish these asap.

We also announced the Open Governance work which we've been doing in order to extend control of the Matrix spec to properly include the wider Matrix community - the plan is to get the Matrix.org Foundation legal entity set up roughly around the same time as the r0 release of the spec in August, and formally decouple control of the Matrix spec from New Vector (the company we set up last year to hire the core team).

We'd also like to welcome mujx (developer of nheko) and kitsune (developer of Quaternion and libQMatrixClient) to the new core team as we start trialling the new governance structure (which mainly amounts at this point to getting review approvals on spec proposals and changes from the relevant domain experts on the new team).  This brings us to a full complement for the team: Erik (servers), richvdh (servers, crypto & clients), Dave (clients & push/identity) and uhoreg (crypto, general) from the current core team; and Anoa (servers, AS API), TravisR (integrations, AS API; acting with Dimension hat on), mujx & kitsune from the community.

Otherwise, spec work has taken priority over writing software, with the exception of: APwhitehat doing as much federation work in Dendrite as part of GSoC as the current unstable state of the API allows; Michael (t3chguy) has been blitzing through P1 Riot/Web issues.  Next week should be back on the normal (if not better!) trajectory however.  No Matrix Live this week however, as we're all exhausted.

Hi all,

Since we created Matrix.org back in 2014, the majority of the Matrix core team has worked for the same company - originally subsidiaries of Amdocs, and then since August 2017 for New Vector; the startup we incorporated to rehire the core team and support Matrix after we parted ways from Amdocs.

Despite working for a for-profit company, our prime directive has always been the long term mission to successfully run Matrix as a non-profit initiative for the benefit of the whole internet: to create a ubiquitous secure open network which gives users control back over their communication and avoids them ever being locked into silos again.  And even though Matrix.org hasn't been a formal non-profit foundation, we've treated it as such in all respects (e.g. gathering donations to support development on Matrix)

Running Matrix.org as a non-profit means prioritising to neutrally support all players in the whole ecosystem without ever giving unfair advantage to any individual participant (particularly New Vector) - where that ecosystem includes end-users, client devs, testers, spec devs, server admins, companies building products on Matrix, bridge devs, bot devs, widget devs, server devs, distro maintainers, moderators, even end-users who are using Matrix indirectly via bridges.

That being said, having the core team work for the same startup is still a somewhat unorthodox model for an open source project building an open standard, so we'd like to explain the main reasons for doing it up to this point:

• To ensure that Matrix is fit for real-world usage and to force us to dogfood it. To ensure that it is a protocol that works well enough that you can build a commercial startup around it if you so wanted, and to motivate us to build Matrix as something more than an academic or nerdy exercise in protocol design - rather one which can be commercially viable.
• To help ensure the core team is aligned and pulling towards the same goal, especially during the process of actually designing and “giving birth” to the initial protocol and getting it to an ‘r0' release across all APIs.  We strongly believe that when a project is in the design phase you get faster and better design from a bunch of people who are collaborating together towards the same goal, rather than independent factions who might pursue their own agendas at the expense of the overall project.
• Because we believe the value of Matrix lies in the size of the ecosystem, and if Matrix realises its full potential (i.e. it grows as big as the web), it only makes it more useful and valuable for *everyone*. We realise that it might be a leap of faith to believe that we don't have any incentive to sabotage Matrix by privileging specific players (after all, there are so many companies out there in it just for the cash), but the fact is that this is where we stand, and we're doing our best to prove it. To spell it out: it is in New Vector's interest (and also in the interests of other Matrix-focused companies) to grow Matrix to be as big, open, unfragmented and as neutral as possible.  Matrix should be big enough for a multitude of wildly successful companies and projects to benefit from it, and everyone wins - just like the web.

However, this approach is not perfect and comes with some major problems:

• Without clear separation of responsibilities and incentives, we have to ask the community to take it on faith that our efforts are never intended to privilege New Vector ahead of the wider ecosystem. This leaves room for doubt, especially when our reasoning is unclear or our conclusions controversial.
  A good example of a controversial decision is the lack of investment by the core team in the Server-Server API.  For the last ~2 years (since Mar 2016) we made the judgement call to prioritise user-facing features and experience.  The rationale was that to grow Matrix we need to provide a viable alternative to Slack/Discord/WhatsApp etc, and doing that means providing a Client-Server API which lets clients do just that, and server implementations capable of running at scale. This is why the CS API has had a stable release since Dec 2015 (currently at r0.3.0) and why we've put so much effort into server scaling/perf... but the SS API itself still has bugs and has still not yet made it to a stable release.
  This is obviously incredibly frustrating to server devs who tried to implement the SS API despite it being unstable and unreleased. In retrospect it might have been a mistake and we could probably have turned off signup on matrix.org and diverted the resources to the SS API work instead.  However, this is a case of making the judgement call to prioritising the overall ecosystem over one class of stakeholders (server devs) by focusing on providing users usable and featureful decentralised communication apps. Indeed we strongly believe that users are the main means to grow the ecosystem (others have failed without them): no one joins a network with no friends, however popular it is among devs.  Nonetheless, we are finally in a position to hire spec maintainers and get to a stable S2S as fast as we possibly can, and frankly feel relieved to be able to unblock this situation.
  Another good example is the recent 0.31.2 security update of Synapse: this was a defensive patch to the protocol that we added to ensure that even if bugs occur when authing events over federation, it should be impossible for a random user to ever hijack a room again.  We specced this out as a formal proposal and are gathering feedback, but expedited implementation in Synapse to protect the overall ecosystem. However, it turns out that the change breaks a small number of highly custom rooms, and so we find ourselves accused of privileging NV.  The reality is that we made a judgement call to protect the vast majority of today's ecosystem (and hope to provide a longer-term fix in the relatively near future which /will/ be compatible with more custom room use cases).
• Another problem is some companies find it a turn-off to participate in Matrix unless they have a well-defined process for influencing the direction of the protocol.  Now, sometimes this could be seen as a feature rather than a bug; the last thing the ecosystem needs is a greedy corp trying to subvert the protocol to its own competitive advantage, and we don't want to be locked in that kind of battle either.  However, there are also lots of well-meaning and constructive companies who want to participate too, and there's an argument that they want a well-defined process for doing so.
• The other main problem is simply one of checks & balances.  Even though NV may be a good guardian today, what if something changed in future? e.g. if NV got bought by Microsoft, or if someone on the team had some crisis and changed priorities?  Whilst one could always fork, such things are incredibly disruptive and fragmenting and it'd be good to engineer Matrix.org's governance to be resilient to such eventualities as much as is possible.

To address these problems, in March of this year we started work on a long term proposal to establish an open governance model for Matrix which ensures the neutrality of the protocol, lets the community contribute as widely as possible, and incorporates a dedicated neutral non-profit Matrix.org Foundation separate to New Vector.

As work progressed on the proposal, it became clear that actually transitioning to a new governance model would seriously slow down the sprint towards a stable r0 release. We therefore decided to put completing the governance model on hold until after the r0 release (scheduled for the end of August).

With the end of r0 now in sight, completing work on the governance model is back on the agenda. We obviously want to ensure that the proposed governance model is going to work for everyone, so we'd like to introduce the first draft of Matrix Spec Change 1318: a proposal for open governance of the Matrix.org Spec. This is quite an early draft; the idea is to gather feedback over the next few months and we'll then incorporate the Foundation and deploy the new governance model to coincide with the long-awaited stable release of all APIs of the Matrix Spec (assuming the release doesn't slip).

The main points in the proposal are:

• To adopt the new governance model once all APIs have had a stable r0 release.  For S2S API, this means fixing the remaining flaws in the federation protocol and closing the spec omissions such that compliant independent implementations can be written purely based on the spec.  For the AS and IS and Push API it means just closing spec omissions (if any) and doing a final review.
• To define the mission of Matrix: to return control of communication to users by building a standards-based open secure decentralised communication network.
• To define the mandate of the core team to act as a neutral custodian of the Matrix Spec, prioritising the long-term success and growth of the overall network over individual commercial concerns.
• To define the guiding principles of the core team, e.g. collaboration rather than competition and contrarianism.
• To restructure the core team to incorporate members of the community as well as the founding core team.
• To propose succession logistics for the core team
• To propose the role and governance structure of the Matrix.org Foundation legal entity.

Feedback would be much appreciated on the MSC1318 Google Doc - or come talk about it on  #matrix-spec-process:matrix.org (which we might as well use for governance too).

It's exciting times as we finally move towards an initial stable release of Matrix across all APIs - we are firmly on the road to a 1.0, and improving our governance model is a massive part of that process.

thanks,

Matthew, Amandine & the core team.