Readers want to find new content. They seek relevance, freshness, and community. This mirrors the three pillars of social sites I highlighted back in 2009, and echoes that readers want intriguing views that mirror their own preferences. Like I'd predicted in 2006, the Web has become a divided place, where we all flock to our groups of like minded people, and disavow opposing views, but we still are eager to find more who reinforce our position. We still crave new friends and stories and we want to find them quickly.

So how good a job do these apps and sites do of surfacing new people and ideas? Do they have an aggregated site with highlights and popular people or posts? Is there a place to find more obscure viewpoints and new voices?

4. Consumption

Since the smartphone revolution, kicked off by Blackberry and the iPhone and now led by Android, more people are constantly connected and reading news from their mobile devices. In many countries, the mobile device is the only window to the Web. Does the content flow well for mobile consumption and new ways to navigate from screen to screen, update to update? Or is it best suited for a leanback tablet experience or for the desktop?

What typically happens with content platforms is the content fills the available container. Twitter is a clear 140 or 280 characters. Social hubs like Facebook and Google+ favor large photos and a short introduction. Instagram is all about the photo with a small description. Blogger and WordPress and Medium are as long as you want to go. One has to consider if users and screens keep up.


We've Come a Long Way from Aggregating Streams and Sharing the Web

As content started to be created in a wide array of social sites, aggregation services like FriendFeed helped bring people's streams together. Bookmark services like Delicious helped people save the highlights from the Web and amplify the world's favorites. Users voted up posts from Digg and passed them along with StumbleUpon. The most voracious consumers lived in Google Reader and didn't miss a single post from the RSS feeds they were subscribed to.

It was too good to last.

The largest social platforms were not content in simply being links to external sites. Facebook focused more on original content shared on the platform, with less priority given to send traffic off site. Google Reader shut down, and while Feedly and others stepped up, the world of RSS never recovered. Delicious died. Digg is a shadow of itself. FriendFeed was obliterated. LinkRiver closed. Socialmedian closed.

In the wake of all these gateways' demise, taking content from the open Web and getting it in front of new viewers is more challenging. While I've always said you need to be where the users are and can't force them to come to you, what could be automated is now requiring manual intervention at practically every step.

Just What Am I Talking About?

The alpha and omega, yin and yang of social outlets (for text, anyway) are Facebook and Twitter. Facebook is much bigger and much more profitable, but don't get distracted. People creating content for the Web also need to make sure that content fares well downstream on Facebook and Twitter. You can write it for the open Web, but you then have to take explicit action to share the content downstream - or set up automation to either site, usually backed by RSS. At that point, whether you get discovered or not is up to each site's algorithm, which has leaned more in favor of implied interest rather than chronology of late - meaning you can see viral content from hours or days ago before you get the newest stuff.

On a mobile phone, notifications are the holy grail of getting someone's attention. (See: Life by Numbers and Notifications from 2014) It's not uncommon to get notified when someone tweets, but it's very uncommon to ask for a notification when a site makes a post.

In parallel, the feedback loop from such networks, as well as Instagram or others, is near instant and acts as an incentive for the author to initiate their content on that silo natively. Post a 20-tweet storm to Twitter, and immediately start seeing those likes and retweets roll in. Post a story to Facebook and wait for the Likes and comments. Post a news story or a blog post, and ... wait. Wait for visitors in Google Analytics? Wait for the post to be shared downstream? Wait for the story to be indexed in Google News and search?

The elimination of Google Reader, FriendFeed, and Digg as amplifiers of Web content, alongside the attention absorption by Facebook and Twitter makes it harder for Web authors to get visibility - and they they aren't dropping their content into the real time stream.

So What Does the New Flow Look Like?




In 2009, it seemed pretty easy to me. Post on the blog. RSS would take it to FriendFeed and Google Reader. FriendFeed would post to Twitter. Twitter would post to Facebook. Then I'd run around and answer comments wherever they were distributed. (More on distributed conversations from 2009)

Now, I can still post on the blog. And the RSS link is the same. I even get the small bump of engagement on Google+ from the blog's page automatically adding my content there. But then, to make sure I cover all my bases, I then make another share of the same content to Medium, for those who love their site, and I've even found good engagement on LinkedIn, by making a third post of the same content on their channel. It's a different audience, but, if on topic, they share and engage.

So that's three posts. Meanwhile, I still have to share the story on Facebook and Twitter separately, hoping that someone will break their consumption flow and engage on my content downstream.

It feels like more work to get less return. And yes, I recognize that some may not miss FriendFeed because they never used it. Maybe others think Digg got replaced outright by Reddit, and gains similar traffic. Others prefer Hacker News. So aggregators do exist, obviously, but hubs aimed at surfacing new content, as opposed to highlight content on the site and keeping readers there, have declined.

To properly make the Web as desirable and viable a platform for publishing, we need to work together to fix the distribution and discovery gaps, make content fantastic on mobile for creation and consumption, and allow for engagement that is as simple as a Like. I applaud (there's the joke) Medium's approach to reward users with claps, for at least they're trying something. We should all be trying.

Disclosures: Yes, I work at Google. Sometimes, I help the Blogger team. I used to work on Google+ and have many friends on those teams still. I miss Google Reader every day. FriendFeed too.

For those who believe strongly in a future of federated social networking, not owned by the large Web brands, the perceived lack of success from existing social projects, including Diaspora, Status.net and others has been extremely frustrating. Darren Bounds, cofounder of the ahead of its time social Web pioneer Cliqset, aims to do something about it, working hard on his second act, called Glow, a distributed social infrastructure aimed at closing the usability and feature gaps in today's federated systems. The launch of this new system is only a few weeks away.

As he describes it, federated protocols and standards often get in the way of building a pleasant user experience, which makes supporting important features like global people discovery, global content search and anti-spam practically impossible, as no information exists in a single place that's easily analyzed. The goal of Glow is to deliver a distributed alternative to Twitter or Facebook, while still delivering full support of their feature set, with no sacrifice to the user experience, while still keeping data ownership in their hands.


Glow looks much like existing platforms, from FriendFeed to Facebook and Twitter, consisting of aggregate network activity, status updates, and nested comments. When creating content, users are able to organize their followers into a number of predefined groups, and you can dictate which group will receive it, keeping the content private to only those on the intended recipient list, unlike Twitter's all public or all private approach, and more similar to Facebook's select distribution and lists, which have proven difficult for most users.


At launch, Glow will offer a centralized option, as well as the opportunity for you to launch your own dedicated node, the equivalent of running your own single user copy of Twitter that looked and felt just like it does on Twitter.com, with the same users and experience.

From a feature perspective, Glow will support all the features of a modern social network, with the usual status updates, photo and video sharing, implementing the "follow" model, along with likes, mentions and comments. Additionally, the service is location-aware, which brings forward its own opportunities. What it does not do is aggregate content, a hallmark of Cliqset and other sites, like FriendFeed.

"Glow is an attempt get us a few steps closer by created a system that behaves as users have come to expect while increasing privacy and user control in the process," Darren wrote me in an e-mail. "Glow itself is not a federated system, it is a hybrid architecture combining aspects of centralization with that of decentralization."

True to Darren's background, which featured early implementation of Web standards like Pubsubhubbub and Salmon with his Cliqset effort, Glow will come with a robust API for developers to create applications on to, assuming user authorization. One example Darren gives is the option for users to provide access to their data in exchange for more personalized advertisements (which we've discussed often).

While Darren says Glow itself is not a federated system, those looking to set up their own Glow nodes can do so - much like Status.net, giving them full and complete control over the content. Glow is heavily tied to the Amazon cloud, helping keep costs free to users and low to Darren.

"Basically, if Twitter and Facebook had a great looking and highly intelligent child together who grew up to solve world hunger, it would be Glow," jokes Darren, who says that the product is still in the realm of personal experiment, more than an actual business. The project is being completely self-built, and Bounds hasn't yet taken any funding.

While Status.net and Diaspora have made new in the past for their approach, most federated systems have put technology ahead of the user experience, and have suffered in adoption. Glow is hoping to achieve the benefits of federation without sacrifice of technology features or user experience.

"I've taken many of the best features of Facebook and Twitter and combined them with some of my own special sauce," Darren says, "The result is a reinvention of social network architecture with none of the user complexity of systems that have come before."


In future enhancements, after initial launch, Glow content will be organized into two types - user content and publisher content. Its architecture ensures that user content is created by people and not bots, and a publisher marketplace is being designed so organizations can push content and build community. Publishers will be organized much like Apple's App store, with categories and featured communities.

Darren is nothing if not ambitious. Cliqset, while it didn't attract massive the massive user base it deserved for all the work put into it and pioneering of leading-edge technologies, was always well respected for its forward thinking. Glow, marinating at http://glow.io, should be just as forward thinking, but instead of pushing people into a single domain, it's allows people to create their own instance, run it anywhere and own their own data. It's all about putting the power of social networking back in the users' hands, with real privacy controls and simplicity.

Taking on Facebook, Twitter and Google in the fiercely competitive world of social networking and community building is a tremendous challenge that can be practically impossible to overcome, even with superior technology leadership and adherence to federated open standards. Cliqset, the wildly innovative social networking aggregator that was among the first pioneers to adopt Pubsubhubbub for real-time updates, and Salmon for cross-network comment posting, faces a murky future with news today that the company's founders, Darren Bounds and Charlie Cauthen, are going to be leaving the company, following an unsuccessful round of funding.

Despite a number of smart moves to make the site increasingly useful, such as the launch of social search in September, and the addition of Groups and Activity Streams in January, the site struggled to grow a consistent and growing community of users, with a short-lived Turkish invasion drawing a traffic bump and some amusement.

Speaking with Darren today, he said that he and Charlie are not moving on to a new project, nor have they sold the company, saying as founders of the company, it didn't seem appropriate to seek out other opportunities while simultaneously growing the site. But there are no regrets about the adherence to cutting-edge open standards with the site, which were ahead of practically any other service on the Web.

"A federated social Web agenda at Cliqset is something we chose to promote," he said. "The open standards aspect is something I believe is still the future. The roadmap to getting there is going to be a little longer than we would have liked. But where these standards can be implemented and improve efficiencies, they deliver real value."


As I wrote a year ago in a post on the 3 social pillars needed for any successful network, one needs to find leading technology, community and relevancy to make a site a must-visit each day. For Cliqset, their technology was never in question, but scrapping for users was a challenge that didn't find a great deal of traction. Darren agreed.

"In order to build a community, you need massive differentiation today," he said. "It's fairly obvious in hindsight. Projects I would be working on in the future would be leveraging the existing social graph, and the need for success wouldn't be contingent on relationships and community within itself. In no means do I think Facebook is impenetrable and somebody can't build something to compete with it, but it's not an easy task."

There are no plans to shut down Cliqset.com immediately, as the company's investors have opted to keep it up and running, despite a lack of engineering and operational support. In the event the service were to be acquired, Charlie and Darren could theoretically be pulled back in, but that scenario is unlikely. As I have been saying for a year aggregation is great in theory, but sites like FriendFeed, Cliqset and Arktan haven't been able to find a unique voice that makes people go their way instead of the original sources of content - Twitter and Facebook. I am eager to learn about the team's next move - they're very sharp and were focused on pushing open standards forward. In an ideal world, their work will not have been in vain.

Thanks to advances in the Web's real-time infrastructure over the last few years, our acceptance of latency or delay in discovery has practically been eliminated. We don't want to wait minutes or hours or days for news and information, and the freshness of content is essential. Often, when people want a near-instant reaction to world events, they're not looking to a filtered editorially driven source, such as CNN or Yahoo! News, but instead, they are looking to social networks like Twitter and Facebook, and often blogs, to get the very latest.

This drive to be completely up to date has led to the development of tools that drive instant notification of "matches" to saved queries. Early in Twitter's infancy, one had the option to "track" a word and get instant notification of its being tweeted. But due to Twitter's rapid growth and some infrastructure holes, the feature has long since been dead. In its place has risen third-party tools and products that tap into Pubsubhubbub, a real-time notification protocol powering most of the world's blogs today, and many different content sites.

Among the most aggressive promoters of Pubsubhubbub and real-time notifications has been Julien Genestoux of Superfeedr, an infrastructure for real-time parsing of feeds in the cloud. Superfeedr recently launched a "Track" tool to instantly find Atom-based entries that match keywords pushed to a developer's application.


One of the simpler and more interesting applications of this tool that I have seen is called Supertrackr. Developed by @Harper, Supertrackr operates within any Jabber-based IM client (or Google Talk), and lets you follow or remove keywords, via something of a command line, and get updates instantly. The app taps into Google's App Engine and Superfeedr to drive results into your chat window as new entries.


For practical purposes, you probably don't want to "track" popular terms like "twitter" or "android" or "e-mail" because your chat window from Supertrackr would get flooded and you would have new entries before you even acknowledged the last ones. I tried, and it works, as advertised. Operating Supertracker is as easy typing "/track word" to follow a term and "/remove word" to stop. So if you are in a Jabber-based IM client or use Google Talk often, you could be leveraging Supertracker to find all URLs discussing hot topics, or following your company or brand.

Twitter may not have brought Track back, despite Steve Gillmor's insistence they do, but other developers are filling the gap to get us closer to that monitoring utopia of instant notifications on anything from any source anywhere. Check out Supertrackr at http://www.supertrackr.com/ or Superfeedr at http://superfeedr.com.

The world of news personalization powered by RSS has been very interesting over the last year or so, with innovation coming from companies such as Lazyfeed, my6sense, Feedly and tweaks to Google Reader, including its "Magic" feature. One personalized aggregator, called Guzzle (which I first covered in July of 2009) has gotten less visibility, but the company is hoping to change that with two major updates - including the refresh of its news aggregator, and the introduction of an iPhone app - to let you get news on topics you have selected while on the go.


How you get news in today's world of streams varies by site. RSS readers primarily ask you to bring your own feeds. Social networks let you follow people. Some sites, like Regator, show you news from select sources by topic. Lazyfeed and Guzzle show you updates by topics you have picked, and the pages are regularly updated. But Lazyfeed doesn't yet have a mobile application, and Guzzle does. True to form, it quickly captured top stories on the topics I'm most interested in, and lets me view them one by one in the browser.

Guzzle's back-end has been completely rewritten from its 2009 launch, and is now powered by PubSubHubbub, thanks to support from Superfeedr. Every time a monitored feed publishes a new article, it is parsed by topic and assigned to the categories you may be viewing. This is similar to the work the late Socialmedian pioneered in 2008, but Guzzle has a portal-like interface to see the updates, reminiscent of My Alltop.


Guzzle's iPhone App Sorts By Topic
Interesting features of the new Guzzle? The product keeps track of every article published, and you can search its archives. You can also display news in an expanded mode, like Feedly, with large images (on the desktop version anyway).


Viewing Stories On Guzzle's iPhone App
While the desktop version of Guzzle is free, the iPhone application is $1.99. (get it here) If you don't mind parting with two bucks, Guzzle on the iPhone is a quick way to get caught up on the topics you're monitoring while mobile - and is an alternative to the personal prioritization of my6sense or the editorial sifting performed by Regator.

Guzzle also is transparent in terms of the sources that power its database. You can see them all here or can suggest new ones that haven't made the list.

Disclosure: my6sense is a client of Paladin Advisors Group, where I am Managing Editor of New Media. My comments on the company's product are always independent, and do not pass their way in advance.

For those of you who follow the @lgstream Twitter account, fueled by my shares from Google Reader, in addition to Delicious bookmarks and blog posts, the flood slowed to a mere drip over the last week, as the service behind its automation was stopped cold, due in part to its own success. The Reader2Twitter application I first featured back in September, which saw an update in February to support Buzz entries to Twitter as well, exceeded its AppEngine quota and ground to a halt on the 12th, leaving its users high and dry in the meantime. With the newly-called Google2Twitter down for the count, all that hit my @lgstream account were the rare bookmarks and posts from here - making me look more self-centered than usual. As of tonight, however, the stream is back in full, having been reenabled.

When faced with the outage, Google2Twitter's author explained that the once-small application had outgrown its 1GB datastore, and required an upgrade to a paid version of Google's AppEngine. But paying from China, where he lives, is no easy feat. In the meantime, he suggested it could be open sourced at some point, and he was going to work out a way to get the project funded.

After six days of downtime, which stopped my stream, streams of my clients, and many others, the stream was unclogged tonight and data is flowing again. Interestingly enough, the author is hinting at bringing on yet another supported service, Blogger. In a quick tweet tonight, he wrote: "the web interface of Reader2Twitter has been restored. I am going to support blogger2twitter later." On the Blogger platform, this would be of benefit to me, although my routing through TwitterFeed already does a fine job.

I'll be checking in with the app's author to see if this is a one-time blip, and what measures will be taken to avoid problems in the future, but for now, I'm just glad it's back. To see my stream through Twitter, don't forget to be subscribed to @lgstream. I share the best of the tech Web so you don't have to read everything else. You can watch Google2Twitter at @gr2t.

As Google Buzz users discover their own approach to using the service, and being selective as to which programs they pull into the site, many have been dissatisfied with the way Buzz has handled Twitter. Unlike other aggregation services, including Cliqset and FriendFeed, Buzz's imported tweets are not imported in real-time, and can seem very disjointed - made worse by their being imported in clumps. Today, one Googler explained they were going to solve the clumping issue in what was termed a public experiment, making things "less awful" in the interim before more capabilities are released, including filtering of imports by source - a popular option seen on sites like FriendFeed and Facebook.

Why Buzz does not pull in tweets in real time is extremely curious, given Google's much-publicized relationship with Twitter, their focus of late on recency in search, and of course, Buzz's centering around standards, such as PubSubHubbub, a big player in the real-time world. That Twitter does not support PubSubHubbub is obviously one contributor, but other services have managed to find a way to get Twitter updates with practically zero delay, through leveraging Twitter's APIs. The result is a truly unsatisfactory experience, contributing to many people removing Twitter as a service feeding Buzz.

The way Buzz polls Twitter for updates now can mean older updates get pulled in as new along with more recent items. To date all "new" updates were added concurrently, but now they will be redistributed using the timestamp of the tweet from Twitter, in effect shuffling those updates throughout the network. This will make Buzz's mysterious "unread" counts even less relevant, and should be seen as a band-aid.



Josh Wills, an engineer on the Buzz team, explained:

"Personally, I really like Twitter, and I want better integration between Twitter and Buzz. My hope is that this is a temporary change until we work out a way to play nicely together that is beneficial to everyone."

Josh went on to say that the changes were intended to "make things less awful" while things get "worked out" to make the tweets appear in real-time. Whether that's a business development decision or an engineering one, to make things "play nicely together" was not explained, but he added that he believed "real-time twitter updates don't make sense w/o the highly-anticipated source filtering."

The ability to hide sources, such as Twitter, from one's feed in Buzz will be as important as it has become to hide services in FriendFeed, or to stop seeing Farmville updates in Facebook, should you not be interested. While Buzz has been fairly close-lipped in terms of talking about future features, Josh's comment referring to the filtering shows it's on their radar, and no doubt coming, rather than being speculated about endlessly by hopeful users.

Older Tweets that do enter Buzz can of course be made more prominent if they gain conversation, and therefore, get bumped to the top of your feed - but from what I've seen, most engagement comes on native items on the network.

While the mass broadcast of status updates across multiple networks is something done best in moderation, the opportunity to distribute one's RSS feeds, from a blog or any other source, to potential viewers, no matter where they are, is core to the nature of the technology itself. Today, Ping.fm, the Seesmic-owned utility that allows for multi-network pollination, announced a new feature that gives RSS feeds the same flexibility as traditional status updates.

The solution is powered by Superfeedr, the real-time cloud based feed parser and publisher who I have long been bullish on thanks to their support and promotion of Pubsubhubbub, a protocol behind real-time data transmission from network to network.

With Superfeedr having already proven capable of acting as the back-end for real-time RSS distribution across the Web, Ping.fm's turning to Julien Genestoux and team makes logical sense, rather than trying to reinvent the process. Now Ping.fm is much more than a massive broadcaster of status updates, but a vehicle for RSS too.

See the official announcement here: Ping.fm Provides RSS Support

In what Google's Brett Slatkin termed a "small foray into productivity software", the developer best known for his work on the PubSubHubbub protocol released a note-taking application for journalists and researchers, featuring rich text, tagging and built-in privacy controls that keep notes available only to the creator. The product, titled LedeLog, runs on Google's cloud infrastructure, and auto-saves progress every ten seconds, so vital notes don't get lost. As simple as it sounds, it is robust enough to serve not just for its intended audience, but it looks like the beginning of new word processing or blog authoring tools. In fact, just for testing purposes, I authored this post on LedeLog.

The product's name derives from journalist's use of the term "Lede", which refers to the lead paragraph in any story, and says it is built for the workflow of modern journalists - but could work for anyone who wants to take down notes and save drafts with tags that are searchable.


When I am interviewing somebody for a story, or dictating notes in a meeting or event, I tend to simply open Apple Mail and tap out my data there - a byproduct of my getting used to older blog platforms from yesteryear that lost my data if the Web browser froze (although Blogger autosaves now). This results in an undesirable list of untitled drafts in my draft messages folder, sorted only by date - certainly without any tags. Going back a full decade to my time at the Daily Californian at UC Berkeley when I was a reporter in college, I similar wrote out my notes in Nisus Writer, an archaic word processing system for the Mac. It's highly likely that many journalists today, provided they aren't using a pen and paper, are typing out their notes in Microsoft Word - so you can forget about tagging or searching those documents. LedeLog, though new and raw, could be an interesting alternative.

For any journalist who wants to keep their sources secure and their notes safe, LedeLog is a step above saving any of that content on a local disk. LedeLog "ledes" are saved in the Google cloud (I assume powered by AppEngine, where Brett spends most of his time), and are accessible only through one's Google Account or OpenID.


Unlike many startup projects, which release in beta with no users, it sounds like LedeLog has already proven itself in the field. Its description in the Google Apps Marketplace says "LedeLog has been in constant use by professional journalists since January 2009." The Marketplace description also says the product is free for the next three months and may have further pricing information after that point. Including the product in the Google Apps Marketplace, in the document management category, enables companies who have set up Google Apps for their domain to deploy LedeLog for their users.

The media hasn't been given too many helping hands of late, and LedeLog isn't designed to make unprofitable businesses profitable again. But it is a very handy tool for note-taking, search and security. It's another peek into a world without Microsoft Office, where documents can be created in the cloud and shared outward. Every LedeLog can be e-mailed to an external address, such as an editor. Brett's initial notes on the product suggest in can handle the management of hundreds of Ledes easily. You can give it a shot at LedeLog.com.

If you haven't seen a lot of applications built in the last few weeks that leverage the Google Buzz API, it's because there aren't any. In fact, Google hasn't yet rolled out any API for Buzz. According to the company, this isn't due to any backroom dealings where they plan to introduce proprietary code and hooks that tie activity to their platform, but instead, because they wanted to be sure they could first build a product that in fullness leveraged open Web standards, and start with that foundation to deliver an interoperable system that could continue to function even if Google were to "disappear off the face of the earth".

In a presentation to the Silicon Valley Google Technology Users Group last night, held at the Google campus, DeWitt Clinton, a software engineer for the company, talked to developers and other tech enthusiasts about the company's API strategy and approach to Buzz, and explained that Buzz is designed not to increase lock-in to Google, but instead, to leverage open technologies that will let data flow to and from sites without central ownership. While a Buzz API will eventually be released, it will leverage the same open standards that power it today.

"The first principle of Buzz is that we can build this on protocols that are open and free, but not centralized," DeWitt said. "Can Google disappear off the face of the earth and Buzz still works? We need to make this data federated and distributed."

On the day Buzz launched, I referenced much of the foundation for Buzz in a quick article about the open tools and APIs that "make Buzz hum". But last night, DeWitt expanded that story to include 9 major open APIs, briefly outlined below.

1. Atom

DeWitt called Atom "the lingua franca of the programmable Web today", explaining that Atom contains entries that are "well structured", and include source entry, GUIDs that enable deduplication, and specification of the content type. He said, "You are able to pass rich data in that Atom feed in a way that is more specific than other feed types."

2. AtomPub

DeWitt said AtomPub "has become the most popular paradigm for restful APIs on the Web." AtomPub expanded the original Atom format to include the ability to both create and update feeds, not just passively read.

3. ActivityStreams

ActivityStreams essentially watch users' activity and can specify rich verbs and actions within those feeds. This enables feeds for all comments posted on Buzz, all likes, or even alerts that one person following you on Buzz also follows you on another network. DeWitt's examples hint at future developments for the platform, as these specific feeds are not yet clearly visible.

4. Pubsubhubbub

Much discussed here on the blog, Pubsubhubbub reduces the need for sites to poll for updates, and powers real-time updates between services. DeWitt reiterated "the hub is decided on by the publisher" and "there is nothing Google-specific about that.", saying that the infrastructure and plumbing for Buzz has been laid for the last few years. Pubsubhubbub has been pioneered by Brad Fitzpatrick and Brett Slatkin, both Google employees.

5. MediaRSS

Developed by Flickr, MediaRSS syndicates rich media through both RSS and atom feeds, creating a structured namespace inside RSS for content and a thumbnail. Buzz leverages MediaRSS, letting you pull rich content, like Flickr photos, into the platform. Of course, PicasaWeb, a Google property, also supports MediaRSS.

6. OAuth

The product of engineers from all corners, including Twitter, OAuth was engineered "to solve a vexing problem in the industry," Dewitt said, explaining OAuth prevents the need to ask users for their name and passwords on third party sites, acting as a delegated authorization protocol that gives permission to the application. Google Buzz, like Twitter, leverages OAuth to provide authenticated access to your data.

7. WebFinger

A new-age version of the old command-line prompted, text responding Finger protocol, WebFinger aims to be a way to get public information tied to an individual, through their identity, assigned to an e-mail address. "We want people to identify themselves, and we want people to discover people," DeWitt said.

WebFinger is similar to the strategy of OpenID, but OpenID hasn't had massive adoption by end-users who have found it unwieldy. WebFinger, aiming to be less arcane, enables the independent nature of Buzz, helping to federate the data and distribute it by domain, owned by the end user. DeWitt said, "The profile lookup and notification mechanism can be in the hands of the user being addressed."

8. Salmon

Still in earliest stages of development, Salmon is an extension or replacement for the old PingBack model that had blogs informing the other about references or links. This "flawed" model only provided minimal data, and could not be verified, letting me send PingBacks anywhere I wish if I chose. Salmon's goal is to leverage what's being called "Magic Signatures", signed with a public key to prove and verify linkage.

The first approach for Salmon will be to migrate comments from aggregators to originating posts, as covered a few times on this blog. But DeWitt said that "Likes" are similar activities that could flow back with Salmon, or be used to notify users of "following" or other activity. DeWitt forecast that sites like Blogger and StatusNet would rapidly adopt and federate Salmon to transmit data updates.

9. Portable Contacts

Simply described, Portable Contacts show your information and that of the friends who you follow, providing users a secure way to get access to address books and friends lists without having to request credentials or scrape the data.

DeWitt also noted XFN, the XHTML Friend Network, and FOAF (Friend Of a Friend) as being key contributors to the Buzz technology stack today, adding that he was "glad smart people were working on this ten years ago because we are all benefiting from it now."

DeWitt, on his Buzz feed, has been talking a lot about open standards and their importance to the Google team at large. See @Jesse Stay A few points of clarification to your most recent post [1], because I believe getting the details right matters. and "The thing I find most attractive about Google Buzz is its stated commitment to open standards.", as well as his first post from February 21st, which thanked the standard developers: Standing on the shoulders of giants—a look at the people behind the protocols behind Google Buzz:

Given Google's size, there is a good amount of distrust on the Web from people who think they own too much of your data, know too much about you, or have goals that run contrary to your own ideals on privacy, communication and sharing. Not even DeWitt's detailed presentations and explanations and promises of openness and data portability will convince everyone that they are on the right path. But I personally believe the frankness and detail that is being shown here is not just promising a strong future for this individual product (Buzz), but also in extending the groundwork done for the entire Web, for products and services we haven't even seen yet.

DeWitt adds: "All of these protocols are open. They are literally also all free. They are intended to be used by everybody, with or without Google being involved. You don't have to ask us if you can use Salmon or Pubsubhububb. We have a liberal and permissive patent license."

Is Google going away? Not today, and not this year. Is Buzz perfect? No. Of course not. Can it do all the things I can do on other sites, like FriendFeed? No. Not yet. But it seems that the Buzz team has opted to make tradeoffs that favor fast shipping and openness over completeness and individual features. And if you don't trust Google, it sounds like you can do something about it.

"We are pretty adamant about not building this on proprietary technology," DeWitt said last night. "If any of you feel that it is not going in the right direction, you have the power to change its direction and Google will not stop you."

You can find me on Buzz here and can follow DeWitt Clinton on Buzz here.

Two of the major outlets where I produce content and consume content, both from Google, took steps forward on Thursday, as Blogger announced new improvements to load slow-performing pages more quickly, and Google Reader unofficially made a big move, with the likely addition of Pubsubhubbub support, which makes the service real-time enabled both incoming and outgoing. Meanwhile, in a separate announcement, Reader promised improved recommendations for you to find new sources to follow - including similar sites per feed.

I've been talking up Pubsubhubbub for months now, because it is the engine that is playing an ever-increasing role in pushing my data faster and faster from site to site. Google Reader shares had already been powered by Pubsubhubbub to flow downstream, but it had been widely assumed Google Reader was not using the same kind of lightning speed to get updates as blog posts were added. Starting today, Jesse Stay and others figured out they had flipped the switch.

As others confirmed, and I saw later also, posts that used to take upwards of half an hour to hit Reader, without manual polling, were there practically instantly, showing 0 minutes to 2 minutes of delay. With FeedBurner also Pubsubhubbub enabled, there should be no latency between when I hit the publish button, and the posts hitting FriendFeed, Buzz Twitter and Reader all at once now.

Google has recently been talking a lot now about making page load times a more important element of how they are ranked in the company's search engine. This leads to the next announcement, from Blogger, who says that traditionally slow-loading pages, including label pages and archive pages, are now going to auto paginate these pages to deliver speedier load times in the browser. They are guessing not only will pages load more quickly, but total page views will go up. Always a good thing.

Reader's move to Pubsubhubbub was likely part of a larger code push from the team, which did announce improved recommendations for new feeds. Now, in addition to tailored recommendations for you, you can click any feed and see what they believe are similar sites. For example, I found that Reader finds me most like Lifehacker, ReadWriteWeb, Engadget, GigaOM and Walt Mossberg. All very cool recommendations. I also found out that Reader finds Loic LeMeur's blog to be most similar to TechCrunch, Seth Godin's blog, Guy Kawasaki and Robert Scoble. I doubt Loic is complaining either.

The amazing thing about this new feature? It was my #1 request way back in March of 2007. It took almost three years, but it's finally here, and I'm going to spend some time finding new sources to follow.

At launch, Google Buzz is not a Twitter client. As the team explained earlier this week, they have about a thousand things they could do with the product, but haven't yet, and sending updates from Buzz to external sites, like Facebook and Twitter, is absolutely on the list. But while Google's developers work on improvements for the much discussed social aggregation service, the developer of Reader2Twitter, initially designed to post shared items from Google Reader to Twitter, has upgraded his product to share native Buzz items as well.

As I highlighted back in September, I set up a new Twitter account solely for my shares from Reader, and now those items which I post directly to Buzz are included in that stream at http://www.twitter.com/lgstream (or @lgstream).



To share items from Buzz to Twitter:

1. Go to http://reader2twitter.appspot.com/buzz
2. Connect it to your Twitter account using OAuth
• (Of note, you need to go to http://reader2twitter.appspot.com/buzz after this, as the OAuth returns you to the URL without the Buzz directory)
3. Add your Google Profile Number ID (find it here at the bottom of the page by clicking "See other options")
4. Make sure "Sync" is On and hit Submit

Now, native updates you make from Buzz, and not those pulled in by 3rd party services, will be sent in near real-time, powered by Pubsubhubbub, to Twitter. Thus far, the vast majority of activity I have with Buzz is shared from other services, primarily Reader. But the two native posts I made to Buzz, once I synched with Reader2Twitter, made it to the @lgstream account. Example: Buzz item | Twitter item. I have been using Reader2Twitter for about five months now, and it is practically seamless. So long as the hub from Google is working, it's good to go. You can get started here: http://reader2twitter.appspot.com/buzz.