I haven’t settled on anything yet but lately I decided to give RSS Bandit another try. So, while working with it I thought it would be nice to add a “Share on Friendfeed” functionality. RSS Bandit supports the IBlogExtension plugin interface, and following Dare Obasanjo’s del.icio.us sample made it very easy to develop a Friendfeed plugin.

The IBlogExtension framework is supported by other RSS aggregators so this plugin may work with other applications but I only tested it with RSS Bandit. Let me know if you successfully use it with other apps.

Download and Installation

Share on Friendfeed Plugin (12Kb)

1. Download and unzip the plugin to RSS Bandit’s plugins directory. The default path is C:\Program Files\RssBandit\plugins .
2. Restart RSS Bandit.

Configuration

1. Right click any RSS feed item and then click “Share on Friendfeed – Configure”.

2. Enter your Friendfeed username and remote key (you can get it here).

3. Check the “Display confirmation” checkbox if you want to see a notification dialog after posting to Friendfeed.

Sharing Items on FriendFeed

1. Right click the feed item you want to share and then click “Share on Friendfeed”.

2. You can edit the URL and title (both are populated automatically from the feed item) and add your comment, before hitting the Post button.

3. If you checked the confirmation box in the configuration dialog, you’ll receive a confirmation message with a link to your newly posted entry.

Disclaimer

This is the very first version of the plugin. It is provided “as is” and under the “works on my machine” terms and conditions. I tested the plugin with RSS Bandit version 1.8.0.870 under Windows XP SP2.

Feel free to comment below or contact me with any feedback.

Here’s a little test I performed. About two months ago I deleted an entry which had an image attached to it. I noted the URL of the uploaded image (the location where FF stored it on Amazon S3 storage service).

I checked this URL a few hours later, the next day, next week and so on, assuming there’s some sort of garbage collection process that would delete this resource, but the image is still there at the time of writing. I have repeated this test more than once.

This raises a few concerns:

1. Potential exploit #1 – someone who wants to save on their site’s bandwidth costs can store images on FF at no cost.
2. Potential exploit #2 – storing files on Amazon S3 costs FF money (currently $0.15 a month per 1GB), so if someone wants to increase FF’s monthly bill they can just dump a lot of large photos there. Not to mention bandwidth costs (think Digg homepage kind of traffic).
3. An entry you delete might not really be deleted – if FF doesn’t bother deleting these binary resources, one may assume the text is kept as well, which is a bit of a problem if you shared something by mistake and wouldn’t want it popping up in the future.

Of course this could all just be a bug and these images should have been deleted in the first place. I’m just speculating here.

I’m not sure how to balance width vs. scroll. Having two columns can be confusing, and I certainly don’t want to scroll down to read the left column only to scroll up again to read the right one. However I’m sure this screen real estate can be used in some way to enhance my productivity.

Maybe something along the lines of the Pagerization Greasemonkey script, only horizontal? Still thinking about it. In the meantime I’ll just keep scrolling down.

Try these links:

• Simpli.st – this domain is registered under FriendFeed.
• Frnd.us – this domain is registered under Paul Buchheit, FriendFeed founder. It actually redirects to friendfeed.com .

Terminology

I changed my terminology from “active” to “most followed” as it better describes what this is all about. When I use the term “active” I mean “discoverable”, and it doesn’t matter if a person actually does anything on FF as long as his feed keeps flowing in. If she streams her twitter activity to FF but doesn’t set foot in FF, she will still be picked up by my crawler because her twitter activity contributes to her FF feed.

Margin of error or coverage limitations

Occasionally FF users mention how many followers they have. I tried comparing these numbers with my limited data and it seems to fit well within the estimated 15-20% margin.

For example, take a look at this entry and notice the numbers reported there by Susan Mernit and Jeremiah Owyang. Susan reports 1290 followers, I was able to discover 1055. Jeremiah reports 1979 followers, I was able to discover 1578.

Also, as far as the “big guys” go, I’m sure I’m missing a lot more than 15-20% which is natural given their popularity. There are probably a lot of dormant/inactive users who simply follow Scoble and Arrington without contributing anything to the feed (which makes them non-discoverable by my crawler).

The top 250

So, here is the top 250 list. As you can see, it goes “long tail” pretty fast.

But enough with the disclaimers, let’s see some numbers.

How many FriendFeed users are there anyway?

For now I stopped crawling at about 60K users since I was discovering less and less new users with every crawl until it became clear that I’m discovering users who have just joined or existing inactive users who just happened to post something and went back to sleep. Basically they don’t interest me in the context of this little research.

Factoring in a few technical limitations, API coverage issues and some secret sauce, I assume I’m missing about 15-20% of the users. In fact I could be bold and speculate that FriendFeed has an active userbase of about 75K users. Again, this is based only on partial data and my own interpretation.

What is the public/private ratio?

The total number of users my crawler discovered is 57560 .
49580 of these users are public, while 7980 are private.
So the public/private ratio is about 6:1 .

Who are the most popular FriendFeed Users?

Out of this total of 57560 users, here are the top 20 “heaviest” (most subscribed to) FF users:

You probably didn’t need my help to figure out that Robert Scoble is the most popular user on FriendFeed but my research seems to support this. Almost 20% of the public population I discovered are subscribed to his feed, 13% follow Michael Arrington, 5% follow Thomas Hawk and only 4% are “stuck following Louis Gray“…

What next?

Any suggestions for further analysis are welcome. I have my own ideas but I’m interested to know what others think and if this research has any value. Leave a comment or contact me by mail.

I wonder, maybe I should just let people search this database? You could ask “who follows louisgray” and get a list of users subscribed to him. Interesting.

In any case I have sent it to crawl the FriendFeed main feed at regular intervals and I should be getting some initial results soon. I will share them of course but first of all we need to understand the methodology and limitations of my analysis.

How does the crawler work?

The crawler starts with the current public feed. For each entry it extracts (discovers) the poster as well as usernames of people who liked or commented on that entry. For each user discovered the crawler reads his or her subscriptions list and keeps on going from there.

So generally speaking the process is: 1) read the feed 2) discover users 3) extend discovery through subscriptions 4) repeat.

What kind of data is collected?

The crawler generates a long list of pairs where each pair represents a single subscription, a relation between a subscriber and the user he is subscribed to. For example, the relation “Robert Scoble -> Michael Arrington” means Robert Scoble is subscribed to Michael Arrington’s feed. Given enough data, I should be able to tell you who else is subscribed to Arrington, at least among the relatively active users.

What are the imitations?

1. Only active users are covered: if you open a new FF account, you have no other user subscribed to you and you do not publish/like/comment on anything then there’s no way my crawler can discover you. In my view this is a good limitation since it narrows the analysis down to the interesting users, excluding the inactive ones.
2. Only public users are covered: if your feed is private I cannot read your subscription list or do anything of value for that matter.

Any interesting numbers to share?

The crawler is running. I will test it, run it once or twice, and then share the results when I decide I’ve reached critical mass.

FriendFeed lets you see a user’s subscriptions but it doesn’t let you see which users are subscribed to that user. For example, you can see who Robert Scoble follows, but you can’t see Scoble’s followers (the list of users subscribed to his feed).

So, I’m thinking maybe I can crawl the public feed, discover users and read their subscriptions. Each subscription will point at other users to discover and so on. Once I get enough data, I can just look at the list of subscriptions from the opposite direction (from the subscribers point of view), meaning I would be able to see which users and how many are subscribed to a user.

This will effectively give an estimate as to the “social weight” of that user, at least among the active and discoverable users of FriendFeed.

Interesting. I’ll get to work on it as soon as I can and share the results.

The 2 most annoying limitations for me are:

1. You cannot retrieve entries by a date range, you can only specify a start position and how many entries you want to retrieve. So if you’re trying to scan backwards you need to jump through hoops to decide when to stop.
2. The “page 11″ limitation – try browsing FriendFeed and navigate through previous pages. Page 9, page 10, page 11, page 12 … What’s that? Clicking anything past page 11 just gives you the same results over and over again. With a limitation of 30 entries per API request this means you can get a maximum of 300 entries.

No other major rants at this point.