Currently integration tests will be broken because we took control
over "who starts Draupnir?" away and gave it to the `SafeModeToggle`.
So we need to fix that.
Something that is going to be broken for sure are the guages on the
appservice manager, since toggling is controlled by the base manager.
I have no idea what these guages are even for except the legacy
draupnir4all work.
disbelief, but basically Mocha is an asshole and was suppressing uncaught promise rejections, and then the throttling queue was catching errors in kick command unit test. So between them the test for glob kicks looked like it was passing, when it was actually causing an assertion failure that we couldn't see. And this meant that we couldn't tell that glob kicks were always banning everyone and everything no matter what. This seems to effect all `v2.0.0-beta.*` releases, but I don't think there is a release where the kick command will actually run without some other error happening first.
This will stop situations where the throttling queue was uninitialized in the Draupnir instances.
We should really enable `strict` for typescript.
The blocker for that is `useUnknownInCatchVariables` around legacy code (which should be minor).
And also `strictFunctionTypes`, which `interface-manager` exacerbates by not providing the right generics for `describeRenderer` and other methods.
https://github.com/the-draupnir-project/Draupnir/issues/496
* Update to @the-draupnir-project/interface-manager@2.0.0.
The interface has been changed in `interface-manager` so that we can't forget them.
Means that our little error renderer works again.
* Update to MPS v1.2.1.
This will allow us to use `describeProtectedRoomsSet` in unit tests.
* Update to @the-draupnir-project/interface-manager@1.1.1.
This allows for better type inference from the command and also for
partial keywords to be provided to commands as arguments.
* Unit test the DraupnirKickCommand.
Allow command executors to be unit tested.
Part of https://github.com/the-draupnir-project/planning/issues/22.
Only testing Watch/Unwatch command for now to prove that it works.
- Kick command will require a tiny MPS patch to expose kicking as a capability (I don't know if we're going to use the word Kick though).
- Kick command also will require the throttling queue to be hooked up and working again.
- Ban command should be pretty straight forward.
The name of the renderer needs to match the name of the associated capability. Otherwise when a protection asks for the capability you will get an obscure error about not being able to find a renderer for the cap.
* Fix the bot-sdk crypto by initializing the bot-sdk earlier
Signed-off-by: MTRNord <mtrnord1@gmail.com>
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Fix formatting
Signed-off-by: MTRNord <mtrnord1@gmail.com>
* Instead of moving the sync start we move the one message causing issues. This makes sure we are actually ready for incoming messages
Signed-off-by: MTRNord <mtrnord1@gmail.com>
* Add a comment on why the startupComplete method is public
---------
Signed-off-by: MTRNord <mtrnord1@gmail.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
We split out some utility types from the matrix-protection-suite into a library https://github.com/the-draupnir-project/matrix-basic-types
I can't believe that like the extra lines from
```
import {
} from ...
```
are adding up so much but whatever.
* Move to @the-draupnir-project/basic-matrix-types.
* Whoopsie missed a test.
This protection allows room moderators to ban new users from servers (matrix.org). Existing users will be able to participate normally, and if they are accidentally banned, once unbanned rejoining will be unaffected.
This is intended to be used during periods of instability. The protection may be removed entirely or modified in a future release. We will add a documentation page shortly.