Skip to content

Instantly share code, notes, and snippets.

@mikaelmello
Last active April 25, 2018 17:01
Show Gist options
  • Save mikaelmello/0b41214fd850d07e4283cc35178535a6 to your computer and use it in GitHub Desktop.
Save mikaelmello/0b41214fd850d07e4283cc35178535a6 to your computer and use it in GitHub Desktop.
Draft of GSoC 2018 proposal for Rocket.Chat

"Improve the integration of bots on Rocket.Chat" proposal for Google Summer of Code 2018

Personal Details

Background Information

Motivation

When I first heard of GSoC a couple weeks ago, I found it a great opportunity to improve myself both as a developer and as a person by contributing to open source (something I had never done until last month) and bonding with the community behind it. Rocket.Chat really caught my attention for a couple reasons: First, it has a well-built codebase in a language I am familiar with and second, it is a Brazilian company, that alone makes me want to contribute to it regardless of GSoC.

Experience

My work with Node is mainly composed of back ends of a couple websites using WebSockets, Steam bots and Express. Regarding general knowledge about bots, I am somewhat familiar with the architecture of Telegram bots and, as previously said, Steam bots.

Availability

For about 2/3 of the Coding phase I will balance this work with my classes, which take approximately 20h/week, leaving me able to work from 30 hours per week on this project. Apart from that, I have a scheduled event from May 30th to June 3rd, but this will not delay any milestone since I'll produce more in the previous week

Project Proposal

Rocket.Chat currently has 2 fronts when it comes to bots.

One of them includes the Rocket.Chat Node SDK, an agnostic interface for bot adaptors, and the connectors/adaptors from varying bot frameworks. The SDK is still under development along with the Hubot adapter and a few more connectors from frameworks such as BotKit or BotPress in the future.

Even though the tools available to deploy new bots to Rocket.Chat are improving, the integration with the Administration Panel is stagnated and basically outdated, some of the problems are:

  • The Internal Hubot tab's package (internal-hubot) has its own (worse) adapter than the one at hubot-rocketchat, which is in the process of converting to ES6 and to use the SDK.
  • The Bots tab has a few settings for the bot-helpers package that is not used anywhere.
  • There is no information regarding external bots that are connected to the server.

The goal of this project is to develop a basic UI to monitor and manage existing bot users along with setting the foundations to create and deploy a new one according to the selected framework.

Regarding management of existing bots, all users with bot roles will be listed along with information about each one of them, such as:

  • Status: Tells if the bot is connected, running or paused, etc.
  • Framework: Tells which platform the bot is running on (Hubot, BotPress, etc) along with informations about the adapter being used.
  • General stats: e.g. total messages received/sent, uptime, ping, etc.
  • Management options: Monitor logs, ability to pause or disconnect the bot if the adapter supports it, list available commands (if something like RocketChat/Rocket.Chat#1086 is implemented), etc.

When creating a new bot, the admin will fill a menu with the initial set of configurations of the bot, such as basic info of the bot account, and choose the framework from a list of the ones supported by the server. Then each framework will have different ways of deploying their bots.

In order to do all of this, a new package will have to be created and new features will be added to the Node SDK, along with new standards to future adapters/connectors.

Proposed Milestones and Schedule

The development of the new package will first add the most basic features and then extend them to support all current needs.

1. Prepare the field -- first milestone (4 weeks)

From May 14th to June 10th

Before starting to code there are a few important things to study and review with help from the mentor, the second section will most likely take more time than the second.

1.1. General overview (1.5 weeks)

  • Rocket.Chat's architecture as a whole, mainly Meteor and Asteroid.
  • Study at depth the Rocket.Chat's Node SDK and the current implementation of the Hubot adapter.
  • Get information about the development of other adaptors (if there is someone developing them at the same time).

1.2. Data modeling (2.5 weeks)

While some of the information provided can be retrieved on-the-fly, some will need to be persisted on the database, in this section I will make the necessary aditions or changes to the database in order to persist whatever is needed for future features to become available.

These changes can have a meaningful impact on this project and on the core of Rocket.Chat and even though there is the need to be careful, the flexibility of Mongo allow us to make changes later due to misconceptions in this phase or future change of plans.

2. Getting the information -- second milestone (3 weeks)

From June 11th to July 1st

In order to get this new set of data, we will refactor the rocketchat-bot-helpers package (basically recreate it from scratch using the same name) by implementing functions that wrap the ones that are current used, but requiring and/or storing additional information that we find useful.

For example, instead of logging in with loginWithPassword, we could implement botLoginWithPassword that requires the adapter to tell its Framework, version, etc. and then store this data along with others such as IP address.

2.1. Getting static data (1 week)

We will implement the functions and wrappers to gather the less complex data that will not change while the bot is connected (framework, version, IP).

2.2. Getting dynamic data (2 weeks)

In this section we will implement the functions and wrappers that will be constantly updated as the bot remains connected (ping, number of messages, logs, uptime)

3. Displaying and managing -- third milestone (4 weeks)

From July 2nd to July 29th

Once we have a way to gather and store the data, it is time to implement the UI in the Admin section to showcase the stats and then implement the functions that will act on the bots, such as pausing the bot.

This will be implemented under a new package, not rocketchat-bot-helpers.

3.1. Displaying the available data (2 weeks)

In this basic UI the admin will be able to easily see general data about the existent bots (connected or not).

All the bots will be listed with the general information about them, with an option to view more details about it in a new page.

3.2. Interacting with the bots (2 weeks)

In this section we will build some basic options that can later be extended by the community, they are:

  • Basic creation of bots, for now we will at most create the bot user and then guide the admin to the installation and connection of the bot.
  • Pausing, resuming or even disconnecting a bot from the admin panel.

4. Documenting -- fourth milestone (1 week)

From July 30th to August 6th

The documentation will be written during the entire project, however we reserve this last week to finish any pending pages, review everything and do general fixes.

@bizzbyster
Copy link

bizzbyster commented Apr 25, 2018

@mikaelmello when do you see having support for a botkit bot with just static data showing in the Administration Panel? Also, what all types of bots do you intend to support? Will api.ai/dialogflow be one of them?

@mikaelmello
Copy link
Author

mikaelmello commented Apr 25, 2018

@bizzbyster

Also, what all types of bots do you intend to support? Will api.ai/dialogflow be one of them?

The implementation is intended to be agnostic, as long as the bot's adapter sends the standardized information we need, we can show it. So it depends on the adapter's implementation.

When do you see having support for a botkit bot with just static data showing in the Administration Panel?

On week 8~9 (section 3.1), if there is a functional adapter developed by then.


Since I wrote this proposal I've read more about what I will be working with and I can see that some things need to be changed, such as the retrieval of some data since not all adapters will use the JS SDK

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment