I’ve been joking with Omar that Google+
is the new FriendFeed. I recently posted
this on Google+ and was asked to explain what I meant since Google+ doesn’t support
importing of content from other services which was the key feature FriendFeed. The
reason I say this is that Google+ fulfills the same need that FriendFeed when it first
came out.

Here’s an excerpt from a post by Robert Scoble in 2008 about FriendFeed titled Loving
my FriendFeed



I love my FriendFeed. Here’s
a list of top bloggers who are using the service. Why do I love it? It’s
one place you can find all my stuff and, even, comment on it. It’s amazing the discussions
that a 140-character “Tweet” on Twitter can generate. I subscribe to a ton of people
on FriendFeed and notice that often the conversations after a Twitter message will
be 1000x longer (and generally more interesting) than the Twitter itself.



In my previous
post I asked what problem Google+ solves and the answer is above. Google+, like
FriendFeed before it, gives people a place to subscribe to and participate in conversations
around content produced by people they are interested in.

Why Twitter Doesn’t Solve This Problem

Twitter relationships have been described as a public
interest graph. Specifically, Twitter is a way to keep on top of people and content
you find interesting whether it is tech news sites, bloggers, celebrities, government
officials and even people you know. However there are a number of key gaps in the
Twitter user experience which FriendFeed fixed and Twitter still hasn’t even though
people have been complaining about them for years.

The first problem is that is really difficult to have conversations on Twitter. Here’s
an excerpt from a TechCrunch post made in 2008 titled Actual
Conversations On Twitter Not Possible Until Twitter Lets Us which explains the
problem



One of the big complaints about Twitter is that conversations are hard to follow.
Users can write a response to a Twitter message (or anything else), but the easy way
to do this is to add an @[username] tag to the Twitter, which refers back to the original
Twitter user. But by then that original user has often moved on to other subjects,
and it becomes impossible to follow the conversation.

…

The fact is that Twitter purposefully doesn’t want users to be able to track conversations.
The content begins and ends with a discreet Twitter message, up to 140 characters
long. Competitor Friendfeed does a nice job of tracking conversations by letting users
reply to actual messages, not just users. Twitter, for whatever reason (possibly to
keep things simple), just doesn’t want that. And until they do, nothing is going to
change.



The ability to have actual comment threads about a status update as opposed to disconnected
@replies is a more satisfying experience for many users. As Mike Arrington stated
above, the challenge for Twitter is that this would change the dynamics of the service
in ways that take away some of the character of the service.

The second problem is that Twitter doesn’t give a public way to indicate that a piece
of content is interesting without also sharing it. Specifically, there is no analog
to Facebook’s “I like
this” within the stream (not to be confused with the like
button social plugin). Twitter has favorites but
it’s actually meant to be a way to bookmark posts not to tell people you like the
status update. There are now sites like Favstar.fm which
have garnered a sizable user base by giving people a way to get “I like this” style
functionality from Twitter and see how many people have favorited a tweet.

Both of these problems are fixed by Google+ and it is unsurprising that the same sorts
of people who loved FriendFeed are not only on Google+ but are its
most popular users. The question is whether Twitter will fix these problems with
their experience given that this has made people pine for alternate services. Given
that they didn’t try to address these when FriendFeed was at the height of its hype
curve, it seems unlikely they will unless they see declines in their more mainstream
user base.

Why Facebook Doesn’t Solve This Problem

Facebook relationships are an attempt to mirror our offline relationships online.
The problem with this is captured in Paul Adams’ excellent slideshow The
Real Life Social Network v2

The problem with Facebook is that people you may find interesting (i.e. your interest
graph) or that find you interesting are not necessarily people you want to sharing
the same space as your family, friends and even coworkers. A good example of this
problem are the following suggestions I saw when I logged into Facebook this morning.

Alexia Tsotsis and Steven
Levy are both journalists who work for TechCrunch and Wired respectively. Although
I find the articles they write interesting, I don’t want to have them be on the receiving
end my mobile phone videos of my son playing in the park or my check-ins from places
around Seattle nor do I want to be subjected to their similar personal updates.

The combination of asymmetric following (people can subscribe to my updates without
my accepting a friend request) and the ability to place people into groups (i.e. Circles)
which can then be used to provide limited visibility to various updates is how Google+
solves this problem for various interest graphs. Neither of these features exists
in Facebook today and while I suspect they will add the latter especially since Paul
Adams now works there, it is harder to imagine seeing asymmetric follow ever showing
up on Facebook outside of Pages.

Where That Leaves Us

I expect that both Twitter and Facebook will lose some chunk of people’s time to Google+.
However Twitter is more vulnerable than Facebook, because Facebook has been fairly
resistant the rise of the “interest graph” by building features like Facebook Pages
which allows people to follow their interests in the same stream as updates from people
they care about offline. For example, it is interesting to note that the most popular
user on Twitter is Lady Gaga with 11.5 million
followers but on the other hand her Facebook fan page has 40
million fans. Secondly, there really isn’t a gap Google+ fills with regards to
communicating and staying in touch with the people one cares about offline via a social
network.

On the other hand, Google+ is more in the same product space as Twitter being interest
graph related which can be seen by the usage patterns of its early adopters. It’s
also telling to read comments
from Google+ readers on how much less time they now spend on Facebook and Twitter.

Now
Playing: Frank
Ocean - Novacane

From the Facebook blog post Updates
on Your New Privacy Tools

Can I limit access to my Friend List?

Many of you have mentioned that you want a way to hide your list of friends. In response
to your feedback, we've removed the "View Friends" link from search results, making
your Friend List less visible on the site.

In addition, you can further limit the visibility of your
Friend List to other people on Facebook if you want. After you've completed the transition
to the new privacy settings, you'll be able to click on the pencil icon in the top-right
corner of the "Friends" box on your profile. Unchecking "Show my friends on my profile"
will prevent your Friend List from appearing in your profile when it is viewed by
people who are logged in to Facebook. Keep in mind, however, that
because Friend List is publicly available, it will be visible to people who are viewing
your profile while not logged in. Again, you will only have this option once
you've completed the transition to the new privacy settings.

Remember, you can also limit who can find you in searches on Facebook and control
whether your information can be indexed by public search engines under "Search" on
the Privacy Settings page.

That's awesome. I didn't realize when I joined Facebook that the
service would retroactively decide that my list of friends was public knowledge and
then would add a privacy setting to "hide" it from Facebook users that could be worked
around by logging out. Join me as I say goodbye to my old privacy settings and old
public version of my Facebook profile which kept my private information private.
R.I.P. Old Facebook Privacy settings

R.I.P. Old Facebook Public Profile

I've been a Twitter user for almost two years now and I have always been impressed
by the emergent behavior that has developed from simply giving people a text box with
140 character limit. The folks at Twitter have also done a good job of noticing some
these emergent behaviors and making them formal features of the site. Both hashtags and @replies are
examples of emergent community conventions in authoring tweets that are now formal
features of the site.

Twitter recently added retweets to this list with Project
Retweet. After using this feature for a few days I've found that unlike hashtags
and @replies, the way this feature has been integrated into the Twitter experience
is deeply flawed. Before I talking about the problems with Project Retweet, I should
talk about how the community uses retweeting today.

Retweeting 101: What is it and why do people do it?

Retweeting is akin to the practice of forwarding along interesting blog posts and
links to your friends via email. A retweet repeats the content of a person's tweet
(sometimes edited for brevity) along with a reference to the user who is being retweeted.
Often times people also add some commentary to the retweets. Examples of both styles
of retweets are shown below.

Figure 1: Retweet without commentary

Figure 2: Retweet with added comment

Unlike hashtags and @replies, the community conventions aren't as consistent with
retweets. Below are two examples of retweets from my home page which use different
prefixes and separators from the one above to indicate the item is a retweet and the
user's comment respectively.

Figure 3: Different conventions in retweeting

However there are many issues with retweeting not being a formal feature of Twitter.
For one, it is often hard for new users to figure out what's going on when they see
people posting updates prefixed with strange symbols and abbreviations. Another problem
is that users who want to post a retweet now have to deal with the fact that the original
tweet may have taken up all or most of the 140 character limit so there may be little
room to credit the author let alone add commentary.

Thus I was looking forward to retweeting becoming a formal feature of Twitter so that
these problems would be addressed. Unfortunately, while one of these problems was
fixed more problems were introduced.

Flaw #1: Need to visit multiple places to see all retweets of your content

Before the introduction of the retweet feature, users could go to http://www.twitter.com/replies to
see all posts that reference their name which would include @replies and retweets.
The new Twitter features fragments this in an inconsistent manner.

Figure 4: Current Twitter sidebar

Now users have to visit http://www.twitter.com/replies to
see people who has retweeted their posts using community conventions (i.e. copy and
pasting then prefixing "RT" to a tweet) and then visit http://twitter.com/retweeted_of_mine to
see who has retweeted their posts by clicking the Retweet link in the Twitter
web user interface. There will be different people in both lists.

Figure 5: Retweets in the Replies/Mentions page

Figure 6: Retweets on the "Your tweets, retweeted" page

It is surprising to me that Twitter didn't at least include posts that start with
RT followed by your username in http://twitter.com/retweeted_of_mine as
well.

Flaw #2: No way to add commentary on what you are retweeting

As I mentioned earlier, it is fairly common for people to retweet a status update
and then add their own commentary. The retweet feature built into Twitter ignores
this common usage pattern and provides no option to add your own commentary.

Figure 7: The Retweet prompt

This omission is particularly problematic if you disagree with what you are sharing
and want to clarify to your followers that although you find the tweet interesting
you aren't endorsing the opinion. 

Flaw #3: Retweets don't show up in Twitter apps

One of the other surprising changes is that Twitter retweets have been introduced
in a backwards-incompatible manner into the API. This means that retweets created
using the Twitter retweet button do not show up in 3rd party applications that use
the Twitter API. See below for an example of what I see in Echofon versus
the Twitter web experience and notice the missing tweet.

Figure 8: Twitter website showing a retweet

Figure 9: The retweet is missing in Echofon

Again, I find this surprising since it would have been straightforward to keep retweets
in the API and exposing them as if they were regular old school retweets prefixed
with "RT".

Flaw #4: Pictures of people I don't know in my stream

The last major problem with the Twitter retweet feature is that it breaks user expectation
of the stream. Until this feature shipped, users could rest assured that the only
content they saw in their stream was content they had explicitly asked for by subscribing
to a user. Thus when you see someone in your stream the person's user name and avatar
are familiar to you.

With the new retweet feature, the Twitter team has decided to highlight the person
being retweeted and treat the person who I've subscribed to that did the retweeting
as an afterthought. Not only does this confuse users at first (who is this person
showing up in my feed and why?) but it also assumes that the content being retweeted
is more important than who did the retweeting. This is an unfortunate assumption since
in many cases the person who did the retweeting adds all the context.

Now
Playing: Jason
Derulo - Whatcha
Say

Last week John Panzer, who works on Blogger at Google, wrote about some of the work
he’s been doing on creating a protocol for syndicating comments associated with activity
streams in his post The
Salmon Protocol: Introducing the Salmon Project. Key parts of his post are excerpted
below



A few days ago, at the Real
Time Web Summit, we had a session about Salmon,
a protocol for re-aggregated distributed conversations around web content.  I
was hoping for some feedback and to generate some interest, and I was overwhelmed
by the positive reactions, especially after Louis Gray's post "Proposed
Salmon Protocol aims to unify Conversations on the Web". Adina Levin's "Salmon
- Re-assembling distributed conversations" is a good, insightful
review as well. There's clearly a great deal of interest in this, and so I've gone
ahead and expanded Salmon's home at salmon-protocol.org with
an open source project, salmon-protocol.googlecode.com,
and a mailing list, groups.google.com/group/salmon-protocol.



Louis Gray’s post on the topic includes an embedded presentation which captures the
essence of the protocol

Before talking about the technical details of the protocol it is a good idea to understand
the end user problem the protocol solves. For me, it solves a problem I have in the
way that RSS
Bandit integrates with Facebook. The problem is that although there is a way to
get regular updates on changes to the user’s news feed by polling Facebook’s stream
and getting
data back in the Activity Stream format there isn’t a mechanism today to get updates
on the comments on items in the feed. What it means in practice today is that once
an item rolls off of the news feed, there is no way to keep the comments up to date
in RSS Bandit.

The Salmon Protocol aims to address this problem by piggybacking on PubSubHubBub as
a way for applications to get real-time updates on comments on items in an activity
stream not just updates on new activities.

There have also been several mentions of Salmon being a way to aggregate distributed
conversations on an item (e.g. this blog post is syndicated to  FriendFeed and
there are comments there as well as in the comments on my blog) but I am less clear
on those scenarios or whether Salmon is enough to solve the various tough problems
that need to be solved to make that work end to end.

Any API for posting comments to a site needs to solve two problems; identity and dealing
with comment spam. I decided to take a look at the Salmon
Protocol Summary to see how it addresses these problems.

The meat of the Salmon Protocol format is excerpted below



A source provides an RSS/Atom feed of content. It includes a Salmon link in its
feed:

<link rel="salmon" href="http://example.org/salmon-endpoint"/>

An aggregator reads the feed (ideally via a push mechanism such as PubSubHubbub),
and sees from the link that it is Salmon-enabled. It remembers the endpoint URL for
later use.

When an aggregator's user leaves a comment on a feed item, the aggregator stores
the comment as usual, and then also POSTs a salmon version of it to the source's Salmon
endpoint:

POST /salmon-endpoint HTTP/1.1

Host: example.org

Content-Type: application/atom+xml

<?xml version='1.0' encoding='UTF-8'?>

    <entry xmlns='http://www.w3.org/2005/Atom'>

    <author>

      <name>John Doe</name>

      <uri>acct:johndoe@aggregator-example.com</uri>

    </author>

    <content>Yes, but what about the llamas?</content> 

    <id>tag:aggregator-example.com,2009:cmt-441071406174557701</id>

    <updated>2009-09-28T18:30:02Z</updated>

    <thr:in-reply-to xmlns:thr='http://purl.org/syndication/thread/1.0'

       ref='tag:example.org,1999:id-22717401685551851865'/>

    <sal:signature xmlns:sal='http://salmonprotocol.org/ns/1.0'>

        e55bee08b4c643bc8aedf122f606f804269b7bc7

    </sal:signature>

    <title/>

</entry>



The commenter is identified in the published comment using the atom:uri
element. How this author is authenticated in situations outside of public comments
on a blog such as RSS Bandit posting a comment to Facebook on my behalf isn’t really
discussed. I noticed an offhand reference to OAuth headers which  seems to imply
that the publishing application should also be sending authentication headers as well
when publishing the comment. How these authentication headers would flow through the
systems involved is unclear to me especially given the approach Salmon has taken to
deal with spam prevention.

The workflow for dealing with spam comments is described as follows



A major concern with this type of distributed protocol is how to prevent spam
and abuse.  Salmon provides building blocks to allow in-depth defense against
attacks.  Specifically, every salmon has a verifiable author and user agent. 
The basic security flow when salmon swims upstream looks like this:

aggregator-example.com: "Here is a salmon, authored and signed by
'acct:johndoe@aggregator-example.com'; please accept it."

Recipient: "I know that this is really aggregator-example.com due
to its OAuth headers, and it has a good reputatation, but I do not trust it completely;
I will do a double check."

Recipient: Uses Webfinger/XRD to discover salmon validation service for
acct:johndoe@aggregator-example.com, which turns out to be hosted by aggregator-example.com.

Recipient: "Given that johndoe has delegated Salmon validation to
aggregator-example, and I know I'm talking to aggregator-example already, I'll skip
the actual check." (Returns HTTP 200 to aggregator-example.com)

The flow can get more complicated, especially if the aggregator is not also providing
identity services for the user.  In the most general case, the recipient needs
to take the salmon, discover a salmon validator service for the author via XRD discovery
on the author's URI, and POST the salmon to the validator service. The validator service
does an integrity / signature check against the salmon and returns 200 if the salmon
checks out, 400 if not.  The signature check means that the given author (johndoe
in this case) signed the salmon with the given id, parent id, and timestamp. 
It does not attempt to do a full, XML-DSig style verification, though such a service
is another reasonable extension.



This flow seems weird and it is unclear to me that it actually solves the problems
involved in distributed commenting. So let’s say I post a comment to Facebook from
RSS Bandit, in step 3 above they are now supposed to use WebFinger to
lookup my email address provider and determine which service I use for digitally signing
comments. Then they ask it if the comment looks like it was from me.

Hmm, this looks like a user authentication workflow in disguise as a comment validation
workflow. Shouldn’t the service receiving the comment (i.e. Facebook) in the example
above be responsible for validating my identity not some third party service? Maybe
this protocol wasn’t meant for sites like Facebook?

Let’s say this protocol is really meant for situations when the comment recipient
doesn’t intend to be the sole identity provider such as commenting on Robert
Scoble's blog where he allows comments from anyone with just an email address
and an optional web page URL as identifiers. So each commenter needs to provide an
email address on an email service provider that supports WebFinger and validates
digital signatures in the specific situation related to the Salmon protocol? Sounds
like boiling the ocean. I wonder why this can’t work with OpenID validation or some
other authentication protocol that has already been validated by developers and is
seeing some adoption?

At the end of the day, I think the problem Salmon attempts to solve is one that needs
solving as activity streams become a more popular and intrinsic feature across the
Web. However in its current form it’s hard for me to see how it actually solves the
real problems that exist today in a practical way.

Of course, this may just be my misunderstanding of the protocol documents currently
published and I look forward to being corrected by one of the protocol gurus if that
is the case.

Now
Playing: Chris
Brown - I
Can Transform Ya (feat. Lil Wayne)