mirror of
https://github.com/moparisthebest/xeps
synced 2025-02-16 07:10:15 -05:00
ProtoXEP: Buddycloud Channels
This commit is contained in:
Matthew A. Miller
parent
f4af46eb9a
commit
ede3a1111d
232
inbox/buddycloud-channels.xml
Normal file
232
inbox/buddycloud-channels.xml
Normal 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 "<actor/>">
|
||||||
|
<!ENTITY invalidactor "<invalid-actor/>">
|
||||||
|
<!ENTITY invalidnode "<invalid-node/>">
|
||||||
|
]>
|
||||||
|
<?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
|
||||||
|
"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.
|
||||||
|
</permissions>
|
||||||
|
<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. ##
|
||||||
|
</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 <
|
||||||
|
<link url='http://www.xmpp.org/extensions/ipr-policy.shtml'>http://www.xmpp.org/extensions/ipr-policy.shtml</link>
|
||||||
|
> 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 <item/> 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>
|
||||||
Loading…
Reference in New Issue
Block a user