In addition to the protocol for semantic email messages I am developing here I do believe there is a need for the more light weight, faster and simpler (ASCII only!) status messages/tweets. So I am going to be running a federated status.net server of my own as well.
Jan 24
PubIdHub->Web Finger
Ramblings
Comments Off
One thing that has always amazed me is the lack of Identity online. There is not even a standardized phone book! A lot of it is due to the inherent problems with email, privacy and spam.
OpenID is a very promising approach but I can not understand why we have to introduce yet another identifier for people? Your personal email is already the de-facto identifier used on numerous websites. What is missing from the equation is a simple bridge between OpenId/OAuth and email. I imagine a simple REST API answering to requests by email or hased md5(email).
http://pubidhub.net/johan.sellstrom@gmail.com/{json,atom}
In return you would get the OpenId provider (if any) as well as a list of public feeds/service ids on various social networks, amazon, ebay or whatever. If an OpenId provider is present the requesting service simply invites to provider to the OAuth dance. If not, we would have to resort to traditional signup but at the same time offer to provide OpenId services. This way we would release the OpenId virus. What is interesting is that a lot can be facilitated by the fact that major identity providers such as Google, Yahoo etc are already OpenId providers and thus we can automagically deduct and assume a default OpenId URL from any *@gmail.com or *@yahoo.com address. The PubIDHub would cache such information until the identity owner takes control and updates the setting.
I am planning to build a simple PubIdHub service to use in the development of this project and hopefully it could evolve. To be totally honest I have not fully penetrated the proposed standards such as XRDS-Simple and OpenID Discovery but I only need something simple. In addition I will discover memberships and affiliations using my own little spider hack and I do not believe that is part of the scope for standardization? Please correct me as I am probably wrong.
The format used for the {json,xml} replies will of course be PortableContacts.
Update: I found this description from the Django Project
“A Consumer wishing to access a user’s data via Portable Contacts must start with an Initial Identifier for the Service Provider containing the user’s data, usually provided by the user. In many cases, this may be the domain name of the Service Provider’s web site, such as sample.site.org, but may be a more specific URL, such as the OpenID identifier of the user, if available. Consumers then perform Discovery on the Initial Identifier to determine where the Portable Contacts endpoint for this Service Provider resides. If successful, the Consumer may then attempt to request information from that endpoint. If the endpoint contains private data, the Service Provider will return an authorization challenge, and the Consumer must then guide the user through an appropriate authorization flow to obtain the credentials necessary to access this private data. Upon successful authorization, the Consumer may request data from the Portable Contacts endpoint using these authorization credentials. Whether accessing public or private data, Consumers may request a specific subset of the user’s data using standard Query Parameters. Upon a successful request, the data is returned in the response, and the Consumer may then parse the response data and use it as desired. ”
UPDATE: Duh, this is actually called web finger: http://code.google.com/p/webfinger/
Jan 24
Eating your own dog food
Ramblings
Comments Off
In recent years the struggle to communicate and stay up to date has become more challenging. There are simply too many channels. While it used to be letters, facsimile, phone (landline/mobile), Short Messaging Service and email we have now added the PC equivalent of SMS in so called Status Messages (i.e Twitter) as well as different types of Social Network messaging (public wall posting, private messages, instant chat messages) and finally a strange hybrid in the form of Google Wave. My focus has been centered around my email inbox and all these other fire hoses of information are har to keep up with. What is being designed in public on this blog is an attempt to solve my own communication problems in the hope that I am not alone and that others might find it useful as well.
Jan 20
By definition the Internet is a network of randomly distributed nodes and it owes a lot of its greatness to that topology. So why did we let Facebook become one central point of failure? What is Social Networking? To me it is just messaging in a Semantic Context. It becomes quite obvious looking at Facebook Lite and the iPhone App. What is that Facebook has that regular email does not?
- Spam control. By only allowing your “friends” to contact and see your activity you solve the most prominent problem of legacy email.
- Semantics. Everytime you receive something new in your News Feed (or whatever they call it for the moment) it has been tagged and contextualized. A did this to B in the context of C.
- User Experience/UX. Your Inbox sure looks a lot more interesting and less intimidating in Facebook than it does in Outlook Express or any legacy email client (including such webmail darlings as gMail, Yahoo, Hotmail and, heck, even Wave)
- Publisharing. Access controlled sharing of private photos.
There are a lot of initiatives around the web to alleviate the situation and try to come up with new technologies and protocols that will finally give us distributed social networking. Email is already by far the largest social networking tool in existance and all of the above could be solved by simply adding a few layers to the email protocol! Lets have a look at some fundamentals before dissecting them one by one.
The most important thing that has been missing on the Internet from the beginning and until recently was Identity or as some like to call it, Digital Identity. That should really have been listed as paragraph one above. Before Facebook there has not been one central catalog with most of the web active people of the world. It is not that the technorati has been neglecting the issue. The OpenID movement started well before Facebook became the de facto standard and harbinger of Identity via its Profiles. That could have been fine and hunky dory if not for one small problem. Facebook owns and controls your data and can without trial simply cut you off and kill you online. That is totally unacceptable and needs to end right now. OpenID/OAuth/OpenSocial are already there to provide fully equivalent alternatives to Facebook Connect and the F8 API. We just need to move on.
Lets have a look at what should be provided by a DIP – Digital Identity Provider.
- Basic Profile Data such as name, address etc
- ACLs or Access Control Lists reaching far beyond the simple *friend* concept.
- Media libraries or pointers to external storage repositories. Any external repository has to be ACL enabled.
A lot can be gained by elevating people to the ranks of servers in terms of how they communicate via APIs. Just as the New York Times asks you for permission to post on your Facebook Wall when you read an article is done via Facebook Connect where the servers nyt.com and api.facebook.com exchange tokens to be used on your behalf we could do the same for the act of befriending.
Lets look at Person A and B each with their own Identity Servers a.dip.com and b.dip.com respectively. Maybe A does not know B too well but would still like to be able to contact him and see when and where he is available (presence). So, asynchronously A sends a Connect Request to be asking for {contact,presence} but leaving things such as permission to view photos and blog ramblings, restaurant reviews etc. Later when B goes through his list of connect requests he accepts contact permission but denies presence. His Identity Server therefor issues and signs a persistant access token and delivers it to a.dip.com. Each time A wants to contact B his server acting on his behalf will have to sign any message using this token and on the recieving end Bs server will cross check the token against his ACL to determine if the message should be rejected or not. What is important is that B ,having given permission, can revoke the token at any point. He might however unprovoked choose to upgrade to As access to include say {photos,blog} once the relationship matures. A will be notified of this and may choose to accept or filter this access from his Incoming Activity Stream. This was just a simple example that will be elaborated upon in later more technical posts.
When it comes to semantics it would be very easy send out Event notifications using the schemas and DTD defined by ActivityStrea.ms. Either we simply put the XML data in the Headers or come up with a new Microformat that embeds the machine readable parts in XHTML. In addition to this and to support not always on devices any media links will be dereferenced, downloaded, thumbnailed and attached inline. This approach means that any HTML capable email client can consume Activity Streams. In order to elevate the UX Semantic Mail clients will however choose to render the stream similar to Facebook.
So far I have been discussing How without adressing the Why. The answers are obvious.
- Scalability. Facebook has to spend hundreds of millions of dollars every year to provide the infrastructure to handle the messaging need of 350M users. Email is a federated protocol with an almost unlimited numbers of servers providing either free service and storage or bundled with from your Internet Access Provider – ISP. The infrastructure is already there without marginal cost and it is robust, resilient and fault tolerant enough to guarantee delivery of all messages. The mere cost of competing and running an operation on the scale of Facebook is undemocratic and a threat to the free world. Semantic Mail will level the playing field.
- Privacy. At the moment Facebook can (and does) read your messages. As a matter of fact that is their primary means to reach their business goal of precise ad targetting. Yes, your email provider can also read your mail (unless you encrypt it) but we generally accept and understand that. The difference is that in a distributed email scenario no one organization can spy on all our communcation (yeah, I am forgetting about Echelon and the NSA). The DIP will only have access to your Social Graph and ACLs. Not all functionality can be pushed all the way to the client as they can not be trusted to be available to validate access tokens when someone wants to access say your blog or publishared photo album.
- Offline. In many parts of the world people are skipping the PC and sees the Internet through their mobiles for the first time. Email is excellent for such devices given the local message cache and the special features such as Push Mail having been developed for mobile not always on devices.
The only part we can not conveniently handle with IMAP and SMTP is the Publisharing of data but that is solved by the Digital Identity Provider.
To be continued
