Cola Technical Overview

Cola Bubbles run within Cola’s overall messaging architecture. That system includes:

  • A phone-number based identity system. Every Cola user is identified by his or her mobile phone number. This number is not exposed to the bubble API, but does serve as the basis of user identity. The user’s identity also includes an associated name and a participant ID.

  • A server-based message store. This subsystem stores all messages and their associated payloads (e.g., the text of a text bubble, the image or video associated with a media bubble, and any bubble-specific payload for Cola Bubbles). Unlike ordinary SMS, or products like iMessage, all Cola messages and conversations are stored (in encrypted form) on the server. The effect of this is that deleting and reinstalling a Cola app will cause all of the messages corresponding to that phone number to be reloaded from the server. Messages are cached locally on a phone, but the master copy is on the server. In the future, this architecture will enable transparent use of multiple devices for a given user.

  • An iOS app. This app hosts the primary user experience. Cola Bubbles run inside this app in their native manifestation. In the future, an Android app will serve a parallel purpose for users of that platform, and the same Cola Bubbles will run in that environment.

  • An SMS/Web gateway. Cola currently enables communication with a subset of users who do not have the Cola app installed on their phone. In today’s Cola, this usage mode is enabled for recipients who have US phone numbers — i.e., users who have the Cola app installed can communicate with US users who have not installed the app, as long as the recipient has a phone capable of SMS and has a recent web browser. Certain Cola bubbles have been enabled to work on the web for this purpose; in the future, this capability will be opened to third-party bubble developers.

  • Separate, external services that offer bubble-specific services. Cola bubbles use external services such as Firebase to maintain consistency between users and to maintain global bubble state (see our example code for how to use Firebase to this effect). Bubbles also can call external APIs for bubble-specific data, functions, and authentication.

That’s the overall system; now let’s take a closer look at Cola Bubbles specifically. Cola Bubbles are written in JavaScript, and run in a Cola-specific version of Facebook’s React Native. React Native is an execution environment that in some ways is analogous to a browser (or more specifically, a webview) — it runs developer-written JavaScript; it supports user interaction, layout and display, but unlike a browser, it’s not based on the DOM; and its design center isn’t desktop documents, but mobile touch applications.

Cola uses React Native in a novel way. React Native is designed as a rapid way to build a “native” mobile app in JavaScript. Cola uses React Native differently — each Cola Bubble runs in its own separate, sandboxed React Native instance. The Cola app which embeds the bubbles creates React Native instances on-demand for each bubble as it comes into view, and may destroy these instances as they go out of view.

While running, a Cola bubble can call external services, as well as certain on-device services (e.g., location) to provide the requisite user experience. They can also send notifications to the conversation. Note: currently, notifications can only be sent by a running bubble. In the future, it will be possible for developers to send bubble-specific notifications without the bubble running.

Cola bubbles can make their way into the Cola app in one of several ways:

  • As a bundled part of the Cola app. When a user downloads Cola iPhone app from the App Store, several bubbles are included in the app. These bubbles appear on the bubble menu.

  • During the development process. In this mode, the Cola app acts as a WebDAV server that can be mounted on the developer’s desktop. Bubbles are copied to the Cola app on the iPhone from the desktop, and recopied as developers iterate on the bubble.

  • During the testing phase. At this point, a bubble developer is testing a newly-built bubble with a team or group. A developer can distribute test bubbles via email, alongside a testing configuration profile supplied by Cola. The recipient of the email needs to open the email on their phone and use Apple’s Mail app on the iPhone to copy the configuration profile and the bubble to the device.

  • In production. When a bubble is completed and ready to be published, a developer submits the bubble to Cola for approval and distribution. It is distributed to users either by bundling the bubble inside the iOS app (which in turn is downloaded by users from the App Store), or by storing the bubble package on Cola servers, where the Cola app will see the package and download it when a user selects (or receives) that bubble. The download process is automatic and does not require an explicit download or installation step on the part of a user. All it requires is that a user select a bubble (sender side) or receive a bubble.

Over the course of the next few months, Cola will ship an Android app that can run Cola Bubbles, and will also make it possible for developers to create web bubbles. In both cases, a developer will start with the same JavaScript source code, and Cola’s “bubbler” packaging tool will output not only a bubble package that runs in the Cola iOS app (as it does today), but also a package for the forthcoming Cola Android app, as well as a package for web bubbles, which runs using a framework called React Native Web.