Monthly Archives: August 2015

Internet, Money, Technology

Towards a universal trade protocol

Leave a comment

In this great talk by Bernard Lietaer, he talks about why the presence of complementary currencies actually INCREASE the stability of a nation’s official currency: Bernard Lietaer – Why we Need a Monetary Ecosystem, INRIA 2014

I’m 100% in agreement that we need complementary currencies to increase the sustainability of our trade networks, both alternative forms (like the e-dollar) of the main competitive debt-based national currencies, but also, and especially, other types of currencies based on different rules (such as to facilitate cooperation over competition, or to incentivize local trade over global trade, etc).

You might enjoy a very short paper that summarizes these ideas that I wrote for an economics class in 2008: Complementary Currencies Increase Economic Sustainability (PDF)

One recurring question I have is: to what degree would having a universal protocol for trading different currencies facilitate there being more of them commonly and easily used and exchanged?

One reason I’m enamoured with Ripple’s and Stellar’s designs is that they facilitate trade between currencies (which can be virtual currencies or proxies for other things). One potential problem is that they enforce the use of their own monopoly currency in order to transact these other currencies. This is why I’m curious as to the potential of a plain ‘bare bones’ trade protocol based on the federated consensus protocol (FCP) that is free from any direct linkage with an underlying transaction currency. This might be useful for facilitating trading information flow between disparate actors completely free of any single central currency or network. The primary driving question for this is whether it would be intrinsically useful and valuable enough in its own right to motivate use and validation without the incentive of the built-in transaction fees that are provided by XRP/STR currencies. This is similar to how the internet itself operates. ISPs and internet backbones are incentivized to provide data flow based on out-of-band financial agreements. The beauty of ripple/stellar/ethereum is that they build the validation incentive right into the system. But they are precomposed of several layers of protocols into one system. My question is what value is there in refactoring the trade protocol layer into its own standalone protocol.

Ethereum takes the transaction currency (the Ether) a huge leap further by enabling logic to be validated with it. In some ways this is orthogonal to the idea above of the benefit of a bare-bones implementation of an FCP-based trading protocol. Ethereum has its own consensus protocol and makes it possible to define a Ripple-like trading network directly on the Ethereum block chain. The potential problem is that it again creates a dependence on the Ethereum central (monopoly?) currency in order to transact.

My curiosity remains as to whether there’s some benefit to there being a pure definition of an FCP-based trading protocol, one that’s completely free of any one underlying monopoly currency system. In some ways it would be a pure protocol in the sense that it would exist primarily as a white paper or protocol description document. It would exist materially first as a reference implementation that runs based purely on intrinsic motivation, and later by various implementations on top of any or all specific information exchange systems, block-chain or otherwise. Perhaps it would just be what Ripple and Stellar already are, but without the XRP/STR layers.

The potential benefit from having this sort of generic FCP trading protocol is akin to having a universal DSL (domain specific language) for currency trading. My sense is that this would foster greater ability for intrinsically motivated parties to get up and running with trading a new currency. Cyclos provides a great product for getting up and running quickly with a new currency, but it does so solely through creating a new walled and isolated garden. A universal protocol for trading currencies would facilitate more communication between different and disparate currency systems.

Coding, Technology

A self-hosting self-emergent system

Leave a comment

The goal: an app hosting system that is emergent from that which is hosted.
The beginning: a component consisting of one UI button that when clicked begins a component creation/extension process that can both construct its own self and any larger system composed of self-emergent pieces. This larger system includes within it this same ability to modify and extend itself.

Primary aspects are the approach to self building and the final user view. WordPress is increasingly adding features that Drupal pioneered in terms of abstracting the notion of what is a “post”, or a “node” in Drupal, to make it easier to add custom content types. You can create a new content type, add predefined or custom fields to it, to create something specific like “Product” or “Article” and to differentiate it from a blog post or web page using different fields. These are CMSy things. In attempting to actually use these systems on both Drupal and WordPress, I’ve found that there is a conceptual difference between the backend user interface for generating these custom content types, and the front end display. Usually, the backend system works well for creating the data schema and editing the data, but there are large obstacles for creating and using the display part work without a lot of custom front end work. The biggest trouble with both the backend and the frontend is that they have strong opinions about how the data is stored in the DB and significant platform requirements for how the data is displayed within the context of the pre-existing WordPress and Drupal way of doing things. Both pretty much require using custom templates and display themes to really make use of the custom types, and even then, the designer needs to know the platform specific ways of doing things. This then spreads the custom types logic out between very different layers: DB storage for data schema, DB storage for data, business logic in a code module, display logic in templates (stored either in a DB or in code), display style in a theme.

One challenge I keep running into is how to abstract this CMS idea of custom content types on the backend side even more, and yet at the same time how to make all the pieces work together even better out of the box on the frontend display and usability side. The Ceptr and Om.Next approaches seem to be heading in similar directions of encapsulating all the parts of a given unit of system into one package that is constructed with specific rules to make it interoperable with other packages. The notion here is more one of self-contained packages that adhere to global protocols of package interoperability. I can imagine abstracting WordPress and Drupal modules further to arrive at a similar place. I can imagine a WordPress Ceptr module that acts as a container for running this new kind of module. This container module could itself be, or include, a module generator for creating new modules, and even for modifying itself, since it’s generated from its own self-emergent creation methods.