We launched anofficial channel about the TamTam Bot API. All the news and updates will be published there, so be sure to sign up. To participate in the testing, developers need to write to account@botapibeta. We’ll add you to the beta testers chat and turn on @primebot for you.
You will also need documentation and clients:
We are also planning a competition on the best TamTam bots, stay tuned.
Meanwhile our senior iOS developer Yuriy Buyanov is telling TamTam Bot API story.
Chat bots have been on a wave of popularity for the last three years. But those developers who have already finished school have a longer story of communicating with bots. For example, in the mid-1990s, I was chatting from Eggdrop on IRC channels, and in the 2000s, I wrote bots for Skype. Stepping aside from messengers and looking to dialog interfaces, you can recall ELIZA (1966), and Turing with his test (1950, “Computing Machinery and Intelligence”), which implied correspondence with artificial intelligence.
We got first requests for messenger Bot API access even before the first public TamTam release. The team used TamTam to communicate with each other and with other developers as soon as the alpha versions of the first clients were available. We wanted to integrate the internal infrastructure (task tracker, CI server, monitoring) into the new messaging system. Despite the fact that as developers we had full access to documentation on the binary protocol used by the messenger (and the WebSocket protocol as well), few decided to write bots on it. And, indeed, few were ready to invest time and effort in working on MessagePack and accurate work with TCP sockets in order to write a bot that would notify participants of the working chat about new builds or crashes.
We needed a special, simplified API, like all modern messengers. The clearer the API and lower the entry threshold for development of bots, the more they will be written and more useful features TamTam will get.
TamTam needed a special, simplified API (REST). An ordinary bot developer doesn’t need half of the features placed in the internal protocol. What is more, by simplifying access to contact synchronization or the registration process, we would make it easier for spammers and scammers to operate. But giving access via REST to a set of API methods is just a small part of the work needed to be done to release the “Bot API” product for external developers.
Developers need an interface to create bots and then manage them. It is not the best idea to issue tokens for work on the API on behalf of the developer himself (few developers would like to see in his chat list all bot correspondence with users), but registering a full user with authentication via a unique phone number is too difficult. We decided to trust one of them to manage bots –@primebot. It is able to create new bots, change their profile details, subscribe to webhooks, and so on.
In order not to confuse users, it would be good to clearly identify bots on the client and support popular UX patterns to work with them. For example, autocompletion and highlighting of commands, as well as messages with buttons.
Developing a convenient and simple API and documenting it is a separate large task that took time and resources.
Tell us about internal testing of Bot API
Any new function is checked by testers and ordinary colleagues for correctness and usability before it is released. Quite often, a feature already completed has to be completely reworked after results of internal testing. It is not difficult to test formal compliance of Bot API to documentation, but how do you test its usability?
The issue was that the API users were developers. Each “session” of its use wasn’t a few clicks on buttons and messages sent, it took hours, and even days of development of a particular bot. It was time to distract the developers from their current tasks and to arrange a hackathon.
Bot writing usually requires experience in developing server applications, but mobile client developers, front-enders and testers took part in the hackathon. Everyone chose a particular stack of development and idea for the bot. There were no strict rules: some joined teams, some made a couple of different bots instead of one.
Bots development took two days, on the understanding that many developers would have to deal with a new stack, and the first attempts to use Bot API would undoubtedly be followed by many improvements. And that’s how it turned out: iOS developers, used to Obj-C, recalled Swift and rooted through documentation on Vapor, testers and front-enders became absorbed in node.js, and the Android team mastered Kotlin.
11 bots reached the hackathon final, and the hackathon team identified 5 winners at the final vote:
- Voting bot
- Chess-playing bot
- Bot for ordering lunch to your office
- Video-download bot
- Excuses generator bot just for fun ;)
We awarded prizes to winning colleagues.