The Concepts

Streams are units of data published by users, whether individuals or communities. Every stream has a type, and is identified by its publisherId and name. Streams published by different users may be hosted on entirely different domains and servers around the world.

It turns out that social apps often require powerful features from their data model, and the Streams plugin provides all those features out of the box. The architecture is built around a unified, standard paradigm that turns every piece of data into something that can become much more powerful.

Example: Personal Data

Suppose you start with a simple piece of data published by a user, such as their location. Now, the client app(s) they use should be able to update their location. This is accomplished by posting messages to the location stream, which are then broadcast to others in real time.

People currently viewing the location online may receive real-time push via sockets, which the Streams JS API handles for you and updates all the tools rendering this stream, such as a map.

Other people might be away, perhaps offline, but still interested in being notified when something happens to your location. They can subscribe to receive offline notifications when something interesting happens, and set up filters to specify what's interesting to them (e.g. when a friend is in their area).

All the messages to update the location stream would be saved in the stream's message history, which might be displayed by a tool that shows the person's movement around the country.

Of course, the publisher needs to be able to control who can see their location and who can't. Streams allows them to manage access for others, the extent to which they can read and write to the stream. It implements one of the most expressive role-based access control systems in the world, with the roles actually corresponding to the user's contact labels, such as "friends" and "family" for individuals, or "admins" and "clients" for communities.

Example: Collaborative Data

Now let's take some other type of stream, such as a chess game. The above all still applies. Some user has to publish the chess game, perhaps a third party Chess app. People might want to join and see the moves being played in real time. They might want to subscribe and get an offline notification when something interesting happens.

Here, more than one user can post messages to the stream, and neither one might be the publisher (which, in this case, is the third party Chess app). In this case, a chess game has two players, and the rest can be spectators. The two players have a high enough write level to make moves in the game, and the spectators have a high enough read level to see the moves (either in real time or to subscribe to offline notifications). If they are online and the moves are pushed in real time to their clients, their tools rendering a chess board will be updated when the moves are made in the corresponding "Chess/game" stream.

In addition, perhaps all the participants in the chess game would be able to participate in a chat as the game continues. All the messages are once again saved in a history which shows all the moves and chat messages in the order they were posted to the stream. The Qbix server of the stream's publisher keeps track of the messages in chronological order even as it sends them out to stream participants and subscribers.

The owner of the stream may appoint managers, and the managers in turn might invite other people to the stream, giving them various admin rights. The invites are all handled seamlessly, and can arrive by email, sms, facebook or other means. Those invited who are not yet in the system are represented by future user accounts and upon accepting the invitation get to adopt those accounts in one step. Everything is already streamlined and designed to reduce friction and increase your app's viral popularity.