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.

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

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.

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

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"

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.

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.

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

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.

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.

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.

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.

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.

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.

Ashley Ward

Appendix C: Legal Notices

Copyright

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.

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