EnThinnai Blog

Yesterday Robert Scoble used a tool from Plaxo to scrape Facebook to retrieve information about his friends. But Facebook deemed it a violation of its Terms of Service and blocked his account, though subsequently it was unblocked. But the more interesting aspect of this episode is the ensuing discussion. It is reassuring to know that some of the salient points people made is in line with the design philosophies and service objectives of EnThinnai.

For example, Marc Cantor feels that opt-in control would solve the problem. He states:

By providing an explicit opt-in mechanism end-users would have to check “YES – I want to allow my email address to be exported inside of my friend’s lists of their friends“, which at that point who are YOU Mr. Social Network vendor – to prevent me from doing what my friend’s say is OK? … Certainly it’s a great day for … DataPortability.org.

Of course in EnThinai, users can identify who has access to any stored information, not just contact information. Additionally, the permission list can be dynamically modified.

Dave Winer wants Facebook to learn from this episode and open up their network.

It’s a big effin loop we’re in. One of these times around one of the companies that feels (incorrectly) that they have a lock on their users, will voluntarily give it up and be a leader in Generation N+1. I’ve never seen it happen, but in theory I think it could.

However, if Facebook doesn’t open up and allow people a system to say who can access what information, we still have to create that system somehow. Google could have done it, but they didn’t. Same with Yahoo or Microsoft. These companies don’t want to empower the users, but if they studied history, they’d see that the evolution of computers always comes in fits and starts. A period when the technology is new and people are snowed by the companies and let them have full control. Gradually people understand what’s going on, and figure out they’re being screwed but they accept it. And then explosively the whole thing disintegrates in a new layer of technology.

Dare Obasanjo feels that data portability folks don’t go far enough. He says that they “want to make it easy for you to jump from service to service. I want to make it easy for users of one service to talk to people on another service.”

But this time the technology like OpenID, OAuth are at hand. So it is feasible to realize this vision. This is the path we are taking at EnThinnai. Actually with EnThinnai users run their own autonomous social network and exchange information with their friends.

This morning Jeff Pulver posted an entry in his blog about how VoIP will again be a disruptive force in 2008. He predicts that IP Communications, which is a natural extension of VoIP, combined with social media will engage consumers in the coming year and that this combination will start social communications revolution. As a response, Kfir Pravda suggests that the first stage will be based on two main features – Presence and Unified Address Book.

He further elaborates on these two features. For Presence, he is not satisfied with a simple notification. He would like to combine status information from multiple sources and be able to present different status information to different people “based on the level or type of connection”. This is what we have implemented in EnThinnai and we call it “Availability status”. Of course currently the process of combining multiple inputs is not automated, but that is our plan.

For Unified Address Book, he doesn’t want to differentiate between the connections in different social nets.

For me, I have only two considerations: who do I need to contact and in which format (synchronous voice conversation, voice mail, video conferencing, mail or IM). I don’t want to know what is his/hers “address” in any of these different means of communication. Who cares about telephone numbers, email address, IM nick names, and social networks entities? I just want to connect to the other person.

Right on Kfir. With EnThinnai, my buddies can access my Contact page get relevant communication mode and the associate addressing information. Indeed this information will be customized in accordance to his thoughts regarding Presence. With the Real Time Communication capabilities that we are planning to develop, my buddies will be able to directly communicate with me with out requiring to go to a third party application.

Kfir concludes his post with three open ended statements/questions:

• “The one who would achieve that would change the way of communication as we know it.”

That is our expectation as well. Since our plan is to realize it in a distributed fashion, we are hoping that finally Jeff Pulver will say, “Indeed, you can be your phone IP communications company.”

• “Can it be done by a simple company?”

We are a simple small company (it may not even a company, but we can handle complex thoughts and models). But we need your support, so please spread the word.

• “How would Standard bodies affected and effected from this process?”

Even though we are spearheading this effort, in the final analysis the APIs needed to exchange data between multiple users (OpenSocial?) and the way to authenticate these exchanges (OAuth) need to be standardized.

Happy New Year to “us”. We are looking forward to this year because we have planned to add new and exciting features that will further differentiate EnThinnai. Thank you for continuing to support us.

In a user-centric social network (aka distributed social network) two friends who would like to share data will nominally use different servers. So we have to decide how the data will be shared between the four entities – the two servers and the two clients. In effect we need to decide who will pull the data from whom.

Email is an early example where such a decision was made. In email, the sender’s client pushes the dat to its server, which pushes it to the receiver’s server from which the receiver pulls it finally. In my opinion the fact that the sender’s server pushes the data to the receiver’s server has been problematic. To protect its potentially limited storage, the receiver’s server may place arbitrary limit on the size of the data. It would have been preferable for the receiver to pull the data from the sender’s server. But it was not feasible because there was no way for that server to authenticate the receiver.

In more recent times, Instant Messaging services share Presence information of its users among designated “buddies”. Almost all of the IM services have adopted the policy of pushing the Presence information to the clients. As the number of buddies a user has increases, the Presence server needs to scale to handle the traffic. Still they were manageable because, except for the case of limited peering instances, the presence information is centrally located. But in our case, the servers are distributed. So we need to reconsider how to distribute presence information.

These and some additional considerations prompted us to classify the data into three categories and use pull/push method as appropriate:

1. Information like “Availability status” are temporal and changing dynamically, but continuously available. Also buddies may be interested in being notified when there is a change is the value. For such data, our plan is for the user to push the data to the sender’s server and allow the buddy to pull the data after authentication using OpenID. Additionally if a buddy is interested in notification, then the buddy can register with the sender’s server. When such an event takes place, the sender’s server will send the notification to the receiver’s server. That server can send a notification (via email, SMS or a third mechanism) or the buddy can pull it from the receiver’s server.
2. Information like Calendar appointment are sporadically generated, may be modified and of limited interest even among the buddies. Also, buddies would like to generate such data but need to be approved by the user. For such data, our plan is for the user to push the data to the sender’s server and allow the buddy pull the data after authentication using OpenID. In the case where the buddy is generating the data on behalf of the user, then the buddy will push the data to the sender’s server, which will send a notification (via email, SMS or a third mechanism) or the user can pull it from the user’s server.
3. Information like Notes, files and photos are bulk items are generated sporadically but persist for a long period of time. In such cases, the user will push the data to the user’s server, which will send a short notification (via email, SMS or a third mechanism) or the user can pull it from the user’s server.

In short, the data is always stored in the user’s server from which the buddies pull the data. In certain cases, a short notification is passed from the user’s server to the buddy’s server and the buddy’s server uses an external mechanism to notify the buddy. There are supplementary benefits to this approach. There is no requirement for a buddy to run a server or be part of a private social network; it is sufficient to have access to the Internet and have an OpenID. The user can monitor who and when the buddies accessed the data and can maintain a log.

This morning Jeff’s status in Facebook read: “Jeff Pulver is wondering if we will still be exchanging business cards in 2010. And why?” An indirect answer:

Jeff’s business card in VON Fall 2007:

His business card in VON Spring 2008:

A couple of days back, Anne Zelenka wrote about DiSo, an approach to building a distributed social network using WordPress as the basic platform. A week back, Chris Messina mentioned in his blog about his plans to work on a “prototype project to build a social network with its skin inside out” and he called the project DiSo. As I mentioned in a previous post, others have expressed a desire to have a distributed social network as well. Based on the comments posted in response to Anne’s post, it is apparent that many others (including yours truly) have been working on realizing this objective. Anne’s post is focused on DiSo and WordPress. If the objective is truly distributed social network, then neither is critical. One could have multiple platforms and multiple implementations. They all should work just fine.

As I mentioned in my VON presentation, three things are needed: a web-wide identity mechanism, an open API to post and retrieve data from one site to another and finally a way to authenticate the entity that is invoking an API call. OpenID and OAuth provide the needed technology for the first and the last items. So the critical item is a generally accepted set of APIs. I am hoping that OpenSocial will be that.

A friendly competition between multiple efforts will do all of us good. So be open and give your attention to all of us. If you are interested in distributed social networks, please take a look at other efforts as well.

In a post yesterday Brough Turner laments that he has multiple communication modes – email, IM and the like, has multiple identities – email id, IM id, has other presence in the Net – blog, social network and the like. Additionally he notes that each of these services allows him to maintain directories of friends, business associates and other acquaintances. Finally he notes that he can access all these using different devices. He wants to know who will aggregate all this in a convenient and meaningful way.

Our thinking at EnThinnai is that it is best if the user aggregates all this information. Introducing a third party will just introduce another redirection with no appreciable benefit. Accordingly, EnThinnai allows the user to create a master list of friends, group them and allow different access privilege. Secondly, EnThinnai allows the user to consolidate the “presence information” from these disparate sources and present a single “availability status”, customized for each of the friends. Thirdly, EnThinnai allows the user to dynamically present a subset of the multitude of access information. In other words, the user can present an aggregated view as far as access is concerned. I feel that EnThinnai belongs to the new class of solution that Brough is anticipating.

In yesterday’s post Chris Messina quotes Joseph Smarr who has laid out an import set of roles that help to clarify how pieces of applications should be architected: “ first of all, people have contact details like email addresses, webpage addresses (URLs), instant messaging handles, phone numbers… and any number of these identifiers can be used to discover someone (you do it now when you import your address book to a social networking site). In the citizen-centric model of the world, it’s up to individuals to maintain these identifiers, and to be very intentional about who they share their identifiers with …”

This is exactly what we do in EnThinnai. Here, the identifiers are stored in the user’s server and the access control list, which is under the control of the user, determines who has access to them.

Another day, another post damning Facebook. This one faults the execution and personally attacks the young Founder and CEO. “In the space of a month, it’s gone from media darling to devil,” according to Josh Quittner, the author of the post. Even though most of the users of Facebook does not know because “[i]t works as well as it ever has”. “The market is fickle, something better is in the wings, and as soon as it arrives, the alienated and angry mob will race to it. Delphi’s errors begat Prodigy and its errors begat AOL, which was crushed by the Web.” He concludes, “The most interesting thing about Facebook right now is who will replace it.”

Of course we at EnThinnai believe it will be “User-centric social networks”.

With the rise of social networks, a sizable number of people have expressed concern that user generated content is being locked up in hands of a few who benefit enormously. To protect this, these networks have hindered attempts by users to port the data from one network to another, confirming the concerns expressed by the first group. In a recent post, Abhishek Tiwari echoes these concerns and suggests that these networks should enable web-service access to these data. To a large extent this is the idea behind OAuth and OpenSocial from Google. Bill Wishon while commenting on this post observes that large networks like Amazon and Facebook have no incentive to share the data. So it appears to me that an alternate solution would be for users to save a copy of the data they generate in these sites for later use. During the days of typewriters, we used carbon paper to make a copy as we typed; email clients routinely save a copy of the mail we send out. So why not the browsers make a copy of the data that we generate at these sites? To elaborate further, I am suggesting that a plug-in for the browser that will scrape the local screen, collect the data as it is being generated and uploaded to the social networking site. Thus collected data can be stored either locally or if further sharing is required, in a user-controlled server residing on the public Internet. Not surprisingly, I am thinking of EnThinnai here. Since EnThinnai provides controlled access to the stored data, users can decide which other third parties can access which portion of the stored data and when.