Global Namespace for People (Part 3)

I ended yesterday’s post by saying that I would write about potential solutions to the global namespace problem for people (parts 1 and 2).   So here we go with a post on what seems to be happening (to be followed by a final post on possible alternatives).

The de facto solution for an increasing number of services appears to be delegating their namespace to Facebook or Twitter or both.  Facebook originally did not have usernames but only real names.  The problem with that approach was that the URLs for profile pages were based on User IDs, which don’t look good, aren’t memorable and don’t SEO at all.  So now I am albertwenger on Facebook as well.  I believe usernames are still optional on Facebook, although this is not entirely clear from the relevant help page (does anyone know the answer to this?).

For relying services there are a few issues.  First, it looks like there could be at least two de facto namespaces (Facebook, Twitter) and there might be a couple more that matter (e.g., Skype).   As a kludge, one could “subnamespace” by having URLs of the form service.com/twitter/username but then one still has to solve how to show usernames.  One option for display (e.g., Quora) is to display real names everywhere and try to provide additional information to help with disambiguation.  Another would be to continue the kludge and show usernames of the form username.tw or username.fb which would be pretty ugly (of course one could restrict it to usernames that would otherwise have a conflict).  Alternatively, for presentation one could punt altogether and let username conflicts exist and rely on avatars and other additional information for disambiguation.  Or one could decide to just force everyone through a single service.

A second problem for relying services is how to deal with changes in usernames.  Facebook allows a single change in username.  Twitter allows ongoing changes.  I don’t think either has implemented a protocol that would call relying parties to inform them of username changes.  Instead a service has to implement logic for tracking the change based on the underlying user ids as users come back to the service.

A third problem is whether or not to chose complete delegation in the first place.  What about users that would just want to sign up for the service and either don’t have a Facebook or Twitter account or don’t want the linkage that is implied by delegating the namespace.  Should a service support separate accounts and usernames at all (opening another door for username conflicts) or force everyone to come in through a service with a namespace?  There is of course also the question of the dependency on a commercial third party that is created by delegating one’s namespace.  While this may be somewhat hypothetical it is not entirely clear who “owns” the username – the person who created it?  The service where it originated?  Both?

Would love to hear from folks whether they think these are real problems with the current de facto solution and how services should deal with them (ideally with examples of good or bad implementations).

Enhanced by Zemanta
Loading...
highlight
Collect this post to permanently own it.
Continuations logo
Subscribe to Continuations and never miss a post.
#usernames#namespace#identity