Recent Changes - Search:
Protocol /

XMPPBinding

To Do

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.

Node Identifiers

A node ID may be any legal Jabber ID, for example user@example.com or user@example.com/resource.

Node Presence

Nodes with permission may subscribe to another node's presence, allowing nodes to know when their neighbours are online.

Contact List Storage

XMPP servers store a roster of contacts 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 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. 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) 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, 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, 0177, and 0179. The BEEP protocol 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. XMPP connections support TLS encryption.

End-to-End Message Signing and Encryption

Still not finalized, JEP-0116 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, 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, 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) by returning 

<identity category="automation" type="ripple"/>
<feature var="jabber:iq:ripple"/>