neomatrix369/chatbot-conversations

Chatbot conversations: a demo application how two (or more) chatbots can talk to each other, the logic used to build Eliza (along with an NLP model) has been used to power the chatbots.

chatbot-conversations's Issues

Publish image helidon-world on Docker Hub

Create frontend app to manage and interact with chatbots

Create MVP frontend to allow interact with chatbots

• Create chat panel to read and write message
• Menu to show all connected participants

Fix resource path loading error from container quarkus-world

Do not clone repo via Dockerfile, use files from parent folder

At the moment the Dockerfile script clones the git repo https://github.com/neomatrix369/chatbot-conversations/ and then performs the necessary build steps.

When running this on a local instance, this may be problematic as it won't be picking up the changes from the local filesystem and expect the changes to be present in the repo to reflect in the built image.

Restructure the Dockerfile such the image is built using the files in the local environment rather than cloning the repo.

We could temporarily copy the files from the parent directory into the local folder near the Dockerfile and this could be packed into the docker image.

Create a single docker image for all components (for dockerhub)

For learning and illustrating purposes it;s a good idea to have a single Docker image via single Dockerfile.

Then executing/implementing issues #1 to #10 will become easier. Thanks for splitting the issues into smaller parts @yugoccp

Here are two examples to follow to create the docker config file(s) and shell scripts to achieve it:

• https://github.com/neomatrix369/awesome-ai-ml-dl/tree/master/examples/deepnetts
• https://github.com/neomatrix369/awesome-ai-ml-dl/tree/master/examples/tribuo

(also check the docker-image folder)

Create Dockerfile for connecting_worlds

Create docker-compose to connect clients and run containers

Improve code quality

We can introduce improvements to the code by doing a number of things:

• apply linters across the Java and Python code
• apply linters across the Docker and shell script
• introduce tests where necessary
• introduce code-coverage across the different sub-projects
• create a CI/CD flow via GitHub Actions
• display quality metrics and badges on the README page

See https://github.com/neomatrix369/nlp_profiler for examples of badges. Also, include the project to the https://app.codeac.io/login/github service and add the badge to README to track issues in the code base.

Make connecting_worlds clients configuration read from external source

Actually connecting_worlds needs to know the host, port and API of each chatbot to interact with it.
When adding new chatbot, we need to make changes on connecting_worlds project to add the new chatbot configuration.

Extracting chatbots configurations to an external resource will make it much easier for contributors to add new chatbots into the project, and won't need to rebuild new Docker image to make those changes.

Note: issue #18 might change the protocols and communication architecture, which affect this solution.

Publish image connecting_worlds on Docker Hub

Publish image roberta-world on Docker Hub

Publish image quarkus-world on Docker Hub

Smart detection of the pull and push images scripts (make them idempotent)

At the moment pullImage and pushImage are not idempotent.

Both the pullImage and pushImage functions in the shell scripts should only do the respective tasks if the target is older than the source image.

We may have to download/extract the digests from the local and remote images and compare them for equality before downloading the images.

Use Websocket to communicate with chatbot

Spike to evaluate use of websockets as protocol to connect chatbots with each other.

Benefits of this approach:

• Centralize message hub to connecting_worlds
• Chatbots can be added at anytime
• Keeps connecting_worlds as a conversation mediator
• Simplicity of the implementation

Deploy docker container onto a cloud

At the moment we can run the docker container on our local machine.

It would be great to run this same container on a cloud service i.e. OCI, AWS, GCP.

A good example can be found here https://github.com/neomatrix369/awesome-ai-ml-dl/tree/master/examples/tribuo/deployments/oci

Improve README page

The following could be done to improve the existing README:

• add the necessary badge to show docker image usage, GraalVM usage using shields.io: or using the logo at https://www.graalvm.org/logo/, or use
• shorten the initial page by splitting the main page and moving them into sub-pages
• create link(s) between other .md pages in the folder to the README page

Examples: See https://github.com/neomatrix369/awesome-ai-ml-dl#awesome-ai-ml-dl-- and https://github.com/neomatrix369/nlp_profiler

Create README file with instructions from the single image

End user should be able to run the docker-container (or even build it) by just following simple steps - running the shells script with the right flags

Compile jar files into graalvm native-images

The 2 chatbots and connecting worlds that are java projects:

• Helidon world (Java)
• Quarkus world (Java)
• Connecting worlds (Java)

are currently built and run via java jar files, the final docker image could instead have native-images for all of them.

Benefits of doing this:

• quicker startup
• low memory footprint

Examples on how to do this can be found in https://github.com/neomatrix369/awesome-ai-ml-dl/tree/master/examples/tribuo/, see https://github.com/neomatrix369/awesome-ai-ml-dl/blob/master/examples/tribuo/builder.sh for the code behind it.

Introduce queues to improve inter-bot communications

As the project started off as a demo project, inter-chatbot communications are not the most optimum.

Also if we would like to introduce a frontend via #17 then the interactions would be best handled by a queue.

Spikes and prototypes to come up with a queue would be a great start, some examples of queues could be:

• JMS
• ActiveMQ
• RabbitMQ
• Kafka

Although for all intent and purpose of this project a simple queueing library is more than enough - a simple approach is a good start.