Design
Design principles, choices and constraints.
Last updated
Design principles, choices and constraints.
Last updated
Generality Building abstractions is a matter of finding generally applicable patterns to describe particular subjects within a common framework. Generality is achieved by identifying all parameters required to create a general-purpose conceptual model that fully describes a set of subjects, while specificity is achieved by enabling the configuration of such parameters.
Uniformity Once patterns are identified, problems can be modeled in a uniform way, and their solutions should have better usability and interoperability. Uniformity is achieved by standardizing the data models and interfaces so that all representations and interactions look the same regardless of the particular details of the underlying resources and operations.
Explicitness Good abstractions make assumptions explicit. Even after identifying enough parameters to fully describe something, some properties may remain hidden due to the assumption that they will not to change in the future. Explicitness is achieved when all properties that are currently constant but could become configurable are added to the conceptual model.
Openness
Source: code must be available to be copied, read, modified, shared and run.
Access: raw data and core functionality should be exposed for direct access.
Publishing: any participant must be able to launch a currency, royalty-free.
Ubiquity
Time: currency should have no concept of business days or operating hours.
Location: must be reachable everywhere without geographical restrictions.
Device: computing can occur on any platform with support for cryptography.
Permissionless
Issuance: every issuer must have complete control over the issuance policy.
Interaction: sending core requests should not require previous authentication.
Innovation: experimentation and integration with no bureaucratic procedures.
Neutrality
Origin: no distinction should be made to favor or obstruct any currency issuer.
Content: all addresses, currencies and transactions must be treated equally.
Purpose: currencies must be censorship resistant regardless of their purpose.
Freedom
Speech: using currency as a form of communication comparable to speech.
Expression: using currencies to express different forms of value and trust.
Association: easily joining or leaving contexts using a particular currency.
Currency-agnostic Webwallet transactions must support multiple units of account simultaneously. Therefore, units of account identifiers cannot be hardcoded, but must be explicitly listed as message properties in all IOUs and transaction outputs.
Transport-agnostic Although WebWallet is intended to be used on the Web, there must be no restrictions regarding the transport protocols. As long as the resource representations remain valid, they should be sendable using any protocol and encoding.
Database-agnostic The transaction clearing protocol should not rely on vendor-specific database functionality, only on general native operations such as key-based access in key-value stores or node creation and relationship traversal in graph databases.
Openly accessible Giving access to all transaction records for auditing purposes must be possible by default.
Publicly verifiable No private information should be needed to verify the state of the system at any given time.
Cryptographically driven All state transitions must be driven by cryptographically signed messages that make them valid.
Domains Both creating new transaction clearing domains, or adding more servers to existing domains, must increase the overall capacity of the information space for storing and clearing transactions.
Addresses The overall information space should scale regardless of the number of addresses using each unit of account, so that the performance of transaction clearing in any given countspace is not affected by its member size.
Count spaces There must be no limit on the number of units of account that can be defined in each transaction clearing domain, and the existing total should not impact the performance of the overall information space.
WebWallet's transactional model uses an asymmetric version of double-entry bookkeping in which all balance additions cause an equivalent balance subtraction from one or more addresses. Given that this constraint must be satisfied from the first issuance transaction, the sum of all address balances denominated in the same unit of account must always be zero.
Due to the asymmetric and zero-sum constraints, it is always possible to determine the source of funds for a given transaction. Although this is necessary for public auditability purposes, it certainly imposes limitations on privacy that currently can only be overcome by designing mixing services and IOU swap schemes that lead the trace of funds back to the issuance address.
Once the zero-sum and source traceability constraints are satisfied, it is always possible to determine the total number of units issued in any given countspace. Although this feature could also be considered a limitation on privacy, it is instrumental for mitigating the credit risk inherent in having the ability to make potentially unlimited promises to pay in arbitrary units of account.
WebWallet makes design choices focusing on transaction clearing for the Web, instead of transaction settlement for the Internet. Defining clearing as the process of determining obligations, and settlement as the actual process of fulfilling them, it therefore makes sense to use promises to pay in the form of IOUs as a way represent information about debts in a given context.
URLs are a useful convention for both naming and addressing in an information space. Besides the obvious benefits of Web compatibility, URLs are a way to emphasize the importance of logical decentralization and abstraction design so that WebWallet remains open to other implementation scenarios with different transport protocols and communication networks.
WebWallet uses JSON-based data structures to represent transaction requests and records, along with cryptographic hashes and digital signatures to secure them. It borrows some structures and naming conventions from the JavaScript Object Signing and Encryption specifications (JWS, JWT), but for the sake of extensibility and generality, it does not comply with the standards.