Protocol /
XMPPBinding
Protocol.XMPPBinding History
Hide minor edits - Show changes to output
Added lines 1-59:
'''To Do'''
* specifying delivery to offline nodes - [[JEP-0160: Best Practices for Handling Offline Messages -> http://www.jabber.org/jeps/jep-0160.html]], [[JEP-0079 Advanced Message Processing -> http://www.jabber.org/jeps/jep-0079.html]], [[JEP-0091 Delayed Delivery -> http://www.jabber.org/jeps/jep-0091.html]]
* network latency discovery - [[JEP-0090 Entity Time -> http://www.jabber.org/jeps/jep-0090.html]]
* date and time - [[JEP-0082 Date & Time Profiles -> http://www.jabber.org/jeps/jep-0082.html]]
!!! Network Structure
The Ripple network consists of user agents, or nodes, connected pairwise by abstract mutual-credit accounts which allow tracking of IOUs between the two parties. Each Ripple node is an XMPP client connected to a server on an XMPP network. The server provides the following:
* node identifiers
* node presence
* contact list storage
* node-to-node message transport
* connection-level authentication and encryption
* end-to-end message signing and encryption
See [[http://xmpp.org/specs/]] for detailed XMPP protocol specifications, particularly [[XMPP Core -> http://www.xmpp.org/specs/rfc3920.html]].
'''Node Identifiers'''
A node ID may be any [[legal Jabber ID -> http://www.xmpp.org/specs/rfc3920.html#addressing]], for example user@example.com or user@example.com/resource.
'''Node Presence'''
Nodes with permission may [[subscribe to another node's presence -> http://www.xmpp.org/specs/rfc3921.html#presence]], allowing nodes to know when their neighbours are online.
'''Contact List Storage'''
XMPP servers store a [[roster of contacts -> http://www.xmpp.org/specs/rfc3921.html#roster]] for each user which specifies node IDs, presence subscription information, contact names, and grouping of contacts. Ripple clients may wish to group all Ripple neighbours together in one group.
Connection account data may be stored while a node is offline using XMPP extension specification [[JEP-0049: Private XML Storage -> http://www.jabber.org/jeps/jep-0049.html]] if it is available. Care must be taken when storing authentication keys.
'''Node-to-Node Message Transport'''
XMPP is designed to be a transport for XML messages, which makes XML a natural fit for Ripple messages, although another textual format would also work. Ripple messages could be carried within an [[XMPP @@<iq/>@@ stanza -> http://www.xmpp.org/specs/rfc3920.html#stanzas-semantics-iq]]. Messages would be contained in an IQ "set", and responses in IQ "result" (affirmative) or "error" (negative) stanza, containing a @@<query/>@@ element in the "jabber:iq:ripple" namespace. The @@<query/>@@ element will contain the Ripple message itself.
Section [[9.2.3 IQ semantics of RFC 3920 (XMPP Core) -> http://www.xmpp.org/specs/rfc3920.html#stanzas-semantics-iq]] describes how IQ messages provide reliable delivery by requiring a response to each query. A Ripple node may resend any query or response if it is not certain it has been delivered. Nodes should disregard multiple messages with the same id.
[[XMPP lacks proper message framing -> http://developers.slashdot.org/article.pl?sid=04/10/05/0226233#10437306]], and as such servers must parse every message in its entirety which may bog down under heavy loads. As Ripple message volume increases -- path-finding in a large network may generate a lot of messages -- XMPP messaging could be used to negotiate a direct P2P connection between nodes, as is done in JEPs [[0176 -> http://www.jabber.org/jeps/jep-0176.html]], [[0177 -> http://www.jabber.org/jeps/jep-0177.html]], and [[0179 -> http://www.jabber.org/jeps/jep-0179.html]]. The [[BEEP protocol -> http://beepcore.org/]] might provide a good framework for these direct P2P connections.
'''Connection-Level Authentication and Encryption'''
XMPP ensures [[authentication of clients to servers and servers to each other using SASL -> http://www.xmpp.org/specs/rfc3920.html#sasl]]. [[XMPP connections support TLS encryption -> http://www.xmpp.org/specs/rfc3920.html#tls]].
'''End-to-End Message Signing and Encryption'''
Still not finalized, [[JEP-0116 -> http://www.jabber.org/jeps/jep-0116.html]] is the latest specification for end-to-end security of XMPP messages. This capability is very important for Ripple.
Also thinking about the [[XML Encryption specification -> http://www.w3.org/TR/xmlenc-core/]], which could be used for signing as well (by encrypting with the private key instead of the public one), although if done straightforwardly, this would be slow. To fix this, a hybrid encryption scheme similar to [[OpenPGP -> http://www.gnupg.org/gph/en/manual.html#AEN210]], where the private key is used to encrypt a symmetric key, which then speedily encrypts the rest of the message would probably work.
'''Service Discovery'''
Ripple nodes should advertise themselves as such in response to [[service discovery queries (JEP-0030) -> http://www.jabber.org/jeps/jep-0030.html]] by returning
[@
<identity category="automation" type="ripple"/>
<feature var="jabber:iq:ripple"/>
@]
* specifying delivery to offline nodes - [[JEP-0160: Best Practices for Handling Offline Messages -> http://www.jabber.org/jeps/jep-0160.html]], [[JEP-0079 Advanced Message Processing -> http://www.jabber.org/jeps/jep-0079.html]], [[JEP-0091 Delayed Delivery -> http://www.jabber.org/jeps/jep-0091.html]]
* network latency discovery - [[JEP-0090 Entity Time -> http://www.jabber.org/jeps/jep-0090.html]]
* date and time - [[JEP-0082 Date & Time Profiles -> http://www.jabber.org/jeps/jep-0082.html]]
!!! Network Structure
The Ripple network consists of user agents, or nodes, connected pairwise by abstract mutual-credit accounts which allow tracking of IOUs between the two parties. Each Ripple node is an XMPP client connected to a server on an XMPP network. The server provides the following:
* node identifiers
* node presence
* contact list storage
* node-to-node message transport
* connection-level authentication and encryption
* end-to-end message signing and encryption
See [[http://xmpp.org/specs/]] for detailed XMPP protocol specifications, particularly [[XMPP Core -> http://www.xmpp.org/specs/rfc3920.html]].
'''Node Identifiers'''
A node ID may be any [[legal Jabber ID -> http://www.xmpp.org/specs/rfc3920.html#addressing]], for example user@example.com or user@example.com/resource.
'''Node Presence'''
Nodes with permission may [[subscribe to another node's presence -> http://www.xmpp.org/specs/rfc3921.html#presence]], allowing nodes to know when their neighbours are online.
'''Contact List Storage'''
XMPP servers store a [[roster of contacts -> http://www.xmpp.org/specs/rfc3921.html#roster]] for each user which specifies node IDs, presence subscription information, contact names, and grouping of contacts. Ripple clients may wish to group all Ripple neighbours together in one group.
Connection account data may be stored while a node is offline using XMPP extension specification [[JEP-0049: Private XML Storage -> http://www.jabber.org/jeps/jep-0049.html]] if it is available. Care must be taken when storing authentication keys.
'''Node-to-Node Message Transport'''
XMPP is designed to be a transport for XML messages, which makes XML a natural fit for Ripple messages, although another textual format would also work. Ripple messages could be carried within an [[XMPP @@<iq/>@@ stanza -> http://www.xmpp.org/specs/rfc3920.html#stanzas-semantics-iq]]. Messages would be contained in an IQ "set", and responses in IQ "result" (affirmative) or "error" (negative) stanza, containing a @@<query/>@@ element in the "jabber:iq:ripple" namespace. The @@<query/>@@ element will contain the Ripple message itself.
Section [[9.2.3 IQ semantics of RFC 3920 (XMPP Core) -> http://www.xmpp.org/specs/rfc3920.html#stanzas-semantics-iq]] describes how IQ messages provide reliable delivery by requiring a response to each query. A Ripple node may resend any query or response if it is not certain it has been delivered. Nodes should disregard multiple messages with the same id.
[[XMPP lacks proper message framing -> http://developers.slashdot.org/article.pl?sid=04/10/05/0226233#10437306]], and as such servers must parse every message in its entirety which may bog down under heavy loads. As Ripple message volume increases -- path-finding in a large network may generate a lot of messages -- XMPP messaging could be used to negotiate a direct P2P connection between nodes, as is done in JEPs [[0176 -> http://www.jabber.org/jeps/jep-0176.html]], [[0177 -> http://www.jabber.org/jeps/jep-0177.html]], and [[0179 -> http://www.jabber.org/jeps/jep-0179.html]]. The [[BEEP protocol -> http://beepcore.org/]] might provide a good framework for these direct P2P connections.
'''Connection-Level Authentication and Encryption'''
XMPP ensures [[authentication of clients to servers and servers to each other using SASL -> http://www.xmpp.org/specs/rfc3920.html#sasl]]. [[XMPP connections support TLS encryption -> http://www.xmpp.org/specs/rfc3920.html#tls]].
'''End-to-End Message Signing and Encryption'''
Still not finalized, [[JEP-0116 -> http://www.jabber.org/jeps/jep-0116.html]] is the latest specification for end-to-end security of XMPP messages. This capability is very important for Ripple.
Also thinking about the [[XML Encryption specification -> http://www.w3.org/TR/xmlenc-core/]], which could be used for signing as well (by encrypting with the private key instead of the public one), although if done straightforwardly, this would be slow. To fix this, a hybrid encryption scheme similar to [[OpenPGP -> http://www.gnupg.org/gph/en/manual.html#AEN210]], where the private key is used to encrypt a symmetric key, which then speedily encrypts the rest of the message would probably work.
'''Service Discovery'''
Ripple nodes should advertise themselves as such in response to [[service discovery queries (JEP-0030) -> http://www.jabber.org/jeps/jep-0030.html]] by returning
[@
<identity category="automation" type="ripple"/>
<feature var="jabber:iq:ripple"/>
@]