I've argued beforethat identity is a building block -- an essential amino acid, if youwill -- for social networks. It's far from the only thing you need,but without stable, persistent, verifiable identity, it's very hard tobuild relationships. It's so important that there are specialized subnets in the human brain that recognize voices and human faces to help you remember people.
The digital world doesn't work like that. Identifying someone onlineis hard. Even solving the more limited problem of verifying that this person is the sameperson who you were socializing with yesterday online is not trivial. All social software has some mechanism for letting people verify someonline identity -- usually a user name and password. Of course thatjust means that you have different user names for different services. In the new "Web 2.0" world, though, a primary rule is for services to be open and interoperate and play together. That's difficult if people have to remember that you're leetjedi67 onservice A and urtha52 on service B. It's fine if you want to do that,but most people want to be themselves most of the time. And ourinfrastructures don't allow for that.
Well, at least they didn't. There's a remarkable convergence of usercentric identity systems happening right now. At the lightweight end,basically everyone has converged on the OpenID standard. This lets you be leetjedi.net everywhereif you want. Or at least everywhere that supports OpenID. The first,most practical benefit is that you won't need to fill out anotherregistration screen on most new services. The more long term benefitis that you get to keep your identity and your reputation with you asyou move between services.
Of course none of this matters if companies don't adopt it, so what'sthe benefit for them? Well, if their service involves a socialnetwork, it gains immediate access to both a network and an ecosystemof services which work with it. The value of a social network grows quadraticallywith the number of users; the value increases linearly as thedifficulty in connecting two users drops. Connecting two OpenID userswith is a lot easier than if you have to convince one or both to acquire a new identity.
This is the big value in promoting and leveraging a common standard. Even Microsoft is adopting open standards for their CardSpace identitysystem (and CardSpace and OpenID are talking cordially to each other,by the way). So embracing the open network, leveraging the quadraticmultiplier in network value, and competing on value added services isreally the way to go. Of course this means that you are opening upyour own services to more competition as well as cooperation). SinceAOL has already committed to open web services, this is a logical nextstep. Just playing around with ideas: What would happen if every AIMuser name were OpenID enabled? What if you didn't need to evenregister to use UnCut Video, AIM Pages, or AOL Journals?
Tags: identity, OpenID, networks, social networks, web2, user centric identity
2006/12/15
2006/12/12
Atom API for AOL Journals
Journals exposes a very complete API for creating and managing blogs, entries, and comments. I'm working on getting the API documentation up on dev.aol.com sometime soon. But it's very easy to get started with basic blog posts. Here's an example using curl, that would post to this blog, if my password were MYPASSWORD:
curl -k -sS --include --location-trusted --request POST --url 'https://journals.aol.com/_atom/journal/panzerjohn/abstractioneer' --data @entry.xml --header 'Content-Type: application/atom+xml; charset=utf-8' --user panzerjohn:MYPASSWORD
where entry.xml is the Atom entry to be created, like this:
curl -k -sS --include --location-trusted --request POST --url 'https://journals.aol.com/_atom/journal/panzerjohn/abstractioneer' --data @entry.xml --header 'Content-Type: application/atom+xml; charset=utf-8' --user panzerjohn:MYPASSWORD
where entry.xml is the Atom entry to be created, like this:
<?xml version="1.0" encoding="utf-8"?>On success, you'll see something like this in response:
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:aj="http://journals.aol.com/_atom/aj#">
<title>Blog entry title</title>
<published></published>
<content type="html">
Hello World!
</content>
</entry>
HTTP/1.1 201 CreatedThere are a lot of other parts of the API, but they're best left for a full document rather than a blog post. There's also at least one known bug, where our servers don't accept the 'xhtml' content type. That should be fixed on beta.journals.aol.com this Wednesday.
Date: Tue, 12 Dec 2006 18:21:57 GMT
Server: Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7e mod_jk/1.2.14 mod_rsp20/RSP_Apache2_v6_2.05-08-11:mod_rsp20.so.rhe_x86-3.v8_r1.44
Set-Cookie: RSP_DAEMON=1ceaffc0a8b18da03cfaaea9b70f236f; path=/; domain=journals.aol.com; HttpOnly
Set-Cookie: MC_UNAUTH=1; path=/; domain=journals.aol.com
Location: http://journals.aol.com/_atom/journal/panzerjohn/abstractioneer/entryid=168
Transfer-Encoding: chunked
Content-Type: application/atom+xml;charset=UTF-8
<?xml version="1.0" encoding="utf-8" ?>
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:aj="http://journals.aol.com/_atom/aj#">
<link rel="alternate" type="text/html" href="http://journals.aol.com/panzerjohn/abstractioneer/entries/2006/12/12/blog-entry-title/168" />
<link rel="http://journals.aol.com/service.edit" type="application/atom+xml"
href="http://journals.aol.com/_atom/journal/panzerjohn/abstractioneer/entryid=168" />
<link rel="http://journals.aol.com/comments" type="application/atom+xml" title="Comments feed for this entry"
href="http://journals.aol.com/panzerjohn/abstractioneer/entries/2006/12/12/blog-entry-title/168/atom.xml" />
<id>tag:journals.aol.com,2003:/panzerjohn/abstractioneer/168</id>
<title type="text"><![CDATA[Blog entry title]]></title>
<updated>2006-12-12T18:21:00Z</updated>
<published>2006-12-12T18:21:00Z</published>
<author>
<name>panzerjohn</name>
</author>
<aj:entrySource>AtomAPI</aj:entrySource>
<aj:mood>0</aj:mood>
<aj:commentCount>0</aj:commentCount>
<content type="html"><![CDATA[ Hello World!]]></content>
</entry>
2006/12/04
At IIW2006b
I'm at the Internet Identity Workshop (part B), listening to a bunch of smart people like Dick Hardt, Johannes Ernst, Kim Cameron, and of course Kaliya. Looking forward to hearing a lot of exciting developments. Already people are announcing open source libraries supporting OpenID.
Dec 5, 11:45am: There's a good article just put up at ZDNet: "The case for Openid" It's been Slashdotted already. At IIW, I've been sitting in on the basic OpenID discussions, finding out what's new with 2.0, and listening in on the user experience/microformats discussion. The latter is potentially interesting; at least there are specific short-term obvious next steps, like supporting XFN, that would help enable potential applications down the road. This is a very difficult thing to sell to business people, though. Maybe there's a session on that -- evangelizing to the business?
Tags: iiw2006b
Dec 5, 11:45am: There's a good article just put up at ZDNet: "The case for Openid" It's been Slashdotted already. At IIW, I've been sitting in on the basic OpenID discussions, finding out what's new with 2.0, and listening in on the user experience/microformats discussion. The latter is potentially interesting; at least there are specific short-term obvious next steps, like supporting XFN, that would help enable potential applications down the road. This is a very difficult thing to sell to business people, though. Maybe there's a session on that -- evangelizing to the business?
Tags: iiw2006b
2006/11/20
Caching for AOL Journals
We're continuing to work on improving the scalability of the AOL Journals servers. Our major problem recently has been traffic spikes to particular blog pages or entries caused by links on the AOL Welcome page. Most of this peak traffic is from AOL clients using AOL connections, meaning they're using AOL caches, known as Traffic Servers. Unfortunately, there was a small compatibility issue that prevented the Traffic Servers from caching pages served with only ETags. That was resolved last week in a staged Traffic Server rollout. Everything we've tested looks good so far; the Traffic Servers are correctly caching pages that can be cached, and not the ones that can't. We're continuing to monitor things, and we'll see what happens during the next real traffic spike.
The good thing about this type of caching is that our servers are still notified about every request through validation requests, so we'll be able to track things fairly closely, and we're able to add caching without major changes to the pages.
The down side is of course that our servers can still get hammered if these validation requests themselves go up enough. This is actually the case even for time-based caching if you get enough traffic; you still have to scale up your origin server farm to accommodate peak traffic, because caches don't really guarantee they won't pass through traffic peaks.
We're continuing to carefully add more caching to the system while monitoring things. We're currently evaluating using a Squid reverse caching proxy. It's open source and has been used in other situations -- and it would give us a lot of flexibility in our caching strategy. We're also making modifications to our databases to both distribute load and take advantage of in-memory caching, of course. But we can scale much higher and more cheaply by pushing caching out to the front end and avoiding any work at all in the 80% case where it's not really needed.
Tags: caching, etags, squid, scalability, traffic, performance, aol journals, blogs
The good thing about this type of caching is that our servers are still notified about every request through validation requests, so we'll be able to track things fairly closely, and we're able to add caching without major changes to the pages.
The down side is of course that our servers can still get hammered if these validation requests themselves go up enough. This is actually the case even for time-based caching if you get enough traffic; you still have to scale up your origin server farm to accommodate peak traffic, because caches don't really guarantee they won't pass through traffic peaks.
We're continuing to carefully add more caching to the system while monitoring things. We're currently evaluating using a Squid reverse caching proxy. It's open source and has been used in other situations -- and it would give us a lot of flexibility in our caching strategy. We're also making modifications to our databases to both distribute load and take advantage of in-memory caching, of course. But we can scale much higher and more cheaply by pushing caching out to the front end and avoiding any work at all in the 80% case where it's not really needed.
Tags: caching, etags, squid, scalability, traffic, performance, aol journals, blogs
2006/11/17
Jonathan Miller: 破釜沉舟
Jonathan Miller wasn't a charismatic leader. But he recognized theneed to fundamentally change AOL's strategy, mappedout a new direction, and got people moving the way that he waspointing. Since last year, especially, he had been executing well andreally seemed to "get it". Giving AOL's services away for free thissummer forced the organization to focus on the new world rather thanthe old; a Rubicon crossing, or as Jon's Sifu might say, "Break the woks and sink the boats(破釜沉舟)". And as Ted notes, the strategy that Jon architected is starting to show good results.
Given all of this, Jon's departure wasa shock. Neither the communications to the rank and file nor to Jonhimself were handled well. There are plenty of rumors and speculationflying around. I hope that the Time Warner leadership team handles thesituation going forward with the openness and honesty that are due tothe people who have worked so hard to turn AOL around.
Jon, you'll be missed.
Given all of this, Jon's departure wasa shock. Neither the communications to the rank and file nor to Jonhimself were handled well. There are plenty of rumors and speculationflying around. I hope that the Time Warner leadership team handles thesituation going forward with the openness and honesty that are due tothe people who have worked so hard to turn AOL around.
Jon, you'll be missed.
2006/11/15
The AIM Network: AIM6, AIMPages, Buddy Feeds
I love launches. This week, we're launching AIM 6 along with a major upgrade to the AIMPages beta. And they work together!
The new AIM is a big improvement; I've been running the various betas over the past many months and they've been both rising in quality and slimming down in footprint. And the UI is finally reasonable: I can now once again edit my buddy list right there in the main window. And buddies now have a little (i) icon that tells you when your buddy has published something -- anywhere. Like blog entries! Profile updates! Or, if they've set things up, new Flickr photos, Diggs, Myspace or Blogger or Xanga updates, or any custom Atom or RSS feeds you care to add.
There are some problems: It keeps telling me about their away message status, and I don't really care that Kevin Lawver is away at lunch. And I see that Kevin posted a photo but there's no thumbnail in the feed... but this is a first release, we can fix these nits. (The feed data is available at http://buddyfeed.oscar.aol.com/rss-push/aol:buddy_feed?request=user&sn=<screenname>, and as an AIMPage module named "What's New" which I demoed at Widgets Live last week.)
There's a good review of all of this on GigaOM by Liz Gannes.
The only downside of all this is that I'm mostly on a Mac these days, and there's no Mac AIM 6 client right now. On the other hand, Adium plus a feed reader works pretty well too.
AIMPages has also added AIM Pages Buddies. I don't think this is the best name, but the concept is good. It's two way, meaning that both people have to opt in to it. And by default your AIM Pages Buddies are shown on your profile (so you really don't want your whole Buddy List showing up there). The invitation mechanism is easy: When you start to add, the system sends an IM to the buddy asking if they agree. A lot better than email, if they're online. If not, they'll get reminded with a little status link at the top of their AIM Page: "Buddy Requests (42)".
Aside: By default, for newly created profiles, only your AIM Pages Buddies can post comments on your profile. You can change this in the settings to open it up if you want to. On the other hand, it's also a way to get more buddy requests.
Tags: aim, aim6, aimpages, buddy feeds, social networks, launch
The new AIM is a big improvement; I've been running the various betas over the past many months and they've been both rising in quality and slimming down in footprint. And the UI is finally reasonable: I can now once again edit my buddy list right there in the main window. And buddies now have a little (i) icon that tells you when your buddy has published something -- anywhere. Like blog entries! Profile updates! Or, if they've set things up, new Flickr photos, Diggs, Myspace or Blogger or Xanga updates, or any custom Atom or RSS feeds you care to add.
There are some problems: It keeps telling me about their away message status, and I don't really care that Kevin Lawver is away at lunch. And I see that Kevin posted a photo but there's no thumbnail in the feed... but this is a first release, we can fix these nits. (The feed data is available at http://buddyfeed.oscar.aol.com/rss-push/aol:buddy_feed?request=user&sn=<screenname>, and as an AIMPage module named "What's New" which I demoed at Widgets Live last week.)
There's a good review of all of this on GigaOM by Liz Gannes.
The only downside of all this is that I'm mostly on a Mac these days, and there's no Mac AIM 6 client right now. On the other hand, Adium plus a feed reader works pretty well too.
AIMPages has also added AIM Pages Buddies. I don't think this is the best name, but the concept is good. It's two way, meaning that both people have to opt in to it. And by default your AIM Pages Buddies are shown on your profile (so you really don't want your whole Buddy List showing up there). The invitation mechanism is easy: When you start to add, the system sends an IM to the buddy asking if they agree. A lot better than email, if they're online. If not, they'll get reminded with a little status link at the top of their AIM Page: "Buddy Requests (42)".
Aside: By default, for newly created profiles, only your AIM Pages Buddies can post comments on your profile. You can change this in the settings to open it up if you want to. On the other hand, it's also a way to get more buddy requests.
Tags: aim, aim6, aimpages, buddy feeds, social networks, launch
2006/11/14
Gold stars for good feed readers!
Over the past few weeks, we've been rolling out support for proper cache control on the Journals blogging platform, which will help reduce both bandwidth and database load, and also make things faster in general. Last week we added ETag based cache control for both Atom and RSS feeds. Today I took a quick peek at our logs to see how things are going...The good news is that a lot of feed readers are being great citizens. Around 33% of our feed requests get satisfied with 304 responses, meaning that clients only need to do a quick validation that they have the latest content, rather than fetching everything all over again. Here's a quick list of feed readers, in no particular order, which are doing the right thing with our servers. Gold stars for everybody!
- Bloglines (http://www.bloglines.com)
- FeedDemon/2.0
- NewsGatorOnline/2.0
- NetNewsWire/2.0
- LiteFeeds/2.0
- http://www.squeet.com
- Firefox/1.5.0.7
- Thunderbird/1.5.0.8
- FacebookFeedParser/1.0 (UniversalFeedParser/4.1;) +http://facebook.com/
- Windows-RSS-Platform/1.0
- LiveJournal.com
- Planet GBT +http://planetgbt.priyadi.net Planet/1.0~pre1-terasi+http://www.planetplanet.org UniversalFeedParser/3.3+http://feedparser.org/
Google Desktop
Surprisingly, we actually have a lower cache hit ratio for Atom feeds than RSS ones... mostly due to one major crawler that seems to prefer Atom feeds and never gets a 304, presumably because it's never sending an If-None-Match header:
- Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)
Subscribe to:
Posts (Atom)
Suspended by the Baby Boss at Twitter
Well! I'm now suspended from Twitter for stating that Elon's jet was in London recently. (It was flying in the air to Qatar at the...
-
Update 6/2/2023: I was right . These are my observations for our local conditions (Santa Clara County, July 10-12, 2020), which to summarize... -
Last night Rachel Maddow talked about an apparently fake NSA document "leaked" to her organization. There's a lot of info t... -
Well! I'm now suspended from Twitter for stating that Elon's jet was in London recently. (It was flying in the air to Qatar at the...
