Gnuxie & Draupnir: early Autumn 2024

If you've ever used discourse, then you'll know that it has a really good system here. By default you can't do a lot, and there are goals and milestones you must complete before you are given access to the full set of features, such as the ability to post links and images.

This is really what we need in public matrix rooms, some time to allow new users to interact with the community before we give them to tools to spam our rooms.

Unfortunately Matrix violates the principle of least authority and by default a user or server can send pretty much all of the available message types and links. And any number of messages². In the worst cases, the only real defense to this is the hope that rate limiting kicks in and that someone sees the attack in time to stop the room being disrupted. In the worst case, these kinds of attacks can destroy a Matrix room and force the room admins to create a new room³. Rate limiting itself is also unreliable and is applied subjectively, even then the behaviour can be complicated by the behaviour of other homeservers that are present in the room⁴.

For Matrix to be safe we need to apply the principle of least authority at the authorization level, and Matrix also needs to end the irrevocability of the power level system. This is verly unlikely to happen in the next five years. It may never happen if MIMI has made the same mistakes as Matrix and we all end up having to use their protocol.

So we're not going to count on it, We're now going to bring forward a protection before v2.0.0 is released to help us here and enforce a custom permission system ontop of the Matrix one. There's a clear need for it and the state of safety is an unfunny joke.

I have proposed a series of MSCs that help in the reactive case, which is to help tidy up gore, CSAM, and other abusive content after it has already been propagated on Matrix. These proposals aim to get us into a position where we can explicitly mark accounts or content with m.takedown⁵ when they post CSAM, gore, or are otherwise just throwaway accounts used in an attack⁶.

As currently there is no way to automatically purge media from your homeserver that has been sent to a public room and is known by the room moderators or otherwise to be abusive.

• MSC4204: m.takedown moderation policy recommendation
• MSC4205: Hashed moderation policy entities
• MSC4206: Moderation policy auditing and context
• MSC4207: Media identifier moderation policy

I don't know when we will implement these MSCs, I had hoped we would get a little bit more feedback first. Implementation will also likely require coordination with other tools. Please do read through the proposals and let me know if you have any thoughts.

So the initial plan for safe mode was to just make something like protection settings work for Draupnir's protected rooms, watched lits, and enabled protections.

Intially I did do this just by copying and adapting protection settings, but there were a couple of issues.

The first issue that I encoutered was that in legacy protection settings, the description of each setting is mixed up with the values. So for example, the threshold in BasicFloodingProtection for the number of events per minute is configurable with an instance of the class NumberProtectionSetting, which not only describes a number to provide its serialization and deserialization, but also wraps the value.

Honestly, I can't remember why I so decisively moved against doing it this way, but I ended up seperating those concerns. At a guess, it was because it was complicating type inference or – aha! It was because it was a pain to integrate with @sinclair/typebox, which is the library that we use for JSON Schema validation. I wanted to be able to piggyback off of TypeBox to be able to define the shape of persistent configs.

export const MjolnirPolicyRoomsDescription = describeConfig({
  schema: Type.Object(
    {
      references: Type.Array(PermalinkSchema, {
        default: [],
        uniqueItems: true,
      }),
    },
    { title: 'PolicyRoomsConfig' }
  ),
});

So this is what I came up with, we just piggy back off of TypeBox for everything.

export type ConfigDescription<TConfigSchema extends TObject = TObject> = {
  readonly schema: TConfigSchema;
  parseConfig(
    config: unknown
  ): Result<EDStatic<TConfigSchema>, ConfigParseError>;
  properties(): ConfigPropertyDescription[];
  getPropertyDescription(key: string): ConfigPropertyDescription;
  toMirror(): ConfigMirror<TConfigSchema>;
  getDefaultConfig(): EDStatic<TConfigSchema>;
};

There's nothing too interesting here, we have a way to parse the config into the decoded version of the schema type, some introspective methods for describing each property, and a mirror. The mirror is for interacting anything that vaguely matches the config shape, which is important since it works with objects which technically don't pass any validation steps. Since we need to be able to use the mirror to remove invalid values from properties.

export interface ConfigMirror<TConfigSchema extends TObject = TObject> {
  readonly description: ConfigDescription<TConfigSchema>;
  setValue(
    config: EDStatic<TConfigSchema>,
    key: keyof EDStatic<TConfigSchema>,
    value: unknown
  ): Result<EDStatic<TConfigSchema>, ConfigPropertyError>;
  addItem(
    config: EDStatic<TConfigSchema>,
    key: keyof EDStatic<TConfigSchema>,
    value: unknown
  ): Result<EDStatic<TConfigSchema>, ConfigPropertyError>;
  // needed for when additionalProperties is true.
  removeProperty<TKey extends string>(
    key: TKey,
    config: Record<TKey, unknown>
  ): Record<TKey, unknown>;
  removeItem<TKey extends string>(
    config: Record<TKey, unknown[]>,
    key: TKey,
    index: number
  ): Record<TKey, unknown[]>;
  filterItems<TKey extends string>(
    config: Record<TKey, unknown[]>,
    key: TKey,
    callbackFn: Parameters<Array<unknown>['filter']>[0]
  ): Record<TKey, unknown[]>;
}

It's important to note that the config mirror doesn't mutate the orignal configuration. That's going to be important if we reuse this as a replacement for protection settings later, as we wouldn't want to accidentally mutate a configuration object that's actively being used by a protection.

By the time I had implemented these interfaces, I still thought that I was going to create some kind editor that could work with any ConfigDescription and an adaptor for storing them. But I figured something out that is more convienant and probably just better.

Just to set some context, now that we have the config description, we also need something that can load and store it from a location.

/**
 * Allows the client to load persistent config data.
 * The schema gets verified before its returned.
 * If there is an error with the data, recovery options are provided.
 *
 * Draupnir maintains a list of these which are editable generically
 * via safe mode.
 */
export interface PersistentConfigData<T extends TObject = TObject> {
  readonly description: ConfigDescription<T>;
  requestConfig(): Promise<
    Result<EDStatic<T> | undefined, ResultError | ConfigParseError>
  >;
  saveConfig(config: EDStatic<T>): Promise<Result<void>>;
  reportUseError(
    message: string,
    options: { path: string; value: unknown; cause: ResultError }
  ): Promise<Result<never>>;
}

This is used to ground a config description against a resource location, like the org.matrix.mjolnir.watched_lists Matrix account data.

So far so good, but validation and parsing isn't the only place where configuration values can be the source of an error, or at least involved in an error. Consider the scenario we described where a policy list cannot be resolved when Draupnir starts up. In this situation, the reference to the policy list is valid. So there wouldn't be a problem trying to parse the policy rooms. We only get an error related to a config value when we try to use the policy room reference at run time. So for example if we discover that the server the alias belongs to isn't responding or we've been removed from the room, or some other reason.

To be able to represent those kinds of errors, we basically need the client code that consumes a config property to report them in a consistent way. We do this by including a reportUseError method on PersistentConfigData interface.

It's at this point that I realised that since we're able to report problems with specific properties, and we have the ConfigMirror that's able to introspect and manipulate config values. Then it makes sense that we can just go ahead and suggest a "recovery option" for each type of error. For example, if we detect that a specific item in an array doesn't match the JSON Schema, we can just go ahead and suggest that it can be removed.

Similarly, if we detect there's a problem while using a config value, such as a protected room ID, we can go ahead and suggest that we remove that room from the config.

This is great because we don't have to teach users how to edit or manipulate the config, we can just give them a few options for how to recover their Draupnir, explain them and let them choose.

This is how that looks, we try to make it clear which value is causing issues by including the config preview at the bottom.

The warning triangle is supposed to show that this is a config use error, rather than a parsing error. Not that it will make too much difference. Originally these were going to use red, orange, and green buttons but some people can't see the difference between those colors too well idk.

I'm not supper happy with this, but it's important not to lose sight of how big of a change this is over having an unrecoverable bot, and probably not even knowing why.

It became obvious at this point that we should probably include a confirmation prompt in the recover command. So that when you click on the reactions, you get a chance to review everything is ok before continuing.

There are several cases in Draupnir where a confirmation prompt like that would be useful, so I thought it was a good idea to try make the prompt behaviour generic so that it can be used in other commands. We need it in the future too, since I want to be able to do cool things like preview the effects of enabling a protection before confirming.

export const SafeModeRecoverCommand = describeCommand({
  summary: "Select an available recovery option to recover Draupnir with.",
  // .... paremeters
  keywords: {
    keywordDescriptions: {
      "no-confirm": {
        description: "Do not prompt for confirmation.",
        isFlag: true,
      },
    },
  },
  // .... more command stuff
});

I don't know whether this was the right choice yet, but I decided that I would just give special behaviour to the the --no-confirm option. If you specify the option in the command description, and when processing the command there is no --no-confirm option, then we will prompt for confirmation.

This is what that looks like in the end, this entire message can be changed on a per-command basis with JSX.

For safe mode, I would have liked to have previewed how the config would look after the change but we wouldn't be able able to accurately show config use errors, only parse errors. Because to be able to get those we literally have to try restart draupnir.

Which I guess, yes, we could do that, but that still requires a lot of extra consideration.