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
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>
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
<?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"
<link rel="http://journals.aol.com/comments" type="application/atom+xml" title="Comments feed for this entry"
<title type="text"><![CDATA[Blog entry title]]></title>
<content type="html"><![CDATA[ Hello World!]]></content>
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?
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
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.
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 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)
- FacebookFeedParser/1.0 (UniversalFeedParser/4.1;) +http://facebook.com/
- Planet GBT +http://planetgbt.priyadi.net Planet/1.0~pre1-terasi+http://www.planetplanet.org UniversalFeedParser/3.3+http://feedparser.org/
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)
We really want to get feedback on both the site itself and the APIs that we're exposing. Both are evolving rapidly and I anticipate that we'll be adding some new APIs there in the very near future -- there are a couple I'm going to be pushing for. So please, give us feedback, or just link to dev.aol.com and we'll pick it up.
In breaking news, our own Michael Chowla just won HCL's Sudoku contest and will be taking home a very nice trophy. I'll add the picture... as soon as the network actually lets my camera phone upload it... oh darn. Apparently the Ning demo suffered from some network issues earlier today too. Infrastructure!
Speaking of infrastructure: Amazon's Elastic Compute Cloud looks very cool. You could run a startup now with nothing more than a laptop and a table at a WiFi-enabled cafe.
Tags: web20, sudoku, ec2, amazon, infrastructure
On the other hand, the panel discussion was fun. We're certainly in early stages; we had four people on the panel, and four completely separate terms for essentially the same things (widgets, gadgets, modules, parts).
Link: Widgets Live! AIM Pages Blog Widgets Presentation (html).
PING 172.17.0.1 (172.17.0.1): 56 data bytes
64 bytes from 172.17.0.1: icmp_seq=0 ttl=64 time=188.881 ms
64 bytes from 172.17.0.1: icmp_seq=1 ttl=64 time=135.392 ms
64 bytes from 172.17.0.1: icmp_seq=2 ttl=64 time=74.55 ms
64 bytes from 172.17.0.1: icmp_seq=3 ttl=64 time=63.111 ms
64 bytes from 172.17.0.1: icmp_seq=4 ttl=64 time=237.2 ms
Especially Chapter 8: Resource-Oriented versus Service-Oriented Architectures:
The main event. We single-handledly take on the SOA, WSDL, and the WS-* stack: an enormous, multi-billion-dollar project that has alrady had about 25 books written about it. We believe this conglomorate will ultimately end up like CORBA, the OSI protocol suite, ATM, and other overengineered big-money flops; and that simpler, more flexible solutions will swallow anything good to come out of it.
In the spirit of comity and friendship, following the smackdown will be a section describing what REST services can learn from the SOA and take from the WS-* technologies.
Tags: REST, Web Services
Tags: widgets, widgets live, blogs, panel
Here's a bonus Easter Egg, just for fun. You can apply a theme to any Journals page by adding an argument "?skin=css url" to the page URL. Like this. Or this, or this... or anything over at the AIMPages themes directory. It shows a direction we're headed; not the end of a journey, but the start of a trip.
We've also updated our whitelist to allow more cool widgets to be put in your posts and About Me box. I just added one of the neater ones -- MyBlogLog's Recent Readers widget. I've put it on my sidebar as an experiment; is it cool, or just weird, to see your visits being tracked and displayed? (Hi Frank!)
Well, after a while I did get a free i-name, a contact page, and now it turns out I can actually use it to log in to something useful, to wit, the new OpenID Wiki. Turns out that the library used for the Wiki authentication automatically supports user IDs like =john.panzer; it just works. Which is of course the goal of the technology, and a good demonstration that user centric identity can become ubiquitous.
If-Modified-Since: Tue, 26 Sep 2006 21:47:18 GMTIf-None-Match, which passes an "entity tag" or ETag, is better to use and was designed to replace the If-Modified-Since header. (If-Modified-Since has granularity only down to a second, and can't be used to indicate non-time-based changes.) In our case we actually have two versions of our pages which can be served up, one for viewers and another one for owners. We really only want to cache the viewers' page.
When our server sees a request like the one above, it first does a quick check (in this case it'll ignore the If-Modified-Since and use the ETag) to see if the client already has the latest version; if it does, it returns a 304 Not Modified result. The big win is that this can be done very very quickly and efficiently, while building a 200KB web page takes lots of work. If the client doesn't have the right version, though, the server returns a 200 and sends new headers, like these:
Last-Modified: Tue, 26 Sep 2006 21:47:18 GMT
If you're obsessive with details you might notice that the modification date is the same as before, but the ETag has changed (the -ow:c has changed to a -c). When the second request was made, it sent cookies that told the server that the user was the owner of the blog. So the page is different and therefore the ETag is different, but the last date modified is the same. We're expecting browsers and caches to detect the change and refresh the page.
This all works fine... except for IE6 (and the AOL client, which uses IE6 under the hood). IE6 seems to see the Last-Modified: timestamp above and simply stop, ignoring the Etag: header and the fact that we're returning a 200 response with new content. I've sat and watched the data flow in and out of my Internet connection and verified that IE just drops the 60K or so of content on the floor, as well as the new ETag, and re-uses its old version. The only way to prevent it is to force a reload using ctrl-Reload, or clearing your Temporary Internet Files.
What this means is that if you change "who you are" by logging in or out, and nothing else changes, you will get a stale, cached version of your own blog's page. Which is certainly not good.
As of this morning, we're running with caching turned off on journals.aol.com but with a bug fix on beta.journals.aol.com. The bug fix is simple: Don't send Last-Modified: headers. So we only send back the Etag:
Etag: "1159307238000-c=2303"Which forces IE6 to pay attention to it, fixing the problem with IE6. IE7, by the way, works either way; go Microsoft!
This all means that we're not going to try to enable caching for non-Etag-aware clients and caches. Since non-Etag-aware seems to pretty much equate to old or buggy, and not having caching is just a minor performance hit, this seems to be a pretty reasonable approach in theory. The question now is, will practice accord with theory? We really need people to hammer on http://beta.journals.aol.com/yourscreenname over the next few days and give us feedback. See Stephanie's post: Like Magic, We're Back Where We Began... and please leave us feedback!
Update: The collective intelligence of the blogosphere is a mighty thing. In a comment below, Doc points at an open source plagarism detector from UCSB (my alma mater) that already does Internet searches. Hmmm....
Update: The audio is up on our podcast feed already!
So anyone who may be parsing our URLs -- be aware that the format has changed :). We will, however, do a permanent redirect from the old URLs to the new ones.
Authorization: GoogleLogin auth ...
Authorization: AWS ...
I know that GData uses 401 Unauthorized and WWW-Authenticate: challenge headers and I'm going to assume that AWS does too:
WWW-Authenticate: AuthSub realm="https://www.google.com/accounts/AuthSubRequest"
So, existing services are using the RFC 2617 framework; it's working for them; why not build on top of that instead of inventing new headers?
So, here's my new summary, which is shorter but more complicated:
- Support and promote feed standards for embedded licenses.
- Allow fair use for unlicensed feed content.
All of which makes embedding licenses in feeds even more important.
Tags: Feed Copyright, Creative Commons, RSS, Atom, syndication
This was also my first foray into the S5 slide show system. I gave up on PowerPoint when it refused to accept .PNG images. I mean, come on guys, it's only been about 10 years since PNG was introduced. Sheesh. S5 works great, though I would love to see a few more generic themes that I could snag and use without working on visual designs.
Tags: iiw2006, conferences, identity
There's a companion service, pingerati.net,to enable real time indexing; it's also a ping hub. The idea here isthat if you want to get updates about structured data from around theweb, you can register with pingerati and get their feed of pings aswell, without needing to go around and convince everyone to ping yourservice. For example, evdb will get auto-notified if you pingpingerati.net. Naturally, any existing Technorati feed update pings also get fed in.
Being a hub is nice.
Tags: microformats, search, pingerati, hCard, hCalendar, hReview, ping, hub
This feature allows you to combine several related tags into a logical grouping. So, for instance, you might combine the tags “hitter”, “pitcher”, and “fielder” into a bundle and call it “Baseball”. It doesn’t change anything about the existing tags, but does allow you to create another level of heirarchy. When looking at your bookmarks, del.icio.us will show this bundle and all the tags grouped under it as a separate section.This is really meta-tagging but explained in plain English with a perfectly sensible immediate end user benefit. Plus bigger benefits down the line if these bundles are shared.
Perhaps there is an optimal strategy for daily meetings thattreats them like insurance and adjusts them according to your riskforecast. If your project is bright red, maybe you need a one hourvideo conference every day with the full team. If you're green, maybe it's sufficient to have an optioanl 10 minute conference call. And something in between for the vast majority of projects. The goal would be to minimize your expected wasted time in a rational way.
Note: We of course do our level best to ensure that engineers are pulled into daily meetings only when they absolutely need to be there!
Greenhouse is particularly special because it's all about getting some sunlight onto some of the cool things that we come up with. Also, it has a monkey. Can't go wrong with a monkey.
At the moment, the blog aggregator seems to be hosed -- it's showing Yoel's post about 23 times. Stan?
Kaliya and others reviewing the Identity Timeline at the start of the workshop:
The lunch that AOL (partially) sponsored, from DeeDee's. Best meal of the workshop:
Dave Winer discussing OPML 2.0 and identity contact URLs with a bunch of very smart people. I am off to the side putting on a wise expression.
This slide is a cool vision statement of how identity URLs enable an entire open ecosystem:
Yan Cheng talks about the dimensions of identity. He convinces everybody that we're good guys. Maybe we should adopt a Googleian corporate motto: "Do good."
Circle time! I'm trying to learn the lyrics. Or maybe falling off my seat. Hard to be sure.
And last but not least, the AOL logo up on the wall:
We had a good discussion about interoperability with AOL's Yan Cheng talking about different dimensions of functionality which are, at least to a first approximation, orthogonal. For example, exactly how authentication is handled is mostly orthogonal to the issues of how public identity and reputation is handled. I do think that we need to talk about these things in the context of real world examples. It's the minor little things that trip these simple scenarios up -- like, how do we auto-discover authentication capabilities from a user without adding even more login steps?
It seems like this space is going into a consolidation/cooperation phase, where everybody agrees to work together using a few very basic building blocks in an extensible framework.
Tags are just labels that you can apply to your entries; since they're public, they're kind of like electronic bumper stickers. If you use Firefox or Mozilla, you can play with them on beta.journals.aol.com/<your screen name>. Otherwise, well, here's a little animation:
...and you can see the results below. I have no idea what "stealth" is going to link to, since right now it just does a general web-wide tag search. I think that's kind of fun, actually, but your mileage may vary. We're looking at various ideas, including having the links go to a blog-specific search page (but perhaps with links off to the general web search to see what other people have chosen the same bumper stickers). Also, we'll leverage the results to provide better categorization tools for your entries and blogs. It's pretty wide open at the moment. So if you have opinions, let us know.
Millions of feeds aren't explicitly licensed. Some can't be becausetheir generators don't allow for it. For others, the owner doesn'tknow or care about licensing. For unlicensed feeds, it's notreasonable to make the default assumption "nothing more than fair use"because there are millions of feeds out there whose owners want theircontent syndicated as-is (headline feeds with links back to content,for example). On the other hand, if you assume anything more than fairuse, you also need to be prepared handle exceptions. So how to do bothof these in a way that minimizes overhead and letsaggregation happen without lawyers while respecting copyright?
My take is that a reasonable default assumption is to assume the Creative Commons Attribution license only if the feed owner hasn't specified otherwise. Thismeans that by default, we'd assume that copying of feed content isallowed as long as attribution is given through an appropriatehyperlink. Then, provide easy ways to let feed owners specify a different license whenever they explicitly declare one.
If a feed owner is happy with the default, they need to do nothing. My senseis that this covers 98% of unlicensed feeds. For the remainder, a feedowner could go to individual aggregators and tell them explicitly whatlicense they prefer. They can always choose a completely restrictivelicense that allows only fair use for the general public. Or, they canchoose a noncommercial license. My take is that something equivalentto the current Creative Commons license chooser is sufficient.
Of course, what we'd all really prefer is for feed owners to put thelicenses in their feeds directly. That way, our AOL proxies and cacheswould simply pass the information along to clients, which would makeappropriate decisions about what to do based on the particularlicense. If we're dealing with a small number of well understoodlicenses, this is the easy part.
How should the feed licenses work? There's a pretty good page with reasonable recommendations at Creative Commons on the subject. James Snell's Feed License Link Relation works well for Atom and is pretty flexible:
<link rel="license" href="http://creativecommons.org/licenses/by/2.5/"/>.The Creative Commons RSS Module works for RSS 2.0:
<creativeCommons:license>http://www.creativecommons.org/licenses/by-nc/2.5</creativeCommons:license>.Both of these work with CC and other licenses and have been deployed in real implementations There's an RDF version for RSS 1.0 as well (cc:license).
Finally there's the RSS 2.0 <copyright> element, which is justplain text. But, given that some tools might allow people to put textin this field but not embed the other types of licenses, I think it'sreasonable to look for a known license URL in the copyright text aswell:
<copyright>Thecontents of this feed are licensed to the public under http://creativecommons.org/licenses/by-nc-sa/1.0/</copyright>If a processorcan't find any of the above licenses, I'm proposing that AOL feedconsumers fall back to a license based on an explicit list that AOLmaintains by feed owner request. This would be part of our feedinfrastructure. I see this working two ways. First, we would addmetadata to feeds which are requested via our feed proxies. For Atomand RSS 2.0, the two output formats we support, this would be anamespaced extension, aol:declared-license:
<aol:declared-license>It would contain a Feed License Link Relationindicating which license the owner specified to AOL. It couldpotentially contain multiple license links. It could contain othernamespaced elements in the future as well, but feed consumers canignore ones they don't understand.
<link rel="license" href="http://creativecommons.org/licenses/by/2.5/"/>
A client might also want to inquire about a feed's declared licensewithout retrieving it. For this, we could provide a simple REST API:
GET http://example.aol.com/declared-license/example.org/feed/atom.xmlwhich returns a simple XML document:
<?xml version="1.0" encoding="utf-8" ?>Note that non-AOLclients could potentially make use of this; you'd just have to believethat AOL is maintaining a good declared license list (the licensesthemselves are the ones the feed owners want to provide to the generalpublic, not to AOL specifically). We could even potentially sharethese lists between feed aggregators. An embedded (original) licensewould always override any declared license; this would let feed ownerseasily start embedding their own licenses in the future. (Should weeliminate any declared license as soon as the source feed startslicensing itself? I think so, but our legal team would need to weighin on that.)
<link rel="license" href="http://creativecommons.org/licenses/by/2.5/"/>
Finally, we'd advertise a variety of ways for feed owners to contact usand declare their licenses. There does need to be some sort ofvalidation step to ensure they really own the feed. As part of thehopefully painless process we'd ask them to pick from one of theexisting Creative Commons licenses. If these aren't sufficient we canadd other licenses but it's easier all around if people can agree on asmall set.
How about a real world example? Brian Alvey of Weblogs Inc. recently announced support for excerpt feeds, for example Engadget full vs. Engadget headlines. The full Engadget feed has the copyright statement:
<copyright>Copyright2006 Weblogs, Inc. The contents of this feed are available fornon-commercial use only.</copyright>Translating into license-speak, we'd get anAttribution-NonCommercial-NoDerivs license for the full feed, meaningno commercial exploitation, links back are required, and editing of the material is not allowed beyond fair use:
<creativeCommons:license>http://creativecommons.org/licenses/by-nc-nd/2.5/</creativeCommons:license>The excerpt Engadget feed has the copyright statement:
<copyright>Copyright2006 Blogsmith, LLC. The contents of this headlines and excerpts feedare available for limited commercial distribution. You may repost thisfeed to your site provided you link back to the original story, do notedit the material, and do not remove this copyrightnotice.</copyright>Translating intolicense-speak, we'd get Attribution-NoDerivs for the excerpt feed,meaning that commercial use is OK but links back are required and thematerial may not be edited:
<creativeCommons:license>http://creativecommons.org/licenses/by-nd/2.5/</creativeCommons:license>(I'massuming here that the restriction on editing applies to the individualarticles, not the feed document as a whole, since feed documents arenot intended to be kept intact in any case. This minor ambiguity goesaway with Atom's Feed License Link Relation.)
So far, so good. Having multiple versions does raise the question of how automated processors are supposed to find these feeds. I think that's going to have to be a followup post.
That's about it. In summary:
- Support and promote feed standards for embedded licenses.
- Treat unlicensed feeds as if under the Creative Commons Attribution license (see update)
- ...unlessthe owner requests something different, in which case honor theirrequest quickly for all your current and future products.
Tags: Feed Copyright, Creative Commons, RSS, Atom, syndication
"Buddy Updates allow you to view changes or additions your buddies make to their away messages, message boards and profiles. You will see a new icon next to the buddy in the buddy list when an update has happened: "
You can grab the latest AIM Triton here. What Greg doesn't mention is that this also works for blog entries made through Journals. So if you use the latest AIM client, you'll be notified about your buddies' latest blog posts. If you try it out, please let me (or Susan or Joe or John) know what you think. This only works for public blogs, the ones that you can find through AOL or Google search in any case, but it does give you an up-to-the-minute picture of what's going on with your buddies.
Oh, and we have an update for Journals going out tomorrow morning. After it's complete, one nonobvious change is that you'll be able to see the list of Journals someone publishes by going to their screen name on Journals (for example, http://beta.journals.aol.com/panzerjohn/ will give you a list of mostly test blogs). The page lists public blogs, plus any private blogs that you're a reader of. (Others are invisible.) Also, the page has a nifty search box where you can type in screen names to try to find their Journals if they have any. Again, let us know what you think. It's sort of a hidden feature right now in that you have to know to type in the right URL. So feedback is welcomed!
There were several reasons why Friendster faded, and some lessons.
- Conflictbetween the user community and the space creators (they wanted a datingsite, the users wanted to do a lot of other things). Lesson:Listen to the community; be flexible; adjust the business plan whenneeded.
- Servers buckled under load when it got too popular. Lesson:The technology has to work or people will lose patience and go to the competition.
- When Friendster started to try to go mainstream beyond the earlyadopter clusters, new users couldn't find any friends on the site so itwasn't useful to them. Lesson: Network effects work inreverse too. Start with small clusters and grow organically.
Best quote: "[Teens are] immune to bouncy visual overload." They'vebeen immunized to this by mass media. (What does this mean foradvertising as a business model?)
Last week, teens used MySpace to organize mass school walkouts to protest HR 4437. That's impressive regardless of your political views.
Tags: Danah Boyd, social software, online social networks
If an author doesn't explicitly give up all rights to a work, which might be a bit tricky,it's automatically copyrighted in the United States and most othercountries. Of course the same is true of web pages. But web pages aremostly intended to be viewed in a browser. Feeds are generallyintended to be syndicated, which means that their content is going tobe sliced and diced in various and unforeseeable ways. This makes adifference.
In what ways is an application allowed to copy and present a given feed's content? To start with, it can do things covered by fair use (*). There are some interesting issues around what exactly fair use means inthe context of web feeds, but ignore those for the moment. What aboutcopying beyond what fair use allows?
It would be awfully helpful if every feed simply included a machine readable license. For example, a <link rel="license"href="..."/> element(http://www1.tools.ietf.org/wg/atompub/draft-snell-atompub-feed-license-00.txt). We could then write code that follows the author's license for things beyond fair use.
Specifically, if a feed author wanted to put their feed content in the public domain, they would simply link to the Creative Commons public domain license which includes the following RDF code:
<rdf:RDF xmlns="http://web.resource.org/cc/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
The code here is a machine-readable approximation of "put this in the public domain".
Alternatively, if a feed author just wanted to require attribution,they'd instead use http://creativecommons.org/licenses/by/2.5/. Toallow copying for non-commercial use only, they'd use the popularhttp://creativecommons.org/licenses/by-nc/2.5/. This license meansthat the content must be attributed, and may be freely copied only fornon-commercial uses. Plus, of course, fair uses.
According to the Creative Commons proposed best practice guidelines,the non-commercial license would mean that a web site re-syndicatingthe feed would not in general be able to display advertisements next tothe feed content. Such an application could fall back to fair use onlyfor that feed (perhaps showing only headlines), or it could suppressads for that one feed. The main point is that it would know what itneeded to do.
So, in this perfect world where everything is clearly licenced, I thinklife is fairly simple. Let me know if you think I'm missing something.
In part 2 I intend to return to the messy real world and start complicating things.
(*) ...or other applicable national legal codes, since fair use applies only in the U.S. as Paul pointed out.
Tags: Feed Copyright
Tags: AOL I+Am+Alpha APIs
(Why a new icon to indicate feeds? Because "RSS" doesn't exactly scream "dynamic feed of updates for this web page". And lots of people our testing thought the tiny icon said "R55", which is even more useless.)
Rogers Cadenhead has a nice discussion here (see the comment thread too).
There's a debate over whether this icon should indicate an action (subscribe to this feed) or be a link to the feed resource (see the feed, and maybe subscribe). I personally don't think this is a huge issue, as long as a user isn't left staring at XML source. If an application only lets you do one thing with a feed, jumping directly to subscribing seems like a good idea. If you can do multiple things, give a menu of some kind (like Journals does) or a preview with options... humans can figure it out given reasonable feedback. Machines can't, but then they're not looking at the icon, they're looking at the <link rel="alternate" type="application/atom+xml" ...> markup in the page header.
Also, they're called "feeds". Doesn't matter if they're RSS 0.91, RSS 0.92, RSS 1.0, RSS 1.1, RSS 2.0, RSS 3.0, or Atom. And it really doesn't matter that they're in XML (well, except for RSS 3.0 :) ). What matters is that you just look for the if you want to keep track of what's new. Simple.
The unconference itself was good. A lot of good sessions conflicted, so I had some quandaries; but I think I made the best locally optimal choices possible. No regrets. The WiFi was good (better than most conferences with 250 people in a single room) but still not perfect. But it wasn't too bad since there was little need for a backchannel.
- Programming, done properly, is not a production activity that can easily be separated from product design. If it could be, it's basically rote work that can and should be automated. The non-rote work that programmers should focus on is all about figuring out how to hack the universe in order to deliver superior benefits to the customer. Which is part and parcel of product design, which is why those small, cross-functional teams are so valuable.
- A big factor in game development and web design companies' successes was sheer volume and high competition. There are plenty of terrible user experience in both camps (books have been written), but the industries have thus had a chance to learn from lots of successes and failures and iteratively improve.
- Nit: The benefits summary is great -- 98% success vs. 18% success is a great statistic that can get business people to sit up and listen. But y'know, this needs to be backed up with specific references to really pack the necessary punch.
I hope we'll be able to do some more interesting things and help contribute to Dojo as well.
(*) OK, technically I'm a manager, but they let me wear the engineer hat sometimes.
Folksonomies: Tidying Up Tags?
"Thisarticle looks at what makes folksonomies work. The authors agree withthe premise that tags are no replacement for formal systems, but theysee this as being the core quality that makes folksonomy tagging souseful. The authors begin by looking at the issue of "sloppy tags", aproblem to which critics of folksonomies are keen to allude, and ask ifthere are ways the folksonomy community could offset such problems andcreate systems that are conducive to searching, sorting andclassifying. They then go on to question this "tidying up" approach andits underlying assumptions, highlighting issues surrounding removal oflow-quality, redundant or nonsense metadata, and the potential risks oftidying too neatly and thereby losing the very openness that has madefolksonomies so popular." Commentary by Marieke Guy and Emma Tonkin,UKOLN. [D-Lib Magazine]
(You gotta hand it to the old-school Digital Library people.)
Empirical evidence suggests that tagging is most useful when public andshared. But why, exactly? Caterina Fake, in a panel atSyndicate, noted that people on Flickr get to "ride free" on top ofcompulsive categorizers. I think this is certainly part of it,and maybe tagging is good occupational therapy too, but I have a gutfeel there's more to the story.
My fifteen month old son is an inveterate tagger. His tag cloud looks something like this at the moment (somewhat elided):
airplane água ana bird book bulldozer bus bye choo-choo-train dada dog down mama phone tractor truck up wow...which I know because he tags things repeatedly and excitedly,especially when someone else is around. And I think this is thekey point -- this is a natural behavior, and a social one. (He'lltalk to himself, but it's really second best -- he wants to share hisview of the world with other people!) And of course it'saccompanied by pointing -- the original hyperlink.
That's as far as I've gotten. Fortunately, Rashmi Sinha, in A social analysis of tagging,does a great job of analyzing exactly how tagging facilitates socialinteractions. Go read it. Also, read her earlier cognitive analysis of tagging as well. Both great forays into the "whys" of public tagging.
I think this all suggests that private tagging might be useful in thesame way that talking to yourself might be useful (yes, sometimes, butnot a primary use case). More interesting is social-but-privatewhere you share with a limited number of people; this is more difficultto do well than either totally private or totally public; is itvaluable? How? When?