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.
125bd2c4-afc2-4d4c-b869-efc0c0dad8c5@montague.lit
Each XMPP domain can have one Buddycloud server that serves user's channels. Buddycloud clients and servers need to be able to discover the authoratative Buddycloud server. find the
To find the correct remote Buddycloud service for a domain, the Buddycloud server should:
The Buddycloud service first sends an items discovery request to the domain to discover all the available components.
<iq type='get' from='juliet@capulet.lit/balcony' to='capulet.lit' id='items1'> <query xmlns='http://jabber.org/protocol/disco#items'/> </iq>
The server replies with the list of available components, along with their associated JIDs.
<iq type='result' from='capulet.lit' to='juliet@capulet.lit/balcony' id='items1'>
<query xmlns='http://jabber.org/protocol/disco#items'>
<item jid='muc.capulet.lit' name='Chatrooms' />
<item jid='buddycloud.capulet.lit' name='Buddycloud Server' />
</query>
</iq>
The entity then iterates through the <item/> elements, sending an info discovery request to each JID.
<iq type='get' from='juliet@capulet.lit/balcony' to='buddycloud.capulet.lit' id='info1'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq>
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'.
<iq type='result' from='buddycloud.capulet.lit' to='juliet@capulet.lit/BuddycloudApp' id='info2'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='pubsub' type='channels' />
<identity category='pubsub' type='inbox' />
<feature var='jabber:iq:register' />
<feature var='http://jabber.org/protocol/disco#info' />
<feature var='jabber:iq:search' />
</query>
</iq>
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.
_buddycloud-server._tcp.montague.lit. PTR buddycloud-component.verona.lit.
This example delegates all the Buddycloud service to an XMPP component running the Buddycloud named buddycloud-component.verona.lit .
Upon connection to the buddycloud server a user should send a register stanza.
<iq type='set' from='juliet@capulet.lit/balcony' to='channels.capulet.lit' id='register1'> <query xmlns='jabber:iq:register'/> </iq>
The register request creates the user's personal channels on first use and has the additional benefit of creating additional new channel nodes as they become available on the server (e.g. 'status' node, 'geoloc' nodes).
Node metadata is used to describe the channel to users. All nodes in a channel have the same metadata and permission.
- using disco-info with the node specified - using Publish-Subscribe (XEP-0060) [1] 5.4 Discover Node Metadata
set Not sure what goes here?
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.
| Metadata | Field | Example | Notes | Defaults |
|---|---|---|---|---|
| Channel Title | pubsub#title | "Juliet's musings" | Should be a brief single sentence | "juliet@capulet.lit's Buddycloud channel" |
| Channel Description | pubsub#description | "This is a channel about the things that I like to do." | A longer description of the channel | <empty> |
| Channel Access Model | pubsub#access_model | open, authorize, local | The channel subscriber model | Dependent on Node |
| Channel Creator | pubsub#creator | mercutio@capulet.lit | The channel creator's JID | Dependent on Node |
| Default Affiliation | buddycloud#default_affiliation | "publisher" | The role given to new channel followers | Dependent on Channel Type |
| Channel Type | buddycloud#channel_type | "personal" | The type of this channel. (see below). Set by the server at creation. Not user changable. | N.A. |
| Channel Creation Date | pubsub#creation_date | "1997-08-29T02:14:42-05:00Z" | When the channel was created in ISO 8601 time format. Set by the server at creation. Not user changeable. | N.A. |
| Channel Updated Date | buddycloud#updated_date | "2011-04-21T20:11:00-05:00Z" | The date the channel configuration was later updated in ISO 8601 time format. Set by the server. Not user changable. | N.A. |
| Node content type | pubsub#type | http://www.w3.org/2005/Atom | The type of content held within this node. | http://www.w3.org/2005/Atom |
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.
| Node Name | Use | Format | Notes |
|---|---|---|---|
| /user/<jid>>/posts | Activity stream | Atom 1.0 | Activty stream formatted posts |
| /user/<jid>>/public-key | RFC 4880 OpenPGP public key | Key is published using ASCII Armour encoding scheme as detailed in RFC-2440, Section 6 and is encoded using the http://xmpp.org/extensions/xep-0189.xml#schema-pubkey syntax. | Applications use the Public Key to encode messages and posts to the node owner. |
| /user/<jid>>/geoloc-past | Describes where the channel owner was previously. | XEP-0080 | Show's key location or place "checkins". |
| /user/<jid>>/geoloc | Describes where the channel owner is now. | XEP-0080 | A single item. |
| /user/<jid>>/geoloc-future | Describe where the channel owner plans to go. | XEP-0080 | Show's an intended location or description (for example "Juliet's Balcony" or "Going out this evening to read love poetry"). A good application will clear the geoloc-future location when it matches the current location. |
| /user/<jid>>/status | A one line descrition of the channels status. | Atom 1.0 | For example a user might enter "Is happy" and a topic channel for a development team might have a status line of "Code is building correctly" |
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.
Many of the item use cases follow those from XEP-0060. This section notes the departures from the parent XEP and specific requirements.
It is possible to retrieve any new items since last retrieval from all subscribed channels ('/posts' nodes specifically) since last retrieval using the recent items functionality.
<iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="get" id="recent-items:1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<recent-items xmlns="http://buddycloud.org/v1"
since="2014-04-18T10:46.100Z"
max="50"
parent-only="true" />
</pubsub>
</iq>
<iq to="juliet@capulet.lit/bc-app" from="buddycloud.capulet.lit" type="result" id="recent-items:1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<items node="/user/romeo@montague.lit/posts">
<item id="tag:channels.capulet.lit,/users/juliet@montague.lit/posts,16584564008760001">
...atom payload...
</item>
<item id="tag:channels.capulet.lit,/users/juliet@montague.lit/posts,10070506450002">
...atom payload...
</item>
</items>
<items node="/user/juliet@capulet.lit/posts">
<item id="tag:channels.capulet.lit,/users/juliet@capulet.lit/posts,3252545492409">
...atom payload...
</item>
</items>
<items node="/user/romeo@montague.lit/posts">
<item id="tag:channels.capulet.lit,/users/juliet@montague.lit/posts,106876700003">
...atom payload...
</item>
</items>
</pubsub>
</iq>
In this example max represents the maximum number of items the user wishes to retrieve from any one channel, since is the datetime from which posts should start, and parent-only allows users to requests posts which only start a discussion (i.e. no reply posts).
The following extended error cases are used:
<iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="set" id="retractitem:32">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<retract node="/user/juliet@capulet.lit/posts" notify="1">
<item id="1291048772456"/>
</retract>
</pubsub>
</iq>
<iq from="buddycloud.capulet.lit" to="juliet@capulet.lit/bc-app" type="result" id="retractitem:32"/>
A retraction message is sent to all online clients, with an Atom tombstone to replace the deleted post
<message from="buddycloud.capulet.lit" id="bc:MGV3B" to="benvolio@montague.lit">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="/user/channeluser@example.com/posts">
<retract id="1291048772456"/>
<item id="1291048772456">
<deleted-entry xmlns="http://purl.org/atompub/tombstones/1.0" ref="xmpp:buddycloud.capulet.lit?pubsub;action=retrieve;node=/user/juliet@capulet.lit/posts;item=1291048772456" when="2012-07-01T15:08:32.950Z">
<updated>2012-07-01T15:08:32.950Z</updated>
<id xmlns="http://www.w3.org/2005/Atom">1291048772456</id>
<link xmlns="http://www.w3.org/2005/Atom" href="xmpp:buddycloud.capulet.lit?pubsub;action=retrieve;node=/user/juliet@capulet.lit/posts;item=1291048772456" rel="self"/>
<published xmlns="http://www.w3.org/2005/Atom">2012-07-01T15:08:30.922Z</published>
<object xmlns="http://activitystrea.ms/spec/1.0/">
<object-type>comment</object-type>
</object>
<verb xmlns="http://activitystrea.ms/spec/1.0/">post</verb>
</deleted-entry>
</item>
</items>
</event>
</message>
Buddycloud item data are formatted according to & atom; standards and optionally making use of & thread; and & review ; extensions.
The minimal payload for a publish request must be formatted as follows:
<iq from="juliet@montague.lit/balcony" to="channels.montague.lit" type="set" id="publish:20">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<publish node="/user/romeo@capulet.lit/posts">
<item>
<entry xmlns="http://www.w3.org/2005/Atom">
<content type="text">O Romeo, Romeo! wherefore art thou Romeo?</content>
</entry>
</item>
</publish>
</pubsub>
</iq>
This payload will be extended with default data by the server if not provided. The final payload looking as follows:
<entry xmlns="http://www.w3.org/2005/Atom">
<id>fc362eb42085f017ed9ccd9c4004b095</id>
<title>Post title</title>
<published>2014-01-01T00:00:00.000Z</published>
<updated>2014-01-01T00:00:00.000Z</updated>
<author>
<name>juliet@montague.lit</name>
<jid xmlns="http://buddycloud.com/atom-elements-0">juliet@montague.lit</jid>
</author>
<content type="text">O Romeo, Romeo! wherefore art thou Romeo?</content>
<activity:verb>post</activity:verb>
<activity:object>
<activity:object-type>post</activity:object-type>
</activity:object>
</entry>
Beyond standard & xep0060 ; error cases additional errors are used:
Posts in Buddycloud can be formed into threads consisting of a parent post and comments to a maximum thread depth of 1. Posts follow the RFC 4685 [2] and utilise the & thread ; namespace with the 'ref' attribute referring to the full global ID of the parent post.
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:thr="http://purl.org/syndication/thread/1.0" xmlns:activity="http://activitystrea.ms/spec/1.0/">
<id>96da02ee1baef61e767742844207bec4</id>
<title>Post title</title>
<published>2014-01-01T00:00:00.000Z</published>
<updated>2014-01-01T00:00:00.000Z</updated>
<author>
<name>romeo@capulet.lit</name>
<jid xmlns="http://buddycloud.com/atom-elements-0">romeo@capulet.lit</jid>
</author>
<content type="text">Shall I hear more, or shall I speak at this?</content>
<activity:verb>post</activity:verb>
<activity:object>
<activity:object-type>comment</activity:object-type>
</activity:object>
<thr:in-reply-to ref="tag:channels.capulet.lit,/users/romeo@capulet.lit/posts,fc362eb42085f017ed9ccd9c4004b095" />
</entry>
Within a single thread comments can reference other comments or the parent item. This is for the purpose of making a comment to a post further back in the thread.
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:thr="http://purl.org/syndication/thread/1.0" xmlns:activity="http://activitystrea.ms/spec/1.0/">
<id>96da02ee1baef61e767742844207bec4</id>
<title>Post title</title>
<published>2014-01-01T00:00:00.000Z</published>
<updated>2014-01-01T00:00:00.000Z</updated>
<author>
<name>romeo@capulet.lit</name>
<jid xmlns="http://buddycloud.com/atom-elements-0">romeo@capulet.lit</jid>
</author>
<content type="text">Shall I hear more, or shall I speak at this?</content>
<activity:verb>post</activity:verb>
<activity:object>
<activity:object-type>comment</activity:object-type>
</activity:object>
<thr:in-reply-to ref="tag:channels.capulet.lit,/users/romeo@capulet.lit/posts,fc362eb42085f017ed9ccd9c4004b095" />
<activity:target> <id>tag:channels.capuet.lit,/users/romeo@capulet.lit/posts,fc362eb42085f017ed9ccd9c4004b095</id>
</activity:target>
</entry>
By making use of the & review; extension of activity streams and the & target ; element outline above Buddycloud is able to support 'rating' a post.
Posts can be rated an integer value between 1 and 5, although may only wish to provide a binary setting to match popular services which provide 'likes', '+1', etc.
Any post content is discarded and replaced with rating:X.0 (where X is the rating value). The activity verb is also overwritten with 'rated'.
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:thr="http://purl.org/syndication/thread/1.0" xmlns:activity="http://activitystrea.ms/spec/1.0/">
<id>96da02ee1baef61e767742844207bec4</id>
<title>Post title</title>
<published>2014-01-01T00:00:00.000Z</published>
<updated>2014-01-01T00:00:00.000Z</updated>
<author>
<name>romeo@capulet.lit</name>
<jid xmlns="http://buddycloud.com/atom-elements-0">romeo@capulet.lit</jid>
</author>
<content type="text">rating:5.0</content>
<activity:verb>rated</activity:verb>
<activity:object>
<activity:object-type>comment</activity:object-type>
</activity:object>
<thr:in-reply-to ref="tag:channels.capulet.lit,/users/romeo@capulet.lit/posts,fc362eb42085f017ed9ccd9c4004b095" />
<activity:target> <id>tag:channels.capuet.lit,/users/romeo@capulet.lit/posts,fc362eb42085f017ed9ccd9c4004b095</id>
</activity:target>
<review:rating>5.0</review:rating>
</entry>
Buddycloud clients follow XEP-0060 subscription mechanisms for following and unfollowing a channel.
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.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
1. XEP-0060: Publish-Subscribe <https://xmpp.org/extensions/xep-0060.html>.
2. RFC 4685: Atom Threading Extensions <http://tools.ietf.org/html/rfc4685>.
Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/
First draft.
@report{tennant2014xepxxxx,
title = {Buddycloud Channels},
author = {Tennant, Simon and Watkin, Lloyd and Ward, Ashley},
type = {XEP},
number = {xxxx},
version = {0.0.2},
institution = {XMPP Standards Foundation},
url = {https://xmpp.org/extensions/xep-xxxx.html},
date = {2014-04-29/2014-04-29},
}END