Music City, Here I Am

Posted on Published by Eugene Eric Kim

Arrived in Nashville on Saturday for the MGTaylor Seven Domains Workshop, a meeting of the minds of many of those tied to the MGTaylor community. I’m working the workshop this week, then am spending a week driving in a circle to Cincinnati, St. Louis, and back to Nashville. If you have suggestions for places to visit along the way — especially interesting towns off the main road — let me know. Also drop me an email if you’re in the area and would like to get together.    (1NE)

My flight was largely uneventful, other than a stopover in Charlotte, my first time in North Carolina. I have this ongoing argument with several of my friends over how long you need to be in a state in order to qualify as actually having been there. We generally agree that stopovers don’t count, although after today, I may have to challenge that rule. Walking through the concourse towards my connecting flight, I couldn’t resist stopping for a pulled pork sandwich. Eating the local cuisine has to count for something, even if it’s at the airport.    (1NF)

You can actually get a decent sense of the local culture from airports. Several of the clerks were listening to bluegrass and country music behind their counters. White rocking chairs lined the entire concourse.    (1NG)

In addition to the sandwich, I tasted hush puppies — fried corn bread — and a fried pickle for the first time. It’s commonly acknowledged that everything tastes good deep-fried. Southerners go out of their way to prove this point.    (1NH)

Not only did barbecue feature prominently throughout the airport, there were also a few local fast food joints. I’m not that into fast food, but I like seeing what different places have to offer. Despite the ongoing conglomeration of most restaurants, even chains retain their local feel. I remember visiting D.C. when I was a kid, and being amazed at the fact that they had different fast food places — Roy Rogers in particular — than California. It’s not just childhood nostalgia, though. Thinking about the first time I had White Castle, after hearing my old boss constantly raving about it, makes me laugh. You haven’t truly experienced New York unless you’ve had White Castle at 3am in the middle of Queens.    (1NI)

After arriving in Nashville, I hopped on over to Ted’s Montana Grill to meet the other Knowledge Workers who are also working the workshop this week. Good people, all. I also enjoyed the bison short ribs. Bison is the specialty of the house, and Ted is Ted Turner.    (1NJ)

Afterwards, Jeff Johnston and Kati Thompson took me to the Station Inn for some buds and bluegrass, where we heard a great band — David Peterson and 1946. Definitely enjoyed the night out in Nashville; hoping there’ll be time for more of the same throughout the week.    (1NK)

Matt Taylor’s 1982 Management Center Concept Sketch

Posted on Published by Eugene Eric Kim

Matt Taylor pulled me aside yesterday to show me a sketch Jim Toohey had drawn for him in 1982.    (1NL)

https://i0.wp.com/www.matttaylor.com/public/graphics2/MTDesign.gif?w=700    (1NM)

Note the flat screen consoles, the laptop on the table, and the rewriteable work wall. Remember, this was drawn in 1982. More importantly, note the multiple modes of collaboration. People are working together in different ways, and everything is being captured digitally.    (1NN)

This sketch was the result of a Back Casting exercise. Instead of predicting the future, you describe the future as if it were the present, then describe what you did to get there. As Matt explained, everything he’s worked on over the past 30 years has been in pursuit of this vision, a vision that is now close to reality. Remarkable stuff.    (1NO)

The Future of Purple: Distributed Transclusions

Posted on Published by Eugene Eric Kim

One of my main interests is collaborative tool interoperability. In that vein, I’ve participated in many conversations, but I’ve been actively involved in two initiatives: Purple Numbers and Identity Commons. On the surface, these two technologies solve different problems, but when you dig a bit deeper, you can actually combine the two to do some very interesting things.    (1N1)

Purple Numbers enable granular addressability, which enables you to attach metadata to finer-grained chunks of data. Instead of having an author of a document, you have authors for each paragraph of a document. This is an especially useful concept for collaborative authoring tools, such as Wikis (hence PurpleWiki).    (1N2)

If you can address granular chunks of data, you can also transclude them. This is generally more useful than transcluding an entire document. (You are more likely to want to quote a sentence from a paper than the entire paper.) So, one consequence of tools that support Purple Numbers is that they also support granular transclusions.    (1N3)

One of the limitations of Purple Numbers as currently implemented is that addresses are only unique in a local context. What we really want are globally unique, persistent Purple Numbers. That would allow me to transclude a paragraph from another blog into this one. If that paragraph moves, the transclusion should still work.    (1N4)

Guess what. XRIs are globally unique, persistent addresses. In fact, they were specifically designed to address data. (See the excellent whitepaper, “The Dataweb: An Introduction to XDI” for more on this.) In other words, we can use XRIs for Purple Numbers.    (1N5)

Even better, Identity Commons is developing schemas for link contracts that allow you to attach permissions with your data. While Identity Commons will use these link contracts for protecting profile data, they could certainly be used for other things as well, such as protecting purpled data.    (1N6)

Suppose Alice writes a paper, and she only wants Bob and Carl to see it. She could attach permissions to the entire paper that says as much. Now Bob wants to write a paper, and he wants to quote a paragraph from Alice’s paper via a transclusion. However, he also wants to make his paper available to the public. So, he transcludes Alice’s paragraph and makes his paper publically available. When most people view the paper, they’ll see everything except for Alice’s paragraph because the link contract associated with that paragraph denies them permission. However, when Bob or Carl view the paper, they see everything, including Alice’s paragraph, because they have permission to view that.    (1N7)

More thinking needs to be done. This originally started as a fancy, but a conversation with Gabe Wachob over IRC a few months helped convince me that using XRIs for Purple Numbers was not only possible, but a good application. Two issues are:    (1N8)

  • What should the Purple Numbers look like? It’s the age-old question. XRI e-numbers are definitely not pleasing to the eye.    (1N9)
  • What should the numbers do when you click on them? The way it works right now is that the addresses are named anchors. But this won’t work out-of-the-box with XRIs, because most XRIs are not valid XML IDs.    (1NA)

Chris Dent has mentioned handles on several occasions as another direction we could go. We need to examine this possibility as well.    (1NB)

Freecycling

Posted on Published by Eugene Eric Kim

Earlier this year, I caught up with my old friend, Aaron Liepman, who’s currently a plant biology postdoc at Michigan State University. Aaron told me about this nationwide phenomenon known as Freecycle. He started two chapters in Michigan, including the first and largest in Detroit.    (1MN)

Here’s how it works:    (1MO)

  • Someone starts up a mailing list in their local community (often a Yahoo! Groups list).    (1MP)
  • People post offers on the list. Everything must be free (and legal).    (1MQ)
  • People respond to offers directly to the poster. When an item is claimed, the poster emails a notice to the list again.    (1MR)

You can also post items that you want. Aaron told me that one person posted on one of his lists asking for a DVD player. He scoffed at the post when he saw it, but sure enough, someone had a DVD player to spare and gave it to the poster.    (1MS)

I’m a reforming packrat, and I’m always trying to get rid of old stuff, so I subscribed to the Palo Alto freecycle soon thereafter. Since I recently replaced my laptop, I decided to give it a shot. This morning, I posted my offer. Literally a few seconds later, I got seven responses. This is for a seven year old laptop running Windows 95! If I hadn’t emailed a taken notice immediately thereafter, who knows how many responses I would have received?    (1MT)

What I love about Freecycle — other than the obvious environmental benefits — is that it’s a wonderful example of patterns trumping tools. First, it’s an innovative and efficient use of mailing lists. Someone could certainly design a custom tool to handle this exchange, but it’s not clear that the gains would be significant. Second, it’s easily replicable. Aaron heard about it and just did it. So did a thousand other cities. Third, it’s a community-builder, just like eBay — a way to discover folks close by with similar interests.    (1MU)

More articles about Aaron and Freecycle:    (1MV)

Identity Commons: Empowering the Individual

Posted on Published by Eugene Eric Kim

At last month’s Planetwork Conference, Blue Oxen Associates proudly demonstrated the first Identity Commons system for Single Sign-On. Conference attendees could access the PlaNetwork Wiki (which we hosted), Living Directory (for online profiles), Neo Society (a social networking site), and the conference site itself, all with one username and password. Although I’ve mentioned this work in passing on a few occasions, I’ve neglected to explain exactly what Identity Commons is about.    (1LG)

In short, we’re building a system where individuals have full control over their digital profiles. It’s an idea that was heavily inspired by the Augmented Social Network paper that was published last year.    (1LH)

Here’s how the system works. Individuals have one or more global identifiers — e-names — and Identity Brokers associated with their e-names.    (1LJ)

These Identity Brokers know three things about you:    (1LK)

  1. How to authenticate you (e.g. your password).    (1LL)
  2. Where your profile data is located.    (1LM)
  3. Link contracts that define who can access your data and what they’re allowed to do with it.    (1LN)

The latter two points are critical, because they differentiate this system from efforts such as Liberty Alliance and Microsoft Passport. Identity Brokers know where your data is, but they don’t necessarily store the data themselves. There is no central repository. Your data can be completely distributed across multiple sites. The only way sites can access your data is if you give them permission to do so via the link contracts.    (1LO)

There are two components to all of this: the technology and the social/legal agreements. The latter is the hard stuff. It’s not enough to build systems that can negotiate and agree on contracts; the organizations behind these systems have to respect these contracts. That’s why Identity Commons exists. Identity Commons is a member-owned Chaordic Organization founded by Owen Davis, whose primary purpose is to work out and enforce these social and legal agreements.    (1LP)

e-names and XRI    (1LQ)

I’ll have more to say about social agreements another time, most likely in response to other people’s queries and comments. In the meantime, here are a few more technical details.    (1LR)

E-names are based on an OASIS standard called XRI — eXtensible Resource Identifiers. Think of them as extended URIs. E-names are (mostly) persistent, globally unique, globally resolvable identifiers. E-names have multiple forms, but the ones most people will see are:    (1LS)

  =eekim   @blueoxen*eekim    (1LT)

The first form is part of a flat, global namespace (as specified by “=”). Sometime in August, individuals will be able to register global e-names as part of an Identity Commons fundraiser. The second form is an e-name associated with an organization (as specified by the “@”). That’s my actual, working e-name.    (1LU)

E-names are associated with e-numbers, which are persistent, numerical addresses. (Think IP addresses, except persistent.) You can associate multiple e-names with an e-number. In other words, requests for the email address of =eekim and @blueoxen*eekim would go to the same place, because they would both be associated with the same e-number.    (1LV)

You can use e-names for Single Sign-On, and you can also use them for data sharing and synchronization. For example, an e-commerce site could regularly request your latest contact information from your Identity Broker via your e-name, and it would get it — provided you give them permission. That information might be stored at another e-commerce site or at a social networking site or at a gaming community to which you belong. Neither the e-commerce site nor the Identity Broker care where that information lives.    (1LW)

Why do users need to remember yet another identifier format? Why not use email addresses? That would defeat the purpose of what this system is supposed to be about. Your email address should be your information, and you should control how it is used. If you just gave your email address out indiscriminately, that leaves you vulnerable to spam, which is the status quo. If you passed out an e-name, you couldn’t be spammed — folks would have to get your explicit permission to get your email address.    (1LX)

Why not use URIs? Two reasons: They’re not persistent, and they’re not user-friendly. One of the nice things about working with the OASIS XRI Technical Committee is that they are accomodating. None of the other TC members have had to worry about identifiers being user-friendly, because only software has seen those identifiers. However, they have already made some changes in their 1.1 spec to accomodate our desire for the identifiers to be more user-friendly.    (1LY)

Single Sign-On    (1LZ)

We’ve got the basic XRI resolution working and a Single Sign-On system working on top of that. The protocol is available on the Identity Commons Wiki. The protocol looks just like any other Single Sign-On protocol, and in fact, will most likely resemble the Liberty Alliance and SAML spec even more closely over time. Our intention is to use what’s good and available, not to reinvent the wheel.    (1M0)

I wrote the Perl implementation of the client library (XDI::SPIT), and there are currently PHP and Java versions as well. One way you can contribute immediately is to develop implementations in other languages (Python anyone?). The other way is to integrate these libraries into your tools. Note that all of this stuff is technically pre-alpha. It will change. That said, the APIs should remain fairly stable. It’s good enough for people to start using immediately.    (1M1)

Link Contracts and XDI    (1M2)

The most important pieces of all this are the data interchange protocol and the link contracts format. Fen Labalme, the chief architect of the Identity Commons project, is working hard on this right now, with help from Victor Grey, who implemented the first Identity Broker and also founded Living Directory.    (1M3)

Both of these pieces will be built on top of XDI (XRI Data Interchange), an XML application that is currently going through the standardization process. This is not something that’s being designed from scratch. XDI is based on previous work developed by One Name (now Cordance).    (1M4)

How does FOAF fit into all of this? The short answer is, “It will.” Think of what we’re doing as FOAF with authentication and link contracts. To be brutally honest, I can’t accurately assess this question until I see the XDI stuff, but I see no reason why XDI won’t be able to interoperate with FOAF, and vice versa. In fact, I’ll be gathering with Fen, Victor, and some other folks tonight to start exploring that possibility.    (1M5)

What’s Next?    (1M6)

This is without a doubt a grassroots effort, but there’s some serious technical and intellectual weight behind it. The technical specs are based on OASIS standards, with representatives from major corporations. The global registry for e-names will be operated by Neustar, which operates the .biz and .us registries among many others. Several of the people working on Identity Commons participated in Liberty Alliance.    (1M7)

Realistically, Amazon.com and Visa aren’t going to adopt this overnight. Once user demand passes a certain threshold, however, companies are going to have to start paying serious attention. Right now, users don’t have a choice. It’s give up your data or nothing. Once users realize they have a choice, I firmly believe that people will opt for privacy over the status quo.    (1M8)

Our strategy for getting to that threshold is to target civil society groups. So far, response has been outstanding, and I hope that this blog entry generates additional interest. Single Sign-On and data sharing solves an immediate technical need, and the fact that it does this while respecting individual privacy is a huge bonus.    (1M9)

What’s my role in all of this? Blue Oxen Associates is about improving collaboration for a better world. This system fits the bill perfectly. Not only does it promote tool interoperability, it does so in a way that will help improve people’s lives. I’m proud to be one of the project’s many contributors right now, and I’m proud that Blue Oxen Associates will be one of the first large-scale users of the system when our collaboratories go live next year.    (1MA)

If you want to help, more information is available at the Identity Commons Wiki.    (1MB)