After recent announcement of new Twitter API limits followed by news of Twitter seeking funding at $250m valuation, I think Twitter may be building a double-prong business model: one they are still trying to define and a platform business model that charges businesses for web services for near future and, later, hosted services (run sandboxed third-party code at Twitter for tighter.

Om Malik writes:

As a company, Twitter is still trying to come to grips with its identity — whether it wants to be a service, a platform, or both. If it is just a service, then a $250 million valuation might be too rich. On the other hand if it ends up becoming a platform that is supporting add-on services such as Twitpic Stocktwits, then it can be accorded a different valuation.

I don’t think Twitter has to, nor should, choose one or the other if it can go after both. Of course, that takes time and resources as well as creativity and control but I think $250m valuation will help.

Speaking for myself, I am fine with paying for Twitter’s consumer service as well as platform service as long as fees are reasonable and service is flexible and dependable.

To other Twitter developers and entrepreneurs, a word of advice: try working within what Twitter API is designed for instead of trying to force it to do what you want.

Cool or not and needed or not, not everything that can be built should be built.

In case you haven’t noticed, I am back to my usual daily blogging habit since I now have more time to chase my own tail. That means I’ll be sticking my fingers into other people’s business and ranting pointlessly like I used to before. Hurrah!

Before I start prototyping some of the ideas I’ve been kicking around, I need to decide which tools I’ll be working with, making choices that’ll haunt me for months to come, as usual.

Language

At SafePage, we started with the assumption of using Java because that’s what everyone had most experience with. Eclipse was also a hard addiction to break from. I tried to get the team to play with Groovy but, in the end, Java was it. This time, I’ll be the only coder for a while so I can be flexible.

At this point, I am leaning heavily toward PHP because that’s what Aptana Cloud supports. Although I’ve been using Java since the first beta, I think I can write most of the front-end stuff in PHP and rest in server-side JavaScript using Jaxer, leaving Java for key web services and bots only. I am pretty sure that early windfalls from using Aptana Cloud will make up for late growing pains due to PHP.

Ajax Framework

At SafePage, we started with jQuery + Ext on my recommendation but discarded Ext within first few weeks because engineers found Ext awkward to use. Much later, we started missing sophisticated layout and table support both Ext and YUI offers.

This time, I am going to go with jQuery 1.3 (released today!) for most tasks and use Ext when complex widgets are needed since I personally had no problem using Ext. Quality and selection of Ext widgets is hard to beat but it’s too heavy for mundane Ajax stuff and style-conflict will create problems later unless Ext style is embraced fully which I am not willing to do. YUI style is cleaner but, egads, verbose YUI API really rubs against my simpletonian vanity. Re Dojo, I’ll just say it’s too liberal for my taste.

I like the choices John Resig made with both design and implementation so far although quality of most jQuery plugins and widgets are too brittle and selection of widgets too skimpy despite the size of jQuery developer community. I think it’ll take another year before jQuery UI widgets mature in substance, style, and selection. Note that both jQuery and Ext can be used in AIR apps which is going to be important later.

Adobe has concluded that ads in PDFs don’t work (via TechCrunch). I agree that normal ads don’t work but the general idea still remains largely unexplored. One variation I think has more merit augments PDFs and e-books in general with helpful context-relevant links.

For example, a PDF report on recent stock market performance could have a sidebar that displays a list of links sorted by relevance to contents of the page displayed. Business model for this variation is the same as yellow pages which sells ad-spaces around fine-grained content with tight contextual constraint.

The key difference between the original idea and this variation is that the original idea attempts to leverage primary content directly where this variation attempts to raise the value of secondary content (page relevant links in sidebars) within which ads are weaved in appropriately.

I just noticed that my ring finger is longer than my index finger. Hmm.

In a study of 44 London traders, the most successful tended to have longer ring fingers than index fingers, a ratio linked to high prenatal exposures to androgen, a male sex hormone. This exposure in turn is believed to increase adult testosterone levels.

– From Wired article Financial Crisis Has Biological Roots, Too

I’ve been meaning to use blog.docuverse.com as permanent URL for this blog but lazyness held me hostage until now. So, there you have it. Tata!

The obvious solution (pun intended) to Twitter auth problem is OAuth. As Biz wrote, OAuth won’t prevent hacking but should reverse increasingly common practice of third-party software and services asking for Twitter credentials. However, OAuth is a disruptive change, one that will break existing code and force everyone to change over. In this post, I will propose a practical alternative to OAuth that offers smoother transition.

PAuth

The core idea behind PAuth is to continue using password for auth but allow multiple passwords to exist for an account, each potentially bound to specific set of clients and permissions.

The key advantage PAuth offers to fast moving services like Twitter is that no client software change is necessary.

User Experience

1. User wants to use Twhirl but, to enable it, Twitter username and password is necessary.
2. User  signs into Twitter with primary password and proceeds to creates generate a limited password for Twhirl, enabling only the permissions Twhirl needs.
3. User uses the limited password to enable Twhirl.
4. When user stops using Twhirl, limited password for Twhirl is deleted.

Multiple Posters

An interesting use of PAuth is limiting password to post-only. By issuing each poster a post-only password, multiple users will be able to post to a single Twitter account and admin (primary password holder) will be able to ban individual posters at any time without affecting other posters.

Details

Limited passwords should be generated for convenience and security. Since limited passwords are maintained by the PAuth provider and typically copy/pasted over to consumer site/client, it can be longer than usual passwords also.

I would like to wish all my friends a happy new year. 2009 is looking to be a tough year but I am hoping this year will become a landmark year. Fingers crossed.

If I had to make some predictions, I think we’ll finally see non-fluff applications for Twitter, Facebook, iPhone, and other ‘virtual platforms’ this year because millions of user-base and relatively low launching cost make those platforms very compelling to developers during the recession.