Summary

Many chat services (e.g. Slack, Rocket.Chat, Mattermost, etc.) offer the ability to "react" to messages with emoji. It would be nice to be able to make use of that capability.

Basic example

func DoWork(msg joe.Message) error {
  msg.React(":+1:")
  time.Sleep(1 * time.Second)
  msg.Respond("Job is done")
}

Motivation

Using reactions is an easy way to acknowledge that a command has been received without cluttering up the chat with intermediate results. Simple commands could even skip output entirely and just use reactions.

Potential Issues

Not all Adapters will be able to support reactions (e.g. CLI Adapter). A decision would be necessary for how to handle reactions in this case. My thought would be to fail silently (optionally with a logger warning) and to document that reactions are optional for adapters. An alternative would be to error if not available and to offer a capability to test if reactions are available ReactionsEnabled or perhaps msg.ReactIfEnabled.

Edit 1

Perhaps a pragmatic way to handle the absence of reactions would be a ReactOrRespond function that would add a reaction if able, respond if not.

func DoWork(msg joe.Message) error {
  msg.ReactOrRespond(":+1:", "Job started")
  time.Sleep(1 * time.Second)
  msg.Respond("Job is done")
}

Fixes #21

The slack implementation is pretty much done but not yet really tested. Reviews and feedback welcome, otherwise I will probably merge this mid or end of next week :)

Fixes #25

• improve documentation about how multiple matching event handlers are executed
• add a way for handlers to prevent execution of later event handlers
• use this in Bot.Respond(…) so only the first matching handler is executed
• unit test it all

I wrote an adapter for Telegram over the weekend...

I also have a memory implementation using bolt

Both still need a README with some documentation but I wanted to open these anyway in case anybody else is interested in this...

• Make Auth.Grant(…) idempotent and do not unnecessarily add smaller scopes
• Support extending permissions via Auth.Grant(…)
• Add boolean return value to Auth.Grant(…) to indicate if a new permission was granted
• Add Auth.Revoke(…) to remove permissions
• Fix flaky unit test TestBrain_Memory
• Fix flaky TestCLIAdapter_Register test

Currently, the Rocket.Chat adapter does not have a released version with Reactions support. I have some initial code on my master branch, but there are some bugs yet to be resolved.

On the other hand, the Mattermost adapter does support Reactions (at least adding them to messages, still working on the event support).

I've been trying to figure out how I can make my bot respond with a helpful message when no message is matched.

Naively I've tried the following approach which results in both handlers to be executed

b.Respond("foo", b.FooHandler)
b.Respond(".*", b.HelpHandler)

Unless I'm missing something, there does not seem to be a way to register a default handler that would only be executed if no other handler matches the message.

There also does not appear to be a way to stop processing handlers after the FooHandler is executed.

I've written an adapter for use with Rocket.Chat based off of the Slack adapter.

I'd be happy to make changes if there are any issues you would like corrected.

I'd really like to have support for lists in Memory implementations, without having to build it up from KV considering that some of the Memory implementations have first class support (Redis). Would you want to add this concept to joe?

I'd also like to have Sets since my ultimate goal is actually a list of unique objects, and if we have List, and Set I can compose them into UniqList anyway.

Currently, the standard joe.ReceiveMessageEvent sent by all documented adapters does not specify whether the message is "private" (a one-on-one chat in Slack, a /msg in IRC, etc).

This can be useful in having handlers process commands differently (e.g. allow admin-level commands in direct chats) depending on the communication mode, without having to either parse the Channel or Data fields (which assumes the handler knows which adapter is being used) or having to use custom events, which assume adapter support.

Thanks for putting together this library, I'm just starting to explore it. I was wondering if there is a recommended method to send an arbitrary message to a channel without needing to "Respond" to a message that has come in.

My [first] use case is that I want to send a message to a channel after receiving a webhook via the http-server.

I suppose one way that I might be able to achieve this is to have the webhook handler publish a joe.ReceiveMessageEvent event with the desired channel that I want to send a message to, then listen for this 'silent' event emitted and respond to it. This will likely work, but it seems like quite a workaround to achieve my goal.

Any insight you can provide would be appreciated.

Thanks

Summary

Since many uses of the Storage interface may have hierarchical keys, e.g. the permissions, it would be beneficial to have a way to iterate over keys matching a given prefix.

Basic example

for _, key := range a.store.KeysWithPrefix("joe.permissions.mymodule.") {
  ...
}

Motivation

From #28

Since we are iterating over all keys the bot knows we should expect that also non-permission keys are among them.

I suggest you update your unit test to check this is also handled correctly.

Rather than push this onto any developer who needs to interact with the permissions, we could require the Storage interface to support prefix scans. Some storage engines may have a higher performance way of doing prefix scans and we could take advantage of that. If the storage engine does not offer it, the bot could handle the naive looping over keys itself. This removes the burden from developers to implement/test this independently.

Potential Issues

• If the prefix scan isn't optional for the Storage interface, a new release would break any third party implementations. As described above, this would not be an issue.