XEP-xxxx: Buddycloud Channels

Abstract:This document describes a profile and conventions for usage of the PubSub protocol in the context of a new type of communication.
Authors:Simon Tennant, Lloyd Watkin, Ashley Ward
Copyright:© 1999 - 2014 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:ProtoXEP
Type:Standards Track
Version:0.0.2
Last Updated:2014-12-12

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.

Table of Contents


1. Buddycloud Introduction
    1.1. About Buddycloud
    1.2. Buddycloud Channels
    1.3. Glossary
2. Service Discovery
    2.1. Discovery order
    2.2. Discovery using Disco
    2.3. Discovery using DNS
3. Register
4. Channel and Node Configuration
    4.1. Get Node Configuration
    4.2. Set Node Configuration
    4.3. Default roles
    4.4. Well known nodes
5. Business Logic
    5.1. PubSub for Humans
    5.2. Channel Read Permissions
    5.3. Channel Write Permissions
    5.4. Maintain Similar Affiliations across Channel Nodes
6. Pubsub Items
    6.1. Retrieving items
       6.1.1. Recent Items
         6.1.1.1. Error Cases
    6.2. Deleting items
    6.3. Item Payload
       6.3.1. Publishing
       6.3.2. Threading
       6.3.3. Referencing
       6.3.4. Rating
         6.3.4.1. Error cases
7. Channel subscriptions
    7.1. Retrieving subscriptions with configuration
8. Channel affiliations
    8.1. Buddycloud to XEP-0060 mappings
9. Federation
    9.1. Inbox
    9.2. Interaction With Other Services
10. Security Considerations
    10.1. Server Trust
    10.2. Default Role

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

1. Buddycloud Introduction

1.1 About Buddycloud

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.

1.2 Buddycloud Channels

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.

1.3 Glossary

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.

2. Service Discovery

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

2.1 Discovery order

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.

2.2 Discovery using Disco

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

Example 1. The Entity sends a disco#items request to the domain


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

Example 2. The server replies with a list of available components.

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

Example 3. The Entity sends a disco#info request to each component


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

Example 4. The Buddycloud server replies with its identity

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

2.3 Discovery using DNS

In the case that no server is found via disco, DNS should be used to discover the Buddycloud server. An IANA service-discovery record (DNS-SD) record can be used to delegate services to a remote Buddycloud server.

Example 5. TXT record for Buddycloud server discovery

    
    _bcloud-server._tcp.montague.lit. TXT  "v=1.0 server=server01.verona.lit."

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

3. Register

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

Example 6. The Entity sends a register request to the domain

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

4. Channel and Node Configuration

Node metadata is used to describe the channel to users. All nodes in a channel have the same metadata and permission.

4.1 Get Node Configuration

- using disco-info with the node specified - using XEP-0060 5.4 Discover Node Metadata

4.2 Set Node Configuration

set Not sure what goes here?

4.3 Default roles

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.

Table 1: Channel Metadata Fields

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

Table 2: Channel Types

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

Table 3: Channel Access Models

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.

4.4 Well known nodes

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.

Table 4: Well known Buddycloud nodes.

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"

5. Business Logic

5.1 PubSub for Humans

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.

5.2 Channel Read Permissions

Table 5: channel read permissions

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

5.3 Channel Write Permissions

Table 6: channel write permissions

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

5.4 Maintain Similar Affiliations across Channel Nodes

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.

6. Pubsub Items

Many of the item use cases follow those from XEP-0060. This section notes the departures from the parent XEP and specific requirements.

6.1 Retrieving items

6.1.1 Recent Items

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.

Example 7. Recent items query

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

Example 8. Recent items reply

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

6.1.1.1 Error Cases

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)

6.2 Deleting items

Example 9. The client sends

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

Example 10. Server replies

  
<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

Example 11. The Buddycloud server sends retractions out to online clients

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

6.3 Item Payload

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

6.3.1 Publishing

The minimal payload for a publish request must be formatted as follows:

Example 12. The Entity publishes to a node

  
<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:

Example 13. Payload with server-added elements

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

6.3..1 Error Cases

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

6.3.2 Threading

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.

Example 14. A valid payload for replying in a 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" />
            </entry>

6.3..2 Error Cases

6.3.3 Referencing

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.

Example 15. A valid payload for referencing another post within a 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>

6.3..3 Error Cases

6.3.4 Rating

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

Example 16. A valid payload for rating another 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">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>

6.3.4.1 Error cases

  • 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

7. Channel subscriptions

Buddycloud clients follow XEP-0060 subscription mechanisms for following and unfollowing a channel.

7.1 Retrieving subscriptions with configuration

It is also possible to retrieve the list of all subscribed nodes with their respective configuration embedded in a single response IQ using the subscription with configuration functionality.

When using this feature, one is able to filter out subscriptions that don't match a given criteria, and/or filter out unwanted configuration fields. That makes it easier to control the size of the payload.

Example 17. Subscriptions with configuration query

  
<iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="get" id="subscriptions-conf:1"> 
  <pubsub xmlns="http://jabber.org/protocol/pubsub"> 
    <subscriptions-with-configuration xmlns="http://buddycloud.org/v1"/>
  </pubsub> 
</iq>

Example 18. Subscriptions with configuration reply

  
<iq to="juliet@capulet.lit/bc-app" from="buddycloud.capulet.lit" type="result" id="subscriptions-conf:1"> 
  <pubsub xmlns="http://jabber.org/protocol/pubsub"> 
    <subscriptions-with-configuration xmlns="http://buddycloud.org/v1">
      <subscription-with-configuration node="/user/romeo@montague.lit/posts" subscription="subscribed" jid="juliet@capulet.lit">
        <configure node="/user/romeo@montague.lit/posts">
          <x xmlns="jabber:x:data" type="result">
            <field type="hidden" var="FORM_TYPE">
              <value>http://jabber.org/protocol/pubsub#node_config</value>
            </field>
            <field var="title">
              <value>Romeo</value>
            </field>
            <field var="description">
              <value>Romeo's node description</value>
            </field>
          </x>
        </configure>
      </subscription-with-configuration>
      <subscription-with-configuration node="/user/juliet@capulet.lit/posts" subscription="subscribed" jid="juliet@capulet.lit">
        <configure node="/user/juliet@capulet.lit/posts">
          <x xmlns="jabber:x:data" type="result">
            <field type="hidden" var="FORM_TYPE">
              <value>http://jabber.org/protocol/pubsub#node_config</value>
            </field>
            <field var="title">
              <value>Juliet</value>
            </field>
            <field var="description">
              <value>Juliet's node description</value>
            </field>
          </x>
        </configure>
      </subscription-with-configuration>
    </subscriptions-with-configuration>
  </pubsub> 
</iq>

In the previous example, the requesting entity didn't specify any filters, thus the response contained all subscriptions plus all configuration fields.

The requesting entity can also filter the returned subscriptions by configuration fields and/or filter specific configuration fields out. The subscription filter is useful when the client is only interested in nodes of a given type, e.g. topic or private; while the configuration filter is useful for bandwith-constrained clients that only require certain configuration fields.

Example 19. Subscriptions with configuration query (with filters)

  
<iq from="juliet@capulet.lit/bc-app" to="buddycloud.capulet.lit" type="get" id="subscriptions-conf:1"> 
  <pubsub xmlns="http://jabber.org/protocol/pubsub"> 
    <subscriptions-with-configuration xmlns="http://buddycloud.org/v1">
      <subscription-filter>
        <allow field="title" value="Romeo"/>
      </subscription-filter>
      <configuration-filter>
        <allow field="description"/>
      </configuration-filter>
    </subscriptions-with-configuration>
  </pubsub> 
</iq>

Example 20. Subscriptions with configuration reply (with filters)

  
<iq to="juliet@capulet.lit/bc-app" from="buddycloud.capulet.lit" type="result" id="subscriptions-conf:1"> 
  <pubsub xmlns="http://jabber.org/protocol/pubsub"> 
    <subscriptions-with-configuration xmlns="http://buddycloud.org/v1">
      <subscription-with-configuration node="/user/romeo@montague.lit/posts" subscription="subscribed" jid="juliet@capulet.lit">
        <configure node="/user/romeo@montague.lit/posts">
          <x xmlns="jabber:x:data" type="result">
            <field type="hidden" var="FORM_TYPE">
              <value>http://jabber.org/protocol/pubsub#node_config</value>
            </field>
            <field var="description">
              <value>A description of Romeo's channel-node.</value>
            </field>
          </x>
        </configure>
      </subscription-with-configuration>
    </subscriptions-with-configuration>
  </pubsub> 
</iq>

In this example, by using both the subscription-filter and configuration-filter, the requesting entity retrieves the description field of its subcriptions which configuration value for the field title is Romeo.

8. Channel affiliations

8.1 Buddycloud to XEP-0060 mappings

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

Table 7: Channel 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

9. Federation

9.1 Inbox

9.2 Interaction With Other Services

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.

10. Security Considerations

10.1 Server Trust

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.

10.2 Default Role

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.

Appendices

Appendix A: Document Information

Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status: ProtoXEP
Type: Standards Track
Version: 0.0.2
Last Updated: 2014-12-12
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0059, XEP-0060, XEP-0313, XEP-0255, XEP-0107
Supersedes: None
Superseded By: None
Short Name: NOT_YET_ASSIGNED
This document in other formats: XML  PDF

Appendix B: Author Information

Simon Tennant

Email: simon@buddycloud.com
JabberID: simon@buddycloud.com

Lloyd Watkin

Email: lloyd@evilprofessor.co.uk
JabberID: lloyd@evilprofessor.co.uk

Ashley Ward

Email: ashley.ward@surevine.com
JabberID: ashley.ward@surevine.com

Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright (c) 1999 - 2014 by the XMPP Standards Foundation (XSF).

Permissions

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.

Disclaimer of Warranty

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

Limitation of Liability

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.

IPR Conformance

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

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) 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.

Appendix E: Discussion Venue

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 <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

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

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 0.0.2 (2014-12-12)

First draft.

(sdt)

END