Skip to main content

Introduction of Bubble

A Conversational Runtime for Devices​

The first key aspect of our software is that everything is based on a messenger model. We call our messenger Bubble. A messenger interface is an incredibly powerful, easy, visual, and fun way for organizing smart devices and programs.

In Bubble, applications are presented in the form of chatting bot. Different from telegram or slack bots, Bubble introduces a fundamental shift in focus. Traditional chatbots are primarily designed for human-to-bot communication—answering questions, providing information, or automating workflows within messaging environments. In contrast, Bubble bots are designed to interact with devices. This means that device control is not an extension or plugin—it is a native capability of the bot itself.

Turning devices into first-class participants in the conversation, alongside users, brings several significant advantages:

  • Seamless multi-user collaboration — Multiple users can interact with the same device through a shared conversational context.
  • Multi-device orchestration — A single bot can coordinate multiple devices simultaneously, enabling complex cross-device scenarios.
  • Low friction interaction model — Users do not need to switch between dashboards, control panels, or separate apps. Everything happens inside a unified chat interface.
  • Scalable interaction patterns — The same conversational abstraction can scale from one user and one device to many users and many devices without architectural changes.

This ability to naturally unify users, bots, and devices inside a single conversational runtime is what makes Bubble unique. It transforms the chatbot from a messaging assistant into a distributed device control layer—making collaborative, multi-device applications straightforward to design and deploy.

Open, Programmable Devices for Everyone​

The second design philosophy of Bubble is to allow anyone to easily write any code for any device, and to allow any device to easily work with any other devices.

The traditional way of developing an application for a smart device like PixelMug is that the code is fixed and spread at three places: the firmware on the device itself, the GUI app on the user’s phone, and the cloud code running on the device company’s servers. What this application would do is determined exclusively by the device company, and the coding at all three places is hard-wired.

If you are a third party software developer who has an idea of a new application or a new feature for PixelMug, for example, if you want show real-time bitcoin price or package tracking info, you’re most likely out of luck. With Bubble, the architecture is different. We make the devices open for software developers.

The firmware on the device is kept minimal and general and is devoid of any application-specific logic. Developer just needs to write a few lines of Javascript/Typescript code of a bot and in a matter of seconds, he can get his bitcoin and tracking apps up and running. Everything, including the device firmware and the application code, communicates with each other with Bubble messages.