A (non intelligent) chatbot multi-interface and distributed as a personal information manager.

This is the description of a personal project (pet project, not part of my work). The title is quite long, but I wanted to make it clear that this is not an intelligent bot. It only tries to be useful (for me) and who knows if it will be useful for others.

This is a extended transcription of a presentation I gave at the esLibre 2020 conference. The conference was intended to be developed in June, but the organizers had to delay it until september and then they adapted the format to be non-presential. It is due to acknowledge the efforts of the organizers for this change.

You can see the video (in Spanish) in:

You can also see in the official repository File:EsLibre2020 19S.P1.07 - Fernando Tricas García - Un bot (no inteligente) multiinterfaz y distribuido como asistente personal.webm

The slides are in English (except for the title), just to see if some more people can read them.

First of all, I would like to show some definitions that will be useful to better understand the project.

From Wikipedia, a Personal information manager:

... (often referred to as a PIM tool or, more simply, a PIM) is a type of application software that functions as a personal organizer.

This idea is seducing me since long time: maybe having some address book, alerts, calendar, and some more things. We have in our pocket a computer device (our mobile phone) which should help us to have a better life or, at least, a more comfortable one.

Now, I would like to show some tools that have some relation to the work presented here.

• First of all, let me name a project as personal inspiration, Hep (Webarchive link) was a project by Abe Fettig proposing some sort of 'multiprotocol message server'. It was able to read RSS feeds, email, and other sources of information and it could redirect them to other destinations.

• Another interesting project is A personal API (there seems to be some problems with this blog now). The author has his music, photos and the possibility (who knows?) of routing the adequate information to wherever it is of interest for us in some moment.
  It can act also as a concentrator of information.
  I'm quite pesimistic about the control and persintence of our information in the public platforms, so it is a good idea to think about these alernatives.

• Recently I saw another proposal by Simon Willison in Personal Data Warehouses: Reclaiming Your Data. This was not exactly my objective, but I'm finding these approaches very interesting.

• Finally, and after the presentantion I've also discovered Personium, a self-proclaimed 'interconnectable open source PDS (Personal Data Store) server envisioning world wide web of protected data APIs.'
  We'll have go give it a try.

A chatbot is:

A chatbot is a software application used to conduct an on-line chat conversation via text or text-to-speech, in lieu of providing direct contact with a live human agent. Designed to convincingly simulate the way a human would behave as a conversational partner, chatbot systems typically require continuous tuning and testing, and many in production remain unable to adequately converse or pass the industry standard Turing test.

As stated before, I'm interested in the textual interface to interact with machines, but not in the simulation aspects.
Of course, if you are interested, you could add this to the presented developments. You know, 'In the Beginning... Was the Command Line' and that's from where we come (Quote by Neal Stephenson).
For me it has been since long time the preferred way of interacting with a computer and that's the way I'm still trying to work. We can write in some small window some text commands and the computer will give some results.

But usually we have some mobility: now we are in our cubicle, but later we can be at home, in the street or in some other part. Maybe we are not in front of our computer or, sometimes, we are not in front of our computer.
We could install in our mobile device something like Termux or another software and we could interact with some remote computer. In this way you can do some interaction from time to time but it is not practical: inadequate keyboard, inadequate screen, ...
Moreover, and from a more philosophical point of view, you know the sorrowful state of the web (not only because of the cookies notice, JavaScript everywhere, adds, notifications, fonts, ...), but also because of the way some pages have been published (non-responsive ones, for example).
This can be a problem when you have a device with limited capabilities as our typical mobile phone.
Sometimes, you just need to access to very simple pieces of information.

Yes, we have apps, but you know: first of all, it is not possible for us to install a new app to interact with each company/organization/site/whatever you want. Second, most apps are just limited versions of what you can do with the web application. Let us forget the issue of permissions, privacy, and so on.
As an aside, let us remember the idea of 'superapps' which try to be aggregators of activity (for example, WeChat, mainly in China. Probably we will see some advances in the near future in this world.

So, why not to test some different approach?

Can we construct an information manager with a bot interface?

I do not wanted to build a bot, but I wanted to have a bot. If you have a look at GitHub you will see more than 405.000 projects (now) and near 150000 of them written in Python, which is my preferred language for this sort of quick development.

The idea of the bot allows us to have some services at home without exposing, for example, our IP. We do not need to open ports, and so on.

There are some other bot-like interesting projects, that I have found after I started my own work:

• Almond has some similarities (about gettin info from different sources) it has a web interface and it is written in JavaScript;
• Jarvis is a command-line 'Personal Asisstant', written in Python.

As an aside, I recently discovered that you can be famous for a Botnet StarBot, which remembered me the 'Fitteen Minutes of Fame' (A. Warhol), or 'Famous to fifteen people'.
Anybody interested?

But let's return to our bot. I selected the Errbot platform for various (self declared, but true) reasons:

• Simple to build upon.
  With Errbot it is easy to add your own commands by creating a plugin, and this seems a very adequate way to work.

• Batteries included.
  It has several backends, so you can choose the way of interacting with the bot (IRC, Telegram, XMPP, Slack...). Unfortunately, you must chose just one (more on this later).

• Sharing and Community.
  Some people are sharing development around their own work, and this is encouraged.
  It is free (libre) sofware, so we can use, develop around the bot and publish the results without limitations.

Some limitations: if I'm on the tramway I'd like to send a Telegram message to my bot, but when I'm on a terminal, maybe I'd prefer to interact using IRC or Slack, if I'm in front of my desktop.
Six years ago somebody asked about this in the Google+ group (now disappeared) and later somebody asked for this in the GitHub issues forum Support multiple backends in one instance #1137. But no advances on this matter appeared.

So, why not to try to add this funcionallity in some way?

We do not want to do a big change but, maybe, add some code to be able to have a bot communicating via different channels. Or, several bots, each one in a different channel that can pass work to others when requested.
This is easy to implement as a plugin, and we can use C&C (Command and Control) techniques, so err-forward was born.
These techniques are used mainly in the malware and botnet management. But we can use them for good.
In our case, the bots are subscribed to some common channel and they can write instructions there for other bots and read the instructions that other bots have written for them.

Let me know talk about parasitic infraestructure (do you remember Parasitic computing?). Of course, we could use a server for this, but my thought was that the project could be more interesing if we take adavantage of available services.

We can use some public (or not so public) site in some service to host the communication channel. We selected a Slack channel, but we have also done some tests with Gitter. Other options would be prossible.
We set up a channel where the bots can read and write (via the plugin) #tavern-of-the-bots.

• Reading: each bot reads all the messages, and it sees if there is something for 'him' (we are using the Errbot prompt for this. We could use a differnt approach based on trying to execute everything, but we decided to use a more 'controlled' approach). They can also process replies from other bots when the delegated command is finished, in order to inform the user.

• Writing: a bot can write when it starts, to show presence (mainly a feature for the manager of the thing, not used by the other bots: they use an asynchronous model to communicate and, in particular, they do not check if the receiver of a command is available or not); they can write instructions for other bots (forward, fw); they can also write the results of some command the have read previously.

There are also some instructions to show the IP address of a bot (myIP) and to list the registered bots in the channel (listB), as an information for the manager.

Some use cases

• err-pim

  • Looking at the directory of my Department for somebody data contact.
  • Getting info (from public API) about the next arrival of a tramway.
  • Searching some mail in my account (using mairix, unmaintaned now)

• err-camera

  • Taking pictures with a webcam and sending them via email. This plugin was published in Hacker News: Show HN: Remote controlled webcam by chat (Pi and errbot)

Being famous for seven hackers! :-)

• err-social

  • Interacting with social media (Twitter, Facebook, Mastodon, ...)

• err-calendar

  • Reading my appointments (and others' authorized ones)

• err-imdb

  • Not happy with it, yet. Asking for the films we can see today on TV, or the IMDB 'stars' for some film.

Some lessons learned.

• The interface is important: when you need to write instructions, you need to have a good set of instructions (easy to write, short, meaningful, ...). This is specially important when you'll interact using a mobile terminal. One click: Two clicks:
• When you have several bots interacting at the same time, maybe with external services you will have some concurrency problems: things that were there and have changed (TOCTOU), and so on.
• Not many people has shown interes in the proyect (two watching people, three stars, ...)

Conclusions

• APIs are important to access information. Web scrapping too. If your service provides an API, mabye someone will use it in some different way (Kudos to the townhall of Zaragoza for the APIs provided).
• We can have access to the information from several places, as desired.
• Having a project like this is fun and you can learn many things (improve your coding, learn about architecture, learn from other ways of working, ...)
• You can also contribute (at least, modestly) to other projects (improving documentation, detecting bugs, ...)