This provides two new arguments for paths to load secretes for `--access-token-path` and `--pantalaimon-password-path` from.
The intention being that they can be used with a credentials system such as https://systemd.io/CREDENTIALS/.
They will take precedence over anything within the config file.
Suggested after https://github.com/NixOS/nixpkgs/pull/274052#discussion_r1481633083.
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* Add support for bot-sdk crypto as an experimental flag
* Import and use StoreType enum
* Fail hard instead of continuing in case of having pantalaimon and bot-sdk set up
* Document Option in default.yaml
* Remove obsolete comment
We were clearly in the process of deleting the
member decleration to just have the decleration be in the constructor.
When we were distracted, leaving a property named `readonly`, which
shouldn't be possible imo, need to add some rule for that prompto.
Before CommandError's where and they are used
liberally for validating command arguments by
returning a CommandResult for several possible
options. Which gives a lot of spam. It's not necessary
anyways since these should only be used for known errors.
Shouldn't change what is being logged to the log file,
but it does change what gets sent to the management room.
I've been meaning to disable this for some time as it generally
confuses new users and it makes the bot feel very confusing and
low quality. It also means you are likely to miss more important
messages in the magement room.
Another problem it causes is an inconsistent view when testing
the software and it's an unreasonable burden to test for both
settings.
It's not clear what the value of this setting is apart from
providing comfort to some users who want to see the ACL readout.
But even then it's a very inefficient way of doing that,
so i'd rather another feature be requested by users that want to see that.
Sometimes we don't need exceptions to be reported on the error level.
This is especially true when the user does something out of order
and there's a permission error.
If we're aware of that possibility as developers and have accounted
for it, then it's unnecessary for it to be treated the same way
as a fatal error.
We also decided to log CommandExceptions and CommandErrors as
early as possible.
https://github.com/Gnuxie/Draupnir/pull/93/
We've done this to make the implementation a lot cleaner and
managable. However, we've taken the opportunity to simplify
all of the client code that would use this method.
Some of these simplifications might come at a small cost.
Updating server ACL, member bans and checking power levels
would all be clearly titled as seperate checks.
However, it should still be obvious what has gone wrong,
since any error would have to give a more detailed explanation.
And not everything is going to fail all at once (and if it does,
there are bigger issues).
a lot cleaner
https://github.com/Gnuxie/Draupnir/pull/85
A bizarre contraption.
The ErrorCache was seemingly introduced to reduce the number of errors
in the management room.
https://github.com/matrix-org/mjolnir/commit/82214c6cd88d83abed05fec4a871a874e6e0265b
It makes sense why it was added if you consider that many admins
will run Draupnir without giving it the permission to manage server
ACL in its rooms. Though, I'm not sure why then you would add the error
cache rather than properly supporting that use case.
So perhaps there were other reasons.
Either way, what is drawing the line for me is that the ErrorCache
will suppress any error within rooms that is not a permission error,
if there was any error that was not a permission error within a
15 minute window.
Considering the typical Draupnir will not even sync
for hours at a time, even in large communities.
It does present a problem for rooms with a lot of join/leave events.
I think that's probably why the error cache was added.
Ahh, well, fuck.
Well what is the real solution to this?
The real solution when the kind is acl is to allow the bot to run
without applying ACLs.
Ok fine but, hey wait a minute.
Why would there be any other kind of persistent error
when banning someone that would be unimportant enough to silently
hide in an ErrorCache??
IDK let's just add an opttion to disable server ACL,
since they might want to use another tool for that anyhow.
Out of scope for the current work though.
https://github.com/Gnuxie/Draupnir/pull/85
This adds the `displayname` command which just sets the displayname of the user.
-----
* Add command that allows to easily set the Displayname of a bot
* Only set the displayname once
* Add missing matrix interface adaptor and use CommandError
* Make displaynames with spaces work
This adds a `/healthz` endpoint to the appservice which allows this to work more nicely in kubernetes.
It also adds some metrics for tracking the provisioning state.
Grafana result:
Note: The ts-ignore are sadly required since the `_getValue` method is not public :/ I didnt find another solution apart from tracking it maybe elsewhere.
* Add health endpoint to appservice and add metrics via prometheus
* Ensure that we dont have duplicate metrics when the appservice is registered multiple times
* Move gauge modifications to utils function
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Fix typo
* Use the new help style on the appservice commands and add missing descriptions for the arguments
* Make the first letter of the table name uppercase in the help table
This was introduced in https://github.com/Gnuxie/Draupnir/pull/54/ (and therefore 1.83.0). Essentially we forgot to remove the room from the protected rooms set, when the remove command was used.
Ontop of this something to note is that during testing it is clear that the protected rooms set is loaded when configuring mjolnir, not when starting it. This is problematic as it means setup code in `fixtures.ts` does not actually wipe the protected rooms set.
This is actually really bad.
For multiple reasons.
The best way for this to be avoided is to drop everything
and reload it when the account data for watched lists is changed.
Then there isn't a situation where you have to inform anyone
about a change in what lists are being watched.
* Do not interrupt redact sequences due to error when backfilling
... Mainly timeouts.
* Change caught redaction error LogLevel from DEBUG to ERROR.
From matrix-org/mjolnir#479
---------
Co-authored-by: Marco Cirillo <marco.cirillo@aria-net.org>
Canonicalise the existence of the "admin room" for managing the appservice and Draupnir instances
* Add utilities for managing users in the admin room
* Merge the appservice admin room and access control list.
The majority of admins will need to use the draupnir admin commands
to manage the list.
* Utility methods for creating generic rules in PolicyLists.
* Commands for managing appservice users.
* use matrix-appservice-bridge support for postgres
* upgrade matrix-appservice-bridge to include postgres fixes.
These are unreleased and a specific develop commit, but we're the only ones
who have made changes so far to the develop branch,
so should be fine.
* Upgrade matrix-appservice-bridge to 8.1.1.
8.0.1 was never added to npm for some weird reason.
TODO:
- Needs description adding into the detail rather than the summary
- needs rich text
- needs markdown detail/summary to not just be the HTML tags, unacceptable since it's supposed to be fallback
- More commands
Rory&