EnThinnai Blog

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.

The set of JP’s posts that are relevant to this analysis are:

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

Even though you will enjoy and benefit from reading these original posts, let me capture the main points here for ease of reference.

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

Given these broad objectives, the Manifesto also identifies a specific set of features:

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 uses company supplied OpenID for authentication. So this can be used for other activities both within the company and also at external sites. Additionally, we can use the Attribute Exchange mechanism used in OpenID to convey HR supplied authorization information like Job Title, scope of control and the like.

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.

Last month Daniel Berninger wrote a guest column expressing the benefits of using high definition codec for voice communication. In that post, Dan argues that widespread use of compatible codecs is critical. When we decided to use a wideband codec in EnThinnai, we also faced the problem of compatibility. More importantly, we decided that our users would like to communicate with people who are not yet users of EnThinnai. Our strategy is to dynamically download the codec. I think this simple technique effectively addresses the compatibility issue.

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.

Tom Evslin continues to add further details to the (Un)Social Directory that is under development at FWD. In today’s post, he explains the reasons for findability feature and how it may work. The reasons for findability are elemental: after all we are all social creatures and are interested in interacting with others. Permission based communication is a defensive reaction to incessant unwanted communication. FWD, assisted by other social networks and armed with self accumulated social graph information of its members will assist you in determining the level of permissibility of a new contact. This is their current thinking and Tom is looking for your input.

Our thoughts are different and our position is clear. The need for findability is real but it is out of scope for EnThinnai. EnThinnai is an application running on your server and serving your needs. Since it is individually focused and under individual control, we can not have a picture of the global social graph. So our users have to look elsewhere when a long lost friend is trying to reestablish a connection. A central component of un-social networks or user-centric social networks is user-centric identity. iName is one such identity scheme. Most of the iName providers offer a “contact” service. It “is a way for you to put a link on your web pages or on your business card that allows people to contact you, without exposing your email address to spammers.” Analogously other ID providers could also offer such a service as well. Armed with my OpenID, a new contact can contact me through this service, providing her EnThinnai particulars and adding me in her permission list. Then I will be able to visit her EnThinnai and initiate the communication. Subsequently, I could add her to my permission list and close the loop.

This method addresses the need for allowing contact establishment without violating the privacy model of EnThinnai and its distributed nature.

After a post by Daniel Berninger on directories and my direct response in how EnThinnai has implemented directory, Tom Evslin has spelled out his views on how to design what he calls an (un)social directory. Since his description of how a directory should work is close to what we have implemented in EnThinnai and his curious moniker is close to mine “un-social network”, a closer comparison of the two line of thinking is called for.

Tom states at the outset that in his thinking the concept of directory is complete inverse of the traditional directory. He says that instead of storing our friends’ contact information, he will store his contact information and will allow others to access it in real-time under the control of a permission based rules engine. This is EXACTLY what we do in EnThinnai and we had implemented it even in a mockup that is two years old.

Next he goes through the mechanics: “We now each have two entries in our personal directory. The contact entry I use to reach you has nothing but permissions in it and the address of your contact page (which I can’t see but can get connected to you through). The other entry is the permissions I granted you which are to a subset of the possible ways to reach me.” In EnThinnai, we will store for each contact information a permission list identifying the list of people who can access that contact information and the address of your contact page. But we do not store your permissions. It is not clear why he does it either. After all he suggests that you will be able to change the permissions dynamically. I suspect that it is an editorial mistake. So he is storing the same set of information as we do in EnThinnai.

The mechanics one will use in his description is also the same we do in EnThinnai: when I want to contact you, I will visit your contact page and after authenticating myself, I will receive all the modes of communication I am allowed to have with you for that time. Then I can pick one that is most agreeable for my purposes.

He promises to deliver on the upcoming nirvana. But the nirvana is here already and is operational now for a year. Furthermore we have been adding specific communication modes. From the beginning, we have provided an email equivalent, but with no spam. In Spring VON, I introduced the ability to do text chat. In a short order we will provide voice and video capability. In Fall VON, I even introduced what a future business card will look like.

But even in technical details, there some differences. EnThinnai does not require everybody to be running this application. If I want to share my contact information with you, it is not necessary that you also should have installed EnThinnai. It is enough that I have. Tom says that findability is also coming. EnThinnai does not offer that. It has to be done outside of EnThinnai. If I am going to share contact information only to identified persons, what good is it a third person finds out where my contact page is located? I suppose I could make one of the contact information public to the whole world. But that is not what we do in EnThinnai.

Of course there is one fundamental difference. I surmise from Dan’s comment FWD is planning on a central gatekeeper; we plan to license the software that can be installed in distributed servers. We truly believe that there is no need for a Middle.

Daniel Berninger periodically writes in GigaOm under an evocative banner called “Here Comes Trouble”. These posts follow a familiar pattern: Historically the business model (invariably referring to the traditional telecoms) has been to have a control over the users, usually aided by monopolistic and regulatory environments; given the distributed nature of IP Communications, such control is not feasible; so the telecoms are under threat by upstarts. And here is the clincher. Almost invariably he will conclude with one of the upstarts will end up having full control. Even though he invokes distributed nature of IP, he replaces one ubiquitous entity with another. He has done the same thing with his recent post where he seems to suggest that the traditional telephone directory will be replaced by a “social directory” created by merging the telephone directory with the social networking model. Not only that. His concluding sentence is noteworthy:

However, Google’s revenue represents less than a third of what the declining telephone directories generate in the U.S. alone. Riches await the infocom company that achieves gatekeeper status for the Internet’s communications applications.

Let me repeat for emphasis. He thinks that there is an opportunity for a gatekeeper in IP Communications. EnThinnai is betting against that.

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.

In one of today’s post, Michael Arrington takes issue with the big Internet companies for their lack of support for accepting OpenID credentials from others. He argues that

… [they] have made big press announcements about their support for OpenID, but haven’t done enough to actually implement it. … Putting my conspiracy theory hat on, it looks to me like these companies want all the positive press that comes from adopting this open standard, but none of the downside. … It’s all gain, no pain.

Even though he quotes Bill Washburn, the Executive Director of OpenID Foundation and David Recordan, the Vice Chair of OpenID Foundation, he uses their equivocal remarks on this matter to admonish these companies “to do what’s right for the users and fully adopt OpenID as relying parties.” I, as an interested person in being a Relying Party, don’t agree with his analysis and for that matter do not share the general perception of the benefits of OpenID.

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.

Last week we learnt that UK based newspaper Telegraph will provide OpenID to its users. When Yahoo announced only a few days earlier, there was a general euphoria. But this time around the reaction has been lukewarm. Johannes Ernst’s reaction is noteworthy. Given the general perception that first movers will gain strategic advantage, he feels that during 2008 we will see many more joining the growing ranks of OpenID providers. He goes on to say:

It also points to the adoption dynamic for relying parties: companies that believe to be the “gorilla” in their respective markets will push their business partners to accept OpenIDs from them, and preferably only from them. That will look like many closed federations for some time, but it’s inevitable that those will get opened — relying parties will see to that. This OpenID provider rush, and the push into closely affiliated relying parties, are going to be the primary business dynamics for OpenID for the next 18 months or so, in my view.

This is interesting because I am of the opinion that from the beginning the Relying Parties are in the driver’s seat as they get to decide which OpenID providers they will accept. That is why I am expecting OpenID providers to come up with some differentiating features. For example, Vidoop offers a revenue sharing plan for the relying parties. OpenIDs provided by Sun assures the relying parties that they are dealing with Sun employees. As I suggested in the previous post, schools can issue OpenIDs to its students. OpenID becomes useful if the OpenID providers mediate and help the Relying Parties to overcome the Internet dog problem.

Yesterday’s big news item related to our industry was that MySpace reached an agreement with 49 of the 50 state attorneys general that it will lead the fight to stop sex predators. Based on the news reports that it will work on among other things

• developing better technology to screen out underage users
• age and id verification technology
• default user profiles of 16 and 17 year olds to a private category.

Connecticut’s attorney general, Richard Blumenthal is quoted as saying, “If we can put a man on the moon we can do age and identity authentication.” He fully recognizes the limits of the agreement. Says Blumenthal: “But for parents, none of these measures are foolproof. Children can create new e-mail addresses that their parents do not know about; adult strangers could obtain enough information about children to get past the site’s safeguards; pornographic links spring up as quickly as they can be removed.

But if we focus on those children who would like to positively identify their age and at the same time not allow others to freely interact, then OpenID could do the job. We can request the school district to issue OpenID to their students – after all they all have reserved domain names of the form k12.state.us – that will be valid only if they maintain their student status. Since the schools are in a better position to authenticate the age of the students and that the management of the ID is distributed, it is scalable and can be realized in a short order. The agreement also calls for the ability to allow adult family members to interact with the minors. This also can be done by the school district because they can assign differentiated OpenID to the family members. The family members and the age group of the student can be made part of the Attribute Exchange process.

Facebook used email id issued by an .edu domain name holder for identification. Use of OpenID is similar to that but can be enriched because of Attribute Exchange. Of course, the ultimate control is for each family to run its own social network in a distributed manner. That is one of the applications of EnThinnai.

I came across this site ostensibly belonging to Joseph Poon. His idea is to instead of distributing a standard business card he will give one that contains the URL of that site and an access key. To get his contact information, one has to go this site and enter the access key. Then you will be presented with the contact information filtered specially for you. The card has maximum of five elements – name, title, company, URL and access key. I had suggested this form of calling card previously.

At that site, you can provide your OpenID instead of access key. If he had entered your OpenID in his database, then you can enter that instead of the access key. In this respect this idea is same as how EnThinnai handles distributing one’s contact information. He uses access key for those who may not have OpenID initially.

Interestingly, Scott Kveton reports that a similar discussion took place at the OpenIDDevCamp today. (It is not clear whether Joseph’s effort is an independent one or is it part of DevCamp.) He concludes with:

I can see all kinds of applications for other types of information you might want to land there as well (can you say your lifestream?). Looks for some folks (maybe those attending OpenIDDevCamp?) will implement these features in the near future. Let’s get some code out there and start playin’ with it!! Yeah!

Scott, please feel free to take a look at EnThinnai to see some of these being implemented.

There are reports that Google, IBM and Verisign are planning to join OpenID Foundation. But it is not clear what does this really mean. Verisign is already an OpenID Provider. Will the other two also become OPs? Since Blogger (which is part of Google) will accept OpenID as a way to authenticate commenters, will Google accept OpenID in other applications as well? Notwithstanding these open questions, this is encouraging. On the flip side, there is a significant amount of skepticism about the utility and usability of OpenID. For example, only yesterday Mark Evans wrote about his poor experience with using OpenID. So much so he feels that OpenID could become an Edsl. He also quotes Devon Young and The Identity Corner to substantiate his points. This clearly suggests that those of us who advocate OpenID must address their concerns and streamline user experience.

Benefits of OpenID – Company line

The current narrative on the benefits of OpenID is that it allows for single sign-on and registering at a new site becomes easy and simple. But the distracters reject the benefits of single sign-on based on privacy and security concerns. They prefer to have different login credentials. Directed identity will allow a user to present a different id to different sites. Still this is not satisfactory because the OpenID provider has the information on a big chunk of the user’s web activity.

As a practical matter, the registration process has not been simplified even with attribute exchange. It is possible that OpenID provider has not collected the information the site is interested in or they are compelled to recollect it for legal reasons. So how do we position OpenID?

Credit cards and OpenIDs

In my opinion it is better to compare OpenIDs to credit cards. A credit card company issues cards to its members and provides monetary guarantee to the retailers. An OpenID provider issues IDs to its users and provides some form of authentication to web sites. Just as a credit card company may place limit on the level of guarantee, web sites are at liberty to restrict the OpenIDs it will recognize and accept. Just as many of us carry more than one credit card, we may have multiple OpenIDs and use them for different occasions. Just as some department store credit card is not accepted outside of that store, it is possible that IDs issued by some OpenID providers may not be accepted by some sites. The credit card companies have good amount of information on our spending habits. But they are expected to maintain certain amount of privacy. Similarly we can expect OpenID providers to maintain privacy of their users. But at least initially, it becomes the users’ responsibility to identify conforming providers.

The beauty of credit card system is that credit management is independent of retailing. It frees the retailers from evaluating the credit worthiness of the card holders and collection activities. Thus even small retailers can afford to accept credit card, which simplifies the consumer’s life. Still, it is possible that a particular retailer asks for extra information like phone number from the consumer. OpenID provides analogous benefits to web site operators.

Restricting OpenID providers

Under certain circumstances, a web site operator may restrict the OpenID providers it will accept. For example a site targeted for senior citizens would like to ensure that a new user is indeed a senior citizen but that site can not reasonably confirm the age of a new registrant. But AARP is in a position to assure that its members are indeed senior citizens. So if AARP issues OpenID to its members, then they can use their OpenID to register themselves in that site. Interestingly, one of the reasons Sun stated for issuing OpenID to its current employees is to facilitate them to get employee discount from Sun’s partnering companies.

User Experience

OpenID verification protocol has too many redirection between the web site and the OpenID provider. This redirections could be a bit confusing and also prone for phishing attacks. We need to address this concern as well. Verisign has a Firefox plug-in called Seatbelt that simplifies the log-in procedure. But there is a simpler way that anybody can follow as long as the browser allows tabbed window. The idea is to visit the OpenID provider on the first tab and login there and leave that tab open for the rest of the session. Now if we use other tabs to visit the web sites of interest, then there is no need for providing login credentials. So if a web site presents with a screen asking for login credentials, we will know that a phishing attack is under way.