social-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Social-discuss] Protocol / Design Considerations.


From: Blaine Cook
Subject: Re: [Social-discuss] Protocol / Design Considerations.
Date: Tue, 16 Mar 2010 23:02:26 +0000

On 16 March 2010 22:42, Petr Viktorin <address@hidden> 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:

address@hidden

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]