Blue Screen Of Duds

Where the alter ego of codelust plays

Kill the “unread” count

with 4 comments

Actually, the title for the post should have been “Why Twitter Works for Me,” but it does have some valid things to say about why it trumps email and RSS readers for me.

1) It has no unread count: Almost every application that has hit us since the advent of email has made a point to remind us constantly how far behind are we lagging on information accumulation, processing and categorization. Everything these days tends to tell you that you suck if you are 1) not overwhelmed by information overload and 2) not trying out the zany fancy ways to kill the overload.

2) Simple is the new complicated: There have been numerous attempts made till date to find a complicated explanation for why Twitter works, while the fact is that it works because it is quite simple. All information is presented in flat structure, in a hassle-free manner that saves you from having to tag/organise, categorize information. In Twitter there are no labels, folders or color coding. You can dive in and swim out of conversations at will and also pick your ideal rate/degree of involvement.

In a weird way, Twitter is exactly what you want it to be. It can be a social network, a meme tracker, time-lapse instant messaging or even email lite, which is why everyone has a hard time trying to define it. It means different things to different people.

3) 140 or bust!: Since there is a soft limit of 140 characters per message, Twitter, by virtue of its form, forces users to condense the matter into concise little capsules. This automatically means that value per message per follower or message is considerably higher than what you get from subscribing to an RSS feed. The form itself ensures filtering of the content, rather than having to rely on social categorization or machine categorization.

4) Single window system: The best thing about Twitter is that it does not enforce the use of any particular software or website to participate in the conversations, or just listen in. You can do all the activities specified in (2) using any of the numerous ways that are available to interact with the framework.


Written by shyam

March 10, 2008 at 12:32 pm

Posted in social media

Tagged with ,

Social networks are bound to fail in the long run

with 4 comments

While they seem to be the toast of the online world, it is only a matter of time before the social networking websites start losing their sheen and the crazy valuations they command these days.

The lifecycle of social networking activities on individual websites can be mapped under the following heads:

Insertion: Social networks are very much like nightclubs and if you have ever been a regular clubber, you would know that not all nightclubs are created equally.

The newer and fancier clubs are where most of the cool crowd will always head for, while the less exciting ones go away pretty much unnoticed or end up serving niches that never scales up either in terms of traction or in terms of revenue.

More often than not the case for being at a new club is to be one of the first ones to get in, granting those who manage it a feeling of exclusivity. And at least in the early days insertion is much more important than the stages that follow after it.

You can see the same behavior in the case of social networks. Both Orkut and Facebook have benefited enormously from the same exclusivity as a result of their restricted entry policies in the early days.

Replication: Once an individual joins a social network, he/she wanders about replicating connections they already have in real life. There are exceptions to this behaviour, especially in the dating, younger demographic. Quite a bit of the initial spurt of activity on social networks is just this – replication of your existing social graph.

Discovery: While almost every online social network is similar to the others, they also have their own little unique ways of doing things. For instance, you “scrap” on Orkut, “poke” and “banter” on Facebook. Everyone has their own little unique way of doing things and these days, with the introduction of various platforms, there are also truckloads of applications, alongside new users to discover on the social networking sites.

The determinants

Degree of participation: Each of the above three points have degree of participation numbers attached to it. Growth on social networks slows down primarily when the number of people being inserted (new registrations, invites) decline. Secondarily, growth also slows down when the replication is mostly done with as everyone you know is already on the network by then.

To counter this, social networks may try and induce more participation from users by rewarding more participation (like a more frequently updated social stream). This can end up being a counter-productive approach, with high risk of alienating the less-frequent users.

Degree of fulfillment: All three factors can also be measured in terms of fulfillment a user gets from them. When you join, (the insertion stage) has a high degree of fulfillment attached to it, which declines over time when it is not that cool anymore, it is not that new anymore.

Replication also has high fulfillment in the initial days, getting more people on to the same platform etc. But it comes at a price. After a while, everyone you know is on the same network.

Moreover, everyone being there also deprives you of privacy. With time, you need increasing degrees of effort to maintain your profile. It is not uncommon to see users withdrawing more and more from doing things which is reflected in the public activity streams.

Gradually, everything moves to the inbox and private messages, which is a need that is already excellently served by email.

Discovery also has a high degree of initial fulfillment with users finding their way around the new websites, exploring new applications, features and people. Eventually, users get bored of using the applications and they have already added most of the people they have wanted to discover and add, resulting in falling rates of fulfillment as time progresses.

The Eventual Failure

As demonstrated above, there is little use case for sustained high levels of usage on online social networks. Over time, it is hard to battle inactivity and increasing levels of boredom for existing users.

To offset this churn, and also to prop up their stellar growth numbers, it is imperative that these websites keep adding a steady or an increasing number of new users all the time. But that number is a finite figure, determined by the number of people who use the internet and not all of them are going to sign up with social networks.

Unlike a Digg, Gmail or a news website, the value addition accrued from sustained usage of social networks is comparitively low and the need that it addresses is fairly artificial.

Another major issue of privacy and it is an issue without having to bring something like Beacon into the equation. If you do not fine-grain access control on your social stream, it is hard to figure out who all are getting to see what all parts of your life.

And if you do fine-grain access controls on social streams, it is either too much of work or it ends up being a better deal to use specialized services for it (email for communication, Flickr/Smugmug/Picasa for photo sharing, for blogging and so on).

Lastly, advertising inventory on social networks has till date been a major failure. Google tripped on the expectations it had from the inventory, advertising on Facebook or any other social network has not taken off much and the click through rates have been pretty poor on them. Unlike search or news, users don’t get on social networks to find ancillary information related to their activities. You don’t have to try too hard to imagine why there is not much context to one person poking another. It is, well, just a poke at the end of the day.

Eventually, even nightclubs need to reposition and redefine themselves every couple of years to stay in the game. Unfortunately, that is not an option that online social networks get to have and that is what will kill them

Written by shyam

March 10, 2008 at 10:07 am

First Impressions: Persai

with 2 comments

“Blogging Persai” is the title of the blog run by the Persai guys. If you needed an indication of how this post is going to proceed, a major hint would be that I was sorely tempted to give the title “Flogging Persai” to it. For a bunch of guys who have been extremely trigger happy during their days to stamp almost everything with the dreaded “FAIL,” it is rather interesting that their own product is nothing short of a half-baked proof of concept that has been cobbled together for reasons that don’t go beyond, well, the fact that it can be done.

Persai, according to the founders, is an ad-supported content recommendation system. Over time, the guys have crawled a truckload of RSS feeds(there used to be a blog entry which said as much, but is not there on the bog anymore, but Sam Ruby has the list here), indexed and classified them and this in turn powers the recommendation system. You can subscribe to “interests” (known as keywords for the rest of humanity) and get sources thrown at you which the system thinks are relevant to you. While you can’t do much else with the sources, since Persai does not have a built-in feed reader, you can reject sources. And that is all there is to see about Persai. Well, at least for now.

The problems

Use Case: Recommendation systems have not traditionally fared too well on the internet. Previous players like Greg Linden’s Findory used to do a lot more than what Persai even does today and have not done too well at all. In fact, Findory, rather sadly, shut shop recently. The only recommendation system (which works in a stealthy manner) is Google News, which works because they don’t blatantly involve you in the recommendation process.

Once you find content on Persai, there is not much to do with it. Fulfillment is a term that is at best very vague on Persai. You can, as they claim, track the topics, but those links lead out the website anyway. Individual interests have RSS feeds that you can subscribe to, but you can already do that with Google News Alerts and other products. I do doubt if anyone is going to use Persai just to have search term driven RSS feeds.

Accuracy: The approach that Persai has taken to classification involves the usage of training data. This approach works well on similar data sets, but the moment you deviate from the similarity, the entropy will be of a magnitude which will send the classifier on a wild goose chase. And as expected, this has an adverse impact on the accuracy of the results. For instance, one of my interests — “mameo” — throws back results at me which has nothing to do with Mameo in the first five results. I could, of course, reject these sources and help improve Persai, but why would anyone do that when there are other avenues that provide me with much more accurate results?

Speed: To do classification, Persai is already using Hadoop’s MapReduce. Mapreduce does an amazing job of distributively processing huge chunks of data (freshly crawled data to be indexed and classified in this case), but it may only help Persai to a certain extent. The reasons for this are simple: If they process interests as unique to each user, it just won’t scale up. There will be numerous threads doing classification for the same interests since they are unique.

And if the interests are not tracked as a unique item per user, it can play havoc with the results with different users rejecting different sources for different reasons. Of course, there are workarounds for it by using a mix of both approaches (classify as non-unique, filter on display by excluding user-specific rejection criteria), but in the end it ends up being a hack.

In any case, the approach results in tremendously outdated results. Some of the interests have really old articles on top. This could also be due to the fact that the sources are manually added into the system, which means that the quality and spread of the sources will be dependent on the bias of the person who is selecting them. Moreover, it another issue that sites without RSS feeds will not be able get into Persai.

Splogs: Possibly the group that will be over the moon about Persai would be the thugs who run splogs. With Persai it becomes ridiculously easy to set up automated blogs based on topics and, honestly, I see more people using Persai for this than anything else.Considering that Persai is still in beta, I would not give it the “FAIL” rating, but I would certainly give it the “FRAIL” rating. I hope it becomes a much better by the time it comes out of private beta.

Written by shyam

March 8, 2008 at 6:46 pm

Break, unintended

leave a comment »

The blog has been suffering from semi-neglect due to the usual refrains: work and life. While I will be pushing out a few drafts that have been in the deep freeze for a while, it will take a while longer to organise things so that I can start blogging again regularly.

Written by shyam

March 8, 2008 at 3:07 pm

Posted in /etc

Decentralized Social Data Framework: A Modest Proposal

with 3 comments

Twitter being down is no longer funny, nor is it even news anymore and the same is the case with Twitter-angst, where loyal users fret and fume about how often it is down. One of the interesting suggestions that have come out as a result of this is to create a decentralized version of Twitter – much on the lines of IRC – to bring about much better uptimes for the beleaguered child of Obvious Inc.

I would take the idea a lot further and argue that all social communication products should gradually turn into aggregation points. What I am proposing is a new social data framework, let us call it HyperID (since it would borrow and use heavily ideas and concepts from OpenID), from which social media websites would subscribe, push and pull data from.

Essentially, this would involve the publication of the user’s social graph as the universal starting point for services and websites to subscribe to, rather than the current approach where everyone is struggling to aggregate disparate social graphs as the end point of all activities. Ergo, we are addressing the wrong problem at the wrong place.

The current crop of problems will only be addressed when we stop pulling data into aggregators and start pushing data into service and messaging buses. Additionally, since this data is replicated across all subscriber nodes, it should also provide us with much better redundancy.

Problem Domain 

Identity: Joe User on Twitter may not always be the same as Joe User on Facebook. This is a known problem that makes discovery of content, context and connections tricky and often downright inaccurate. Google’s Social Graph API is a brave attempt at addressing this issue using XFN and FOAF, but it won’t find much success because it is initiated at the wrong end and also because it is an educated guess at the best and you don’t make those with your personal data or connections.
Disparate services: Joe User may only want to blog and not use photo sharing on the same platform, unlike Jane User who uses an entire gamut of services. In an even worse scenario, if Jane User wants to use blogs on a particular service provider (say, Windows Live Spaces) and photo sharing on another (Flickr, for instance), she will have to build and nurture different trust systems, contacts and reputation levels.

Data retention: Yes, service providers are now warming up to the possibility of allowing users to pull out user data from them, but it is often provided without metadata or data that is accrued over time (comments, tags, categories etc). Switching providers often leaves you with having to do the same work all over again.

Security: Social information aggregators now collect and save information by asking you for passwords and usernames on other services. This is not a sane way to work (extremely high risk of phishing) and is downright illegal at times when it involves HTML scraping and unauthorized access.

Proposed solution

Hyperid Layout

Identity, identity, identity: Start using OpenID as the base of HyperID. Users will be uniquely addressable by means of URLs. Joe User can always be associated with his URL (, independent of the services he has subscribed to. Connections made by Joe User will also resolve to other OpenIDs. In one swipe you no longer have to scrape or crawl or guess to figure out your connections.
Formalize a social (meta)data vocabulary: Existing syndication formats like RSS and ATOM, are usually used to publish text content. There are extensions of these formats like Media RSS from Yahoo!, but none of them address the social data domain. 

Of the existing candidates, the Atom Publishing Protocol seems to be the most amenable to an extension like this to cover the most common of social data requirements. Additional and site-specific extensions can be added on by means of custom namespaces that define them.

You host your own social graph: With a common vocabulary, pushing, pulling and subscribing to data across different providers and subscribers should become effortless. This would also mean that you can, if you want to, host your own social graph ( or leave it up to service providers who will do it for you. I know that SixApart already does this in part with the Action Streams plugin, but it is still a pull than a push service.

Moreover, we could extend the autodiscovery protocol for RSS and use it to point to the location of the social graph, which is a considerably better and easier solution than the one proposed Social Graph.

Extend and embrace existing tech: Extend and leverage existing technologies like OpenID and Atom to authenticate and advertise available services to users depending on their access levels.

What this could mean

For companies: They have to change the way they look at usage, data and their own business models. Throwing away locked-in logins would be a scary thing to do, but you get better quality and better-profiled usage.

In the short run you are looking at existing companies changing themselves into data buses. In the longer run, it should be business as normal.

Redundancy: Since your data is replicated across different subscribers, you can push updates across to different services and assign fallbacks (primary subscriber: twitter, secondary: pownce and so on).

Subscriber applications can cache advertised fallback options and try known options if the primary ones are unavailable. 

For users: They will need to sign up with a HyperID provider or host one on their own if they are savvy enough to do that. On the surface, though, it should all be business as usual, since a well-executed API and vocabulary should do the heavy lifting behind the scenes.
The Opportunity

For someone like, diversifying into the HyperID space would be a natural extension. They could even call it Socialpress. The hypothetical service would have a dashboard like interface to control your settings, subscriptions and trusted users and an API endpoint specific to each user.


Complexity: Since data is replicated and pushed out across to different subscribers, controls will be granular by default and across different providers this could prove to be very cumbersome.

Security: Even though attacks against OpenId has not been a matter of concern, extending it would bring with it the risk of opening up new fronts in what is essentially a simple identity verification mechanism.

Synchronization: Since there is data replication involved (bi-directional like any decent framework should do), there is the possibility that lag should be there. Improperly implemented HyperID compliant websites could in theory retain data should be deleted across all subscribed nodes.

Traction: Without widespread support from the major players the initiative just won’t go anywhere. This is even more troublesome because it involves bi-directional syncing and all the parties involved are expected to play nice. If they don’t, it just won’t work. We could probably get into certification, compliance and all that jazz, but that would make it insanely complicated.

Exceptions: We are assuming here that users would want to aggregate all of their things under a single identity. I am well aware of the fact that there are valid use cases where users may want to not do that. HyperID does not prevent from doing. In fact, you could use different hyperIDs, or even specify which services you don’t want to be published at all.


The comment space awaits you!
p.s: Apologies for the crappy graphic to go with the post. I am an absolute newbie on Omnigraffle and it shows! 

Written by shyam

February 4, 2008 at 1:46 pm

Sign o’ the times

with one comment

There are events and then there are not-so-ordinary events that give us hints, even in their disassociation, about the direction that technological (or any other type, for that matter) developments will head.

In the past week we have seen three such events – Microsoft’s formal overture towards Yahoo!, Facebook’s less-than-stellar numbers and Twitter’s ongoing saga in trying to keep a web-scale messaging framework up and running – that give us tasty hints as to where we may be headed.

The simpler, shorter version of the Microsoft – Yahoo! story is that companies that do business in the old school way – a manner similar to a behemoth, clumsy and ugly in gait – are history on the internet. Lock-in of the user and his/her data to platforms or products is a strategy that is history. It is only a stellar product that will keep companies alive in the future. And neither Microsoft, nor Yahoo! have built and in-house hit web-scale product in recent times.

The feeling that keeps coming back to my mind is that Microsoft and Yahoo! will be one of those weddings that look perfect as a mental image (for the shareholders and business wonks), but in practice it ends up being an absolute nightmare. There is a staggering amount of redundancy (for every Yahoo! product you can think of, there is almost a competing one with MSN/ and the integration will also be rotten in terms of platforms and cultures.

Even if you set apart the strong stench of desperation in the move, the fact remains that these are two companies that are struggling to catch the imagination of the younger and upcoming generation. By the time the dust settles on this one, much confusion would have ensued, which would tick off the loyal users who make up a vast majority of the numbers that make the deal look exciting.

That said, it is indeed a sad development to see an internet icon like Yahoo! being in the position that it finds itself in now. And in that state of distress lies a story for everyone who makes a living off the internet – don’t take anything for granted. Earlier, a company’s lifecycle – from inception to success to the demise – used to take decades, now the same is being compressed into ten years.

It is a theme that I will never tire of telling everyone I know: being nimble is a priceless asset in doing business now – nurture it, grow it and covet it with as much care as you covet your bottom line.

Written by shyam

February 4, 2008 at 12:32 pm

Leopard Tip: Flushing DNS cache

leave a comment »

Instead of doing “lookupd -flushcache” you have to do “dscacheutil -flushcache”.

Written by shyam

February 1, 2008 at 12:20 pm

Posted in Apple, Leopard, OSX

Tagged with , ,