FWD International’s Design Objectives
Nov 12th, 2007 by Aswath
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.
- 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.
- 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”.)
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.)
- 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 )