I wrote an earlier version of this post as part of private discussion with JP Rangaswami.

Public Transportation:
In many communities, commuters pay a flat rate for use of public transportation. Here again the usage is pretty much uniform among all commuters. Nominally commuters use the transportation system two times per day. Occasionally some may use it a few times more per month. But that is noise. So it is easy to stipulate a common, equitable flat rate.

Television:
Cable television charges a flat rate even though they have a stratified group of channels and different rates for different groups. This again reflects a stratified interest groups among their viewers and the need to reflect the need to be equitable.

Utilities:
Contrast these services to utilities like electricity or natural gas. Given the vast difference among the size of the residences and the machines that consume these energy sources it is safe to assume that usage patterns also will be widely disparate. Indeed it is very likely that the right tail will be so long and thick, it may not be feasible to come up with an equitable flat rate. Since high usage adds an extra cost to electric distribution infrastructure, many of them have progressively increasing rate structure.

So this brings us to the case of internet access. I think my dear friend and virtual mentor Tom Evslin popularized flat rate service when he was operating AT&T Worldnet Service. In one of his posts he has described his rationale for introducing flat rate price and the difficulties he encountered in making it happen. Being an analytic person, he also kept track of usage pattern. What he observed was that people didn’t dramatically increase their use, but clearly they liked the fact that the monthly bill was a predictable amount. He is a strong believer of flat rate billing system. I am not sure whether he still is given the change in usage pattern.

At that time most used desktops. This means they had to sit in front of a desk. So people logged on, stayed for a while and logged off. So only occasionally people used the connection for a long period of time. So there was a natural gap. Also most people used for email and browsing. So even the use case was uniform across the customer base. But now each household has multiple devices connected to the Internet on an always on basis. Some of them are laptops and tablets; and some them are devices that download media. Usage patterns change dramatically quickly as new applications are introduced. Since adoption of these new services is unevenly distributed, there is a wide disparity in usage as well. In an attempt to cut the heavy right tail, service provider try to throttle heavy users.

Net Neutrality:
Metered regime for internet access will naturally force ISPs to adhere to Net Neutrality principles. After all, ISPs can equitably recover the cost involved is carrying their customers’ traffic within their “subnetwork”. Additionally, the existing Bill and Keep regime with other “subnetworks” ensures that ISPs will not be further burdened when their customers increase their usage. Since the metered charge can reflect the true cost of operating the “subnetwork”, there is no need to distinguish between wired and wireless access networks.

As a netizen, I prefer we have symmetric access pipes to the Internet with unfettered access upstream and downstream, to run our own servers. I don’t think all these wishes are compatible to a flat rate pricing regime. I am willing to pay metered rate, whether ii is tiered or flat is a secondary question.

Background:
During the recent Enterprise 2.0 Conference that took place in Boston, there was a panel called Microsharing: It is All About the Tools. It is Not About the Tools. It was moderated by Marcia Conner. Stowe Boyd felt that the panel "demonstrated that there is widespread disagreement, confusion and even antipathy about streams in business." So he wrote blog post enumerating the characteristics of Streams, which is an abstracted service concept of Twitter and also highlighted the differences between Streams and email.In this post I argue that indeed business would benefit from the service concepts of both Streams and email and I propose a service concept that integrates them.

Boyd contrasts this to email where the publisher determines and selects the set of consumers. For him this is a critical flaw. If streams are elective on the consumers' side, email is elective on the publishers' side. If streams are inherently more distributed and bottom-up, email is inherently more centralized and top-down.

But I am uncomfortable with this categorical dichotomy. If Twitter is a prototype of Streams, it may be instructive to note how it is being used by its users, especially because Twitter users are well known to develop adhoc conventions to overcome some of the limitations. Even though Twitter streams are public and anybody can access them, users feel certain tweets are private and meant for a single individual. This is met by "direct message" (DM). In a business environment, the need for privacy is more acute. Businesses have fiducial and legal requirements to keep certain messages confidential. Only the publisher can know the level of restriction. Secondly, the general understanding in Twitter is that it is possible for a person to miss a particular tweet. It is well known that tweets are phatic. To ensure that a particular person reads a tweet, publisher usually uses an "@message". Twitter's web interface and almost all third party clients list @messages ("mentions"). This is a call for a specific consumer to pay attention to a particular tweet, but decided by the publisher. Thirdly, as Boyd notes, publishers can use hashtags to telegraph the intended audience for a tweet. All these point to the need for "elective on the publisher's side" as well.

To summarize, Streams must allow for different level of access restriction: all the way from free access to free within a domain to restricted to people with a certain responsibility to a set of identified people.

Tummlers: Individuals and Tags too:
Kevin Marks talks about the role played by "Tummlers" in expanding the conversation. Since one routinely reads tweets from only a set of people, it is possible to be stranded in a Twitter island. But so called Tummlers play the role of bridging these islands. Usually Tummlers retweet to spread information from one island to another. But ever inventive Twitter users have found another way - hashtags. Publishers attach hashtags to their tweets and others, even non-followers can search for a specific hashtag term. These tags can be viewed as "interest tags" as expressed by consumers. In other words, a publisher is saying that a tweet will be of interest to those who are interested in the tags identified in the tweet. But business context requires another kind of tags. In keeping with the requirement that businesses may have to control access, publishers may have to control access to only those whose area of responsibility includes those identified in what I call "responsibility tags".

Accordingly, in the new service access rights will be determined by three parameters: A "To" list as in the traditional email, a list of responsibility tags along with the identification of the authority that issued the responsibility and finally a list of interest tags. A publisher has to identify these three parameters and the specific logical combination that should be applied.

Let me elaborate with a few examples. If the publisher has put Aswath in the To list, acme.com/marketing in the responsibility tag and VoIP in the interest tag and the logical combination, is "AND", then Aswath can access this post only if acme.com has asserts that Aswath has marketing responsibility AND Aswath has expressed an interest in VoIP. On the other hand if the logical combination is "OR", then Aswath or anybody who has marketing responsibility according to acme.com or anybody who is interested in VoIP can get access to this post. Of course the logical combination can be a bit more involved.

Anatomy of a Stream:
As was pointed out earlier, Boyd states that Twitter's size restriction may not be relevant for businesses. Dave Winer has been lobbying for a long time that Twitter should allow for metadata. He points out that shortened URLs are attaching pictures or other media via URLs are examples of metadata. Twitter itself has announced plans to introduce a new feature called Annotated Tweets. Not withstanding all that, there is a real benefit in capturing the main idea of a post in a pithy comment. This allows the reader to quickly scan many messages before deciding to select a subset of them to dig deeper.

So Streams should adopt "Subject" field used in email, but restrict the length of Subject field to 140 characters. Furthermore, the recipients will first see only the Subject and possibly an initial segment of the post, but no more than 140 characters. A recipient can access the full post if so desired.

Distribution of Streams:
email and Streams differ in how they distribute messages. In email the sender explicitly identifies the list of recipients. Then the sender's server distributes the message each of the recipients' servers individually. On the other hand distributed systems like XMPP use Pubsub like mechanism. More recently, this mechanism is further refined with PubsubHubBub. In this mechanism the originating server uses intermediary Hubs to reach the ultimate servers. In a business environment either of the schemes have some undesirable qualities. Since the email system delivers the complete message to the recipients, one of them can forward it further down the line. The originator has no control or record of such distribution down the line. In the case of PubSubHubBub, the intermediary nodes have access to the message. even if the message is encoded, the mere fact that two enterprises/individuals are communicating itself may be potentially sensitive information. So an alternative, efficient mechanism must be used that takes into consideration privacy concerns.

When Streams identifies an individual recipient, then it should first determine whether that recipient is a Streams user. If so, the Subject of the post along with the URL to retrieve the complete post will be posted to the recipient's server using webhooks. If the recipient is not a Streams user, then the creator will be notified to inform the recipient using some other method like an independent mode of communication. The address resolution algorithm may resolve to a group of people identified by a Responsibility tag under a domain. In this case, the domain may not revel the individuals associated with the Responsibility tag since that could be a sensitive information. In this case, the Subject of the post and the retrieve URL will be deposited to the domain which in turn will distribute to the relevant individuals. Finally if a group is identified by an Interest tag under a domain it is possible that the group may be a large number. So in this case, the Subject of the post and the retrieve URL will be deposited to the domain, which will distribute to the individuals.

Threaded Stream:
Traditionally email systems treated messages individually. Then Google introduced the concept of threaded messages in GMail. Still it is from the perspective of the recipients. If one person is excluded from the reply then that person looses the threaded view. We should also note that an email thread captures organizational memory. This organizational memory would be of help to a new person joining the group.But current email systems are not very effective in facilitating transfer of knowledge base. Streams musty endeavor to provide this.

Accordingly, Streams should keep responses to a message along with the original message, identifying the author of each of the responses. Further, the original creator of a message must be able to add new recipients at a later time.

Summary:
1. Publisher can specify the audience for a stream using three parameters: Individuals identified by "To" field, Responsibility Tags and Interest Tags.
2. A stream will contain a Subject field that summarizes the content of the stream and is of limited length.
3. Stream will also contain a field called Body. It can contain arbitrary digital content and can be of arbitrary size.
4. Recipients can be individuals or a group whose members can only be determined by a third party domain.
5. Individuals and third party domains will be given the contents of the Subject field and an URL to retrieve the stream. When somebody tries to access the URL, the user will be authenticated to maintain the integrity of the access control stipulated by the publisher.
6. Any followup exchange to a stream will be appended to the Body of the stream.

Shameless Self-promotion: These and other thoughts were the motivational forces for EnThinnai. A showcase implementation has captured all of the requirements except for Responsibility and Interest Tags.

As a conservative estimate for revenue potential, let us ignore all of the premium features like international calls. But previously they had telegraphed a business model for deriving revenue from Gooogle Voice service. In an earlier blog post, they had indicated that Google Adwords that appear on mobile devices with full internet browsers can include "click to call" links. Further, the cost of a click to call is same as the cost of a click to visit a website. This is a big disruptive move because till now click to call service providers have charged a disproportionately high fee compared to normal CPC rates. They need to expand this service to other devices as well.

But usual click to call use case scenario has experienced pushback because they ask the user to enter a call back number. This has been a turn off because users are reluctant to share that information with advertisers. Google Voice avoids this problem. If the user has signed into her Gooogle Voice account while browsing, the click to call action can direct Google Voice to reach the subscriber using Google Voice call routing logic; so there is no need for the user to enter the call back number. Furthermore, Google Voice provides a shield of privacy for user's phone numbers. Also a user can selectively block a particular advertiser using standard Google Voice tools.

Going back to revenue potential of Google Voice. Assuming an average rate of $0.80 per clicks, Google Voice will break even if an average user makes 5 calls per month. I think this is a reasonably low figure for them to meet. So the revenue potential is very high.

This is an interesting development that other advertisement outlets like Bing, AT&T Buzz, Superpages, Yelp and many others will be well adviced to consider. And they do not have to develop the service all by themselves. There are many platform companies that can deploy a similar service readily for them: Ribbit, uReach, TringMe ...

To data almost all Presence serving system push a user's Presence status to others. It is widely considered to be an efficient mechanism rather than individuals periodically polling the Presence status of all of their friends.But this is based an a oversimplified analysis that does not take into consideration accepted social etiquette and potential security and privacy issues. It is better that buddies pull the Presence information of a user directly from that user's Presence server. To further enhance the user experience, Presence server must allow for buddies to subscribe for changes in a user's Presence status with the approval of that user.

Consider the following scenario: Abel and Betty are buddies with each other. This allows Betty to constantly monitor Abel's Presence status, so much so can reconstruct Abel's timeline. In real life, even if Abel and Betty are close friends, Betty's behavior will be considered abnormal as dramatized by Lucy and Holden:

Indeed the situation is worse. The real comparison would be the case where Betty were to observe Abel using a periscope without Abel knowin about it. That would be a real anti-social behavior. But that is exactly what the Push system allows.

This problem further compounds when Presence information is shared between federated networks. How does one network ensure that the other network maintains the confidentiality of the shared information? Specifically, if Abel is sharing different status information with Betty and Charles belonging to the same federated network, the expectation is that Charles will not be able to access the information shared with Betty. What about all other members belonging to the federated network who are not Abel's buddies? Andy Zmolek points out this scenario in one of his blog posts.

This can be ensured only after extensive testing, leading to a time consuming routine before two networks can federate. But this is counter to the objectives Unified Communications and Collaboration (UCC) of which Presence is a component.

Given these issues, I wonder why Push system is still being used. I have raised this point with a few people. The consistent response is Push is considered to be an efficient way of distributing seldom changing Presence info; otherwise all the clients will be polling all of their buddies' Presence info, overloading all the servers. This is true only because they have fixed a specific use case scenario where the user is able to ascertain the Presence info of all of their buddies with a single glance. For this small convenience, we are paying a huge price.

But there is an alternative that addresses the concerns described earlier with a small change to the user interface. The alternative is for Betty to query Abel's Presence server whenever she needs that information. Since Abel's server will log all such requests, Betty will be discouraged from stalking Abel, except when she is desperately trying to contact Abel.

Federation is not a big problem anymore since the server belonging to the federating network is not involved in this transaction. Of course Betty and Charles can exchange and compare the information they received. But that happens in real life as well. We as social beings have developed social norms to handle such situations.

Finally if the User clients have a simple mechanism for a user to query Presence information of a single or a group of buddy, then this would be an acceptable compromise for other benefits. But there is one technical issue. Since Betty will be querying Abel's server, it must be able to authenticate Betty. Here my suggestion is to use OpenID/OAuth. By the way this is how EnThinnai serves Presence information of its users.

Pulling of a user's Presence information can be further enhanced by allowing for Betty to subscribe to Abel's Presence information. For example Betty would like to be informed when Abel's Presence info changes or it contains a specific string and the like. Of course such a subscription needs to be approved by Abel before the updated information is delivered to Betty. Of course this mirrors what happens in real life interactions.

In summary, we should not push a user's Presence information, but instead buddies must be allowed to pull after they are properly authenticated. Servers should also accept subscription requests which will be responded to after the user has given permission. Finally, the server should log all requests and make it available to the user.

Over a series of posts in his blog Confused of Calcutta, JP Rangaswami presents his thoughts on how corporate IT department should get inspiration from Facebook to develop and deploy software infrastructure that emerging workforce will demand. I call the collection of posts “facebook Manifesto” (the case of the letters being used advisedly). The purpose of this post is to compare EnThinnai against this Manifesto. Admittedly, EnThinnai has some gaps to fill. In some cases, we have taken some of the ideas a step farther and in a few cases there are fundamental breaches. This posts catalogues them in an attempt to develop a road-map for our future development plans.

1. Facebook and the enterprise: Part 1


2. The Facebookisation of the enterprise


3. More on the Facebookisation of the enterprise


4. Walls and bridges: even more on Facebookisation

1. Tomorrow's workforce is experiencing and learning social skills in Facebook, which seem to have different collaboration philosophy than what is traditionally practiced in the corporate world. Just as corporations have supplied old world social facilitators like watercoolers and canteens, modern corporations must supply social network platforms. In his opinion the platform must support publishing, search, fulfillment and conversation. He calls them Four Pillars.


2. An enterprise worker would prefer to see all theses things for a quick review: news events, a unified inbox, appointments, communities, consulting and sharing views and opinions.


3. The unified inbox is enabled with both a white list and a blacklist.


4. Colleagues' presence information


5. Search and discoverability tools


6. Easy to mash-up third party applications


7. Ability to federate with customers, partners and supply chain


8. Total flexibility in privacy and access control

1. A personal token that can be used for all the activities in the company


2. A place to create personal profile that allows for discoverability


3. Create and maintain a social graph


4. PIM - Address book, calendar and to do list


5. Real-time communication with the members of the social graph


6. Publication platform


7. News feed

EnThinnai allows for its users to create a rudimentary profile and also a set of contact information. There is no address book in the traditional sense. EnThinnai maintains a list of Contacts, their OpenID and the name of their EnThinnai server. When a user would like to access the contact information of a specific person, it will retrieve the information in real time. The current version does not have Calendar, but it is in our road-map.

EnThinnai has its own version of social graph but it is very different from the normal one. Unlike many other social graphs, in EnThinnai the concept of buddy is unilateral. If B is in the social graph of A does not mean that A is in B's. Indeed, B may not even know that she is in A's social graph. B may not even be a member of EnThinnai. Of course B is identified by her OpenID; so it requires that she have an OpenID. (Though the "follower" relationship in Twitter is also unilateral, there is a fundamental difference between these two.)

EnThinnai allows real-time communication with Availability status, text-chat and voice communication between users of EnThinnai and members of their social graph. It is to be noted that this is done with no requirement on pre-installing a client by either parties. Oh, we use a wideband codec for voice chat. The text chat is a persistent chat in the sense that the chat session can be continued at a later time and the whole session is saved.

The main objective of EnThinnai is to share digital information. Accordingly, users of EnThinnai can publish documents, share files with explicit access controls. Furthermore people allowed to access the published information can post comments. EnThinnai is planning to integrate recently open spurced Etherpad so it is possible to edit a document in real-time.

If two people are mutually in each others social graph, but are under different EnThinnai deployments, then the update information is exchanged between the servers using webhook technology. This simple mechanism is used to federate multiple EnThinnai deployments.

So over all we are very satisfied in how we meet the objectives of the Manifesto. Still we have lot more to do and we are very encouraged.

But this means that the codec we use must be freely distributable. This is the reason we decided to use Speex. Last week Skype announced that they will make their codec widely available. I am not sure whether this kind of use is allowed.

In his post, Dan also makes a point that is not really relevant. He suggests that supporting wideband codec in PSTN will require massive overhaul of the network and so is not practical. But that is not the case. It has gone into the folklore that PSTN is not a "stupid network" and no change can be introduced at the edges. But that is not really true. Data modems and fax machines are well known examples. STU III that is designed for encrypted communication is another. So if we really want to use wideband codec and both the parties have wideband codec enabled telephones, then they can switch over to this codec, just like STU III users switch to secure mode. So let us not perpetuate the myth that PSTN is not a stupid network.

But more importantly, we should recognize that if a VoIP end-point is based on ATA, then it is "PSTN" for all practical purposes. So let us try to guide the industry to use native end-points and not ATA based. This is more critical.

Just as I could run the basic services on my own server, I could run any additional services as well. For example, as is done in EnThinnai, you could get my availability status from my server. There is no need for some third party to provide Presence service. You take any service offered by the companies that Andy mentions in his post. Do you think they can not be run in a common server?

So what is needed is packaging EnThinnai in such a manner that people can install them in their servers just like they install Wordpress or MovableType. Of course that is coming soon.

Secondly, the service should really believe in “intelligence at the end” mantra and its close cousin “stupid network”. So if a service lobotomizes the intelligence at the end or if it inserts itself in the middle destructively, then it is not VoIP.

Thirdly, notwithstanding voice in the title, VoIP must be multi-modal with the ability for the ends to dynamically add/drop/change mode(s), without much interference from the “Middle”.

Have you seen an animal that meets all these requirements? Has it not lived up to your expectations? Do think such an animal will ever fail?

To see this in action, please click here. There you will be able to view my status information when you hover the mouse over “My available status” text. You can view my contact information when you click on “My Contact information” link. Finally, if I am connected to my ET server, you can chat with me by clicking on “Click here to chat with me” link.

If you are interested to explore further, you can get a trial account at EnThinnai. Once we finalize our business plan, you will be able to download and install it in your own server. In any event, I am looking forward to your feedback.

If you take a look at the petition by Embarq that FCC is poised to consider, it is clear that Embarq is focused only on those instances when a call is offered at an PSTN interconnection point. According to the petition, the current practice seems to be for some interconnect carriers to declare that a call originated as VoIP and so claim exemption from settlement charges. I am not trained in legal matters. So it could be perfectly valid to make such a claim. But as a layman, it doesn’t seem to be fair. As a cynic I wonder how does one prove or disprove the validity of the claim of origin. With my bias, I conclude that such claims are purely for arbitrage purposes.

As a society we may conclude to give an advantage to new technologies in the hope that we all could benefit from new services, features or capabilities. But alas. Most of the VoIP providers are content in replicating the services and features available in PSTN. Most of them provide an ATA to their subscribers which basically functions as a Class 5 switch in PSTN and users connect an ordinary phone to this box. In other words, even though the providers have a sophisticated signaling link to the subscriber, they do not make that available to the end user. We were told that with VoIP users can know the “presence” information of each other; we were told that with VoIP I can inform you the subject of my call even before you decide to answer the call; we were dazzled with many such features. Where are they? Why do we need to extend our support when there is no evidence that promised items are being even worked on.

Long time back it was claimed that VoIP is a product and not a service. I firmly believe in that. Given that belief, why would I support service providers? This is not my fight. I do not wish them ill. I just do not care. As far as I am concerned it is an intramural tussle. The product I am developing will be able to interconnect to PSTN. But the primary value of the product is the better user experience and feature set. If these are the reasons users decide to use my product then they will not mind if the interconnect charges are the same as if they used PSTN altogether. In other words, my focus is at the End and the issue FCC is considering is in the Middle. Anybody focused on IP Communications should not be distracted with non-relevant Middle.

From the description of Flash 10, it is clear that they are also doing a similar thing. But it is not clear whether they are following the full ICE framework or a subset. It is worthing looking into it once we have additional information.