BALL

Usage

Here we cover only the basics, find more details in the wallet howto here.

Creating Assets

It all starts out by issuing a payment instrument in the form of a Ricardian Contract. (The reader should be familiar with the idea here, that personal credits or invoices are a payment instrument, not only "real money".) The account owner must fill in the form titled Claim:

  • An amount of units
  • A title
  • Terms&Conditions expressing the intent

For technical reasons there is a second step to book the resulting OID into the account. The user is given a chance to add some "pet name" or comment for internal reference.

As a result the inventory listing contains an entry for the amount and a link under the given pet-name referencing the XHTML document by OID (hash) which defines the issued instrument.

When accounting is checked in the form, a fresh wallet can be attached to the payment instrument. This is how new accounts are created. The purpose of the new account should be clearly stated in the terms and conditions attached to the asset.

Sending Payments

To pay (or send an invoice, which is the same at this level of detail), the sending account files a message with the notaries. The user needs to select a receiving account, an amount and the asset – optionally adding a title (recommended) and a free text message – and sign the payment. This will result in a new transaction listed in the Ledger marked outgoing (and later sent) and the amount is counted against the senders balance.

Important: The identifier (or – more practically often – the link in the column labeled "##" – without the quotation marks) must be transfered to the receiver "manually". Use any channel deemed appropriate wrt. your privacy, e.g., mail, chat or cut&paste. The demo manages only the "registered messages", not the message transfer.

The transferable identifier/link refers to the XHTML document with the order. Again in both human and machine readable form. See also "access control".

For the purpose of the demo we are free to choose the encoding. To keep the demo code (a single script) simple, we embed in a to be refined way. (Currently as illegal attributes of the html element, to be turned into meta elements.) For a production system an appropriate standard should be selected.

Receiving Side

The receiving account needs to put that into the field *get satisfaction* and push Go. The payment will be read from the receiving account and the user given a chance to verify it. The user may select a title for unknown payment instruments, add a note and optional message and sign the receipt. At this time the amount is added to the receiver's balance.

The user may alternatively choose to reject the offer (for dislike of terms) and sign a return receipt instead (which than has to be transfered back to the sender to receive the value back.

Technical remark: the amount and payment instrument are taken from the incoming order, not the user's input. This is why we need a machine readable format: we can not trust the user to specify the correct amount. Since all the commissioned notaries are listed in the receipt, we know that at the time of issuing the receipt (as included in the receipt) there was a qualified majority of them convinced that the order is pristine.

Other Forms

See the wallet howto here for lifetime management of wallets, access control, commissioning notaries customization and advanced usage.

About
Example
Usage
Trust and Verification
On Contracts
Discussion
Roadmap
Demo:Wallet FAQ