The following terminology derives from Ricardo, which forms the basic architectural layout to which WebFunds conforms.
An Application is a programme that does something for users. For example,
WebFunds is a user client that can hold different value managers (in G3), and can use the payment technologies within in a sensible fashion.
Teller is a merchant application that can receive requests to deposit incoming payments and requests to write outgoing payments. It only works with one value manager, being the SOXWallet. (This application is being written internally by Systemics.)
Pumphouse is a merchant application that can receive requests in XML-X and convert them to matching operations in Ricardo. It is a more powerful variant of Teller. It can handle the full suite of XML-X commands needed to provide a user-based website access to value.
The latter two are server applications, so the user is really another application.
These terms may sometimes mean the same thing:
item is a SOX value identifier (byte array), literally, the field in the SOX payment or the SOX sub account that identifies value type. This is at the lowest protocol level, and has no meaning ascribed to the contents. It could be the bytes that come from the strings "dollars" or "USD" or "AirMiles". Or, it could be the byte form of a contract, below.
SOX does not assume any semantics for items, as a protocol, although the current implementation requires that it be a Ricardian Contract, within the code.
contract is a Ricardian contract, the hash of which is used as an item (SHA1).
WebFunds assumes that all value (regardless of the value manager) is identified by a Ricardian contract. So, if we were to add a form of value that was distinct, say, smart card money, then we may have to write some contract wrappers to keep WebFunds happy with its assumption.
instrument is a financially traded ricardian contract, as opposed to a contract that is not traded, or outside the trading context.
So, an issue like pints of beer might be an instrument, a contract, and an item, depending on the context.
These terms are often used interchangeably to mean some place where value is kept.
In more precise Ricardo terms, we have the following:
account is a SOX construct to control an asset. It is the unit of authentication, in cryptographic terms. In this narrow sense, an account is best modelled as a capability within the SOX world. It is built out of a private-public key pair, and the public key is registered with one or more SOX Servers.
At a SOX Server that is a Ricardo Issuance Server, the account may be able to drive a value subaccount with TransactionRequests. If that or another SOX Server also operates as a Rafi's Server, and the account is also registered there, this account may drive a messaging relationship (chat).
subaccount is the value account that results from registering a public key at a Ricardo Issuance server. That is, a subaccount can manage the value of one contract, with one psuedonymous identity as managed by the key. If the account key is registered at many Issuance servers, the account becomes capable of controlling many subaccounts.
Holding is the Lucaya name for the combination of the single key / single sub account model. In Lucaya, each private-public key is used for one and one only contract, so the distinction and relationship between the Account and subaccount is submerged at the (Lucaya) application level.
See more on the SOX page .
WebFunds is the basic downloadable cash management application, written in Java. It is now in its 4th generation.
Lucaya, the 4th generation of WebFunds, was started by Edwin Woudt in the summer of 2002, and further developed in 2003 with Jeroen van Gelderen. Ian Grigg worked on it from then on until mid 2004. Around the end of 2003, it first become demonstrable, although it is some way from achieving the feature set and stability of G3. By mid 2004, the transactions were stable and robust, and management of servers and contracts was substantial up to the standards of G3.
Lucaya brings 3 things to the table:
a completely reengineered event and thread model,
a custom object database that imposes a threading and commit regime, and
a more modern and convenient GUI.
The thread and events model was required for Rafi's which didn't cope with the lack of live events coming from the network. It was also required in order to cope with persistent network difficulties. Underlying, Lucaya uses the same basic SOX package, in much the same fashion as Pumphouse, Teller and WebFunds G3.
Lucaya drops the ValueManager 3rd party plugin concept of G3. The main reason for this was the complete absence of any support for 3rd party plugins. Even though Lucaya is planning to deliver 3 applications, in some technical sense plugged in to the core application, this will now be managed centrally.
G3 - third generation - was first started in late 1998 by Erwin van der Koogh, and has been in continuous improvement since then, mostly by Ian Grigg, and with some work by Edwin Woudt and Jeroen van Gelderen. It is now mature, but also on a track to be replaced by Lucaya (which is only just entering demo mode).
+------+ +-------+ +-------+ +------+
| u2u | |auction| |loyalty| |retail|
+-|plugin|---|plugin |---|plugin |---|plugin|---+
| | | | | | | | | |
| +------+ +-------+ +-------+ +------+ |
| |
| c o r e W e b F u n d s a p p l |
| |
| c o m m o n c a p a b i l i t i e s |
| |
|G U I - n e t - D B - P K I - c o n t r a c t s|
| |
| +------+ +------+ +------+ +------+ |
| | SOX | |Trader| |Mondex| | E | |
+-----| vm |---| vm |---| vm |---| vm |-+
| | | | | | | |
+------+ +------+ +------+ +------+
The original motive for ValueManagers was the need to create a bearer token system. SOX was to be one VM, and the token payments the other. In the event, the tokens VM was never delivered, but a Trader VM did get completed.
A Value Manager is a module offering payments of a particular type and technology. E.g., SOXWallet can do SOX payments and deposits. We refer to the value manager as the protocol manager for a given system, such as Trader, SOX/Ricardo, E-protocol, Mondex, etc. G3 strived to permit multiple value managers to exist underneath it, and offers the user a coherent interface.
Each Value Manager conforms to the interface located in webfunds/client/WalletInterface.java. In the case of the SOXWallet, the module is at webfunds/client/sox/SOXWallet.java, although this is migrating to webfunds/sox/value/*,
There was some early confusion on terms. Originally, the value manager was referred to as a wallet, but as many systems refer to the entire application as a wallet, the term was deprecated.
We refer to the plugin as the application that gets plugged in to the top of G3, using the cash management capabilities of the system, perhaps provided by multiple value managers. Here, we would be referring to plugins for u2u, retail, loyalty, auctions. The one plugin that was added was the ContractSignWizard, written by Edwin Woudt to sign Ricardian Contracts.
The 2nd Generation of WebFunds was a substantial rewrite by Gary Howland of Mike's application. The AWT-based GUI did not change much, but the underlying organisation did, making it more robust. It was also updated to Java 1.1. This was completed around 1997.
The 1st Generation of WebFunds was written from scratch by Mike, based on the work done with Trader. This was completed around mid 1996. It was substantially written in Java 1.0.
The primary feature of WebFunds then was a proxy design that allowed the application to handle seamless requests for payments driven by the browser and server shopping cart interface. The web server was empowered with The SOX Shop, a simple requestor of payments.
Back to Index.
Copyright © 1999-2004 Systemics Ltd. All rights reserved.