It's Like Déjà Vu All Over Again
"You could probably waste an entire day on the preceding links alone. But why take chances? We also give you Paul Snively..." — John Wiseman, lemonodor
There's only one way to know whether we can reasonably associate someone's "voice" with the "someone" we believe that voice to belong to.
Time.
The joker in the deck is that there's no actual consistency to someone's physical make-up anyway. We're all constantly tossing off and taking on the random stray particle; long term, we toss off and take on different ones. The result is called "aging" and, ultimately, "death."
Physical identity is just a convenient shorthand. If I have good reason to believe that I'm talking to Doc Searls, then I can get away with making a set of assumptions about what he's going to "sound like." But those assumptions are themselves approximations. When they are violated outside some slop factor that I have in my head, I might say, "hey, Doc, what's on your mind? You don't seem like yourself today!" I don't mean that Doc has taken on one too many free radicals. I mean that Doc doesn't sound like he's sounded before.
Aha. "Before." Time. The assumption is that I know what Doc used to sound like. That is, I have a record of what he's said before. At the moment, that record is in my head. Granted, it's largely based on stuff "Doc" has said in print, but good grief, I've never even met "Doc Searls." How do I know he exists? How do I know he isn't a small army of hired flacks? Well, I don't. I trust that his weblog is the work of one guy who wrote all the stuff attributed to "Doc Searls;" I trust that The Linux Journal isn't pulling a fast one. But these are unenforceable social contracts. Besides, even if none of the participants knowingly, deliberately violated the social contracts, unscrupulous individuals could hack and deface Docs' weblog. More sophisticated people could hack into The Linux Journal's workflow system and quietly replace Doc's work with their own. Doc wouldn't sound like himself (i.e. like he used to sound), but for reasons that have nothing to do with Doc.
This is the reason that unforgeable pseudonyms with digitally-signed reputation trails are necessary. They're the only rigorous analog we have to the informal process that we have historically enjoyed. That informal process worked sufficiently well when most interaction that had value to the participants was face-to-face and a handshake was as binding a signature on a contract as there could be. This worked because, modulo plastic surgery, it was hard to change your face, and besides, a new face in town wouldn't be trusted on a handshake either.
This reminds me that the most heart-rending moment in the recent "The Lord of the Rings" was, of course, at the very end, when Sam Gamgee demonstrated that he would literally rather drown than break a promise. I can imagine that, in a town like Hobbiton, a promise-breaker would find themselves in considerable trouble; everyone would know your name and your face. Of course, even by Hobbiton standards Sam is unusually steadfast, and those who have read the books know well how this steadfastness plays out in Sam's adventures with the Fellowship.
But less and less of our valuable interaction is face-to-face; less and less of it can be closed on a handshake with both participants knowing that, if they violated the terms of that handshake, they'd likely never be able to conduct another such transaction again. This is why some commentators who either misunderstand the description of the technology or latch onto accurate descriptions of the wrong technology are critical of "anonymity." And they're right. It's not anonymity we need. Far from it; part of the problem is precisely that we are anonymous, at least in the sense that we're just another face in the crowd.
Most "identity" online is an e-mail address change away from being someone else.
It's pseudonymity that we need. A pseudonym that persists through time and that accumulates reputation through time. A pseudonym that is associated with our values—the things that we believe to be inviolate—and our value—the unit of exchange for goods and services. A pseudonym without a reputation trail shouldn't be trusted much, although they might just be a newcomer. A pseudonym with a long, trustworthy reputation trail would be worth its weight in gold (interestingly, the Judeo-Christian Bible already says that a good reputation is worth its weight in gold). The pseudonym cannot be associated with its holder's physical being, leaving whistleblowers free of the fear of violent reprisals or even the threat of violent reprisals. And the whistleblower has their own reputation to either lend them credibility or not. Likewise, presumably, the target of the whistleblowing. Think of it as built-in character witnessing.
It's a leap. It's a stretch. But it's one that we have to make sooner or later in an increasingly-distributed world. The OpenPrivacy initiative has it right. We need to develop, field, and enhance this architecture and these protocols with as many concrete, easy-to-use implementations as we can come up with. Now's the time.
11:51:04 AM
What is it with parents and their kids' sports?
I usually keep score for my 12 year old's basketball games. The center for the other team fouled out in the 3rd quarter of today's game. His coach (also his father, it turns out) is officially protesting the game; he thinks I cheated by giving his kid five fouls. Well, the ref tells me the player's number and I write it down.
First of all the thought would never even cross my mind to cheat in this role so that a seventh grade team can win a basketball game. The time keeper (a parent for that other team) can at least attest that I cheer their team's baskets as well as my son's team's. I even moan when the other team takes a good shot that just rolls out.
Secondly (and this is what's really going on, I believe) is that his son was not having a great game. He only had two points, and the two players he had been defending were in the top three scoring. My son's team was ahead by 12 points at the time.
I'm not even sure what it means to protest a game in this league. The refs backed me up, so... well... so what?
Here's what... from now on I will always tell the other coach how many fouls a player has every time they get one.
Oh... the kids mom also came over and gave me her opinion to. Who do they think I am? An accountant for Enron?
One more reason I can't condone competitive sports. Couple outmoded, projected turf defense instincts with a reinforced, false lesson that zero-sum games are the only kind there are, and you've created a breeding ground for sociopaths.
The only reason that zero-sum games such as chess or backgammon are better is because they lack the testosterone-poisoning element... although, by the time you get to the international grand master playoffs, or a human vs. computer game, it starts to get bloodier again. And backgammon has a pleasing combination of luck and skill; it's as much about making the most of a bad roll as it is about simply crushing your opponent.
I think I'll play backgammon with my stepson later.
10:59:08 AM
'Sleeper Cells' in Singapore Show Al Qaeda's Long Reach... So, the lesson for the US is: don't spend a lot of money and time clamping down on individual freedoms, focus on improving the information transfer between citizens and the government. Better information flow, not less, is the route to improving security. Ways the government can provide that: force the regional bells to connect fiber to the home for true broadband connectivity. [John Robb's Radio Weblog]
I like this idea. Make communities more open and connected, and you might improve their security. Instead of retrenching into a restricted, quasi-internet era, we should instead jump in with two feet and use the internet as tool for building communities and defending them.
Seems like another reason we need unforgeable pseudonyms with persistent, digitally-signed reputation chains. Long term, leaving trust measurement to intuition and the ether just won't work. And lest you think that recording reputation at each interaction you deem significant sounds outlandish, just look at even a relatively low-end PalmOS or PocketPC device with infrared. Add a JavaRing to that to store your key(s) in and you're literally a button away from recording a transaction, and that technology will only get smaller, cheaper, and more transparent than it already is.
10:52:47 AM
It would be great to see a project that utilized BEA's new Cajun serives framework with Radio on the deskop for a complete end-to-end solution. Java-based Web Services developed at the server level and Web apps that consume and inform them on the desktop. I think the vision is similar here. They are bootstrapping .Net and Java to hide the complexity of Web Services development and we have bootstrapped Internet Explorer to add Web Services support on the desktop in an environment people are familiar with. [John Robb's Radio Weblog]
I like the vision. And what I really like about Java is that there are many efforts from third parties to provide frameworks; web services is just one key example. I wonder if .NET will support the same kind of innovation? Microsoft wants so much to provide the entire foundation. There at least a half dozen web services frameworks already for Java, with their own strenghts and weaknesses. But this is a good thing. (BTW GLUE is my favorite so far.)
I am a little concerned about Java. Sun's new web services offering is beginning to show up in the press as the Java web services offering as compared to Microsoft's .NET web services offering. So far Java third parties have showed no signs of giving in to this notion of it being one-on-one, Sun vs. Microsoft. This is a key differentiator between Java and .NET.
I'd have to add that Caucho Technology's Resin offerings are still my preferred Java app server tools, and with the addition of Burlap and Hessian have only become more so. Simple, reliable, fast, and inexpensive. Good stuff!
Having said that, I appreciate what Graham Glass has done with GLUE and Electric XML. Graham is a very sharp guy, also writes simple and fast Java code, and is a lot of fun to hang around (I had the pleasure of meeting him at OOPSLA '98, while he was still with ObjectSpace working on Voyager).
10:47:16 AM
5{ ws is anomalous in its lack of transparency. By choosing to develop OS X on a transparent base [~] Darwin, which is BSD on a Mach kernel [~] Apple respected the essentially infrastructural nature of operating systems, and the need for transparency at that level. I was talking with an Apple guy who works on OS X last night, and he was going on about the synergy between the company and outside Darwin hackers who shared an interest in improving Darwin as base-level infrastructure. [The Doc Searls Weblog]
The Intel platform desperately needs a successful Unix-based *desktop* OS. What went wrong with Linux?
I have a tough time treating this as a serious question. A desktop OS needs a consistent vision of its interaction with the user. The Open Source development process offers a lot of benefits, the most clearly articulated of which seems to be making bugs increasingly transparent as the code is exposed to more eyes. But one thing it most definitely does not offer is a unified vision of how anything interacts with anything at a certain scale. The UNIX mindset of scads of small, self-contained pieces that can be recombined in myriad ways—extremely useful if you're a geek with a job to do—makes it extremely difficult for that culture to present a "single face" to the user.
10:42:21 AM
did not keep the formatting very well. This will not make any converts to Lisp syntax. I need to see if it can be improved or just include links to better representations on another page. [Patrick Logan's Radio Weblog]
Definitely agreed. I gave up on preaching Lisp to people a few years back. Now what I say is: if you like the idea of Lisp but find the parenthesis intolerable, you'll enjoy one of the other functional languages. Go with Haskell for purity, Objective Caml if you just want functions and objects, and Oz if you want to discover that you can do things—easily—that you never thought you could do at all.
10:36:31 AM
11) You live in North Korea. Three days ago the soldiers came to your tiny patch of farmland and took the few scraps of food they hadn't taken the week before. You have just boiled the last of your shoes and fed the softened leather to your 3-year-old child. She coughs, a sickly sound that cannot last much longer. Overhead you hear the drone of massive engines. You look into the sky, and thousands of tiny packages float down. You pick one up. It is made of plastic; you cannot feed it to your daughter. But the device talks to you, is solar powered, and teaches you how to use it to link to the Web. You have all the knowledge of the world at your fingertips; you can talk to thousands of others who share your desperate fate. The time has come to solve your problem in the most fundamental sense, and save the life of your daughter.[http://www.skyhunter.com/marcs/finalexam.html]
LOL People's reactions to Marc's question #11 are always interesting; they're a far more interesting Rorschach test than any actual inkblot test.
10:31:49 AM
The problem is, I also believe that scripting languages shouldn't have to roll their own support infrastructure. Far too much effort is expended wrapping components -- an XML parser, a database adaptor, whatever -- for every language that comes down the pike. But what's the alternative? Lacking widely deployed common infrastructure, our scripting languages must carry it around with them like turtles carry their shells.[Jon's Radio]
A reasonable alternative, I am finding, is to use Java as the common infrastructure. There are many scripting (and otherwise) languages which run in the JVM and are integrated with Java to one degree or another. DotNet would be a reasonable alternative except the cross-platform capabilities are too uncertain.
It's not the perfect choice but it beats the situation above, about turtles. Funny that this is still such an issue. Here's some nostalgia as a reminder that it used to be worse.
Actually, I think most scripting language implementations now have pretty reasonable bindings to C and/or C++, and for the ones that don't, SWIG might either already accomodate the language or be easily extended to do so.
The whole topic is interesting, though, because it points out the fact that the distinction between "scripting" and "non-scripting" languages is artificial, a fact that's been appreciated by those of us who have been using extremely powerful, dynamic, interactive development environments such as Lisp or Smalltalk for years.
10:27:41 AM
Here's the overhead required for GLUE to publish a Java web service. It's not much, but more than necessary. I've been playing with publishing web services from GLUE, written in JScheme. I'll follow up with that before too long.
One big difference between GLUE and .NET is that GLUE separates the application code from the "publishing code".
In GLUE and Java, write the service in Java...
public class Hello { public String hello(String name) { return "Hello, " + name; } }
I have to confess that I have a tough time understanding how to avoid this "overhead" (and I object to the loaded terminology, too) in any environment that is intended to be a general-purpose programming environment as well as a web service host. Before someone attempts to give an example, let me posit that any compelling example will simply make the "overhead" implicit: the code will have to be in the right context, whether that context is a directory, a namespace, inheriting from some class, or what have you. The third alternative is that literally everything is published automagically, which is just an extreme case of "implicit overhead."
There's a follow-on observation about the scripting language/WSDL debate, but it's not yet clear enough in my mind to articulate. So consider this a placeholder and reminder to me more than anything else.
10:15:04 AM
Dan Gillmor: "Each of us has been asked to nominate some technology or agent of change. I'm suggesting the combination of sensing with computation, creating machines that will observe and interact with the people and things around them." Dan, that's the wrong answer. It's people, not machines. Oy. Machines make people more powerful. Don't expect machines to become people... [Scripting News] ... Dan's particular comment puts him right alongside Dr. Rosalind Picard in terms of goals. Briefly, human beings shouldn't need to become more accomodating to machines; machines should become more accomodating to people. A major step forward in accomplishing that goal would be for machines to interact with humans in ways that humans are accustomed to being interacted with. If that makes the machines "more human," so much the better. [It's Like Déjà Vu All Over Again]
I'll toss in Terry Winograd, co-author of Understanding Computers and Cognition for this discussion. I think Dave Winer and Paul Snively are both saying machines should accomodate people. I have my doubts that that is best done by attempting to make machines more *like* humans.
Mea culpa that I—an old computational linguistics guy—should have neglected to note Terry Winograd as well. And Patrick, your name is familiar, too—aren't you a regenerate Lisper yourself?
What I wanted to emphasize, though, was that, in the limit, making machines more accomodating to people does imply making machines more "human," the very concept that Dave rejected (unnecessarily perjoratively and rooted in ignorance, which was also part of my point) as a "looney tunes notion."
10:04:42 AM
I mean that Doc doesn't sound like he's sounded before.
