apk zenonia 5

Mike Arrington wrote a plea for better social software on Sunday:

The online social landscape today sort of feels to me like search did in 1999. It’s a mess, but we don’t complain much about it because we don’t know there’s a better way.

Everything is decentralized, and no one is working to centralize stuff. I’ve got photos on Flickr, Posterous and Facebook (and even a few on MySpace), reviews on Yelp (but movie reviews on Flixster), location on Foursquare, Loopt and Gowalla, status updates on Facebook and Twitter, and videos on YouTube. Etc. I’ve got dozens of social graphs on dozens of sites, and trying to remember which friends puts his or her pictures on which site is a huge challenge.

What enabled Google to solve the search problem was a common standard for expressing pages and the links between them, so that they could index the webpages and derive a metric for which ones were more important. They didn't do this by replacing the web with a structured database that they curated, they worked with the standards in use to make sense of it.

To solve the social conundrum we need the equivalent - agreed standards in widespread use so that we can generalize across sites. Fortunately, we have these. We have OpenID and OAuth for delegated login; we have XFN, other microformats and Portable Contacts for public and private people connections; we have Feeds and Activity Streams for translating social actions between sites.

This enabling social infrastructure means that we'll be able to have a new generation of sites that enhance our web experience through social filtering without our connections being centralised in a single company's database.

Once we get used to the experience of being able to delegate login, personal connections and activity updates, we'll look askance at developers who insist we create yet another profile and invite all our friends by email to experience their site; it'll be like a website without links.

Dave Winer used the public beta of Google Friend Connect to reflect on tech industry cycles:

A new generation of young techies comes along, takes a look at the current stack, finds it too daunting (rightly so) and decides to start over from scratch. They find that they can make things happen that the previous generation couldn't cause they were so mired in the complexity of the systems they had built. The new systems become popular with "power users" -- people who yearn to overcome the limits of the previous generation. It's exhilirating! [...]
The trick in each cycle is to fight complexity, so the growth can keep going. But you can't keep it out, engineers like complexity, not just because it provides them job security, also because they really just like it. But once the stack gets too arcane, the next generation throws their hands up and says "We're not going to deal with that mess."

Now, I may be a few years behind Dave, but I think he is throwing the baby out with the bathwater, or the stack out with the cycle here. Back when I started out, to get my computer to generate sound, I had to make my own D to A converter to attach to the parallel port, and for non-character graphics, my hardware hacker friends swapped the character generator ROM for RAM, and I had to code in assembler to swap the display data in time.

Now my son thinks nothing of mixing 10 polyphonic Midi tracks in an afternoon or editing hi-def video (and yes, it's on an OS I helped to make capable of that).

Dave's revolutionary impulsiveness has a germ of truth, but what really happens is that successful technologies become invisible infrastructure for the next things that build on them.

I no longer need to write assembler, heck I no longer need to write C code. Dave's very URL - scripting.com - shows how we have built up layers of utility to work upon.

HTTP, HTML, JSON, Atom and Javascript are infrastructure now. Our deepest role as developers is to build the invisible infrastructure for the next generation to take for granted, so they imagine new abstractions atop that. Dave did it with feeds.

What we're doing with the Open Stack — OpenID, OAuth, PortableContacts and OpenSocial— is part of this evolutionary cycle too. We're combining building blocks into a simplified whole that makes sense to people who want their websites to become social.

It comes down to what you can take for granted as the baseline to build the next exciting cycle on.

Just over a year ago, we launched OpenSocial to the web, with a few example applications and a lot of potential. Now, a year on, over 600 million social network users can use OpenSocial applications in their preferred social network sites.
Then, applications had to be embedded in sites as gadgets, which makes the social context clear for users, but means developers have to write some Javascript, and can only run code when the user is looking at the site.
With OpenSocial 0.8 rolling out, the REST APIs mean that developers can integrate with social sites using server-side code directly, potentially delegating user registration, profiles and friend relationships to an already-trusted social site, and feeding activity updates back into them.
To do this, we are building an Open Stack, based on OpenID, XRDS-Simple, OAuth, PortableContacts and OpenSocial. By composing open standards in this way, we can make each one more valuable. The advantages of OpenID over email login in itself are not that obvious to users, but if the OpenID can be used to bring in your profile and contacts data - with your permission via OAuth - suddenly the added value is clear to users and developers alike. This connection was one of the exciting discussions at the Internet Identity Workshop this week - here's a video of myself, Steve Gillmor, David Recordon and Cliff Gerrish talking about it.

I'm puzzled by Dare's post on OpenID, as he is wilfully misunderstanding its advantages at each stage, and I know he's smarter than that. He gets it right that OpenID is a way to confirm that a user owns a URL, without the rigmarole required to do so for an email address. 

However, the then uses his unmemorable Facebook URL http://www.facebook.com/p/Dare_Obasanjo/500050028 as an example, rather than any of the memorable ones he actually uses and people refer to, such as http://www.25hoursaday.com/weblog/ or http://carnage4life.spaces.live.com/ or http://twitter.com/Carnage4Life

DeWitt Clinton did an excellent job of clearing up some of Dare's other innaccuracies, but he then rhetorically exaggerated thus:

URLs make fantastic identifiers — for the 0.1% of the web population that understands that they “are” a URL. Fortunately, the other 99.9% of the world (our parents, for example) already understand that they have an email address.

This is missing the huge population of the online world (our children, for example) who consider email a messy noisy way to talk to old people, or to sign up to services when forced to, but are happy using their MySpace or Bebo or Hi5 or LiveJournal or Blogger or Twitter URLs to refer to themselves.
As I said in URLs are People Too:

The underlying thing that is wrong with an email address is that it's affordance is backwards - it enables people who have it to send things to you, but there's no reliable way to know that a message is from you. Conversely, URLs have the opposite default affordance- people can go look at them and see what you have said about yourself, and computers can go and visit them and discover other ways to interact with what you have published, or ask you permission for more.

Where I see OpenID providing a key advantage is in it's coupling with URL-based endpoints that provide more information and save the user time. The OpenID to PortableContacts connection as demonstrated by janrain can add your friends (with permission) from an OpenID login directly via OAuth.
This makes the OpenID login instantly more useful than an email one, and by connecting to an OpenSocial endpoint too, you can couple activities you take on the wider web with the site you trust to be a custodian of your profile and friends data, so your friends can discover what you are doing elsewhere, and come and join you.

I'm looking forward to talking through these issues at Internet Identity World next week in Mountain View.