On 16 March 2010 22:42, Petr Viktorin <[email protected]> wrote: > The problem of good identifiers is unique to decentralized systems. > Indeed, it's the one area of the Web that's still fairly centralized – > you can't just grab a domain and use it. > We have to make this work well, and there aren't many good examples of > how to do it out there. > The fundamental problem, IMO, is that any fully qualified, unique ID > is just too long.
I'd argue (and do, often!) that email addresses are fully qualified, unique IDs that are sufficiently short and also represent the "free" characteristics that we need in any sort of decentralized system. I'll offer another criticism of HTTP URLs in the context of personal identifiers; take the following two URLs: http://flickr.com/lattice http://images.google.com/images?sourceid=chrome&q=blaine+cook&um=1&ie=UTF-8&oi=image_result_group&ct=title&resnum=1 Both occupy the same "namespace" as far as users are concerned. The fact that the formats are so different means that pattern matching rules that our brains constantly use don't apply. The seven components of the URL each express a different abstract concept, so to effectively apply pattern matching rules, a user needs to be able to understand all seven components. compare with: [email protected] which, in addition to encapsulating the above flickr address and implying the above google search (with *more* specificity), also encapsulates my homepage, my blog, my twitter account, reviews, events, and so on. The email address requires understanding only two abstract concepts – one, for the individual who is addressed, and second for the hosting provider (which is treated in practice as an opaque string). > I would very much like to see some kind of local aliases. Here's the > idea (Concrete syntax/terminology might be different of course): > If I write "@fred", the software knows I want the Fred from my "friend list". > If I want to reply to someone I don't know, I can use a full URL. > One question is what happens if I know two (or zero) Freds. Does the > software make me choose one before posting? Does it go unresolved, > until I come in later and resolve it? Or do I need to assign explicit > unique nicknames to people to use this? I love the idea of using @-style addressing in this way; The behaviour would need to be defined in the context of the software (not the interoperable specifications), and could work in any number of ways, including the ones you've described. Twitter works by just assuming that you know the @fred in question (as opposed to @fred2), and the nicknames are global. If you get the wrong @fred, that's your problem. > Another problem is sharing (reposting, retweeting). A solution here is > to let the full URL get embedded in the post, so anyone sharing it > wouldn't have to know this particular Fred. The string "@fred" itself > wouldn't be that much of a problem, as when someone sees the post is > from me they should know I'm talking about the Fred I know. So long as the nickname resolves to some URI, that URI is the one that should be represented in "public"; it might be translated to a personalized nickname, but in any event all of this would be up to the actual social software, not specific to the protocol. As an aside, you probably don't want to share nicknames, since someone might give their boss or someone they don't particularly like an unsavoury nickname, thinking it's private, but getting in trouble when it turns out it's not. Principle of least surprise. > Obviously this needs a lot of careful thought, but if the goal is user > friendliness it's the way to go, IMO. Nicknames are great as local "helpers", but when it comes to *sharing* identifiers across "communities" (e.g., from tweet.ie to identi.ca), nicknames break down. Webfinger represents a lot of thought and debate on this topic, and in many ways (as is usually the case with things that people talk and debate a lot about) represents the way that existing social networks approach the problem of identifying friends (see any "Find Friends using your Email Account" for a vivid example). b.
