How Buddycloud Works

Three components that work together: Open SDK, open protocol and open-source server.

You add a small SDK to your mobile or web app; your users communicate.

Web applications then communicate via a websocket with the Buddycloud Server. Mobile applications use the REST API (or XMPP).

Channel.

Each Buddycloud server will find, connect and share the data you choose with users on other Buddycloud servers.

This approach has huge benefits, especially for industries that care about data privacy.

	Old Design (Twitter, Facebook, G+, App.net)	Buddycloud
Trust Model	Trust them	You control and choose
Data location	USA	You choose
Intranet only/behind the firewall (runs in-house)	Not possible	Hosted or behind your firewall
Add new features	One-size-fits-all	Fully extensible

A channel is a collection of activity feeds and value-stores that can have publishers, and subscribers. Buddycloud channels can scale up to millions of followers or scale down to be used as an individual data-store.

Channels look like:

Channel Address	Description
user@example.com	A user's channel
user@other-domain.com	A buddycloud channel on a remote site
customer-support@company.com	A channel that anyone can post into and get support

Channels are a bundle of nodes.

Each channel is made up of application nodes. When you follow a channel, for example, user@example.com you are really following a collection of application nodes. (user@example.com/posts, user@example.com/public-key, user@example.com/geolocation, etc). Any updates to a node are pushed out to all followers of the channel. So when you want to build your application on Buddycloud you simply use an existing application node or create a new one for your projects specific needs.

Each Application node can have different stream formats, different metadata fields and different stream lengths (single item vs infinite items).

Channel and Application node name	Example
user@example.com/posts	One or more, activitystream of public posts
user@example.com/selfies-application	One or more, activitystream for a selfies application
user@example.com/public-key	A single public key that can be used to encrypt messages to user@example.com
user@example.com/geolocation	An application updates the users location and all followers receive the update
user@example.com/webrtc	An application node used for webRTC call negotiation and setup

Personal and topic channels.

There are two different types of channels. Personal channels and Topic/Group/Application channels.

	Personal channels	Topic/group/application channels
Creation time	Automatically created for new users	Created by users or applications
Example	user@example.com	football@example.com cat-pictures@example.com {uuid}@example.com
Channels per user	Always one	Infinite

Channel privacy.

Each channel can have different privacy models

Privacy model	Typical use	Example
Whitelist	New followers to a channel need to be approved	user@example.com
Open	A popular channel that serves public information	news-updates@bbc.co.uk
Site-wide	A company channel where you want to automatically approve anyone on a domain	team@example.com

Channel roles.

Channel followers have have different roles. Most of the time you will not need them but roles can help keep the social aspect flowing.

Role	What can they do?
Owner	A single user who can make other users moderators
Moderator	A list of users who can approve new followers to the channel. Curate posts.
Follower+post	A list of users who can post to the channel
Follower	A list of users who have read-only access to the channel
Banned	A list of users that cannot access the channel

Channel owners can set the default role for new followers. For example: new followers will inherit the follower+post role.

Federation.

Like Facebook has a wall, Twitter has a Feed, Buddycloud has channels. User's follow channels that can be another user (for example: juliet@capulet.lit follows romeo@montague.lit) or topics (juliet@caputlet.lit follows fan-club@verona-fc.lit).

Your users can follow channels and chat with users on local and remote Buddycloud sites.

Authenticate against your existing database of users.

Buddycloud has a number of ways to authenticate against your existing database of users.

	How it works	Use case
Buddycloud user database	Use Buddycloud API for user authentication	Starting fresh with a new set of users
Parallel secret	Your application generates a secret to be used with the buddycloud service	New user base or existing user database
Remote application call	Authenticate users according to a pre-existing application API (for example https://your-app.com/auth)	New user base or existing user database