Out of the 2.7 billion people with mobile phones, those not carrying a smartphone still represent the majority of handset owners. But these people deserve an easy way to access their email and social network notifications, too, even if they can't afford or don't want to pay for a sophisticated smartphone.

Says Michael Maguire, founder and CTO, who previously worked in the BlackBerry Applications team at Research In Motion, "My team and I think there are some great dedicated mobile email devices out there - but we're biased, because half of us helped build one of them. Unfortunately the rest of the world's 1.1 billion email users have phones with unusable, hard to configure in-built email that few people can be bothered to set-up. With BlueWhaleMail, we've gone back to the drawing board so that people can keep the phone they like and still stay in touch on the go."

At the moment, the BlueWhaleMail app is only available for Nokia Series 60 and SonyEricsson phones, but that list will grow in time as BlueWhaleMail branches out to serve the needs of those who carry "ordinary" mobile phones.

Where To Download

BlueWhaleMail can be downloaded from http://apps.facebook.com/bluewhalemail/ or by browsing to m.bluewhale.net on your mobile phone. The application is ad-supported and features a small banner ad at the top of the BlueWhaleMail message viewer.

To learn more about BlueWhaleMail, check out this video, where founder Michael Maguire discusses the application:

BlueWhaleMail Interview with Michael Maguire - video powered by Metacafe

It works something like this: Let's assume your lifestream aggregator supports idAuth. From within your aggregator, you specific a unique identifier that you'll use around the web (such as OpenID or email address -- it is important to note that while idAuth has low-level support for identity systems such as OpenID, it is using them only as an identifier, not for authentication). You'll also specify some keys for use, such as "blog comments" or "readwriteweb.com blog comments" or "photos." These details are then set in a cookie.

When I add data to a service -- which would also support idAuth -- it searches for an idAuth cookie and then looks for an appropriate key. For example, ReadWriteWeb would search for a "readwriteweb.com" key or a "blog comments" key, Flickr might search for a "photos" key. Once it finds the right key, it packages the data you've entered and pushes it back to your lifestream aggregator (whose information is included in the idAuth cookie) in XML format, which the aggregator compares to your cookie to make sure the keys match and the data is valid. You can think of this as something akin to the trackbacks that blogs use to notify one another of links, with a layer of identity verification.

It might seem that something like idAuth wouldn't be necessary for Flickr -- whose stream you verified as yours when you added it to your aggregator -- but the idea here is that your lifestream aggregation service can collect data you create from anywhere on the web and verify that it was indeed you that created it. And you don't have to add a million feeds into your aggregator (nor do they have to bake in support for a million different services), to get it done. That would be supremely useful for something like blog comments, which are very fragmented.

Brady hopes that moving forward he can gain the support of some current lifestream aggregators, then start creating libraries for popular languages and plugins for popular blog clients. His entire proposal, which goes much more into depth about the technical specifics than this post, can be downloaded on his blog in PDF, Word, and OpenOffice formats.