On Sarcasm and Irony

While we were waiting for the OSIS session to start this past Monday at the Identity Open Space, Owen Davis told us about a study he had read claiming that only 20 percent of people understand irony. Upon hearing this, Joaquin Miller shared this great joke:    (L69)

A linguistics professor was teaching his class, and he explained that in some languages (like English), a double negative is a positive. “I am not unhappy with your work.” In other languages (like Russian), a double negative expresses stronger negativity. However, claimed the professor, there are no languages where a double positive is a negative.    (L6A)

“Yeah, sure,” responded one student.    (L6B)

You had to be there.    (L6C)

Free Identity!

A suggestion for Jimmy Wales‘s list of things that need to be free: Free identity!    (JNG)

“Free” in this case has a different meaning than it does than it does with the other items on Jimbo’s list. We need to free our digital identities from the organizational silos that currently collect and control information about ourselves. I am not suggesting that all digital identities fall under an open content license; I’m saying that the individual should have the ability to decide who has access to his or her digital identity and what they’re allowed to do with it.    (JNH)

Why is this important? Privacy is the obvious and most important reason. A secondary reason is that free, or at least mobile identities are a prerequisite for Jimbo’s tenth item: Free communities! It’s not enough to be able to migrate content from one community to another if you can’t also migrate people’s identities as well.    (JNI)

How can we free identities? Technically, it’s not that’s hard, and there are already several proposed specs and implementations, all of which support some notion of Single Sign-On and profile sharing with individual control. Personally, I’m partial to the Identity Commons approach with i-names, where identifiers are globally resolvable, information is distributed, and the notion of contracts built into the data structure. In the end, it doesn’t matter. What matters is that we agree on an interoperable technical specification for identity. Fortunately, many of the folks in this space are already working on collaborating, thanks to the efforts of Owen Davis, Kim Cameron, Paul Trevithick, Doc Searls, and many others. These people have taken to calling themselves the “Identity Gang.”    (JNJ)

The social questions are the hard ones. What does it really mean to control our identities? What should the social and legal agreements between individuals and organizations look like? If I give my business card to someone, what’s the implicit contract associated with this action, and what would it mean to make that contract explicit?    (JNK)

These questions are hard, but they’re solvable. Unfortunately, we’re not devoting much energy towards these issues right now. Perhaps a more public exhortation for freeing identities will lead to an effort to address these social questions that equals the current effort to solve the technical ones.    (JNL)

WikiMania Hackfest Day 4

Bits and tids:    (JM7)

  • I didn’t plan my Hacking Days schedule very well. I missed most of the first day, when the Mediawiki developers apparently made progress on a new metadata design. Days 2 and 3, from which I based most of my criticism, focused on servers and reliability, an area to which I really couldn’t contribute, not because I’m ignorant, but because I’m powerless. This morning, they discussed Single Sign-On and usability, two areas that I do know something about. Sadly, I missed these sessions, because I was too busy spouting on and on about how we really can save the world. Owen Davis, Fen Labalme, Kaliya Hamlin, and the rest of the gang will undoubtedly kick my butt when they read this. In my defense, I managed to talk a bit about Identity Commons later in the day. I also plugged the FLOSS Usability Sprint, and met Zeno Gantner, who’s done some usability studies on Mediawiki.    (JM8)
  • I was one of the featured participants for the afternoon “Wiki developers informal discussion,” along with Ward Cunningham, Sven Dowideit, Christophe Ducamp, and Brion Vibber. Domas Mituzas, Wikimedia Foundation‘s head of operations, asked Ward, “Why Camel Case?” I won’t go into the explanation here — I have a long interview with Ward, to be published eventually, that explains this in detail — but you should know that hating Camel Case is a running joke among this community. I laughed along with everyone else, but when Sven mentioned his desire to remove Camel Case from TWiki, I felt compelled to pipe up. I gave a balanced defense, describing Camel Case’s advantages over free links, but also acknowledging the appropriateness of free links in Wikipedia. Then I got a very amusing introduction to Erik Moeller, one of Mediawiki‘s core contributors and the Wikimedia Foundation‘s chief research officer. Erik had a strongly worded response. It got a bit heated, but never overly so, and I closed by saying that we were in violent agreement. We laughed about it over dinner, but then we got serious again. We also talked about Purple Numbers. I’ve explained many times why I may seem like a poor evangelist, but I think Erik was one of the few people who appreciated my perspective. He was clearly not a big fan of Purple Numbers — as it turns out, he was somewhat familiar with my work — but after hearing my explanation, he responded, “Only intelligent people are going to understand what you just said.” Fair enough. Fortunately, regular folks don’t need to get Granular Addressability for Granular Addressability to become ubiquitous.    (JM9)
  • A group of us broke out into a small group to discuss a Wiki Interchange Format, knowing full well that this is an issue that’s been discussed many times before (Wiki:WikiInterchangeFormat, MeatBall:WikiInterchangeFormat). Nevertheless, I think our discussion was not only constructive, it has a high chance of succeeding. See my summary.    (JMA)
  • Magnus Manske, the original creator of Mediawiki, participated in our Wiki Interchange Format discussion. He also mentioned a clever idea: a “shopping cart” where people could aggregate and possibly export Wiki pages they were interested in.    (JMB)
  • Sven Dowideit demonstrated the prototype WYSIWYG editor for TWiki, based on Kupu. He also showed a WikiText editor with real-time preview, which was pretty slick. Also, Ross Mayfield showed me a prototype editor for KWiki in response to my previous post. Very good to see these things.    (JMC)
  • So many people have come to this gathering to learn from others with different experiences. Granted, all of these experiences center around Wikipedia, but I’m still envious. My neverending quest is for folks interested in collaboration to look beyond their own narrow domains for deeper insights.    (JMD)

“Introduction to XDI” PowerPoint

Andy Dale and his team at ooTao have written the first implementation of the XDI data sharing protocol, which Identity Commons will use for profile sharing. As important a step that this is, Andy’s best contribution to date, in my opinion, has been his excellent “Introduction to XDI” PowerPoint slides, which he recently updated.    (IMU)

Last month, I spent an intensive day with Andy, Steve Churchill, and Owen Davis reviewing the XDI architecture. It was very enlightening, and it gave me greater faith in the decision to use XDI for data sharing and link contracts. Of course, I still had my gripes. I recorded some notes and observations at XDI Data Sharing.    (IMV)

Identity Commons: Empowering the Individual

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)