If you use !mjolnir unban @whoever:wherever --true then --true is given to the command executor as the policy list rather than the result of the prompt. As an aside, i don't think we need to use --true with unban anyway?

See the screenshot in #201 for an example of this.

The issue is simply from a missing await around the banning code in the prompt response listener. Would link but on a phone, and i've already forgot about it while away once this year

The behaviour of clients formatting mention pills is making the bot unusable to some users, who don't have the knowledge to distinguish between a displayname, pill, mxid. So they become very confused and frustrated.

For example schildichat and element both format mention pills (ie [Meow (Backup)](@meow:example.com)) in the body by just printing their displayname.

  "content": {
    "body": "!ban Meow (Backup) coc",
    "format": "org.matrix.custom.html",
    "formatted_body": "!ban <a href=\"https://matrix.to/#/@meow:example.com\">Meow (Backup)</a> coc",
    "msgtype": "m.text"
  }

This is actually behaviour that is encouraged by the specification (not mandated), which as of v1.8 states:

When linking to users, use the user’s potentially ambiguous display name for the anchor’s text. If the user does not have a display name, use the user’s ID.

The text component of the anchor should be used in the event’s body where the link would normally be represented, as shown in the example above.

Unfortunately, this makes it impossible for a bot to parse. A bot cannot safely resolve a displayname back to an MXID even if it were possible to parse the displayname in the first place. So it is unclear how we should proceed.

Depending on intentional mentions doesn't fix this problem either, since we still can't tell where in the message the mentions are.

Additionally we see that the behaviour for the room is the opposite

When linking to rooms, use the canonical alias for the room. If the room does not have a canonical alias, prefer one of the aliases listed on the room. If no alias can be found, fall back to the room ID. In all cases, use the alias/room ID being linked to as the anchor’s text.

Instead of printing the title of the room, clients are encouraged to print the room ID or alias.

So we can actually use this.

  "content": {
    "body": "!ban @meow:matrix.org #policy-list:example.org  ",
    "format": "org.matrix.custom.html",
    "formatted_body": "!ban @meow:example.org <a href=\"https://matrix.to/#/#policy-list:example.org\">#policy-list:example.org</a>",
    "msgtype": "m.text"
  }

am I right that Draupnir sees @A:example.net on top of users to ban and fails to do that and then gives up banning users below it like @b:example.net? or is it ignoring knocks?

using https://github.com/spantaleev/matrix-docker-ansible-deploy/tree/a573619330767085af220715e66840d01a71bed5

1. create coordination room
2. draupnir has PL = 0
3. !draupnir config add TrustedReporters.mxids @trusteduser:example.com
4. Draupnir says Failed to set setting: M_FORBIDDEN: You don't have permission to post that to the room. user_level (0) < send_level (50) - it is unclear who "You" is. This message could be improved
5. repeat 3.
6. check !draupnir config get TrustedReporters
7. User is now doubly trusted: TrustedReporters.mxids: @trusteduser:example.com,@trusteduser:example.com

One issue seems to be missing documentation around draupnir being able to write state to the coordination room. That includes downstreams such as https://docs.draupnir.midnightthoughts.space (@MTRNord) and https://github.com/spantaleev/matrix-docker-ansible-deploy.

Another issue would be the dupe check/constraint on the TrustedReporters.mxids.

isn

This came up in d4all and I am not sure what exactly caused it. It might have been Synapse omitting it or draupnir not properly updating it's cache.

Specifically it didn't recognise it was admin even after reload/restart.

Originally matrix-org/mjolnir#412

There should be some way to emulate a syncing matrix-bot-sdk client with a matrix-appservice-bridge MatrixIntent. This should preferably be implemented as something that can be contributed to matrix-appservice-bridge or as another package.

See: https://matrix.to/#/!IaWNErZAgQUhGqJXjX:matrix.org/$S2YQ30oHVV-U7nlSYhHY-jQo71B9_Uj3iE7YXnPZAz4?via=matrix.org&via=envs.net&via=the-apothecary.club

Alternatives: Number emoji or alphabet instead.

(This is an informal list of things I want to work on, or I am working on. Hence, a grouped Issue. Feel free to extract tasks and work on them, though. Tick means work is happening already.)

• Yara Rules (#139)
• MSC1929 (#150)
• Updating the rest of the commands to the new system
• Updating the synapse module
• bot-sdk crypto (#145)
• Adding the policy list system to protections
• Extending the documentation especially for protections
• Improving tests
• Improving code quality where sensible

A remaining unmitigated reason for why ErrorCache was added was because if Mjolnir had been offline and is unable to ban a bunch of new members when it comes back up (receiving lots of join events from sync) it will spam the exact errors for every member event). The management room also reports the errors because Draupnir forcibly verifies permissions at startup and performs a full sync.

This problem really is "find some way to classify whether these errors are the same errors sorts of errors as before, ie is it the same problem and do i already know about it?"
We could be lucky and this is a problem people have to solve all the time and is well documented.

Follow up from #85

Todays help command in upstream atleast only gives out a massive text block with little information.

It would be better to if not replace this whole function extend it where you can invoke help command and get documentation for that command. For example if you invoke it for ban you could get told about the fact you can target servers for ACL bans and their implecations and target users and the other relevant documentation. The idea is that it would give you access to all the information you might want but do it on matrix instead of having to push you to support channels or online docs.

(This might be a good item for new contributors to tackle.)

Draupnir needs eslint applied and any issues it rustles up should be resolved. Going forward all new code should probably pass the linter, confirming existing code may take longer.

Currently Draupnir configurations are encouraged to use /joined_members (via fasterMembershipChecks) to check the room members before applying bans to a room. This means that invited users and knocked users will not be banned for the majority of deployments. They can choose to rely on a query to the room state by disabling fasterMembershipChecks, but it can come at a great performance cost for large rooms (in the region of a couple of seconds all the way to thirty depending on the size of the room and deployment setup of both Draupnir and Synapse). This has been a neglected issue for some time, but has become more important and will remain important as more rooms move to using a knock policy. As any number of users can knock on a room and appear in the members list to be reviewed by moderators with their chosen display name and avatar.

A script has been created to help guage the response times for each method of fetching room members. Would be interesting to see other people's results or improvements to the test.

This is to save people in case they don't want to use draupnir and go back to mjolnir seamlessly

Protections should just have their own command tables that are accessible via a top level draupnir command

Weirdly because the old command "parser" is "parts based", the examples provided never would have worked.

We get in our control room this message:

The user was banned in <room-id/room-alias> by for .
Would you like to add the ban to a policy list?

This don't really help me, because i only set someone on a ban list, when I am sure its a severe thing.
e.G. As a room admin I can be more strict then when this would have effects for hundreds of rooms.
=> I don't do anything.

Would be cool if the last message(s) would be send with the report
Design Idea:

• perhaps as a thread
• make it configurable how many messages should be included

It makes sense that redacting a message from a user should offer a prompt to do so for all rooms. This should really require an extra confirmation prompt so it's not used accidentally. E.g. Redacting an active user's message because it didn't have a cw or something, getting the prompt and another moderator clicking on it.

https://matrix.to/#/!IaWNErZAgQUhGqJXjX:matrix.org/$QD9PyOXm1vizpbCXsPia2Mc5onoHWSZfkrM0K8uXtfE?via=matrix.org&via=envs.net&via=the-apothecary.club

Not a Issue with a high priority for me.
It's a pitty that you can't search in a ban-list-room.

I like the !mjolnir rules matching command where you can search if room/server/person is already banned.

Sometimes it could be handy beeing able to search in the ban reason, too.
(Yes it looks like I am one of the seldom people who make custom ban reasons^^)

Example:
Sometimes you have person who create multiple accounts and we ban them with a comment like "alternative account of "
If I see a person again and think: Wasn't this the person who made several accounts?

Running !draupnir since 1d show 20 * outputs joins in last days room-by-room however it's not showing for which room which joins. Might be little improvement to include rooms in output as well.

mahdi has reported that users aren't being redacted automatically until draupnir is manually synced with the sync command. in their setup, server ACL is disabled. There is a queue that users get added to to be redacted once all rooms have been synced. I suspect that this queue is not being popped for some reason when membership changes force a sync within a single room

see also turt2live/matrix-bot-sdk#347

Should make managing a bit easier

https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file
https://github.blog/2023-08-24-a-faster-way-to-manage-version-updates-with-dependabot/

Hi! It appears Draupnir does not support Node 20 for building as trying to run yarn install on a host with Node 20 installed errors with:

$ yarn install
yarn install v1.22.19
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
error [email protected]: The engine "node" is incompatible with this module. Expected version ">=14 <=18". Got "20.5.0"
error Found incompatible module.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

matrix-appservice-bridge in Draupnir's package.json, which uses matrix-appservice, is on 8.1.1 even though the latest version is 9.0.1 (https://github.com/matrix-org/matrix-appservice-bridge/releases/latest) which does add support for Node 20 and drops Node 16 support which Draupnir also recently did: matrix-org/matrix-appservice-bridge@d5ab312

I'm not sure how much needs to be done to make Node 20 work, but I was able to just update matrix-appservice-bridge in my package.json and it seems to work?

"Constructed server ACL:" message can be very long (hundreds of ACLs), it would add to readability of control room if it was collapsed by default like help command does.

Can the top level help command gain collapsey boxes per generic section so that it doesn't fill scroll history on mobile with 3-4 pages of commands?

Makes sense that someone struggling with unbanning a user would try to unban them from a room without checking the rules. It used to happen all the time with Mjolnir because of the confusing --force requirement of the unban command.

people shouldn't have to go through the prompt ux just to ban when they only have 1 list, and they should be able to provide the reason at the same time.

https://matrix.to/#/!IaWNErZAgQUhGqJXjX:matrix.org/$HhT8b7ksISHdbNZvoEeovZz4Osdj4DRAefQgAaXTOQM?via=matrix.org&via=feline.support&via=pikaviestin.fi

The prompts only make sense for people on mobile with multiple lists like CME members.

When trying to add a rule without permission (for example a list where normal rules are allowed but ACLs are not for the bot) the message:

There was an unexpected error when processing this command:
Unknown Unexpected Error
Details can be found by providing the reference 0c250e35-ed81-4b12-ba04-dd1167d183bfto an administrator.

is shown. Instead, it probably makes sense to just say that the bot has no permission to add this rule to the list.

Currently !draupnir unban removes all matching rules including explicit allow such as

{
  "entity": "*",
  "reason": "Default allow rule",
  "recommendation": "org.matrix.mjolnir.allow"
}

Resulting into somewhat unforeseen consequences 😅

Originally reported at matrix-org/mjolnir#482

The appservice admin room should be spacial cased when watching for invitations so that the appservice bot can just join the room.

Draupnir has inherited the confusing punishing moderators issue from Mjolnir and Matrix is somewhat hostile towards moderators trying to release other moderators from it.

• matrix-org/mjolnir#200
• matrix-org/mjolnir#341 (@Raatty)

PolicyListManager.start() hard-fails and prevents Draupnir start-up, when it tries to join each watched and protected room, if it fails to join any of the rooms.

I understand this is by design, in its basic form: because we don't want Draupnir taking drastic actions (like banning) based on missing info.

This happened to me when I thought I'll just delete this unwanted empty policy-list room in synadm but it was still listed in the bot's account data.

In the management room I got only the generic message, "‼ | Startup failed due to error - see console". (As I'm running it as a developer I can see the console logs, but I'm thinking someone other than the developer/installer/sysadmin will run into this sooner or later.)

Work-around:

• manually edit the bot's matrix account data to remove the references to the nonexistent room. (In org.matrix.mjolnir.watched_lists and/or org.matrix.mjolnir.protected_rooms.)

Desired behaviour (minimal):

• Log a more specific diagnostic in the management room.

Desired behaviour (optimal, "stretch goal"):

• start-up continues, recording the failure states;
• Draupnir is put into "dry-run" mode as we don't want it taking actions based on missing info;
• the failure to join one or more rooms is noted and made clear to the moderator (in the admin room);
• moderator is able to use normal Draupnir commands to see which room(s) it failed to join, to delete those room(s) from its watching/protecting lists, and/or add replacement room(s);
• moderator is able to tell Draupnir to check everything is OK now and switch out of "dry-run" mode.

I acknowledge the latter may be too big, too much work to take on at this stage, but wanted to write it down anyway.

https://matrix.to/#/!IaWNErZAgQUhGqJXjX:matrix.org/$huXIxAH_PQxvpSWx7xHQPZUafMr-kYDgBhhSPW7dd98?via=matrix.org&via=envs.net&via=the-apothecary.club

• Can we allow the defaults for commands to be configurable?
• If there is only one suggestion, can it be offered as a default?
• Can we allow the prompt flows to be configurable? e.g. confirm default VS just filling in the a default silently
• For the suggestion lists, should we use emoji or just plain numbers for reaction keys?

onlookers: Do not take eyes off the prize, which presentation types + commands being specified in the Matrix spec NOT gimmicks to enable interaction. The major benefit of having presentation types + commands being specified is that it allows for most prompts and interaction to take place within the client without needing to for a trip to the bot and back.

I think https://github.com/Gnuxie/Draupnir/blob/8894e296060974c92a1010eb5c84d51a59d665c6/config/harness.yaml#L150-L178 isn't possible on the appservice currently. It would be nice to have a dedicated health endpoint for appservice mode as well.

(It should only monitor the process. Not if any of the "workers"/provisioned bots are alive or dead)

We deploy Draupnir through matrix-docker-ansible-deploy, migrated from a previous install of Mjolnir.

Current version: v1.83.0

One of the protected channels (and only one) keeps getting set to private from time to time.

Example event:

{
  "content": {
    "join_rule": "invite"
  },
  "origin_server_ts": 1692574292625,
  "room_id": "!aPqEsAdWuysydZNCic:matrix.org",
  "sender": "@nickcalyx:matrix.org",
  "state_key": "",
  "type": "m.room.join_rules",
  "unsigned": {
    "replaces_state": "$xbLTAhmv9EXBxYgs7w-zdAtEfI2fU9bq1iIX3zQqw-A",
    "prev_content": {
      "join_rule": "invite"
    },
    "prev_sender": "@bot.mjolnir:calyx.dev",
    "age": 45597433
  },
  "event_id": "$YGWMm0WXP3-aV11wMP9egt6Z2Ww9Q6egaIQYqXk4Y-I",
  "user_id": "@nickcalyx:matrix.org",
  "age": 45597433,
  "replaces_state": "$xbLTAhmv9EXBxYgs7w-zdAtEfI2fU9bq1iIX3zQqw-A",
  "prev_content": {
    "join_rule": "invite"
  }
}

The thing to note here is prev_sender and prev_content, where it shows the bot setting the channel as invite only.

We've set it to public again after this, but from time to time we find that it gets set to private, and we see a similar event like the above.

The JoinWaveShortCircuit protection has been disabled for a while. It was briefly enabled a long time ago. Mentioned because that's the only place in the code here where I see join_rules being touched.

I suspect that there's a case conversion being done on only one side of a search

currently when a redact command or policy matching.redact reasons is issued, draupnir checks the most.recent messages sent to all rooms for.that user, and not all.users who have been marked for redaction previously. When it could redact all marked users

If Draupnir notices a room level ban has been used then it should prompt the management room to add a policy for that user.

There should probably be a command to check for room level inconsistencies with policies that will put a bunch of these prompts into the room

currently draupnir will just try to protect the room even though it has been kicked, and will also just post 'done updating rooms' to the management room

We have a bunch of rooms where draupnir doesn't have permission to set ACLs, and we don't need it to do that. It would be nice if we could disable the spam about it that happens at startup and when setting bans.

Disabling the ACL feature entirely would also work for us, but wouldn't support use cases where people want ACLs but only in certain rooms.

Somewhat related: #57

I propose to develop a bot matrix to remove users from rooms for unseemly behavior, insulting users, selling illegal goods, services of whores and prostitutes, porn, erotica, spam.

getting reasons for automatically redact for reasons configured is silly, there should just be a policy for redacting recent or new messages. Also even if we donmt have ways to manage who.you trust to do.this yet, the situation.is already that someone.can guess your automatic redact reasons if you trust them to follow.their list