I've been wondering whether a special protocol for creating and managing Ripple shared accounts is necessary. Businesses commonly manage shared accounts by each keeping their own copy of the account data and modifying it separately when payments are made. Ripple is at the core a transaction system and ought to be agnostic to the accounting method. If both parties wish to keep track of the account for themselves, then they can do so. If there are other ways of making account entries other than via Ripple, it is not up to Ripple to handle.
Each party sets a credit limit for themselves and for the other party, and authorizes transactions based on those limits. The end result is that the lower number for either limit becomes the defacto limit for Ripple transactions. If the parties want to expose those limits, their interpretation of the current balance, or other pieces of account data to each other, that can be left up to the accounting system itself.
To ripplify an account with party B on party A's accounting system, A's accounting system would register the account with A's Ripple transaction server, which would then notify B's transaction server, which would ask B to give a corresponding account ID, if one exists, on his accounting system. If A and B happen to share an accounting system, each transaction server would query the same accounting system independently to ensure that the other transaction server wasn't cheating. If A and B also shared the same transaction server, then obviously the accounting system would only need to be queried once.
The Ripple transaction server design allows for integration with different accounting systems. To integrate with accounting systems, the Ripple transaction server provides the following API hooks:
In return, to integrate with the Ripple transaction server, the accounting system must expose the following capabilities through an API:
The following examples illustrate a few modes of registering accounts on the Ripple network.
This is a basic type of account with balance and credit limits. Its main distinguishing feature is that the account data is shared between two hosts, neither of which have to trust the other to be honest with the account-keeping. See Ripple Shared Account Protocol.
Example: A user on Ripple host A wishes to create a Ripple shared account with a user on Ripple host B. Both Ripple hosts must support Ripple shared accounts by running a Ripple accounts server.
An electronic accounting system at a bank, credit union, or private currency issuer can be integrated into the Ripple network.
Example: A user on Ripple host B wishes to create an account with a private currency issuer, who operates Ripple host A for that purpose.
These types of accounting systems include peer lending and social IOU tracking systems. This category includes all systems where accounts are kept between users of the system, and not with one single entity like a bank. These accounts may have different features from generic Ripple shared accounts.
Example: Alice on Ripple host A wishes to have an account with Bob on Ripple host B kept by IOU tracking system C.