jaimeteb / chatto Goto Github PK

When connecting to an extension server it would awesome if we could send the bot our own classifiers and transitions. This would allow us to programmatically generate questions and answers.

An example where this would be used is the company I work at. We have an internal StackOverflow site. We could write an extension that gets all the questions and answers from that site and generate classifiers and transitions and register them with the bot.

It would be super powerful for automatically training the bot to respond to questions with a set of predefined answers from other tools.

It's not clear which APIs should be public and which are private. We should move private APIs to the internal/ directory.

Internal packages
Go's package system makes it easy to structure programs into components with clean boundaries, but there are only two forms of access: local (unexported) and global (exported). Sometimes one wishes to have components that are not exported, for instance to avoid acquiring clients of interfaces to code that is part of a public repository but not intended for use outside the program to which it belongs.

The Go language does not have the power to enforce this distinction, but as of Go 1.4 the go command introduces a mechanism to define "internal" packages that may not be imported by packages outside the source subtree in which they reside.

To create such a package, place it in a directory named internal or in a subdirectory of a directory named internal. When the go command sees an import of a package with internal in its path, it verifies that the package doing the import is within the tree rooted at the parent of the internal directory. For example, a package .../a/b/c/internal/d/e/f can be imported only by code in the directory tree rooted at .../a/b/c. It cannot be imported by code in .../a/b/g or in any other repository.

We should ensure the sender key we use to store the FSM into is unique across channels.

A very simplified example would be...

// Answer takes a user input and executes a transition on the FSM if possible
func (b *Bot) Answer(question *query.Question) ([]query.Answer, error) {
        sender := fmt.Sprintf("%s/%s", channelType, question.Sender).  # <----- Set a sender name based on channel and name?

	if !b.Store.Exists(sender) {
		b.Store.Set(sender, fsm.NewFSM())
	}

It would be handy to allow for multiple extension servers.

Add ability to transition from multiple states not just any.

functions:
  - transition:
      from:
        - "gomodules"
        - "goreleaser"
      into: "initial"
    command: "thanks"
    message:
      - text: ":thumbsup: no problem-o"

A more complicated example, for instance, we want a robot that can solve some basic functions like what's the weather today? Tell me a joke, do u know how is the tallest man in the world, how to combines all these intent into a full example?

for use in extensions

We should use goreleaser for releases.

The following would probably need to change...

• Change the Dockerfile to work with goreleaser.
• Change Github actions to run gorleaser when a semver tag is created.

how to call a function with params inside program when a action triggered?a

Awesome project. What would it take add a new slack integration?

Currently extensions do not have support authentication. This is insecure. We should add support for setting an auth token.

We should support SSL for extensions.

There are a few nice things that we can add to make the chatto server friendly for Kubernetes usage.

1. Use a prefix for env variables CHATTO_BOT and CHATTO_CHN. [x]
2. Hot reload when configuration changes. [x]
3. Provide an example deployment YAML. [x]
4. Add a liveness/health check endpoint that does not require auth to the bot. [x]

I’ve been thinking about the FSM.Domain and how we pass it to extensions. When I did the internal refactor I felt like FSM package should be a private API.

Maybe the bot should have some REST APIs for the extension to work with FSM with some safeguards in place. Instead of directly sending the FSM.Domain to the extension. I do feel like this make it less complex for developing new extensions so the extension author does not need to learn how to work with the FSM directly.

Thoughts?

We could make the fsm.yml configuration easier by determining the states and commands automatically from the transitions. It would be a matter of looping the transitions to enumerate each automatically. Below is an example fsm.yml with the proposed changes from the 01_test example.

initial_state: "off"

transitions:
  - from:
      - "off"
    into: "on"
    command: "turn_on"
    message: 
      - text: "Turning on."

  - from:
      - "on"
    into: "off"
    command: "turn_off"
    message:
      - text: "Turning off."
      - text: "❌"

  - from:
      - "any"
    into: "off"
    command: "hello_universe"
    extension: "any"

defaults:
  unknown: "Can't do that."
  unsure: "???"
  error: "Error"

In examples section of readme file, Pokemon Example link is broken.
It should point to https://github.com/jaimeteb/chatto/tree/master/examples/02_pokemon instead of
https://github.com/jaimeteb/chatto/tree/master/examples/03_pokemon
PS: 02_pokemon instead of 03_pokemon.

I think it would be clearer to rename extension.RegisteredFuncs to extension.RegisteredCommands or extension.RegisteredCommandFuncs.

This would make it more inline with the wording used throughout the bot.

Hi there! I have had some success following your docs to stand up a Flask app that roughly supports the restful extension API. Very cool project, thank you.

I couldn't help but be a bit jealous of the Go examples being able to just import extension and run with it.

I'd like to help make this more accessible for would-be Python, Ruby, JS, etc. bot authors. @jaimeteb have you or @ryancurrah plotted a way to give the rest server API a quicker onramp?

I've thought about maybe building a python library to abstract a few of the basic bits of the Flask use case, but maybe a swagger-oriented codegen approach could cover more ground with less work. I haven't yet tried the RPC model so I imagine it's got some implications for potential approaches to bootstrapping new REST integrations..