raf924 / bot Goto Github PK

When relaying a message from the hc chat server, the connector should embed all available user data for the sender in the packet.
On private messages relayed by the connector, the isMod user field is always false even if the user is mod.
Public messages do not have that issue.

Problem might come from the HC relay if the user information it provides is not enough to pair the sender with a known user correctly.

Problem might come from the connector if for some reason it handles private messages differently.

When the connector fails to dispatch a message to a client, either remove the client immediately or implement a backoff algorithm.

Requires #18

Requires #18

Right now, if two clients define the same command name and/or alias, both of them will have the possibility to execute it.
While this can be mitigated by disabling the command in one of the client's config, there should be a way to make it so only one client can use the command.

One solution would be to implement a first come first served algorithm.
Another would be to implement a load balancer.

Reload configuration without restarting the process/container/pod when it changes on the filesystem.

If at all possible keep the commands state intact. Would imply either tracking which configuration property they use or adding an update method to the commands API so they can handle the change themselves

Allow the connector to be accessible via different protocols at the same time (CapnProto, GRPC, Websocket, etc)

AFK should be recognised as afk