Design, Studied

I’m in Portland staying with my good friend and data mentor, Nick Johantgen and his talented and stylish wife, Nina Davis. Nick & Nina and Tamara and I go way back, to Seattle, Philly and now bi-coastal. Roland Tanglao and I are meeting in Portland on the occasion of the O’Reilly Open Source Conference this week. (Flemming‘s moving to France next week, so he’ll be here only in spirit and iChat). Mitch is driving down from Tacoma to join us tomorrow. Our purpose is to hammer out some Xpertweb design details and to get some input from the Opensourcerati.

If Xpertweb does its job, we might one day see an Open Data Conference. “Open Data” is meant to suggest an architecture that mirrors data among participants’ web sites. It formalizes what we already embrace in a random fashion as we scan multiple RSS feeds, blogs, news and research to triangulate what we accept as true. If multiple sources describe roughly the same story, we come to embrace it. Multiple sources implicate the truth while open data explicates it. Our resentment of dead links indicates our commitment to open data, though we’ve not yet committed to an open data standard.

In transactional reporting, the kind of data that our clients and employers pay us to manage, Xpertweb wants to foment identical data in the records of both parties to the transaction. That alone is worthwhile, but the real win comes by making the data also open to other parties, anyone who may want to trade with the parties to this transaction and who would benefit from full disclosure of the character and quality of past undertakings.

I find it ironic that everyone uses open source tools to create closed data. Perhaps the benefits of open data are not obvious.

Lopsided, Balanced or Open Data?

The more technical terms might be Asymmetrical, Symmetrical and Transparent data.

Several years ago, it occurred to me that the world is built on asymmetrical data, where transaction records are maintained and controlled by the designer of the transaction. So, when a buyer and a seller transact, the seller (the designer of the transaction) keeps and controls the data. When an employer and an employee intersect, the employer (designer of their transaction) keeps and controls the data. That’s when I started my quest for a symmetrical data standard, where both parties maintain identical records of their transaction.

And realized how profound is the power to design transactions.

Later I realized that was a partial step. Symmetrical records may help the parties approach parity, but the smaller party will still be subject to the larger party’s, well, largesse. (It sounds like a contradiction in terms. Do we ever see largesse practiced by larger parties?) After some digging, I realized there’s lots of symmetrical data, but it’s hidden from view.

Symmetrical data is built cooperatively when businesses insist on parity of transactional data, using standards like EDI. So far, only largish businesses have had the luxury of symmetrical data, since it has required expensive tools, data servers, staffs and usually lawyers. And there’s nothing inherent in symmetrical data that will keep a GM manager from trashing a supplier as a smart career move.

Open Data is the next step. An ideal Open Data transaction is one where the symmetrical data is published on the web so it requires no permission for any interested party to examine it. Further, the data need to be persistent over the life of a transaction, not just archived at the close of the deal. This encourages the parties to deal as they say they should, since the details of failed transactions will be as visible as successful ones.

What’s in a Name? We had no ID…

We seem to have solved the hard part of the Digital ID challenge, as Doc described after we showed it to him in May. There’s a review of our digital ID system at the end of this post, for those patient enough to wade through it.

We have an ID process, which would seem to be the hard part, but not an ID format, which is harder than it seems. Our naming challenge stems from Xpertweb’s lack of centralization–there’s no central registration authority as for internet domains. Instead we have to rely on each mentor to generate a unique Xpertweb ID for all those who come after her. It’s a little like surnames, where John’s son Dave became Dave Johnson. Too bad that medieval standard wouldn’t scale past the first metadata level.

But the geneology model is compelling. Since we can compare satisfaction ratings for any users or groups of users, then, if each Xpertweb user’s ID contains the IDs of all the mentors who form the user’s “family tree,” so to speak, we can quickly compare any mentor’s effectiveness to any other’s. This seems to me an overarching value. The following method is the least worst we’ve come up with, which Roland describes as “Britt’s method.” Perhaps he’s distancing himself from it…

Procedure for Assigning a New Xpertweb ID (implemented by the Mentor’s Registration form)

The New User’s ID will be an extension of the Mentor’s ID The last character of the new user’s ID will be a single A-Z character (ASCII 65-90 or 97-122) for the first 26 New Users sponsored by the Mentor. All IDs shall be assigned in the order of the date and time of the Mentor Agreement by which they are created. There is no provision for a Mentor to assign Xpertweb IDs to more than 26 New Users. EXAMPLE: James Franklin’s ID is ADCGEFH. The first 7 characters (inheritance code) of the user ID for all Franklin’s New Users is ADCGEFH If Mary Smith is Franklin’s 5th New User, Mary’s ID would be: “ADCGEFHE“: her inheritance code + “E“. If Mary is Franklin’s 26th new user, her ID would be “ADCGEFHZ“.

Simple enough, right? Unique IDs all around. But we need a lot of unique IDs, since Xpertweb means to be a data collector and an alternate economy and globally virulent. Further, each human may have more than one persona, operating in parallel or serially.

The issue is the length of each ID. As we add users, their IDs get longer. At what length does an ID become unwieldy? Are ten digits too many? 15? 20? Does it matter, since each mentor’s web site will point out who begat whom? Theoretically, you can imagine a string as long as the number of users, if they’re added serially. However, since the Xpertweb system depends on each person training several others, (four is the recommended minimum), 4x4x4, etc. yields I
Ds about 16 digits long. Not bad, and we get to keep the geneology model.

While we need to anticipate every eventuality, such as a thousand people at a meeting, each of whom mentors the person seated to their right (AKA “Ming’s Nightmare”), I feel human nature is on the side of one person mentoring several others, so the digit-length tax on each generation seems likely to earn a four-fold population gain:

 

# Chars Population # Chars Population 1 4 1 6 2 16 2 36 3 64 3 216 4 256 4 1,296 5 1,024 5 7,776 6 4,096 6 46,656 7 16,384 7 279,936 8 65,536 8 1,679,616 9 262,144 9 10,077,696 10 1,048,576 10 60,466,176 11 4,194,304 11 362,797,056 12 16,777,216 12 2,176,782,336 13 67,108,864 14 268,435,456 15 1,073,741,824 16 4,294,967,296

Xpertweb has generous rewards for mentoring new users (some say they’re too generous), so it’s likely that many mentors will introduce more than four new users. That’s my story and I’m sticking to it. Unless we can come up with a better story.

Whaddaya think? Does this approach make sense? Do we need a more elegant, computing-intense way to generate IDs? How important is it to provide a simple means to look at ID strings and see within them the ” geneology” of the mentors who trained an Xpertweb user. Please send any comments to Roland.

Why work on an idealized, theoretical economic system?

Is one better off to work directly on the symptoms of the real socioeconomic climate, like getting an Internet-based President elected? Or is it better to fantasize that a novel transaction data model could grow to significance? As you guessed, I like to place both bets.

Clearly, Xpertweb is a delicate, tentative little evolutionary economy. Like all evolutionary species, you can almost hear it gasping and flopping around at the edge of the water hole, wondering if breathing air is really such a great idea. But it’s a little horny, nonetheless.

“Oh well, maybe it’s wo
rth it. Let’s find someone to transact with…”

---

Current Method for Authenticating an Xpertweb Buyer

Since both parties control web servers containing the ID data they wish to selectively expose, we can use cooperative scripts to identify ourselves to each other, making the steps fairly straightforward. Here’s an example where I might want to buy something from Flemming Funch, but he doesn’t know if I’m the person I say I am.

1. I’m attracted by FFUNCH’s reputation and click on a product link.
2. The product page asks me to enter my unique Xpertweb URL.
3. Upon submitting a URL, FFUNCH’s site visits the URL and discovers there IS an Xpertweb site present with a properly formatted me.xml file at the root level and a script that says it’s ready to play nice with his script. Only then does FFUNCH’s script learn that I say I’m BRITTB.
4. FFUNCH’s script still doesn’t know if I’m BRITTB, so his script notes the current time, the visitor’s IP number, composes a unique ID for this contact and places a cookie on the visitor’s browser, something like:
        taskid FFUNCH.BRITTB.1054746754; IP 66.65.84.10 and some product info
        (a task ID = both users’ IDs + the Unix epoch [# of seconds since 12/31/1969])
5. FFUNCH’s script directs my browser to the URL I presented
6. The script at BRITTB’s site asks me (still unverified) to enter BRITTB’s name and password.
7. If I pass the challenge, we need a stateless way to confirm to FFUNCH’s script that I am indeed BRITTB.
8. BRITTB’s script looks in its buystuff/sellers directory for a subdirectory labeled FFUNCH.
         [If absent, it creates a buystuff/sellers/FFUNCH directory]
         It creates FFUNCH.BRITTB.1054746754.xml in buystuff/sellers/FFUNCH
            … listing the now-current epoch, BRITTB’s IP # and the product info
9. BRITTB’s script returns me to the FFUNCH site
10. FFUNCH’s script visits BRITTB’s site and notes that the properly formatted file was created in the proper directory at a time shortly after the task ID creation, from a browser at the known IP number.
11. FFUNCH’s script looks in its sellstuff/buyers directory for a subdirectory labeled BRITTB.
          [If absent, it creates a sellstuff/buyers/BRITTB directory]
          It creates FFUNCH.BRITTB.1054746754.xml in sellstuff/buyers/BRITTB
             … listing the current epoch, BRITTB’s IP # and the product info

Now the two of us can transact with high confidence that our reputations are accurately represented. Naturally, no system can guarantee that we’ll behave well. All it can do is report what we say about each other’s behavior.

And that seems like a good start.

[back to the Unique ID discussion]

9:31:45 AM