This is an experimental ruleserver that will serve the combined rules from
the active policy lists to a Synapse module over a web api.
This makes it easier to communicate changes in policy lists to Synapse workers
that do not have an immediate view over all of the policy rooms at
the same time.
This also allows us to express moderation actions to the homeserver
beyond what is currently expressible via MSC2313 policy
lists.
- Use the configured username & password when registering the test user to run Mjolnir with (was hardcoded).
- Remove bogus imports from the helper that have accidentally been introduced with VSCode.
- Keep `enable_registration: true` in the homeserver config to save time.
We do this so that there is only one source of truth for which rules
are active and it simplifies de-duplicating rules of conflicting event
types (e.g. m.room.rule.user vs m.policy.rule.user).
The reason for doing this is because otherwise there may be duplicate
rules under different state types for the same entity.
This simplifies the process of modifying or invalidating rules affecting
an entity because the rule with the most recent type will always be
preferred.
Only shows changes to lists made by other accounts (than the one used by Mjolnir).
Displays when rules are added, removed and modified by either replacing the state event or redacting them.
Fix various issues with timeline pagination (getMessagesByUserIn)
- Ensures the callback that is provided to getMessagesByUserIn is only called when there are relevant events (Ie never called with an empty array)
- Changes getMessagesByUserIn to await on the callback it has been given. (This stops async callbacks failing outside of the context which they were provided if the caller awaits on getMessagesByUserIn).
- Changes getMessagesByUserIn to return a promise that resolves when either: limit has been reached, no relevant events could be found or there is no more timeline to paginate.
- Fixes an issue where a sync filter was being given to `rooms/messages` which led to Mjolnir paginating the entire timeline in situations where it was not necessary (e.g. exact sender was given)
Specifically `onReactionTo` was starting and stopping the client
argument it was given, which could be problematic if the caller
didn't expect that or didn't want it to.
This is so that the context of failing callbacks are not lost.
We also await during pagination and not after so that if a call to the callback fails, we will not call it again.
