- specifying delivery to offline nodes - JEP-0160: Best Practices for Handling Offline Messages, JEP-0079 Advanced Message Processing, JEP-0091 Delayed Delivery
- network latency discovery - JEP-0090 Entity Time
- date and time - JEP-0082 Date & Time Profiles
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
A node ID may be any legal Jabber ID, for example email@example.com or firstname.lastname@example.org/resource.
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
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.
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"/>