Friendfeed - nice service. I pulled this Atom Entry out of my Friendfeed feed:

<entry>
    <title type="text">Free as in electricity (via Blog)</title>
    <updated>2008-07-12T15:33:12Z</updated>
    <published>2008-07-12T15:33:12Z</published>
    <id>tag:friendfeed.com,2007:1d0c3524-1c88-d01e-5864-21953bef1ca1</id>
    <link href="http://www.dehora.net/journal/2008/07/12/free-as-in-electricity/"
       rel="alternate" type="text/html"/>
    <content type="xhtml" xml:base="http://friendfeed.com/">
       <div xmlns="http://www.w3.org/1999/xhtml"
       style="font-size:10pt;font-family:Arial,sans-serif;color:#222222">
          ...     
       </div>
    </content>
</entry>

Here's the original Entry from my feed:

<entry>
  <id>http://id.dehora.net/entry/2008/07/12/ea18ed947f5ba3e06ff02528f7e6b150</id>
  <title>Free as in electricity</title>
  <updated>2008-07-12T15:59:34Z</updated>
  <author>
    <name>Bill de hÓra</name>
   </author>
   <link href="http://www.dehora.net/journal/2008/07/12/free-as-in-electricity/" rel="alternate"></link>
   <content type="html">&lt;p&gt; ... &lt;/p&gt; </content>
</entry>

Some observations:

• The Friendfeed updated value happened a few minutes before mine did. It doesn't seem to be a multiple of anything, so let's assume it's a clock skew. What's interesting there is that Friendfeed's Entry could show up after mine in an aggregated feed.
• The Friendfeed Entry doesn't have an author element. The enclosing feed did have one, and the author is "Friendfeed", which means the author of that Entry is "Friendfeed", not me. I guess that makes sense. Or maybe it doesn't.
  
• Friendfeed added their own id. It's a Tag URI that has a uuid embedded. This makes me think their backend is decentralised or at least has the potential to be. The date part of the tag appears to be hardcoded to 2007.
• Friendfeed munged the original title with a suffix. They added a type of text/html as well. I wonder if that was derived or assumed. And I wonder what would happen if the source type was set to say, xhtml. In any case what's nice about my use of Atom here is that Atom Text constructs have well-defined escaping rules - unlike RSS2.0, there's no need to second guess the upstream provider (unless it's borken).
•  Friendfeed have copied the link@rel=alternate across. They've added a type of text/html. Again I wonder if that was derived or assumed. It would be interesting to have a JSON alternate.
• Friendfeed have written out their own content. That's fine; what's notable is not providing a summary of the original. Or maybe that's because I don't server summaries, just full content.
• Friendfeed use xml:base. It would be interesting to see if what would happen if relative URLs were in the source title, which seems to have been copied into their content.
• Friendfeed are not proxying or rewriting upstream links. A naive system would do something like that for tracking reasons, and eventually melt down under load. The only interesting redirect walling they perform is to route the "link to this entry option" on the site back to their permalink and not mine. The slug for the permalink is the same as the uuid in the tag URI.
  

But for a syndication wonk, by far the most interesting thing is that Friendfeed aren't using the Atom source element. The feed could have looked like this:

<entry>
    <title type="text">Free as in electricity (via Blog)</title>
    <updated>2008-07-12T15:33:12Z</updated>
    <published>2008-07-12T15:33:12Z</published>
    <id>tag:friendfeed.com,2007:1d0c3524-1c88-d01e-5864-21953bef1ca1</id>
    <link href="http://www.dehora.net/journal/2008/07/12/free-as-in-electricity/"
       rel="alternate" type="text/html"/>
    <content type="xhtml" xml:base="http://friendfeed.com/">
       <div xmlns="http://www.w3.org/1999/xhtml"
       style="font-size:10pt;font-family:Arial,sans-serif;color:#222222">
          ...     
       </div>
    </content>
    <source>
       <id>http://dehora.net/journal/atom.xml</id>
       <author>
         <name>Bill de hÓra</name>
       </author>
    </source>
</entry>

Not many people seem to use Atom source. It can contain the whole original entry, but the most useful parts to pass along are the id and the updated elements. Why? Well, aggregators and clients can immediately pick those out, tell you if you've smelt what the Friendfeed is cooking and mark it as read. In this particular case the fact that Friendfeed's outer updated date is ahead of the source might confuse some code, depending on the implementation logic. Possibly they should consider treating updated as an offset to the original Entry timestamp. It might not be precise relative to a particular server/system but globally it will be more accurate and the partial ordering would be preserved. You could also put the source author in there as well ;)

Wrong. Oops, big mistake. The atom:source copies over Feed metadata, not Entry metadata. The author element could be copied across in it was in the feed, but there's no way I can see to preserve the original id/updated pair if they are rewritten by an aggregator. Ben Darnell commented: "The spec's answer to determining whether you've seen an item in another feed is that atom:ids should be globally unique, so equal atom:ids are proof that two entries are the same. However, many aggregators don't trust the web to use ids correctly and end up generating their own." So I guess this means there's no way to track an Entry that has its id rewritten except through eyeballing feeds and searching for the URLs of the original atom:links. This feels like a gap in Atom spec maybe?