You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AppServices are not informed about events they have sent (whereas a client syncing does).
This is important because we rely on this behavior (in Mjolnir) as a cheap way to avoid inconsistency. For instance, when adding a rule to a policy list, we do not update the model policy list until we have received the rule down from sync.
Currently managed by
Some way to split mjolnir code out from the main Mjolnir instance and have a matrix-bot-sdk client based .onEvent system and an asppservice .handleEvent system.
List short codes need isolating, i.e. they only apply if mjolinr is able to post rules into the list. There’s going to be a lot more Mjolnir’s in the universe and currently watching someone else’s list will also make Mjolnir use its shortcode.
We should also consider MSC3784 when list creation is refactored. .
List creation needs to make the room public but avoid assigning an alias, people aren’t going to know what the policy room is for until they have used it, so they won’t be able to give it a good alias and there won’t be many short aliases available (at least on matrix.org) which will result in frustration and errors. Avoiding this currently by just making them one to start with (without an alias) via some glue code.
Either a change to the default configuration (for autoJoinOnlyIfManager which is false, but being false means that it tries to load from a group (a community which are not even in the spec anymore), which causes a crash. We can change it to a space but it’s still a bit weird, is a requested feature though. Managed by:
Health monitoring of provisioned mjolnirs - need to track and restart them, tell us of failures. Probably part of a bigger issue with tracking failure in mjolnir in general. The only way to make a serious error visible is by logMessage, and that might not be good enough here.
The text was updated successfully, but these errors were encountered:
AppServices are not informed about events they have sent (whereas a client syncing does).
This is important because we rely on this behavior (in Mjolnir) as a cheap way to avoid inconsistency. For instance, when adding a rule to a policy list, we do not update the model policy list until we have received the rule down from sync.
Currently managed by
List short codes need isolating, i.e. they only apply if mjolinr is able to post rules into the list. There’s going to be a lot more Mjolnir’s in the universe and currently watching someone else’s list will also make Mjolnir use its shortcode.
We should also consider MSC3784 when list creation is refactored. .
List creation needs to make the room public but avoid assigning an alias, people aren’t going to know what the policy room is for until they have used it, so they won’t be able to give it a good alias and there won’t be many short aliases available (at least on matrix.org) which will result in frustration and errors. Avoiding this currently by just making them one to start with (without an alias) via some glue code.
Either a change to the default configuration (for autoJoinOnlyIfManager which is false, but being false means that it tries to load from a group (a community which are not even in the spec anymore), which causes a crash. We can change it to a space but it’s still a bit weird, is a requested feature though. Managed by:
Persist which mjolnir's have been commissioned by which users and add the code to start the mjolnlir's we created previously at start up. This will involve stealing from the fragmented storage layers of bridges https://github.com/matrix-org/matrix-appservice-irc/tree/develop/src/datastore https://github.com/matrix-org/matrix-appservice-discord/tree/develop/src/db
Health monitoring of provisioned mjolnirs - need to track and restart them, tell us of failures. Probably part of a bigger issue with tracking failure in mjolnir in general. The only way to make a serious error visible is by
logMessage
, and that might not be good enough here.The text was updated successfully, but these errors were encountered: