EnThinnai Blog

Two weeks back, one of my inspirational leaders Tom Evslin announced that he is taking on the duties of CTO for FWD International. In that post, he revealed that FWD International will be “[e] nabling voice, video, and other forms of communication into and between social media sites and connecting that all with other networks.” He also listed 9 “constraints” and 1 “non-constraint” that will guide them in their development. It will be an interesting exercise to see how EnThinnai compares to these set of guidelines. Certainly some of these principles do not show up in the current version; in those cases I will be comparing to our planned design. 

1. Communication is permission-based: In EnThinnai the user will be able to set permission for every piece of data. For example, the user can stipulate the Availability status that can be shared with a specific individual, a group or the whole list. Similarly, the user can specify the list of permitted buddies who can access specific contact information, a Note or a file.
2. Every user owns his or her directory information and decides how it gets used: Even though the current version runs under a single umbrella, the design is such that each user has her own database and can be hosted in an autonomous server controlled by that user. (EnThinnai is truly a “product”.)
3. Communication is between people with names, not between devices, not to or from numbers: The current version does not support real-time communications. But as the current implementation itself suggests that the individuals are identified by their OpenID and for users’ convenience, these OpenIDs can have local aliases that resemble names friends give to each other.
4. There should be no islands: EnThinnai does not require a buddy to be a registered user of EnThinnai; it is sufficient that the buddy have an OpenID. Since OpenID is user-centric and not controlled by a single authority, there are no islands. The whole Internet becomes a the whole range for EnThinnai.
5. Every communication can include text, pictures, voice (sound, actually) and video: The current version does not support real-time communications. But when it will support, our plan is to support the objectives of Unified Communications. Even in the current version, a user can embed links to YouTube and other such sites to share pictures, video etc.
6. Any communication can be real time or not: When we add communication capability, we will use SIP protocol and will be able to select and negotiate the session characteristics with the other participants of the session.
7. Presence information is very important: We feel that it is not only important, but it should be reflect more than the status of the keyboard. That is why we selected the phrase Availability status, rather than Presence. What is more, third party applications, like Calendar or authorized agents will be able to have input into the algorithm that will determine the status.
8. Charging incrementally for interpersonal communication is passé: We provide a product and not offer a service. So this question does not arise. (In case there is a market need for a hosted service, the charges will be based on the incurred cost.)
9. Everything we do should be exposed through the simplest APIs possible: EnThinnai visualizes a distributed model with each user running their “thinnai” in autonomous servers. This model requires an API. Our plan is to use an open (standard?) API set so that third party applications can access the data as well. Our current plans call for use of OpenSocial (or extensions thereof) and OAuth for API authentication.

And for that non-constraint … 

• We’re not letting ourselves worry about downward compatibility with the POTS network: We are not in agreement here. Our view is that PSTN is a “sub-network” of the “Internet”. Just like the Internet translates a domain name to an IP address which is then finally translated to a “hardware address” (MAC address), calls to PSTN will be handled. But the user interface will be uniform across all “sub-network”. The choice of codec will be based on the real-time conditions whether the call is to PSTN or to another IP end-point. (In reality, we are in agreement with the spirit of the non-condition, but it makes a good copy if there is a disagreement someplace. J )

For the past couple of days, there has been a lot of chatter about OpenSocial from Google. People have focused on how developers can write applications once and run it in multiple social networks (“containers”). Some have suggested that this falls short, because the ultimate goal is to knock down the vertical silos created by each of the social networks. What is required is for the development of an open container that pulls data from all the individual social networks and present list of friends, feeds etc and displays in this container. At the same time, this container must allow for one to post to one or more social networks. This way one does not have to visit multiple social networks. This can be achieved by properly using OpenSocial API and OAuth.

EnThinnai addresses this problem in a different way. It will allow a user to maintain her “social graph” in her server; will notify new information to the affected friends; will retrieve information from friends from their servers. This way we truly knock down vertical silos and allow users to take the ownership back from social network providers. Of course the current version of EnThinnai does not provide distributed servers; but otherwise realizes other objectives. Please register for EnThinnai and explore its features and services.

In a post today, Paul Sweeney expressed his concern about using EnThinnai because “lack of company information and information on who has developed to the service a little off putting.” The truth of the matter is that we are not yet a legal entity in any shape or form. We are a small group of people (one in US and the rest in India) who have somewhat unorthodox view on how to do IP Communications and certain amount of development know-how. We are self-funded, that too by a salaryman. So our resources are limited and have been targeting them at developing the application. Given that, we have been careful in collecting your personal information. Currently we are using Amazon Web Services’ EC2 for running the application and store the database, and S3 to store files. We hope that will give some level of assurance. Still, during the current trial we can only ask you to sign up and try out the application as a favor to us so that your feedback will only enhance the application. We hope the novel concepts and approaches we utilize, prompt you to support and encourage us. But till we put in place the required legal structures in place, you need to consider twice before you use EnThinnai for sensitive data.

Brough Turner in his post yesterday mentioned that EnThinnai has “done a peer-to-peer implementation with a choice of query (you only ask when you’re interested in knowing my availability) or subscribe (you want to be notified when I transition to a specific state).” I didn’t flag it because I took it as his way of saying that not all users need to belong to the same central server as is normal in most of the currently deployed Presence servers. As a follow-up to Brough’s post, Paul Sweeney, while commenting positively about the technical aspects of the features in EnThinnai, expresses concern regarding lack of information about the company or people behind this effort, “[e]specially as this is a P2P play”. So I want to confirm in no uncertain terms that EnThinnai is not P2P; it is most assuredly a client-server model. But the difference is that theoretically it is possible for each user to have their own server, that they control and store their digital information. The way it works is that when a buddy of mine wants to access my Availability status information, she will access my server (whether or not she has her own server is immaterial here), upon which my server will authenticate her and then provide the required information. I want to point that it is feasible for me to run EnThinnai in my server with all of my buddies not having their own EnThinnai servers.

Yesterday’s post describing how EnThinnai handles Availability information and future plans on enhancing it got favorable reviews from a handful of thought leaders. Today I will describe how EnThinnai makes available to your buddies your contact information that is relevant to them and appropriate at the time the query was made.

EnThinnai allows a user to store all sorts of contact information like various telephone number, email addresses, geographical addresses, IM ids and so on. In addition to this, for each piece of contact information, the user can identify which subset of buddies can access that information. The process by which a user can specify the access control list is made simple: when a user adds a new buddy, a pop-up guides the user to specify which contact information the new buddy is allowed to access; for a buddy who is already in the Buddy list, the user can drag and drop the buddy’s name into an icon next to the desired contact information. It is also simple for a buddy to access the contact information of the user: if the user is in the Buddy list of the buddy, then the buddy will just drag and drop the user’s name into the Address Book tab. The system will retrieve all contact information that the user has allowed this buddy to access. Since the user can populate the fields with the current contact information and also can dynamically change the access control list, EnThinnai makes the most up-to-date contact information available to the buddies. 

A future release will make this feature more powerful when third party applications will be allowed to both populate the contact information and also add/delete buddies from the access control list. For example, consider the case where the user has scheduled an important conference call with a client. Then the Calendar application can instruct EnThinnai so that all other buddies (except for this client) will not be able to access phone contact information; even this client will be given only the phone number that the user is planning to use for that call.

Wait a minute! You mean to say that buddies need only one information – how to access the user’s EnThinnai. This becomes the user’s “number for life”?

Exactly. But that is for another post.

The following is a list of references where EnThinnai is discussed or mentioned.

•  10/23/2007
  • Paul Sweeney – He likes the idea behind Availability status and how it is made availble to others. But he finds “the lack of company information and information on who has developed to the service a little off putting.” The post “About Us” is in response to this observation. 
• 10/22/2007
  • Brough Turner – He likes the implementation of Availability status and thinks it is close to his line of thinking. We knew that! 🙂
  • Gokul Gopalakrishnan – He believes we have the potential to leverage presence to the fullest.
  • Greg Galitzine – “…offer[s] some cool, Web 2.0-like promise.”
• 10/21/2007
  • Rich Tehrani – He introduces EnThinnai to his readers by highlighting the importance of “Presence information”, need for maintaining privacy and the ability to provide individualized information.
• 10/17/2007
  • Tom Keating – He introduces EnThinnai to his readers. He says that use of OpenID for authentication is a cool feature. He points out the benefits of using Amazon EC2 and S3. Once he recovers from his recent vacation, he is going to try out the application. I can not wait for his valuable feedback.

Presence is a common feature in many Instant Messaging applications. Nominally it reflects the status of user’s interaction with the computer that is running the application and has been used as an indication of the user’s readiness to interact with others. When it was originally conceived, most used a dial-up access and it is important to know whether a user is connected to the internet. Now most of us are always connected to the internet and have multiple devices connected at the same time. Consequently, the traditional Presence information is not very informative. For example, if I am busy on my computer and not used the standalone VoIP device is inactive, its Presence information will indicate that I am “away”. What good is this kind of Presence information and how could it become the “new dial-tone”?

Taking the above under consideration, EnThinnai does not provide “Presence” information as discerned by it; instead we allow the user to set the “Availability Status” information. The user can select one of the predefined values or can define a custom value. Additionally, the user can set the value globally applicable to all the buddies, or buddies belonging to a specific group or to a specific buddy. At first blush, requiring a user to manually set the value for Availability Status may look cumbersome or unwieldy; but this facilitates a future release to allow an authenticated third party to set the value. Indeed we envision EnThinnai or its agent to synthesize status information provided by multiple applications to a single value specific to a buddy, group or for the whole list. If you are familiar with iotum’s Relevance Engine, you know what I mean.

EnThinnai’s approach is also unique in the way the Availability information is notified to the buddies. Normally, Presence servers constantly update the status information to all the relevant parties. But we would like to avoid common centralized servers. One of our objectives has been to ensure that we realize all the features in a distributed fashion. Additionally, we feel that constant update places enormous load on the Presence servers. Since a user is interested in a buddy’s Presence information only occasionally, we feel that it is just as effective to query the information as and when it is required. If a user is interested in the change in the status, that can also be handled by registering for such an information with the buddy. Accordingly, in EnThinnai a user can get the Availability status information by hovering the mouse over the icon next to the buddy’s name. A future version will allow third party applications to retrieve the Availability Status information and also can register to get notified when the status changes.

Since the traditional Presence servers passively broadcast the Presence information, it is possible for a buddy to track a user over a period of time without that user’s knowledge. That is not possible in EnThinnai. Since the buddy has to query the status each time, EnThinnai can keep a log of such queries. In the current implementation, this log cn be accessed under the Syatem tab and Status Query Log sub-tab.

All in all, EnThinnai provides Availability status information using a different architecture that allows for distributed servers and protects the privacy of its users.

Many aspects of this feature is better articulated in an independently developed paper “New Presence” authored by Alec Saunders. Interestingly, Brough Turner in a follow-up suggested that we use “Availability” instead of New Presence. I hope that they feel that our implementation is in the right direction towards their stated objectives.

This morning we opened up registration for a new and exciting web application we call EnThinnai. EnThinnai provides a simple way to store and share digital information with your friends and family, called buddies. You interact with EnThinnai via a simple unified UI to exchange with your buddies digital information like notes (think of whitelist based email), share files and contact information. At this point this description reads like any other social networking application. But EnThinnai has many differentiating features. Indeed even the motivational objectives are also different.

First let me describe the differentiating features of the deployed version. To begin with, EnThinnai uses OpenID for authentication. There is no need for your buddies also to be registered users of EnThinnai. The only requirement is that they have a valid OpenID. Thus you do not depend on the popularity of EnThinnai to realize the “networking effect”. Since many people have already an OpenID (even if they may not know of it), the networking effect OpenID is big.

Almost all social networking applications share, if to varying degree, your data with others. EnThinnai’s operating principle is “default deny” – stored information will be stored only with the people you explicitly identify. An implication of this is that you can not search EnThinnai to locate your potential buddies. You have to establish contact with a person outside the context of EnThinnai to exchange respective OpenIDs. Traditional social networking sites allow for one to form new friendship or to renew lost friendship. By necessity, they are public places like a bar. By design, EnThinnai is a private realm with a reach to the outside world – it is like your front porch (thinnai, in Tamil).

In most of the social networking applications, the buddy relationship is mutual – I can be your buddy only if you have agreed to be my buddy. Some new applications have recently introduced a concept called “follower” or “fan”, which is kind of one-sided relationship. In EnThinnai, the relationship is always one-sided (a mutual relationship is made up of two one-sided relationship). If I have declared you to be my buddy then it means that when you post a Note to me or share files with me, I will get a notification. You need not have declared me to be your buddy for you to send me a note.

I feel that EnThinnai is a better way to share the digital world with your established buddies. It also has lots of new and exciting technology that will allow its users to derive new benefits of IP Communications. I will elaborate on some of them in subsequent posts. Meanwhile, please register yourself and explore. What do you have got to lose and you will help us to test the application. We shall be indebted to you.

We are not yet a legal entity in any shape or form. We are a small group of people (one in US and the rest in India) who have somewhat unorthodox view on how to do IP Communications and certain amount of development know-how. We are self-funded, that too by a salaryman. So our resources are limited and have been targeting them at developing the application. Given that, we have been careful in collecting your personal information. Currently we are using Amazon Web Services’ EC2 for running the application and store the database, and S3 to store files. We hope that will give some level of assurance. Still, during the current trial we can only ask you to sign up and try out the application as a favor to us so that your feedback will only enhance the application. We hope the novel concepts and approaches we utilize, prompt you to support and encourage us. But till we put in place the required legal structures in place, you need to consider twice before you use EnThinnai for sensitive data.