This previous bit of time for Gnuxie & Draupnir, March-April 2024.

Table of Contents

Introduction

Since the previous update, I've been focussing on getting Draupnir's MPS backend not only into the main branch, which is now complete, but also a release. The merge for the backend completed with compromise, there are a number of issues to follow up on. We also have significantly less test coverage than I had hoped1, as some of the goals laid out in the previous update about testing are unachievable within the time I have left to spare keeping this project in active development2.

Despite all of this, there are still relatively few issues, and even the first development images were surprisingly stable.

Draupnir v2.0.0-beta.*

We have now prepared a beta pre-release channel for Draupnir v2.0.0, which can be found on the Draupnir releases page.

For the changes, you should see the notes for v2.0.0-beta.0 but don't forget that there is a more recent version to use.

The pre-release has gone smoothly so far, there's been bugs, some of which have been a result of compromise. Though I think we can still be proud compared to other projects, and after all these bugs occurred in the pre-release, not v2.0.0 itself.

Time is running out

In the first update I made, I mentioned how we had applied to NLnet NGI Zero Core. I received written confirmation on April 12th that Draupnir had made it to the final round3. This was a surprise to me but I still do not expect anything to come of it. We weren't counting on any kind of funding to begin with, the whole idea for me was to get 2.0.0 across the line and document as much as I can. Maintenance will continue thereafter but development will not be happening at its current pace. However, should we receive support there is a road-map for further development.

Developments

This is a long section, some parts are more fleshed out than others, so feel free to skim over until you find something interesting.

I do recommend reading the Matrix meta section at the end though, including technocratic geeks who control Matrix and why I did not stand for the governing board.

Draupnir: RedactionSynchronisationProtection

The way redaction works in Mjolnir is basic. When Mjolnir sees a new policy, Mjolnir tests the reason against config.automaticallyRedactForReasons. If the reason within the policy matches against the config, then Mjolnir will begin a painful process of making a request to /messages4 for every protected room with a filter for the user contained within the policy. If any events are found, then a call to /redact5 is made individually for each discovered event.

This is why redaction has been so slow and error prone previously for both Mjolnir and Draupnir. In v2.0.0 we don't do much better, but we have the upper hand in that now we cache state. We can now at least check which rooms the user was actually ever present within before make a request to /messages.

Ideally, we'd provide a timeline cache to protections, which will be useful for all kinds of reasons. But here the timeline cache would not only eliminate redundant calls to /messages, but allow us to check the timeline against all policies, and not just when they are first published.

Draupnir: RoomStateBackingStore

Previous updates have covered how we model room state. revisions, the cost of state tracking, and how changes are calculated.

As Draupnir now caches all of the room state for the rooms that are being protected, we need to be able to initialise that cache somehow when Draupnir starts. Normally this is done by making a request to /state one by one for each room, but this can be very slow. On my homeserver protecting 46 rooms, Draupnir takes roughly a minute to startup. Considering how resilient Draupnir is to crashing these days, this might not sound so bad. Though it has to be remembered that this is for a relatively small rooms. Matrix.org's Mjolnir instance by comparison protects well over 100k users cumulatively, and likely takes many minutes to start up (and many minutes each time that it tries to apply a ban, since the poor thing has to do all that work again as it has no cache).

To try ease some of the pain, I decided to create a backing store for room state. As we already calculate changes to room state over time, it's quite easy for us to just write these changes back as we get them from a RoomStateRevisionIssuer. This works out ok, because even if somehow we miss a set of changes, such that next time Draupnir starts and loads an incorrect view of the room state, then this will be corrected the next time /state gets called. Another thing to note that is if at startup we can't parse an event that is in the store (for example, because the event schema has changed between versions of Draupnir), we just drop the event from the store.

To implement all of this I decided to use better-sqlite3, as the author made some strong claims in regards to the other available libraries, which after some consultation with others we decided probably are true.

Draupnir: Contributing

I can't actually remember what I saw that made me want to redo the contributing documentation, but I saw something and immediately went about updating the Draupnir contributing documentation.

I think what I saw was someone trying to open a PR with another project and being turned away or put off by how unwelcoming the state of a repository was.

Draupnir: Core as protections

The main focus of the MPS (Matrix Protection Suite) rewrite is so that Draupnir's core can be implemented as protections (plugins) on top of a capability based plugin system. We don't use capabilities for security reasons, but modularity reasons6.

RedactionSynchronisationProtection

Mjolnir and Draupnir have a component I wrote called the ProtectedRoomsSet, not to be confused with the ProtectedRoomsSet that MPS now provides. The ProtectedRoomsSet had code to redact the messages of users who were recently banned. So to replace this code we needed a dedicated protection, the RedactionSynchronisationProtection. Ideally, we'd have a timeline model in MPS that the protection can use.

Unfortunately, creating a timeline model and allowing protections to scan the timeline is a huge piece of work that other SDKs have struggled to get right. And we need the redaction behaviour for Draupnir right now. So for now we have a very simple duplication of the same behaviour, where Draupnir will only apply redactions when there has been a recent ban.

MPS: MembershipChange

When I started writing MPS I created a MembershipChange enum, for the membership field of a m.room.member event. We use this while tracking changes to room state to represent how room member's membership has changed between calls to /state. So the MembershipChange represents the change of the membership field for a given member and not the change in the overall membership event. Since we have other enums for detecting changes to the profile information. Unfortunately there are a few issues with this.

If you are observing changes to membership events in the room state, and you for example receive two events with membership: "left", then what are we supposed to infer from this?

Well, the user likely joined and releft, and we never saw the intermediate join event because we didn't poll /state/ while the join was the current state. But equally they could have been invited and rejected the invitation, which would mean the intermediate event would have had a membership of invite. There could even be an entire lifetime of different membership events in the intermediary period which we have no data for.

The only way to fix this is for us to chase the intermediate state by requesting those events individually, probably by depending on the replaces_state field in the event's unsigned data. However, this is not reliable, not all servers provide the replaces_state field. I also don't know how they derive the field, does it mean the previous state from the perspective of our server? or is it derived from power level ordering?

MPS: SafeMembershipEvent and SafeMembershipEventMirror

When testing the main branch prior to the Draupnir-v2.0.0.beta pre-releases, our event parsing code had first contact with the Matrix federation. There were membership events created by clients that contained display_name: null which are invalid. Even if Synapse validated these events in the client-server API, authorisation rules very scarcely explicitly validate event content and reject them. The display_name field is one of the fields that a server can generate invalid events for that must be accepted by conforming homeserver implementations.

Membership events are vital for Draupnir's MemberBanSynchronisation functionality, and it would be terrible if someone could evade a ban by creating membership events that our parser couldn't handle.

Equally, in the future when we create API's for extracting and scanning event media (mostly text), it would be bad if they could evade detection by deliberately failing our strict parsing standards.

This leaves two options, I can force all of the MPS clients to deal with unbounded bullshit in Matrix events, or find some clever solution.

So I developed something called the SafeMembershipEvent.

The way this works is we try parse the redacted version of the membership event first, and then the full version. Any fields that fail to parse are then placed into an object only accessible using the SafeMembershipEventMirror on the SafeMembershipEvent. The same field will then simply be undefined when accessed from the SafeMembershipEvent.

So for example, a membership event with display_name: null will create a SafeMembershipEvent with display_name: undefined7.

We can then access the original value by using SafeMembershipEventMirror.getUnsafeContent(safeMembershipEvent).

MPS: Revision has access to shortcode

Mjolnir has this concept of shortcode which is just a little alias that can be used to refer to a policy list. So for example, CME uses cme-bans as their alias such that you can use the alias anywhere a policy list is expected like so: !draupnir ban @spam:example.com cme-bans spam.

Now this is great, but what happens when there are conflicting shortcodes among the lists your Draupnir is watching? Well it turns out this happens quite often, because matrix.org's code of conduct list is named coc. Additionally, in Mjolnir for all and Draupnir4all, the list that gets created for you has a shortcode of list. Which is very problematic as just watching another d4all user's policy list will immediately cause the alias to conflict each time it is used.

Mjolnir doesn't keep enough information about policy lists to be able to work out a precedence scheme, Draupnir attempts to by figuring out which lists you actually have the power level to edit.

Originally I didn't want to give shortcodes a return in Draupnir-MPS, instead I wanted people to rely on the client auto-complete to find rooms and room aliases for the command. It turns out that when it comes to needing to do this when trying to ban someone is a giant pita, even when ignoring that not every client has auto-complete.

Fortunately bringing shortcodes back was a relatively tiny change.

MPS: ProtectionsManager and ProtectionsConfig

A frequently requested feature for Draupnir was to disable server ACL synchronisation, and this was implemented in v1.85.0 with the setting config.disableServerACL. Now that the functionality to synchronise server ACL is a protection, the ServerBanSynchronisationProtection, this setting would either need to be made obsolete or disable the protection post-startup.

Unfortunately, the matrix protection suite's ProtectionsConfig is not only responsible for enabling and disabling protections, but also reading and writing the associated room state to persist which protections are enabled. Making a change to accept arbitrary changes to the set of enabled protections before the protections were ever enabled would require patching on shit code to an already messy class.

So the solution was to separate these concerns, leaving ProtectionsConfig to simply manage loading/saving the set of enabled protections from persistent storage. Then introducing a ProtectionsManager to create and manage the protection instances from their descriptions and the config. In Draupnir, config.disableServerACL would disable the protection by using the ProtectionsConfig before it is given the the ProtectionsManager.

Loggable config

When debugging problems that system admins encounter while setting up Draupnir, there have been cases where we regrettably have to request the account data8. This was more of an issue for Mjolnir, but caveats remain and regressions mean that there is a risk we would have to do this again in the future. To work around this, I wanted the abstractions that load config from account data or matrix events to be able to log the raw json (or as close to it) when Draupnir exits due to a fatal problem (or a dump is requested by other means).

The way I have implemented this is by requiring these config abstractions to accept a LoggableConfigTracker as a dependency, when they're initialised they will register themselves with the tracker and then we can use the tracker to log all config associated with a Draupnir instance.

MPS: EmptySchema validating everything moment

Not really thinking too much about it, when we were first using TypeBox to create schema, we accidentally started using Type.Object({}) to mean "empty content" or redacted content (when there are no preserved fields). This was a huge mistake of course, since in JSONSchema, this means validate anything as true. We've since replaced this with Type.Object({}, { additionalProperties: false });.

It's a little bit annoying that the shorthand for the true schema seems to be provided by JSONSchema for convenience, when people are forgetful and the meaning is really unsafe.

MPS: PowerLevelsMirror

Remember how Mjolnir and Draupnir had a sync command? Well if you're not using the v2.0.0-beta you won't know what I mean, but it is gone now. If a user needed to use the sync command, it meant that for some reason Mjolnir had just totally misread the room.

The most common reason for this was changing the room power levels after using the rooms add command and Mjolnir complaining at you for not giving it permission. A user would change the power levels so Mjolnir would be happy…. and then nothing, it wouldn't try retry setting server ACL or banning users. This is because Mjolnir didn't know it had been given the correct permissions, that code didn't exist.

So in MPS I have created the PowerLevelsMirror so that we can figure out whether we have certain permissions and compare a current power level event to a previous one.

We use this to now figure out if protections have had their permission requirements met, and call a handle on the protection interface. So now protections will synchronise and apply to rooms as soon as the power levels have been changed, which should eliminate the biggest reason for the sync command existing.

We want to keep the sync command away because ultimately if Draupnir is going to be provided in the future as a bot that runs in the background without user intervention, then it needs to run without being told to sync.

Matrix meta

Fail unsafe FCP (Final Comment Period)

I had noticed at the beginning of April that MSC2870 had entered final comment period. This is a fairly straightforward follow up MSC to mark `allow` and `deny` fields of the server ACL event as protected. Believing that there would be some final review, I wanted to capture the attention that had been sparingly given to server ACLs to try make further improvements to it. I was imagining there would be some final meeting of SCT members, maybe just a final OK where any of the final comments would be discussed. While I didn't raise any issues that would block the MSC, I found that the FCP process is fail unsafe, because no final approval is required. What instead happens is SCT members have only time to interject rather than approve the MSC once FCP is over. The real approval of an MSC happens before FCP, during the vote to enter the final comment period.

You can read the Matrix spec change process here, but if you want to have a discussion, you really need to get your point in as soon as FCP has been proposed rather than started.

MSC4124: Simple Server Authorisation

Given my other attempts at representing servers in the DAG, and my belief that some attention would be given by the SCT to server ACL in the review process of MSC2870, I set about formulating my ideas within MSC4124.

This time, I would propose an authorisation layer that sits above the current authorisation rules that concern room membership.

One of the key features of my proposal is to provide no way for a new server to ever be able to generate activity within a room unless it has been explicitly allowed to do so. This is with one exception, a user on a new server can send a unary knock event for their entire server into a Matrix room to let the room admins (or their Draupnir) approve their server to participate.

So, this is essentially allow list federation, but with the hopes that servers with good reputation will get approved as quickly as they would if the room was entirely open. All without having to use out of band communication or application processes to get onto the allow list.

The main motivation behind this is that currently in Matrix a homeserver can join a room with an unlimited number of generated users and basically trash them. This was quite common in the past and if there is ever an explosion in variety for homeserver implementations then this kind of attack will make a comeback.

I haven't finished writing the context for the MSC, I need to incorporate or appeal to the following issues:

The origin of server ACL and soft failure

The creation of server ACL are worth discussing here. Element were and still are extremely relaxed when it comes to glaring security issues, banking on a threshold that is provided by the esotericism of the knowledge required to exploit rooms and also the resources required to do so. It's also worth noting that the effort required to fix the these exploits is far greater than the effort required to execute them.

As Matrix ages and homeserver implementations become more accessible to contribute to, flaws and exploits become a lot more accessible to abuse. The ecosystem can even move backwards in this regard though, and probably has done in recent years as the specification became more complex.

In the early days, around when the first major independent homeserver implementation was being developed, a contributor lashed out at Element's complacency by exploiting known flaws and weaknesses in what is now known as room version 19. This didn't result in them being acted upon, the attack mechanisms were mitigated directly and the underlying flaws remained.

One of the exploits was generating PDU's that referred to a prior state of the room in order to evade room bans. This directly led to the creation of "soft failure" as a stop-gap.

Another exploit involved joining rooms with various "alt accounts" from the same server without restriction. This led directly to the creation of server ACL events as yet another stop-gap.

If these attacks didn't happen, we can't say what the present day of Matrix would be, but I don't think it's relevant. When these attacks eventually would have happened, the same stop gaps would have been deployed because they are consistent with and are a product of the design culture Element has.

That all being said, I do think there should be some slack for hindsight, just not as much is being appealed to. The ideas we have now for fixing server ACL are a product of years of discussion when concentration and effort in the area is close to zero. So while these ideas have developed over time, they haven't developed very much, and it has been a very long time. In contrast entire protocols get created and die in the span of 5 years, so my point is that an appeal to hindsight in this scenario is bullshit.

Documentation of security issues

Just a heads up about this section: to be clear, this is not to suggest that every exploit should belong in a public tracker, but there does need to be a policy of disclosing security issues if they have been in the internal tracker for at most an entire year. I don't think the public tracker even needs to detail them, only give enough details so that those who know, know. It's also worth noting here that the triage process for specification issues in general as far as I can tell, is not public, but more likely does not exist at all.

As far as I'm aware there is no public tracker for security issues in the Matrix protocol that could affect the Matrix ecosystem. Therefore there is no assessment of risk against the ecosystem either. This is because even if an exploit is glaringly obvious to those loosely familiar with the specification, just having a central tracker does increase the likelihood, and therefore risk, of an exploit being executed.

However, there is a huge cost to this, which is that failures are not acknowledged, are actively buried, and silenced with appeals to "send an email to security@matrix.org if you think that this is important". There is a culture of extreme paranoia, mostly to do with the PR of the acknowledgement10.

This goes against the values of the matrix foundation, crucially:

  • Accessibility rather than elitism

    Solutions cannot be derived, developed or collaborated upon by third parties because the existence of exploits cannot be acknowledged publicly or indirectly. Only those very closely associated with matrix.org can both protect themselves or work on solutions. You can email security@matrix.org and make your own disclosure but if you don't have clout it really doesn't matter, you're back to square one.

    If you do collaborate, you're going to do so by acting outside of the structure of the foundation as things currently stand.

  • Transparency rather than stealth

    This one goes without saying

  • Proof rather than conjecture

    Where is the proof that the Matrix ecosystem is not at risk, if having a public database of security issues is just that risky.

Why I didn't stand for the governing board

So if you haven't been living under a rock you will know that matrix.org kicked off its governing board election season.

Before nominations opened, I organised a little community called the #ecosystem.forum:matrix.org. Back then the number of ecosystem members was much smaller, so I was really worried about the number of people actually willing to stand. I wanted to get in touch with the other members in case they knew people who knew their stuff and could really hold the line out there for us. But it didn't really happen that way, and we ended up with a lot more members and people wanting to represent, which was a good outcome.

What does it mean to represent

If there wasn't enough variety in candidates, I wanted to stand myself. But doing so should take a lot of consideration.

See the whole electoralism thing seems a little bit backwards to me. If things were "working", ecosystem members would already be outside of their silos and talking to each other11. And if they were working exceptionally well, they would already be able to provide their representatives as a consensus. But it goes a lot deeper than this. If things were really working, why would we need representatives to begin with? Things aren't working though, so I'm happy this is happening.

What needs to happen next is that people do talk to each other, organise and plan ahead with each other. This means outside of the domain of the foundation.

  • Representation

    This one is probably just me, but I find it a bit wrong that most of the representatives talk about how they're going to represent the ecosystem by talking about their own goals for Matrix and agenda. Isn't this wrong? That's surely representing your own interests and asking people to hope their own interests aligns with yours, rather than actually representing other views.

My self-nomination

I thought that the document was explicit with its wording to suggest that ecosystem members could nominate anyone to stand for them.

However, when I asked about this in the Matrix spec office, I was silenced. It was however later clarified (after nominations had closed) that this was actually allowed. If I'd have known sooner, I'd have made a wider appeal in search for people to nominate.

In the end I decided that I was not going to run for the Matrix governing board. A lot of things are too uncertain, and there is likely to be a lot of bullshit. I am currently quite confrontational, and very emotionally invested in Matrix. So some space needs to be created.

Below was the statement that I made for the nomination form.

I'm not interested in pushing a specific set of goals, especially while it is still uncertain how the board will function. Instead I want to ensure that there is as much transparency and communication between representatives and the ecosystem as possible.

My main concern is ensuring the foundation's independence from Element, in all of its functions, and supporting that in any capacity that the governing board can express.

I not only want to be able to accurately replicate the concerns of other ecosystem contributors and the users that stand with us, but understand them deeply and technically enough to be able to withstand a hard testing from the more corporate voices within Matrix.

Although positive progress will likely be made, I fear there is a great risk of conflict, and this can only be avoided or resolved through good communication and strong organisation within the ecosystem.

Technocratic geeks who control Matrix

Now we're going to talk about the structure of the foundation, what we have learned the board's role will be, who the guardians are, and what the big players are already saying.

Community Interest Company

The Matrix Foundation is a community interest company. From the limited legal reading I can perform, this is a company that is bounded by a set of articles of association. Which seem to legally bind the objectives of the company to whatever is written in the articles of association.

Here are matrix.org's articles of association.

These name the objectives of the foundation, which are as follows:

7.1 The objects of the Foundation are for the benefit of the community as a whole to:

7.1.1 Empower users to control their communication data and have freedom over their communications infrastructure by creating, maintaining and promoting Matrix as an openly standardised secure decentralised communication protocol and network, open to all, and available to the public for no charge;

7.1.2 Build and develop an appropriate governance model for Matrix through the Foundation, in order to drive the adoption of Matrix as a single global federation, an open standard unencumbered from any proprietary intellectual property and/or software patents, minimising fragmentation (whilst encouraging experimentation), maximising speed of development, and prioritising the long-term success and growth of the overall network over the commercial concerns of an individual person or persons.

7.2 The objects shall be supported by the Guiding Principles.

Matrix.org has a loophole in its articles of association to refer to a separate document, the rules (Guiding Principles). These rules are therefore legally binding, you will find they are open to abuse and differing interpretation.

  • Representatives beware

    Those who will be on the governing board should be aware of what the guiding principles and rules are, as the rules are going to be appealed to by other representatives. The rules will be presented with varying interpretations to push through certain aims, and block other aims. You urgently need to familiarise yourself with them so that you can counter this tactic, which I believe is already being deployed.

The guardians

From the matrix.org website:

The Guardians are the legal directors of the non-profit Foundation, and are responsible for ensuring that the Foundation (and by extension the Spec Core Team) keeps on mission and neutrally protects the development of Matrix. Guardians are typically independent of the commercial Matrix ecosystem and may even not be members of today's Matrix community, but are deeply aligned with the mission of the project. Guardians are selected to be respected and trusted by the wider community to uphold the guiding principles of the Foundation and keep the other Guardians honest.

The important thing to note is that guardian's hold all of the legal power. They can delegate their responsibilities freely, and ad-hoc, to anyone. But anything the foundation does is under their direction, and with their approval. You will find the articles of association and the rules reinforce this.

There are five people who legally hold all of the foundation's power, two of them are Element executives.

The governing board

In addition to the existing information on the election, I found the best insight into the role of the governing board to be Matrix Live S09E23 — Elections!.

Their responsibilities are described by Josh here as:

  • Meeting twice a year.
  • Reviewing and approving the foundation's annual budget.
  • Reviewing any significant contracts the foundation engages in, with a threshold of $50k
  • Approving initiatives or programs of the foundation that concern branding, reputation, or provide a revenue stream.
  • Provide input to the spec core team about prioritising what happens in the spec.
  • Recommendations and guidance on next steps in general to the guardians.
  • There will be smaller governing board committees who will work together to present things to the rest of the board.

The governing board is there to act mostly in an advisory capacity to the guardians. Though I am sure that responsibilities will be delegated from both the SCT and Guardians in different ways.

The important thing to remember, is that even though as I stated earlier the guardians have all of the legal power, it would be completely de-legitimising if they ignored their advisory board. That being said, it will be unlikely that the board will be unanimous on the issues where this is likely to happen, so there is wiggle room. As the governing board will have several members loyal to the guardians. I find it unlikely that something like this will play out, but it's always a possibility. If there is a polarising situation, that ends with one side being ignored, it will mean the board and guardians are not doing the job that they are supposed to be doing.

Dogwhistles and roundabouts

As expected, on the 20th of April, Matthew (who is the CEO/CTO of Element) announced his self-nomination to the governing board in his capacity as a Matrix foundation Guardian. You can read his nomination message here. However, I want to pay special attention to one sentence.

In particular, I want to work towards taking Matrix mainstream, and avoid it getting stuck as technology just for geeks and governments.

This seems very reasonable, and this statement even aligns with the governing principles of the foundation, seems to be even self aware?

Later, during a discussion in the foundation's room about diversity of the Matrix ecosystem, Matthew again raised these concerns in a different light.

<Matthew> personally I am a little more worried about the risks of tech elitism (ie building clients by geeks for geeks, and looking down at mainstream users or forgetting them), which has caused huge problems for XMPP and IRC.

<Gnuxie> Why are you worrying about that all of a sudden?

<Matthew> wow, what an unpleasant thing to say :)

<Matthew> i’ve been worrying about it all along

<Gnuxie> Ok

<Matthew> especially in terms of the risk of toxic environments where more geeky users jump on others to try to assert their geek dominance

I tried to ask for the context for these comments but I was already being met with hostility. Initially I did tolerate what seemed like pretty blatant attempts to make an example of an elitist geek out of me. Though pretty quickly I snapped back and pointed to Element for reinforcing all of the things that Matthew seemed to be criticising. All while the community largely works to undo Element's neglect and guide newbies12.

I have not seen behaviour like this in any part of the Matrix ecosystem with the exception of a much lesser known client13. It feels like Matthew is projecting his own failures onto the community, in particular in the wake of articles like this one, which point to an appalling on-boarding experience in Element X.

There may also be other context, Matthew also recently had to admit to what he calls "over engineering" the design of sliding sync, seemingly after Element's own developers couldn't make their apps deliver on the promises that sliding sync had made.

There has also been a revival in discussions about the existence of Mjolnir and Draupnir, and their current reliance as appearing as a bot14. I have covered those a little bit in this series, most notably here. Which is also why Matthew may have seen a need to paint me as an elitist geek.

What I find disappointing from the whole thing was that the wider Matrix community was hung on the same peg as Element. After all, I do believe it is Element who pushed Matrix in the direction of contracts with governments, and also tried to take the specification that mostly focussed on serving Matrix rooms in a public and open context to instead serve a private and high security one.

  • The whistle

    What I worry subtext is, is for Element to double down on ignoring its own community, to entice a community that it doesn't yet have15. Appeals like the one we're discussing here are being made all over the place at the moment to build a Matrix "for everyone". And yes, of course we want that at face value. Though I can spot this being used from a mile away to continue to silence contributors and instead exert element's technocratic elitist geek control by somehow being the people who understand what "everyone" really needs and wants. Despite everything16.

Trust, safety, and moderation

Something that is being brought up again and again as candidates speak to each other in the run up to the election is trust, safety, and moderation. Not much more is said other than there's a need to focus on it and that it's important. No one really knows how to go about improving the situation either, if they do attempt to describe the situation and why it needs improving.

  • So what are these words?

    I honestly don't know and I don't think they matter. Trust probably refers to some corporate thing anyways. I'll tell you what matters to me though. Reducing the need to trust single parties in the first place by restructuring the power that they have. Making sure power is used with transparent and mandated justification. Ensuring you have a plan for when every consequence is enacted without either of the above. But to be honest with you, that's just some idealistic stuff I cooked on the spot.

  • What is the problem then?

    As one of few people in the entire ecosystem knee deep in the development of this stuff, I honestly don't really know what's needed, I don't think the problem lies with the protocol (in the sense of specific features). The protocol has problems in that it is complex and any attempt to bring the skill level down with some tool already has to deal with a bunch of complexity. I've covered a lot of that already, as I've been describing to you how I am trying to tame a bunch of this complexity so that Draupnir can focus on features instead. One thing that has really stood out so far is dealing with state and room members, one of the most complicated pieces of code in the rewrite of Draupnir is creating accurate state deltas and from that deriving membership and policy changes. I have written about room state specifically quite extensively in this blog series.

    Most of all though the problem is that real work isn't being done by Element or the foundation in any visible way beyond meeting the bare minimum obligations to maintain their reputation and also their legal obligations. For a whole lot of talk that goes on about fostering other communities to adopt Matrix there's been very little concrete given here in comparison to desperate attempts over the last few years to jam Matrix into an entirely new private and high security context. The priorities are and demonstrably have been at conflict17.

    This work cannot be done by Element, and I would not want to do my work under their direction either. Especially with the precedent set by matrix archive. A project that was in the works for years, that was hidden from the community and only revealed by the time Element had already decided to kill it. Inevitably the project did not survive contact because community concerns were never given chance to be heard during its development21 , 22 , 23.

  • What can I suggest?

    Some things are clear to me.

    Gathering round to add some new features to Synapse and the protocol so we can pat ourselves on the back and say it's a job well done, is not going to cut it. But this is what is going to be sought.

    Work must be done in the open, in collaboration with the community, and also community moderators. Element's design doctrine of sitting back in the shadows is not only against the Matrix mission, but has been extremely harmful. We've even seen Matrix staff making strange appeals to T&S related projects that are being worked on; they don't land as a neat brag, it means you've completely failed to engage with key stakeholders24 in the design25.

    Issues of all kinds need to be triaged based on their relation to usability and harm. Draupnir has already taken this approach but it could be revised further. While this will not provide an objective order of work, or a place to start, it will go a long way. Provided that you still respect yourself enough to occasionally ignore it. And this needs to happen in the open too.

    Strategic planning, it needs to be easier for developers and one-time 'modders' to create, adapt, and modify this tooling. Developer resources are scarce in this area, so it's important to make the most of what is available. On top of this, everyone has different needs and it's not possible to satisfy them all at the same time, the good news is that you don't need to.

Footnotes:

1

So much so that I can't even tell you what the figure is, and sure I can get a readout from jest but that is somewhat flawed. The coverage is for the set of files that have been imported by unit tests, not the whole project, fun!

2

Standard have been dropped to make things happen, but in the the end we probably still hold relatively high standards.

3

Also it's really annoying to see people with tonnes of clout announcing getting approved within the week I get an email about making the second round.

4

https://spec.matrix.org/v1.11/client-server-api/#get_matrixclientv3roomsroomidmessages

5

https://spec.matrix.org/v1.11/client-server-api/#put_matrixclientv3roomsroomidredacteventidtxnid

6

However, if you're going to dig into it, then you will find the concerns are intertwined. It's just we aren't planning on running arbritrary code downloaded from the internet in Draupnir, so there's a lot of things we don't have to worry about, yet. I do really want to add directories to the config to be able to load protections dynamically from though. But that is far away.

7

Well, we simply omit the field, but still.

8

This issue describes the situation with system admin woes https://github.com/the-draupnir-project/Draupnir/issues/217.

9

State-res version 2 was released shortly afterwards. I don't know the specifics of the attacks, everything I know is second hand I don't actually remember what happened, and I haven't been able to find a written account either. The contributor in question will not be named, because I don't want to glorify their part both in the attack and lack of ingenuity to clean things up.

10

Quite honestly this culture of paranoia extends far beyond security issues. Just take a look at Matthew's need to respond to every single negative comment online and make a complete fool of himself. If you're reading this, just take a break, someone else will debunk them for you and if they're not doing that, then you need to ask yourself why first.

11

For some of us, this is already the case, just not through any organisational or powerful means. I talk to a few of the other members daily. And that informal chat is often good, we know how each of us feel. What worries me is if everyone is so burnt out and depressed that this sort of spontaneous chat can't happen.

12

Someone has since pointed me to this article https://blog.koehntopp.info/2024/02/13/the-matrix-trashfire.html, where Element X's store page and onboarding caters specifically to Element customers while leaving "mainstream users" confused. So perhaps Matthew is projecting quite a lot.

13

Maybe Fractal?

14

Though I stress again that this is mostly irrelevant, it doesn't really change much whether there's a bot or not, what matters is having something that exists in the first place. And I've already made my arguments about how a bot user can be managed much the same way as an integration or a bridge at worst. But at best gives them a lot of flexibility, without knowing that what is there is "a bot". I don't think that Matrix would even be the first platform to include bot users by default, Slack has Slackbot. And they're turning over way more cash in a month than Matrix has ever had to play with. That being said, maybe we need to talk more generally soon about appeals to consistency VS developer freedom, since this is something that is bound to come up a lot in discussions about direction.

15

And will not have, if they continue to be this arrogant and ignorant.

16

I elaborate on this in the next section.

17

Again, Element has prioritised a lot of features above "trust and safety" work within the past two years, including concurrent P2P experiments, the now failed sliding sync18, the matrix archive19, third room, Element X, the matrix-rust-sdk, the transition of multiple clients to become dependants of the matrix-rust-sdk, the transition of several clients to become dependants of the new rust crypto. They're just what I can remember from the top of my head.

18

Of which the sliding sync proxy does contribute significantly to matrix.org's operating costs just to run.

19

Which I understand actually took years of work and was only revealed to the community weeks before Element had already decided they were going to axe it, not really giving it any fighting chance or to respond to the strong feedback that it received. Some of which totally could have been foreseen if collaborating with community was ever taken seriously as an option20.

20

And not just strawmanned as being privacy fanatics wearing tinfoil hats who believe in lizard people. Which is something that has been done by someone high up in TWIM before. Strawmanning no doubt played a large part in why the community was not consulted until it was too late.

21

I cannot stress enough that certain people spend and have spent their airtime infront of 60-200 people straw-manning people in the community and failing to understand or take their concerns seriously.

22

Say that development did continue after 2022 on Mjolnir4all, I would have been forced to also release it in a botched state, the dire state of Mjolnir as of 2022 and now. So many of Draupnir's more ambitious features would never have made it. The command refactor for instance is mostly artwork, and punches way above the project's weight. The matrix-protection-suite itself would have been unlikely to ever have been a focus, and if it were it would only be marketable as a Rust library. That's ignoring the firefighting that needs to be done to maintain matrix.org. That being said, ignoring that working in a sinking ship is not great for mental health, having some coworkers would be nice, and also having the monetary compensation that you get with working full time at a tech company. Mjolnir still could have gone a lot further than Draupnir has.

23

It's somewhat clear to me in hindsight that they would have liked Mjolnir4all to be in a similar working condition to matrix archive when it was also killed in the prior year. They would have totally released that and it would have been disastrous.

24

Sometimes this is done with the defense that a lot of this work cannot be made open because abusers would be able to see exactly what methods are being deployed on matrix.org and therefore be able to avoid them. However, this is untrue because these are not simple systems and do not do much of anything without configuration. Crucially, this configuration is not the part being made open source or collaborated upon. Need I remind you that the current approach is not working.

25

And are one of these technocrats that are being complained about.