The True MINGing of Xpertweb

Flemming Funch, AKA Ming the Mechanic, has posted an overview of Xpertweb’s precepts and processes, emphasizing that everything’s public and everything’s decentralized and there’s no central greedpoint. Ming’s description carries more weight than others, since he’s the guy who’s putting it into practice. His approach to building this web app is to make it as simple as possible—notice that he calls himself the mechanic, not the theoretician. We both believe that code must follow custom, not enforce behaviors. Like, when you’re designing a park, put the sidewalks where the grass wears out.

I’ve admired Flemming since I discovered him last December, when I mirrored his entire Organization Archive in a blog titled “Ming’s Dynasty“. He learned a lot about reputation systems as originator and designer of the New Civilization Network, which now has thousands of participants:

“If there is a list of people’s reputation ratings as numeric values, ordered in descending numeric order, people change their behavior and get competitive about getting better numbers.”

At NCN, he quotes Margaret Mead:

“Never doubt that a small group of thoughtful, committed citizens can change the world.
Indeed, it is the only thing that ever has.”

Who better to birth the Xpertweb code than a programmer-philosopher? And civilized—he’s a great Dane

GUI and EUI

As the posts by Flemming, Mitch and Doc suggest, our little design study is morphing back into programming mode. That means we’ll be finalizing our Graphic User Interface, of course, but also developing an Economic User Interface—the essential events that define economic activity. Fortunately, when you’re not trying to design a multi-national lock-’em-in enterprise, the economic imperatives customers care about are pretty straightforward.

Caveat Venditor

Mitch wrote Sunday about Xpertweb’s inversion of web-based economics, whereby work is done first and satisfaction-based payment later. That simple inversion opens doors for less selling, more buying, and a healthy microeconomy of satisfied peers.

The secret sauce we are adding to our microeconomy is reputation. In order to do that, we must collect every task rating without exception. To ensure 100% compliance, we need to embed the rating—a numeric grade and a written comment—in the invoice so it cannot be put off and thus not entered. If we’re to rely on ratings, they can’t be entrusted to sellers nor should they be centralized: why do all this work to build a closed system bound to collapse under its own weight?

So it’s mandatory to have open data co-hosted by the seller’s and buyer’s synchronized web sites. The data set includes the surprisingly few types of promises and outcomes common to every transaction: due date, description, price, etc.

Project Background

Over the last four years, five programmers worked on various aspects of the project, proving that we could synchronize the buyers’ and seller’s transaction records and equip users to create and modify data forms even if they couldn’t spell XML.

When Flemming and I started talking, he was very diplomatic. He said the programmers had done a good job of implementing what I’d asked for. His point was, of course, that I’d been asking for the wrong things. I appreciated his restraint.

I had always felt that our data files need to be as simple as possible, which meant well-formed XML but not validated against a strict schema or DTD. This was due to the overarching need to avoid centralization in any form, even an “official” namespace, to preclude any future possibility of a determined party gaining control of the namespace server and steering the community away from openness.

The decentralized approach also seemed to dictate a truly aberrant file structure: each datum would have its own 3-line xml file, avoiding any assumptions about how a data collection might be structured. Verbosity seemed a reasonable penalty for the simplest possible data structure. Our users won’t be data managers.

As Flemming and Mitch and I discussed architecture, we realized that we might have a data structure if it reflects the real world. In the Agora, there have been three kinds of things worth knowing for 5,000 years:

People (“youruniqueid.xml”, sometimes selling and sometimes buying),
Products (“Widget1a.xml”) and
Transactions (“sellersuniqueID.buyersunique.numberofunixsecondsuponsubmitbutton.xml”).

So we’ve declared those three categories to be the core datasets for the Xpertweb universe. It seems so obvious now, but that’s hindsight. Sometimes the obvious takes 5,004 years to sink in. For me, anyway.

That People datatype includes the Digital ID part of Xpertweb, which may be a pretty exciting byproduct. Xpertweb gives DigID something to do.

To Schema or Not to Schema?

We wrestled with this. Finally, as Flemming says,

“Certain relationships are built-in. Both providers and customers have mentors, who both might act as helpful consultants in making this all work, but who also serve a function in letting their software verify and aggregate activity for the people they have sponsored. That introduces some checks and balances that makes the system more fault-tolerant, and that fosters synergetic relationships.”

At the beginning, Flemming’s will be the only code at work, so there’ll be no need for a schema or DTD to enforce structural rules. However, Many Xpertweb users will embrace and extend Flemming’s code, so we’ll be adding a validation tool and a schema located on each site. That solves the decentralization problem, but still provides confidence that the directory structure will conform to other users’ expectations, and so that data forms and those three kinds of data sets are structured correctly.

Jon Udell suggested that we not build the schema first, but wait until we’ve banged on Flemming’s code for a while. Who are we to argue with Jon Udell?

Each Xpertweb site’s validation tool will also be able to validate another site. Specifically, a mentor’s validation tool will monitor her protegé’s sites’ integrity, and any site will accept validation requests from another site.

Unearthing a 5,000 Year Old Flow Chart

It’s obvious the transaction record must reflect the real-world dynamics of the special kind of conversation called a transaction, which, for the same 5,000 years, has had six distinct stages:

1. Discover Find a seller to deal with
2. Identify Select the specific product
3. Negotiate Resolve delivery location, timing, quality, etc.
   (often a back-and-forth between buyer & seller)
4. Commit Buyer and Seller commit to the negotiated terms
   (Goods or services are delivered between steps 4 & 5)

Invoice Seller reports the actual results and amount due

5. Evaluate Buyer rates seller and vice versa
   (this is the vital metadata of relationship, now made explicit rather than as a general impression. Or worse, hidden from the market by the seller)

Notice that Xpertweb doesn’t attempt to describe the actual work nor to manage the payment details. Work details are too specialized for our generalized data capture, though it’s described by the Productid.xml metadata and can also be discussed in task remarks. As for payment, that’s left to whichever means the parties prefer, though some third party payer is required, one which sends a confirming email to buyer and seller upon taking irrevocable responsibility for payment. Third party payer commitment closes out the transaction.

Reputation – The Secret Sauce of Decentralized Bookkeeping

Employees go to work for an accounting system, not the management. Managers hate that truth, but we all know what’s really going on. When you see an office full of busy people, you conclude the reason they showed up is the company is making payroll, so you agree to work today in anticipation of payment later.

Most of the compromises in our lives are based on our need to find a reliable accounting system, in the presence of which we agree to fritter away our days and imagination. What we really want is that future payment but hold the fritters, please.

After a series of Xpertweb transactions, some of us will be provably reliable and some less so. When that happens, even for a single expert and customer, we will have succeeded in reinventing communal reputation.

An expert will perform work for a reputable customer without needing to see that office full of busy people. That’s the EUI—Economic User Interface we’re designing. Will it work? No way to know for sure, but like GUI design, you take your best shot. To our design team, the EUI is just another feature of the web application and, since we’ve all done a lot of buying and selling, what we design for ourselves will probably work for others. But just to be safe, we’re including a tool to let anyone generate or modify the PHP forms so they can roll their own EUI.

If the Xpertweb EUI causes people to be more useful and to readily send money to each other, that EUI design is valid. If not, we’ll work on it. Eventually it will take.

11:44:01 AM