Atom feed updates: Pagination

One of the hidden changes from last week's release is the support for Atom pagination.  This will potentially let tools browse of the entries in a blog, copy them, archive them, search them, etc.  Technically, this means we're supporting the link@rel="first", "last", "next", and "previous" relations.  Get the current feed and follow the "previous" links until you run out of data; then you've got all of the entries in a blog, in standard Atom format.  And, we're valid according to http://feedvalidator.org.  Let me know if you see any problems.

Tags: Web Bumper Stickers

Our new entry tagging secret beta stealth feature might be a little difficult to see since it doesn't work on IE yet, though Joe did a great job with screen shots.  (Joe: It's not much of a stealth feature if you tell everybody about it, is it?)

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.

Tags: beta, tag, tagging, stealth

Whoops. Seriously.

This week, AOL accidentally started spam blocking email with "dearaol.com" URLs embedded in the text.  And then we fixed it.  Never ascribe to malice that which is adequately explained by... um... never mind.  I know of no conspiracy and the people running our spam filters are good folks, it's just sometimes the software they wrangle gets a little obstreperous.

(techdirt)

Code, and other laws... (part 2)

In part 1I talked about the ideal world where feeds were all clearly licensed. Sonow I'll turn to the real world, and I'll be very US-centric becausethis article is quite long enough as it is. You might want to skip tothe happy fun summary at the bottom.

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>
      <link rel="license" href="http://creativecommons.org/licenses/by/2.5/"/>
</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.

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.xml

which returns a simple XML document:

<?xml version="1.0" encoding="utf-8" ?>
<declared-license xmlns="http://example.aol.com/2006/aolfeeds">
    <link rel="license" href="http://creativecommons.org/licenses/by/2.5/"/>
</declared-license>

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.)

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.
  

None of this is black or white.  I shouldalso mention that I'm completely conflicted here, in that my companyboth syndicates and aggregates content and I'm directly involved on both sides. I'm coming at this from the viewpoint of someone trying to provideonline feed aggregation services where the end users subscribe to thefeeds; they're not being selected or screened by editors.  In othersituations other rules about default licences might be better. Explicit licences are definitely best to avoid problems down the road. Here are some other links I've stumbled across:  A basic practical primer on copyright and RSS. One re-aggregator's viewpoint (Palfrey).  Producer's viewpoints: Shelley Powers, Om Malik (here and here) .  Some legal discussion (with Wendy Seltzer, previously of the EFF, weighing in). (Feedburner already does CC licensing following the methodsoutlined above, except that they're using the creativeCommons namespace extension for Atom as well as RSS 2.0; consumers should look for either one in Atom feeds.)

Tags: Feed Copyright, Creative Commons, RSS, Atom, syndication

Buddy Updates for Blog Entries

Greg of aiminfo blogs about IM Triton release 1.2.37.2 :

"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!

Danah Boyd at AOL Mountain View

Danah Boyd just wrappedup a great talk about online social spaces here at AOL Mountain View(the podcast is up already).  She delivered information via firehose. Some random notes...

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.
  

MySpace did a big thing right: When people started 'hacking' HTML intheir own spaces, the creators let it happen, then made it easier byadding the features that people actually wanted to use, like soundfiles (for indie bands) and videos from YouTube. This means thecommunity is designing the service as much as the creators are; notjust putting content, but guiding much of the design direction, alongwith highly visible and passionate designers engaged with thecommunity.  Danah calls this Embedded Community Design. 

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