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.

Just because I take exception to their solution does not mean that the pain point they address is not real. My suggestion to IVR designers is to recognize this and simplify those callers who have access to Internet. A preferred approach could be for these enterprises to produce IVR map on their own website. Then internet connected callers can first visit this website, traverse the IVR menu tree just like Fonolo users will do. Once they reach the desired point, the site can generate a string of digits. Then a caller has to dial the standard number and enter the generated number string. The IVR system can correlate the entered digits to the selection made on the website and route the call accordingly. This way, we can augment the limited signaling capability available in PSTN with the rich UI available through the web browser. This is what “Intelligent at the End” will suggest.

Dan suggests that traditional directories and their online versions can not handle currently available multiple communication modes. So he suggests that the optimal solution is “a user-generated directory in which individuals own and update their own listing.” EnThinnai, which has been operational for a year, does exactly that. He further states that the access to the directory needs to be restricted. He thinks, “[t]he social directory could implement an invite authentication process like any other social network.” Here again EnThinnai is ahead. EnThinnai users will have the ability to control who can access when and which contact information. However, we disagree that there will be a single or even handful of gatekeepers. We are striving to provide a mechanism for each individual to run their own EnThinnai and control their own directories. We do not just mouth “Intelligent at the End” mantra; we believe in it.

First a cheap shot: Michael, there are no downsides in being a Relying party and there are no pain points. If anything, OpenID simplifies the lives of Relying Parties. More seriously, the confusion is created by OpenID proponents themselves because they highlight unrealistic benefits.

A relying party that has decided to accept OpenID has no obligation to accept ID issued by one and all ID providers. For example one of the stated reasons for Sun to issue OpenID to its employees is that retailers who would like to give discount to Sun employees can use Sun issued OpenIDs as verification of employment. So it is conceivable that a retailer may decide to accept OpenIDs issued by Sun and nobody else. OpenID is a “Passport” and not a “Visa”. One of the implied casualties is the possibility of Single-Sign-On.

Secondly, there is a general perception that registration procedure is simplified because the Relying Parties could collect profile information from the ID providers. Even though the protocol allows for this exchange of information, there could be external reasons for Relying Parties to explicitly collect them from their users.

These are the top two claimed benefits of OpenID. But many of the OpenID proponents do not emphasize the real benefit of OpenID. We all the time joke that “in Internet, nobody will know you are a dog”. So if a Relying Party is interested in serving senior citizens, then it can look for an opened issued by AARP. If a social network meant for middle schoolers, then it can look for an OpenID issued by school districts. This is the benefit of OpenID. So as a proponent of OpenID, I would like to lobby AARP, AAA and school districts to issue OpenID to its members/students. Then as a Relying Party I will be able to target services to the appropriate audience.

Now let me defend the actions taken by the big Internet companies. As I reasoned earlier, it is not against the protocol for a company to only issue OpenIDs and not accept from others. It is not even detrimental to wider adoption of OpenID. Just this morning Alec Saunders (most assuredly a friend and a well wisher) discussed Michael’s post in his daily Sqwakbox. There he mentioned EnThinnai and laments that one of the reasons he is not trying it out is that none of his friends have OpenID. This suggests that as a Relying Party, I will benefit enormously if the Big Internet companies issue OpenID to their members and raise general awareness. What will be my benefit that they also accept OpenIDs from others? I am afraid not much. On the other hand if they talk up OpenID and people have general exposure to it then Alec will not have his reservation. So I would rather advocate the big Internet companies to educate their members of OpenID rather than expend my goodwill on them accepting OpenIDs issued by third parties.

I am passionate about the objectives of EnThinnai and it is not viable without the services of OpenID. I do not care so much as whether other sites accept OpenID or not; but it is imperative that there are enough OpenID issuers and that Internet users have pocketful of OpenIDs so that any two Internet citizens will have a mutually acceptable ID providers.
So if you are an OpenID proponent then i urge you to do the following:

1. Ask any and everyone who provides authentication services to issue OpenID.
2. Ask Internet citizens to amass as many OpenIDs as possible.
3. Give visibility (not suggesting you heap praise, but offer an objective review) to budding Relying Parties. This is from a personal hurt. Here is EnThinnai, whose service objectives are viable only with OpenID. But not a single OpenID proponent has analyzed or discussed EnThinnai. But there is no end to people talking about Plaxo et. al. who don’r particularly require all that exposure.

In certain cases, the LEAs may not need access such an elaborate setup. It so happened that in a recent case, the Italian authorities needed to locate one of the suspects. “Soon after the murder, Guede (the suspect) left Perugia, but he kept checking Facebook for messages from friends. The Communications Police arranged for one of those to contact Guede using Skype from their office, and as the two chatted, the cops traced Guede to a computer in Dusseldorf.”