Escapable Logic

Escapable Logic
Design Study for a New MicroEconomy

Home

Tuesday, September 17, 2002

Design Review

This design study is meant to be both focused and meditative. If we're lucky, we won't fail at both. After the last several meditations on the evolution of leadership personalities from Attilla the Hun to John Malone, it's time to recap our study criteria and get down to the nitty gritty of Xpertweb data structures and why they have to be so idiosyncratic.

Conclusions to Date

The economy is an Operating System, due for a major revision

All transactions depend on forms and protocols constraining the participants' behavior

The forms are based on data describing the rules - data controlled by sellers or government

Proprietary data is the root of tyranny

Sellers and buyers need equal authority over the transactional data archive

New standards are rarely effective because they need the buy-in of too many players

To design an economy, we'll start with a microeconomy and make it viral

Symmetrical Data
It's not yet obvious how tyrannical proprietary data has become, but perhaps we'll soon recognize that all our customer frustrations are based on the seller's control of customer records and their disinterest and incompetence in satisfying a customer. Doc Searls was called by a Wall Street Journal salesperson after paying in advance for a two-year subscription:

"Wait," I said. "Can you check and make sure you got the payment and it was credited?" "Sorry, I don't have access to those records, but you can call customer service at 1-800..."
Translation: "I'm just an outsourced telemarketer reading from a script."
Sheesh.

Doc's frustration is based solely on WSJ's inability to deploy people with access to and competency with all his account data and the authority to correct data errors on the spot. But why would they ever do that? They know their primary mission is to obligate him to assign some of his cash flow to them. There's a lower emphasis on doing what we think their mission is: delivering a fine paper to his doorstep.

There's another proprietary database lurking behind the scenes to enforce the WSJ's one-sided rules, and it's the most tyrannical private data in the world - the one that will hammer his credit rating if he goes to Tahiti for the winter and his subscription doesn't get paid. If Dow Jones hires Doc to speak, they'll probably pay him as companies usually do, 60-90 days after receiving the invoice. The Wall Street Journal will call that sound cash management. But if Doc pays his clients for their products on the same schedule they pay him, he's labeled a deadbeat.

It's solely because they control the data. Doc has no influence over it and a US citizen is an idiot if he doesn't cower at the magic incantation, "will be reported to a credit agency." That's probably why he pays his WSJ subscriptions 2 years in advance (as if that helped him in this case). How much customer money is held by companies, simply because a late payment carries such an inordinate burden? How much stronger might the economy be if the cash spent more time in customer's accounts under symmetrical data protocols?

The current data model is assymmetrical - all of the data is managed by one party.

Building the Symmetrical Data Store, one datum at a time
Every Xpertweb user maintains a complete record of every transaction they conduct, whether they're a buyer or seller. The data for every transaction is identical on the buyer's and the seller's data store. That's why every user has a web site even if all they do is buy stuff - their data record is always available and it's stored in the open on each web site, so any attempt to change data is immediately detected by the other party's specialized spidering software.

Every Xpertweb user has a mentor, who sets up the new user's web site, teaches him how to use the forms and provides disk space to mirror all the user's data. That leaves four copies of each record as a redundant archive. Each user could modify any data on their own web site, but the most damage thay can do is cause a transaction record to labeled as unreliable because it's not synched with the other 3 copies.

Each user's web site is managed by their local open source, trusted PHP scripts. When a buyer enters task data on the seller's site, it's immediately reviewed by the buyer's own trusted script and written to the buyer's Xpertweb site upon the buyer's confirmation.

Here's the high-level data structure for an Xpertweb user. Directories are blue, data is red:

myxpertwebsite.com
xpwid.xml
admin
mentor
buystuff
sellers
sellstuff
buyers
products
Here's a detailed data structure depiction.

Wasting Newly Abundant Resources

"So today, the prime rule of thrift in business is "waste transistors." We "waste" them to correct our spelling, to play solitaire, to do anything. As a matter of fact, you've got to waste transistors in order to succeed in business these days."
- George Gilder

The Xpertweb data storage design takes that advice to heart. One reason data is proprietary is that it's so complicated to manage efficiently. Millions of dollars are spent to make a corporation's customer records quickly accessible to only its authorized employees and increasingly, to customers on the web. The data sit on huge dedicated server farms. It involves a lot of customers and just a little bit of data on each one. It rarely describes how happy the customer was with the last transaction, and never lets prospective customers know how happy are the past customers. When it's accessed, it's by using a specialized data program that knows how to read and translate all that encoded, compressed data.

So transaction data has to be sketchy but archives millions of encounters. But when you or I have a transactional data store we find useful, it will have lots of data on each of just the few transactions we participate in.

So the resources wasted by Xpertweb are web server hard drives. Most ISP's give you 10, 20, up to 100 MB of storage for free, which is a lot of space for the 85-100 data items required to describe each of a few thousand transactions in enough detail to be useful to all interested parties.

The data is stored as XML data, which means it takes a lot of words to describe each datum (rather than looking like a compressed Excel table, with 1 header row describing the data, XML tags each datum with its own label):

<xpw_project_data project_id='ADCGEFH.FHECDBAM.1003863968'>
<xw_customer_email_address>brittb@xpertweb.com<;/ xw_customer_email_address>
</xpw_project_data>

The project ID is unique because it's a combination of the seller's unique ID (ADCGEFH), plus the buyer's unique ID (FHECDBAM), plus the number of seconds since the start of the year 1970 (1003863968). Presumably, this buyer will be unable to submit more than one initial purchase inquiry to this seller on that particular second.

In order to be even more wasteful, Xpertweb puts just one datum in each XML file, so this file might be called customeremail_ADCGEFH.FHECDBAM.1003863968. Like a packet sent over the Internet, the file contains all the information needed to relate this data item to its transaction forever.

12:31:19 PM comment []