BALL

How To Go Productive

Some notes what should taken care off before going production.

  • The user interface is too basic.
  • There needs to be a way get rid of accounts.
  • Web developer's groundwork. See below under "Accessibility".
  • Select a standard encoding according to your needs; see "Standards".
  • Use an appropriate set of notaries, where all peers are operated by different humans.

Accessibility

The demo leans towards minimalcode. This may result in arguments like this from Ian Grigg:

The document that would be something that I would say a judge cannot read without a HTML parser. When I clicked on it, my Mac opened it up in Xcode. I had to point my browser at it to read it in display form.

This was due to an artifact from forwarding the document instead of the OID per mail. We handle this by the "holder statement" having a clause to agree to the format as long as there are two independent ways documented how to display the document.

IanG: What happens if the document was presented in Firefox which failed to show the "sign-your-life-away" clause to the user?

You may want to double check using a known-to-be-good client.

Otherwise: we take great pains to assert that there is no so called active content in the documents.

Standards

Standard is better than better. The nice thing about them is: there are so many to choose from.

For the demo we chose to embed in XHTML.

XML/XHTML/style etc is wonderful for web devs but pretty much unintelligible for everyone else. I think in due course some > judges will accept it ... but in the first instances they should reject it for its lack of transparency.

Production systems will certainly need to comply to other standards. This will not effect the logic.

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