Synapse 0.33.0 is here!!

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

This Week in Matrix 2018-07-13

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 / advices 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!

This Week In Matrix 2018-06-22

[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/versionsPOST /_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/gomatrixclient
P.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.

Towards open governance for Matrix.org

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.

This Week In Matrix 2018-06-15

[Ben is out this week, so this week’s TWIM has been hastily assembled without the usual love and care by Matthew instead]

TravisR joins the core team!

First off: we’re super-excited to announce that TravisR is joining the core team on July 3rd, hired to work fulltime on maintaining the Matrix spec and improving Riot/Web (including helping implement the new redesign!). Travis has been one of the most prolific independent contributors to Matrix, between his own 40 personal projects and massive bug & PR contributions to matrix-react-sdk, riot-web and the spec), and we can’t wait for him to be able to finally work on Matrix full-time.  Between TravisR and uhoreg we now have two more people who can focus on improving the spec and help fix the backlog we’ve accumulated there – exciting times :D

Nheko now supports E2E Encryption!!!

In other massive news, mujx has an initial cut of functional megolm E2E encryption working on the e2ee branch of nheko!  This also inclues a massive refactor of the whole app into a generic boost::asio based (and e2e-capable!) mtxclient library. There are still a lot of edge cases to sort out before the branch is merged to master, but the core tech works as you can see in the video below (which we’ve had to speed up by 3x because matrix.org is so overloaded this afternoon :|)  Massive congratulations to mujx and everyone else who has worked on this – it’s incredibly exciting to see 3rd party implementations of Matrix’s E2E encryption evolving.

Seaglass

The elegant macOS native client entered the second week of its existence!  Seaglass is now released under AGPLv3, and has lots more refinements – Markdown support, UTF8 bugfixes, Bubble UI and more!
There’s also experimentation on the horizon to use NSWebKit rather than NSAttributedString for rendering. For more info, join #seaglass:matrix.org.

Fractal

Tobias Bernard tells us that Fractal 3.29.0 was released: “our first release following the GNOME versioning scheme. It includes Eisha’s redesigned room directory, and the all-new account settings by Julian. Daniel worked on adding a message queue, which makes Fractal much more usable on slow internet connections.”.  And here’s a pic of the new room directory!

 

Useful Gists!

TravisR shared a bunch of useful gists for including in upcoming guides rework:
* https://gist.github.com/turt2live/f7e33017e72a83905f7f6acae31f4143 <– how to set a default ‘tint’ colourscheme on riot
* https://gist.github.com/turt2live/697d5b3781fb7ab7e11d704ea90e3dbe <– how to set custom tags on a room
* https://gist.github.com/Matrixcoffee/73e84990c29a2f26ece7f09e0bc39bfa <– how to configure RSS bot without a client

hacklab.fi

Vurpo says: I successfully set up our hacklab.fi Matrix server (+ invite registration links using ZerataX’s system that we saw here a while back) and demo’d it to our crowd here at Helsinki Hacklab – also got some people on the server and testing it out, and I’d say it was in general a success! https://matrix.hacklab.fi/register.html

gomuks and maubot!

Tulir says: 🌈 TWIM: Its pride month, so I added font tag support and a command to gomuks!

I’m also working on a plugin-based matrix bot system. It’s not very usable yet, but I did just get a hello world type bot to be loaded at runtime and respond to my ping. https://github.com/maubot/maubot

It’s plugin-based (as in load at runtime) and I’m planning to make the message formatting/ui better than what go-neb does currently

Neo

f0x announces Neo Release 0.07, with HTML and Markdown support, both sending and displaying. Usability fixes such as entertosend on mediaImprovements with sending replies.

It looks like 90’s mIRC aesthetic colour codes are here to stay in Matrix if folks want them ;)

Alias Bot

TravisR says: Alias Bot got a v1 release this week, whatever that means to you. More information can be found in the changelog: https://github.com/turt2live/matrix-alias-bot/releases/tag/v1.0.0

matrix-monitor-bot

More from TravisR: https://lag.t2bot.io/ shows end-to-end message latency within Matrix as seen from different hosts. The Matrix.org HS is missing from the list currently due to concerns over the additional load that the e2e traffic could produce – for more on the load problem: people may be generally interested in watching this issue: (which, when will eventually have all the raw data available for people to play with)

mxhsd

Max says: mxhsd is no longer a thing within the Matrix world and will follow a fork of the protocol instead.

Synapse

Lots of time spent looking at federation auth behaviour after Monday’s hijack on #matrix:matrix.org.
Security bug release for 0.31.2 in order to fail-safe rather than fail-deadly in the event of any further hijack attempts.
GDPR erasure work continues…
Lazyloading membership proposal now has full sytest coverage; just needs a solution for calculating room names serverside (MSC688)
hawkowl has been working away at improving our unit testing in order to have more confidence in ongoing python2->python3 porting work
Security work is taking priority over performance work though, so apologies that Matrix.org is going to keep being overloaded for a while longer :|

Dendrite

Breakthroughs on implementing the AS API!
Anoa has first traffic flowing back and forth between Dendrite and Discord!

Meanwhile, APwhitehat is filling in gaps on the S2S API where possible (and is as anxious as all the other HS implementers out there to have a fully documented S2S API release at last!)

Riot/Mobile

Implementing E2E key requests is almost finished on both iOS & Android
Lots of perf work ongoing – e.g. Realm on Android and UI thread profiling on iOS (turns out read receipt animations are way slower than they should be)

Unfortunately the GSoC project for implementing alternative push mechanisms (i.e. free alternatives to GCM/FCM/APNS) hasn’t worked out. We would love contributors to pick it up however – https://docs.google.com/document/d/1ULOMnR7YehCJD-VCYplWC3e9KRZynSgUo5wk-nwnzds is a Google Doc which lists various possible approaches.  This is a really important project; please get in touch with Matthew or Dave if you want to help make it happen!

Riot/Web

Residual GDPR erasure work ongoing and generally distracting from everything
Lots of E2E-capable antivirus work (more details coming soon)
The big PR to replace Draft with Slate for rich-text editing is reviewed and almost ready for merge
Lots of P1 bug fixing from t3chguy
matrix-search is pretty much ready to go!

E2E Crypto

uhoreg is making good progress with adding PKI APIs to libolm to support better key verification, incremental megolm backup, and encrypting keydata when doing serverside antivirus scanning of e2e attachments!
zil0 is also making good progress with adding E2E support to matrix-python-sdk in GSoC, gluing together libolm’s python bindings with matrix-python-sdk to all the intermediary key management and device management required to make megolm actually work with python!

Spec

Lots of work from TravisR on the spec, including a new proposal for managing ASes via API
Lots of new MSCs and PRs:
* MSC688 Proposal to calculate room names server-side
* MSC1301 Proposal for improving authorization for the matrix profile API
* MSC1304 Proposal to simplify the auth rules of m.room.power_level events.
* MSC1306 Proposal to filter out traffic to Appservices based on filters
* MSC1308 Proposal for speeding up review of simple spec changes
* MSC1309 Proposal for for an application service management API

Controversy over process and the fact that S2S API has stagnated.

There have been some accusations from displeased HS implementors that the lack of S2S API progress from the core team is malicious and some kind of attempt to disadvantage independent server implementations.  This is categorically not true.  Instead, it is a case of prioritising user-facing and client-dev facing stuff (scaling, performance, keeping matrix.org online, CS API, client features, bridging, AS API etc) on the basis that the network is nothing without users, and that we had to prioritise thanks to the core team shrinking by ~5 people during the funding crisis at the end of the last year. Matrix is an open network, and an open standard, and we want to build the world’s biggest open network for realtime communication – ideally as big as the web itself.  There should be room in that network for many companies to exist and thrive, just as on the web, and we would never ever risk sabotaging the success of the wider Matrix network in order to give any single company an unfair advantage.

However, it’s certainly true that S2S API has ended up stagnating for way too long, which is why we’ve been hiring folks to help with spec bandwidth (uhoreg & TravisR), at which point we finally have bandwidth to make consistent progress again.

On that note, lots of work spec work (especially S2S API) planned next week.

And finally…

Here’s me and Amandine chatting through the core team bits of the above for those who prefer a podcast format to a blog post: Matrix Live S02E23!