The Buddycloud project is a set of independently deployable services, that inter-operate to create a rich collaboration service.

Buddycloud Channels build on XMPP's native federation and publish-subscribe principles to connect to, and synchronise content with users on local and remote domains. Services are designed to interoperate. For example, the Media Server, Friend Finder, and content recommendation engine work together to help developers build a unified collaboration services for individual and groups of users.

This XEP seeks to define how the Buddycloud Channel service currently functions. It also seeks stay extensible for accommodate future, undefined use cases.

Buddycloud channels are a bundle of XEP-0060 publish-subscribe nodes with identical subscribers and permissions presented as a JID-like name (example: juliet@capulet.lit . Content posted into channels is automatically synchronised to the correct followers on other Buddycloud domains.

Personal Channel

Personal channels are a group of pub-sub nodes that have the same owner, followers and access permissions.

Topic Channel

Topic channels are for group discussions and decoupled from the owners jid. For example balcony-speeches@topics.montague.lit could be owned by speechwriter@montague.lit.

Ephemeral Channel

Ephemeral channels, are generated for one-off use and automatically removed by the Buddycloud service after the last participant unfollows them (similar to the Google Hangout service) An example ephemeral channel would be 125bd2c4-afc2-4d4c-b869-efc0c0dad8c5@montague.lit .

Buddycloud Service

An XMPP component which hosts channel nodes and provides an interface conforming to this document to allow access to them via XMPP.

Home server

The Buddycloud service responsible for a JID's channels and Inbox.

Remote Server

Buddycloud service that run on other XMPP domains.

Buddycloud Inbox

Service on the entity's home Buddycloud service which subscribes to nodes on the Entity's behalf, and may cache node data and provide an ability to replay recent messages.

To find the correct remote Buddycloud service for a domain, the Buddycloud server should:

1. Use a disco#items query against the XMPP service for the remote Buddycloud domain.
2. If no answer is returned (perhaps the remote site doesn't run a full XMPP service) the Buddycloud service should proceed to use the DNS discovery method.

The Buddycloud service first sends an items discovery request to the domain to discover all the available components.

The server replies with the list of available components, along with their associated JIDs.

The entity then iterates through the <item/> elements, sending an info discovery request to each JID.

Each component replies with its identity. The Buddycloud server has an identity of category 'pubsub' and type 'channels'.

A domain MUST only host one component with an identity of category 'pubsub' and type 'channels'.

In the case that no server is found via disco, DNS should be used to discover the Buddycloud server. A PTR record can be used to delegate Buddycloud services to a remote Buddycloud server.

This example delegates all the Buddycloud service to an XMPP component running the Buddycloud named buddycloud-component.verona.lit .

minimum setting/optional recommended fallbacks

Channel metadata is stored as node metadata against the /posts node of the channel. It is recommended that all channel nodes have the same permissions and an update to one updates the others.

Most metadata fields used for Channels are already defined in XEP-0060. The relevant ones are listed below.

Channel owners and moderators can also set the default affiliation for the channel

Channel Type	Description	Example
personal channel	Channel named after and owned by the user's JID.	romeo@montague.lit
Topic channel	A channel features around a common topic.	cauldron-recipees@coven.shakespeare.lit
local	Appears as an open channel to local users on that domain. Appears as a closed channel to users on remote Buddycloud domains.	montague-family-channel@montague.lit

Access Model	Description
authorize	The channel is only viewable by it's producer, followers, followers+post and moderators.
open	Anyone can view the channel.
local	Appears as an open channel to local users on that domain. Appears as a closed channel to users on remote Buddycloud domains.

Buddycloud is designed to be extended with new node and content types. To kickstart Buddycloud starts with some well known and used nodes. It is recommended that new nodes are announced publicly on the XSF standards mailing list and an informal registry will be kept.

Buddycloud adapts XEP-0060's machine-to-machine design goals with logic and presets that work better in a social person-to-person and person-to-group environment. For example, to discourage "glorifying the wicked", the list of banned users is only presented to the channel's moderators.

Property	Access model	Example	Channel Producer	Channel Moderator	Follower+post	Follower	Anonymous (e.g. web)	Banned users
channel name	all	juliet@capulet.lit	yes	yes	yes	yes	yes	yes
channel title	all	Posts about Romeo	yes	yes	yes	yes	yes	yes
channel description	all	Posts and photos of my darling Romeo. This is not a place for Verona gossip.	yes	yes	yes	yes	yes	yes
banned user list	all	father@montague.lit	yes	yes	no	no	no	no
pending subscription list	all	nurse@capulet.lit	yes	yes	no	no	no	no
channel posts	open	O Romeo, Romeo! Wherefore art thou Romeo? Deny thy father and refuse thy name. Or, if thou wilt not, be but sworn my love, And I’ll no longer be a Capulet.	yes	yes	yes	yes	yes	yes
	authorize		yes	yes	yes	yes	no	no
	local		yes	yes	yes	yes	no	no
followers, moderators and owner	open	tybalt@capulet.lit, servant@capulet.lit, peter@capulet.lit	yes	yes	yes	yes	yes	yes
	authorize		yes	yes	yes	yes	no	no
	local		yes	yes	yes	yes	no	no

Property	Producer	Moderator	Follower+post	Follower	Anonymous (e.g. web)	Banned users
change channel name	only at creation time	no	no	no	no	no
channel channel title	yes	yes	no	no	no	no
change channel description	yes	yes	no	no	no	no
change banned user list	yes	yes	no	no	no	no
approve pending subscriptions	yes	yes	no	no	no	no
create posts	yes	yes	yes	no	no	no
delete posts	yes	yes	own posts	no	no	no

A Buddycloud server MUST maintain similar affiliations and permissions for a subscribed entity across all nodes that comprise a channel. For example, following the "posts" node would also follow the status node.

The server should automatically ensure that all nodes belonging to that channel are updated with the same permissions. This helps address a common criticism of the "privacy confusion" of other social products where users need to search settings on different clients to ensure that their profile really is private.

Buddycloud item data are formatted according to & atom; standards and optionally making use of & thread; and & review ; extensions.

Buddycloud channels build on XEP-0060's node affiliations.

XEP-0060 Affiliation	Buddycloud Affiliation	Description	Required?
Owner	owner	The channel owner. Full access rights. Can add and delete moderators.	REQUIRED
-	moderator	A follower who has follower+post rights, rights to manage the affiliation of entites with the node (except changing ownership), and rights to manage the subscriptions of entities with the node.	REQUIRED
Publisher	follower+post	Entity can view posts and replies, publish new posts, and publish replies to posts.	REQUIRED
Member	follower	Entity can view posts and replies for whitelist and open channels, but cannot publish new posts or replies.	REQUIRED
None	none	Entity can view posts and replies for open channels, but cannot publish new posts or replies.	REQUIRED
Outcast	outcast	Entity cannot view any posts or replies, and cannot publish new posts or replies.	RECOMMENDED

The Buddycloud service is designed to work with interchangeable components that offer discrete services and together form a complete communication service.

While the Buddycloud Server is designed to work independently of other services but can be enhanced with helper services. Each helper communicates with the Buddycloud server and other components using XEP-0114 connections. Examples of helper services include: push notifications, media hosting, contact matching, content search and channel recommendations.

Helper services' specifications are covered in separate XEPs.

The Buddycloud server should make sure that the remote server component is the authoritative Buddycloud server for the domain it claims to represent. This is done by running the server discovery process and confirming the same XMPP component name.

Open channel where members join with a follow+post role present an attractive target for spamming and malicious behaviour. This default role should be use with caution especially when the Buddycloud server federates with remote Buddycloud-enabled domains.