moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

ProtoXEP: Buddycloud Channels

This commit is contained in:
Matthew A. Miller 2014-04-28 10:07:19 -06:00
parent f4af46eb9a
commit ede3a1111d
1 changed files with 232 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

232
inbox/buddycloud-channels.xml Normal file
View File

@ -0,0 +1,232 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
<!ENTITY actor "&lt;actor/&gt;">
<!ENTITY invalidactor "&lt;invalid-actor/&gt;">
<!ENTITY invalidnode "&lt;invalid-node/&gt;">
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Buddycloud Channels</title>
<abstract>This document describes a profile and conventions for usage
of the PubSub protocol in the context of a new type of communication.</abstract>
<legal>
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2014
by the XMPP Standards Foundation (XSF).
</copyright>
<permissions> Permission is hereby granted, free of charge, to any
person obtaining a copy of this specification (the
&quot;Specification&quot;), 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.
</permissions>
<warranty> ## NOTE WELL: This Specification is provided on an
&quot;AS IS&quot; 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. ##
</warranty>
<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.
</liability>
<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 &lt;
<link url='http://www.xmpp.org/extensions/ipr-policy.shtml'>http://www.xmpp.org/extensions/ipr-policy.shtml</link>
&gt; or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201
USA).
</conformance>
</legal>
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0059</spec>
<spec>XEP-0060</spec>
<spec>XEP-0313</spec>
<spec>XEP-0255</spec>
<spec>XEP-0107</spec>
</dependencies>
<supersedes />
<supersededby />
<shortname>NOT_YET_ASSIGNED</shortname>
<author>
<firstname>Simon</firstname>
<surname>Tennant</surname>
<email>simon@buddycloud.com</email>
<jid>simon@buddycloud.com</jid>
</author>
<author>
<firstname>Ashley</firstname>
<surname>Ward</surname>
<email>ashley.ward@surevine.com</email>
<jid>ashley.ward@surevine.com</jid>
</author>
<author>
<firstname>Lloyd</firstname>
<surname>Watkin</surname>
<email>lloyd@evilprofessor.co.uk</email>
<jid>lloyd@evilprofessor.co.uk</jid>
</author>
<revision>
<version>0.0.1</version>
<date>2014-01-29</date>
<initials>sdt</initials>
<remark>
<p>First draft.</p>
</remark>
</revision>
</header>
<section1 topic='Introduction to Buddycloud' anchor='intro'>
<p>Buddycloud is a collection of servers, running as XMPP components
that enable rich, federated communications for groups and individual
users. users uses and groups. Buddycloud builds on XMPP's native
federation and pub-sub principles to connect to and synchronise
updates with other Buddycloud servers.
</p>
</section1>
<section1 topic='Channel Introduction' anchor='intro'>
<p>Channels are a bundle of pub-sub nodes that have the same owner,
folllowers and access permissions. There are two types of channel:
user channels (named after the user's JID), for example
romeo@montagu.lit) and topic channels, for example
balcony-speeches@topics.montague.lit) which are owned by the channel
creator. Content posted into channels is automatically synchronised to
the correct followers on other Buddycloud servers.
</p>
</section1><section1 topic='Service Discovery' anchor='servicediscovery'>
<p>Service discovery happens per domain, and is a multi step process.
</p>
<p>To discover the channels component for a domain, the entity first
sends an items discovery request to the domain to discover all the
available components.
</p>
<example caption="The Entity sends a disco#items request to the domain">
<![CDATA[
<iq type='get'
from='juliet@capulet.lit/balcony'
to='capulet.lit'
id='items1'>
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
]]>
</example>
<p>The server replies with the list of available components, along with
their associated JIDs.
</p>
<example caption="The server replies with a list of available components.">
<![CDATA[
<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>
]]>
</example>
<p>The entity then iterates through the &lt;item/&gt; elements, sending
an info discovery request to each jid.
</p>
<example caption="The Entity sends a disco#info request to each component">
<![CDATA[
<iq type='get'
from='juliet@capulet.lit/balcony'
to='buddycloud.capulet.lit'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]>
</example>
<p>Each component replies with its identity. The channels component has
an identity of category 'pubsub' and type 'channels'.
</p>
<p> A domain MUST only host one component with an identity of category
'pubsub' and type 'channels'.
</p>
<example caption="The Buddycloud component replies with its identity">
<![CDATA[
<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>
]]>
</example>
<section2 topic='DNS Discovery' anchor='servicediscovery-dnsdiscovery'>
<p>Buddycloud components can also be discovered using a DNS SRV record
formatted as follows.
</p>
<example caption="SRV record for channel server didsovery">
<![CDATA[
_buddycloud-server._tcp.EXAMPLE.COM. IN SRV 5 0 5269 buddycloud.EXAMPLE.COM.
]]>
</example>
</section2>
<section2 topic='Discovery priority' anchor='servicediscovery-which-is-more-secure'>
<p> In the case of conflicting answers, the DNS result is
authoritative. This permits domain owners to run Buddycloud on domains on "chat only" domains such as google hosted apps.
</p>
</section2>
</section1>
<section1 topic='Register' anchor='register'>
<p>Upon connection to the buddycloud server a user should send a register
stanza.</p>
<example caption="The Entity sends a register request to the domain">
<![CDATA[
<iq type='set'
from='juliet@capulet.lit/balcony'
to='channels.capulet.lit'
id='register1'>
<query xmlns='jabber:iq:register'/>
</iq>
]]>
</example>
<p>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).
</p>
</section1>
</xep>