Like redactions

similar to the deactivate user command

To determine if there's even a need to apply ACLs, etc

After giving the error message about missing PL in certain rooms, the bot will start spamming the moderator room with messages, presumably because it's still trying to update there but failing

Just warn once

Should probably sync the lists before applying ACLs

The bot was using half a gig in production when it should be around 100mb.

as well as move them

For when the bot is missing a feature you really need, we could do light sandboxing and expose an instance of MatrixClient in a closure. Sanboxing would not be a huge concern because the command would only be available to moderators/managers of the bot.

Related: #17

Stuff like mjolnir : help and @mjolnir : help should just work instead of silently failing for invalid formatting.

Something like:

Looks like @userid:example.org has banned @someone:example.org from [room], would you like to import this ban into a ban list? 👍 for terms of service ban, 🚀 for code of conduct.

Though the language might need to be more machine-friendly.

And i get many of these errors:

  errcode: 'M_LIMIT_EXCEEDED',
  error: 'Too Many Requests',

This could be because of ratelimiting in synapse. Maybe a proper rc_admin_redaction value could solve the problem?

How tricky would it be to make the name the Mjolnir bot responds to configurable? Calling it with !mjolnir works, to be fair, but when the account's not named mjolnir:matrix.example.com it can be a bit confusing, especially when the banhammer must be swung in broad arcs, if you catch my drift.

Being able to set an arbitrary name in the config file (like !anton or !nuke) but defaulting to !mjolnir would be really handy.

Hi,

I'd like to propose a feature request for a Debian package of mjolnir in https://packages.matrix.org/debian/. The rationale is that:

1. I already and prefer to use this packages repository for synapse on my Debian server
2. I prefer to avoid Docker
3. Building mjolnir has the disavantage that I don't get automatic updates when there's a new release

Thanks for considering this feature request :).

• Don't let moderators set ACLs that prevent the bot from participating
• Prevent globs from matching the bot's user ID (but still allow people to set rules like @*:*)
• Don't let moderators demote the bot in rooms that are protected. Allow promotions though.

matrix-org/matrix-spec-proposals#2313

Either I am misunderstanding something or it's broken, I have banned someone:

!mjolnir ban sunpy user @Nabobalis:matrix.org Test ban

the state event get's put in the ban list, and the bans are issued over all the rooms as expected.

running

!mjolnir unban sunpy user @Nabobalis:matrix.org true

removes the ban from the ban list but doesn't actually reverse the ban in any of the rooms. (This was the only ban in the ban list, so nothing else should be getting in the way).

Stuff like sending to moderators (a popular request) first, approve/disapprove of recommended actions, and general cataloguing.

We'd intercept the /report endpoint from Matrix at the reverse proxy level for the homeserver, and do things with it. Common requests are documented in the comment below.

!mjolnir remove #example can infer its server part, for example

We really just need to pick different emoji.

It would be nice to have a docker container preconfigured with pan installed, so that it can be easily activated in some manner. Either in the main container or a separate tag.

!mjolnir ban tos user @example:example.org is fairly complicated to remember, particularly when you flip the order of the arguments by accident. Instead, the bot should support a default ban list in the room to make the shortcode optional and it should discern the entity from the thing being banned, optionally.

This would make the command work for:

• !mjolnir ban @example:example.org
• !mjolnir ban tos @example:example.org
• !mjolnir ban user @example:example.org
• !mjolnir ban tos user @example:example.org

Hi,

thank you for your great job and this cool software!
I just want to leave some suggestions for improvements and say where the setup needs some explanation:

• Explain where to get access token. When logging in to riot, copy the access key and log out, the access key is outdated
• Docker container refused to start until i deleted /config/default.yaml even if production.yaml exists
• Docker container refused to start when not having set "protectedRooms" even if protectedAllJoinedRooms is set to true
• Explain how to kill container and/or to run in background when started like in your documentation
• Explain how to set up ACL and ban lists

It would be nice if Riot can render the rule events, so I can join someone else's banlist room, and keep track manually, without giving their banlist full control over my room

Might be an alternative to #40

It's not obvious that a pill expands to an mxid, so if you try to suffix it with a domain, badness

Following the instructions in the readme, I get this from yarn build:

yarn run v1.19.0
$ tsc
src/index.ts:22:5 - error TS2305: Module '"../node_modules/matrix-bot-sdk/lib"' has no exported member 'PantalaimonClient'.

22     PantalaimonClient,
       ~~~~~~~~~~~~~~~~~

src/index.ts:54:38 - error TS2339: Property 'parseUrl' does not exist on type 'typeof Permalinks'.

54         const permalink = Permalinks.parseUrl(roomRef);
                                        ~~~~~~~~

src/index.ts:69:38 - error TS2339: Property 'parseUrl' does not exist on type 'typeof Permalinks'.

69         const permalink = Permalinks.parseUrl(roomRef);
                                        ~~~~~~~~

src/models/ListRule.ts:17:28 - error TS2307: Cannot find module 'matrix-bot-sdk/lib/MatrixGlob'.

17 import { MatrixGlob } from "matrix-bot-sdk/lib/MatrixGlob";
                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Found 4 errors.

node v12.11.0
yarn 1.19.0

If someone like matrix.org is smart and uses tos as their shortcode, no other Mjolnir that is subscribed to that list can use tos for their own purposes.

For ex: if I join a room with 5 bots called @evil{1-5}:example.com, it would be cool if you could tell mjolnir that "@evil.+" is disallowed and have those users banned on join before they can cause trouble.

Homeservers should be recommended to disable rate limiting on the account.

This appears to be a matrix.org issue.

It's awful. Take inspiration from Trello bot?

Possibly on !mjolnir help show a quick summary from the moderator's guide, then on !mjolnir help all give the giant thing.

This takes two forms:

1. Literally the entity has to match N rules before they'll be banned, across any number of lists.
2. The entity must match N lists before they'll be banned. The lists valid for counting N might be specified by the moderation team.

Multiple confirmations are useful for communities who want to subscribe to another community's lists, but don't want to subject control of their rooms to that community. A good example of this is any community which wants to use the matrix.org homeserver lists, but isn't willing to let us ban whoever we want in their rooms.

New rule updates will not be seen by the module, leading to them not being applied. The module needs to contact the bot to use the untested and new "ban list server".

Limited tightly in scope to the management room, there could be state events which have arbitrary bits of JS in them to process messages. The state key could be the protection name (with some sort of prefix to avoid clashes with the official ones?). The JS would be a function which takes some sort of arguments to do the processing. For instance:

return async function(mjolnir, roomId, event) {
    // Do work
    return Promise.resolve();
};

This is relatively safe because the only way to pwn the bot is to be a moderator, who already has the power to !mjolnir ban @* lol if they wanted to.

A version number should be in the event content for future iterations. Mjolnir will not make any guarantees about API compatibility, so maybe it needs a "compatible version number" too?

e.g. botzilla is currently running rogue, and there is no easy way to mute it, short of deactivating it.

Something to give/take ops to people in all protected rooms. Commands/approach undecided.

Otherwise the rule is invalid.

An instance of the bot failed the list sync due to a 500 on resolving the room alias of a ban list. The bot never reported this failure to the management room, though the silence of it indicated failure.

It should report the problem to the room, and if it fails to report the problem to the room, crash.