%ents; ]>
Buddycloud Channels This document describes a profile and conventions for usage of the PubSub protocol in the context of a new type of communication. xxxx ProtoXEP Standards Track Standards Council 0.0.2 2014-04-29 sdt

First draft.

NOT_YET_ASSIGNED This XMPP Extension Protocol is copyright (c) 1999 - 2014 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 shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ## 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 out of the use or inability to use 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 may be found at < http://xmpp.org/extensions/ipr-policy.shtml > or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). XMPP Core XEP-0059 XEP-0060 XEP-0313 XEP-0255 XEP-0107 Simon Tennant simon@buddycloud.com simon@buddycloud.com Lloyd Watkin lloyd@evilprofessor.co.uk lloyd@evilprofessor.co.uk Ashley Ward ashley.ward@surevine.com ashley.ward@surevine.com

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.

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:

  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 .

Upon connection to the buddycloud server a user should send a register stanza.

]]>

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 XEP-0060 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.

]]> ...atom payload... ...atom payload... ...atom payload... ...atom payload... ]]>

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:

  • max-required : A maximum number of items per node is required
  • invalid-max-value-provided : The value of max must be a positive integer
  • since-required : A valid value for since must be provided
  • invalid-since-value-provided : since must be a parsable date string (ISO-8601 format)
]]> ]]> A retraction message is sent to all online clients, with an Atom tombstone to replace the deleted post 2012-07-01T15:08:32.950Z 1291048772456 2012-07-01T15:08:30.922Z comment post ]]>

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:

O Romeo, Romeo! wherefore art thou Romeo? ]]>

This payload will be extended with default data by the server if not provided. The final payload looking as follows:

fc362eb42085f017ed9ccd9c4004b095 Post title 2014-01-01T00:00:00.000Z 2014-01-01T00:00:00.000Z juliet@montague.lit juliet@montague.lit O Romeo, Romeo! wherefore art thou Romeo? post post ]]>

Beyond standard & xep0060 ; error cases additional errors are used:

  • entry-element-required : Where no entry element has been provided in the payload
  • content-element-required : Where no content element or an empty content element is provided
  • unsupported-content-type : If provided the 'type' attribute of the content element must be either 'text' or 'xhtml'. If not provided value will default to 'text'

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 ATOM threading specification and utilise the & thread ; namespace with the 'ref' attribute referring to the full global ID of the parent post.

96da02ee1baef61e767742844207bec4 Post title 2014-01-01T00:00:00.000Z 2014-01-01T00:00:00.000Z romeo@capulet.lit romeo@capulet.lit Shall I hear more, or shall I speak at this? post comment ]]>
  • parent-item-not-found : A reply must be made to an existing post within the same node
  • max-thread-depth-exceeded : An attempt to comment on a comment will result in this error response

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.

96da02ee1baef61e767742844207bec4 Post title 2014-01-01T00:00:00.000Z 2014-01-01T00:00:00.000Z romeo@capulet.lit romeo@capulet.lit Shall I hear more, or shall I speak at this? post comment tag:channels.capuet.lit,/users/romeo@capulet.lit/posts,fc362eb42085f017ed9ccd9c4004b095 ]]>
  • missing-in-reply-to : As posts referencing other posts can only be comments then attempting to do so results in this error
  • missing-target-id : A target ID must be specificed as text to the target element
  • targeted-item-not-found : If the targetted item can not be found in the current thread this error response will be returned
  • target-outside-thread : The targetted item must be within the same thread as the new post

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'.

96da02ee1baef61e767742844207bec4 Post title 2014-01-01T00:00:00.000Z 2014-01-01T00:00:00.000Z romeo@capulet.lit romeo@capulet.lit rating:5.0 rated comment tag:channels.capuet.lit,/users/romeo@capulet.lit/posts,fc362eb42085f017ed9ccd9c4004b095 5.0 ]]>
  • invalid-rating : A non-numerically parsable rating value will result in this error message
  • rating-out-of-range : A rating can only have an integer value between 1 and 5 (inclusive)
  • invalid-rating-request : Ratings can only be made against post types 'post' and 'comment' i.e. it is not possible to rate a rating
  • item-already-rated : A user can only rate a single post once

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.