Blue Screen Of Duds

Where the alter ego of codelust plays

Archive for the ‘Blogging Frameworks’ Category

Decentralized Social Data Framework: A Modest Proposal

with 3 comments

Twitter being down is no longer funny, nor is it even news anymore and the same is the case with Twitter-angst, where loyal users fret and fume about how often it is down. One of the interesting suggestions that have come out as a result of this is to create a decentralized version of Twitter – much on the lines of IRC – to bring about much better uptimes for the beleaguered child of Obvious Inc.

I would take the idea a lot further and argue that all social communication products should gradually turn into aggregation points. What I am proposing is a new social data framework, let us call it HyperID (since it would borrow and use heavily ideas and concepts from OpenID), from which social media websites would subscribe, push and pull data from.

Essentially, this would involve the publication of the user’s social graph as the universal starting point for services and websites to subscribe to, rather than the current approach where everyone is struggling to aggregate disparate social graphs as the end point of all activities. Ergo, we are addressing the wrong problem at the wrong place.

The current crop of problems will only be addressed when we stop pulling data into aggregators and start pushing data into service and messaging buses. Additionally, since this data is replicated across all subscriber nodes, it should also provide us with much better redundancy.

Problem Domain 

Identity: Joe User on Twitter may not always be the same as Joe User on Facebook. This is a known problem that makes discovery of content, context and connections tricky and often downright inaccurate. Google’s Social Graph API is a brave attempt at addressing this issue using XFN and FOAF, but it won’t find much success because it is initiated at the wrong end and also because it is an educated guess at the best and you don’t make those with your personal data or connections.
 
Disparate services: Joe User may only want to blog and not use photo sharing on the same platform, unlike Jane User who uses an entire gamut of services. In an even worse scenario, if Jane User wants to use blogs on a particular service provider (say, Windows Live Spaces) and photo sharing on another (Flickr, for instance), she will have to build and nurture different trust systems, contacts and reputation levels.

Data retention: Yes, service providers are now warming up to the possibility of allowing users to pull out user data from them, but it is often provided without metadata or data that is accrued over time (comments, tags, categories etc). Switching providers often leaves you with having to do the same work all over again.

Security: Social information aggregators now collect and save information by asking you for passwords and usernames on other services. This is not a sane way to work (extremely high risk of phishing) and is downright illegal at times when it involves HTML scraping and unauthorized access.

Proposed solution

Hyperid Layout

Identity, identity, identity: Start using OpenID as the base of HyperID. Users will be uniquely addressable by means of URLs. Joe User can always be associated with his URL (http://www.joeuser.com/id/), independent of the services he has subscribed to. Connections made by Joe User will also resolve to other OpenIDs. In one swipe you no longer have to scrape or crawl or guess to figure out your connections.
 
Formalize a social (meta)data vocabulary: Existing syndication formats like RSS and ATOM, are usually used to publish text content. There are extensions of these formats like Media RSS from Yahoo!, but none of them address the social data domain. 

Of the existing candidates, the Atom Publishing Protocol seems to be the most amenable to an extension like this to cover the most common of social data requirements. Additional and site-specific extensions can be added on by means of custom namespaces that define them.

You host your own social graph: With a common vocabulary, pushing, pulling and subscribing to data across different providers and subscribers should become effortless. This would also mean that you can, if you want to, host your own social graph (http://www.janeuser.com/social) or leave it up to service providers who will do it for you. I know that SixApart already does this in part with the Action Streams plugin, but it is still a pull than a push service.

Moreover, we could extend the autodiscovery protocol for RSS and use it to point to the location of the social graph, which is a considerably better and easier solution than the one proposed Social Graph.

Extend and embrace existing tech: Extend and leverage existing technologies like OpenID and Atom to authenticate and advertise available services to users depending on their access levels.

What this could mean

For companies: They have to change the way they look at usage, data and their own business models. Throwing away locked-in logins would be a scary thing to do, but you get better quality and better-profiled usage.

In the short run you are looking at existing companies changing themselves into data buses. In the longer run, it should be business as normal.

Redundancy: Since your data is replicated across different subscribers, you can push updates across to different services and assign fallbacks (primary subscriber: twitter, secondary: pownce and so on).

Subscriber applications can cache advertised fallback options and try known options if the primary ones are unavailable. 

For users: They will need to sign up with a HyperID provider or host one on their own if they are savvy enough to do that. On the surface, though, it should all be business as usual, since a well-executed API and vocabulary should do the heavy lifting behind the scenes.
 
The Opportunity

For someone like WordPress.com, diversifying into the HyperID space would be a natural extension. They could even call it Socialpress. The hypothetical service would have a dashboard like interface to control your settings, subscriptions and trusted users and an API endpoint specific to each user.

Risks

Complexity: Since data is replicated and pushed out across to different subscribers, controls will be granular by default and across different providers this could prove to be very cumbersome.

Security: Even though attacks against OpenId has not been a matter of concern, extending it would bring with it the risk of opening up new fronts in what is essentially a simple identity verification mechanism.

Synchronization: Since there is data replication involved (bi-directional like any decent framework should do), there is the possibility that lag should be there. Improperly implemented HyperID compliant websites could in theory retain data should be deleted across all subscribed nodes.

Traction: Without widespread support from the major players the initiative just won’t go anywhere. This is even more troublesome because it involves bi-directional syncing and all the parties involved are expected to play nice. If they don’t, it just won’t work. We could probably get into certification, compliance and all that jazz, but that would make it insanely complicated.

Exceptions: We are assuming here that users would want to aggregate all of their things under a single identity. I am well aware of the fact that there are valid use cases where users may want to not do that. HyperID does not prevent from doing. In fact, you could use different hyperIDs, or even specify which services you don’t want to be published at all.

Feedback

The comment space awaits you!
 
p.s: Apologies for the crappy graphic to go with the post. I am an absolute newbie on Omnigraffle and it shows! 

Written by shyam

February 4, 2008 at 1:46 pm

Posted in Blogging Frameworks, Blogs, Take-two, social media

Tagged with , , ,

Automattic turns down $200 million offer

without comments

Automattic, the company that created the WordPress.com blogging platform and oversees the WordPress.org open source project, has rejected a $200 million acquisition offer, says multiple sources. — Techcrunch

I’d said a while ago that even the $300 million figure quoted by Rafat earlier was not the right valuation for the company. Automattic does not only create software that helps people — and now a fair number of publications — publish content, they also organise it in a consistent manner using global tags and categories. They are, in fact, a content management, content delivery and allied services company, very much unlike what the world thinks of them as: a blog software company.

If they stick it out in the long run by themselves (no reason why they should not do it, since they have not taken on board any major funding in a while now, which is a good indication that the company is doing well in terms of cash flow/reserves), they would be worth a whole lot more.

Update: More evidence to back it up that WordPress is much more than a blog software company.  How long it will be before they get an actual editor to run that page and push out more organised content?

Written by shyam

October 30, 2007 at 9:15 am

Posted in Blogging Frameworks, Content Management Systems, Wordpress, business

Tagged with , ,

Feedburner and RSS aggregators

without comments

Feedburner is one of the best tools that any blogger or publications could befriend for analytics or feed management. But one downside of using the service is that it is a pain when you have to link to a story when you read it in a RSS reader. For instance, the latest post on Fred Wilson’s blog (don’t tell me you don’t read him!) will have the link http://feeds.feedburner.com/~r/AVc/~3/83929503/my_keynote_yest.html on all self-respecting aggregators, while the actual article link looks something like this http://avc.blogs.com/a_vc/2007/01/my_keynote_yest.html. I could, quite easily, link to the Feedburner URL, but that would poison Fred’s clickthrough numbers in Feedburner, especially if you do it from a website with pretty good traffic (which, thankfully, mine is not). Moreover, it is a pain to open the link in a browser just to fish out the actual URL. I guess they could add another link to the actual URL in their ’flares’ link (Email this • Digg This!) that they have and make life easier for us and get one step closer to perfection.

Technorati tags: , , ,

Written by shyam

January 30, 2007 at 2:44 pm

Posted in Blogging Frameworks, Blogs

Skin yo feeds bros

without comments

Alex Boxworth has a yummy application that is hosted at the Sourcelabs sandbox called Skinnerbox. As most you might be unaware, it is possible to make your XML feeds look a lot more decent than the taggy mess it looks right now by using XSL transformations. Bascially, you just slap on an XML stylesheet to it (very much on the lines of the normal CSS that you use in HTML) and you get a page that looks a lot better.

Now, Blogger already ’skins’ its Atom feed, but it is pretty plain and sadly, since you cannot mess around with the XML feed templates in Blogger (at least that is what I remember), you can’t do much more than to drool at what you could do with it. But if you are one of the lucky ones who can tamper with their XML templates, make sure that you try this one out.

p.s: IE7 already formats XML feeds internally, which is both good and bad. Users would no longer be exposed to raw XML as a result of this, but what if I want to use my own stylesheet to format my feed?

tags: , , ,

Written by shyam

September 7, 2006 at 10:47 am

Posted in /etc, Blogging Frameworks, Blogs, Content Management Systems, Technology

The Upgrade That Was Not

without comments

Hell has frozen over! Blogger is rolling out a new backend. On second thoughts, it is only getting a bit chilly out here, but it certainly ain’t cool enough for things to freeze over. At least not yet. Apparently, the greatest of the changes is in a place where the end user, like you and me, don’t see much of. Blogger is going off the static publishing set up (one where it would pick up content from its database and spit out static HTML and XML files based on the templates and settings you had specified) and moving to a new set up where all the content is served dynamically (the way in which WordPress blogs functions now).

The immediate change you’ll get to see is a top bar, quite similar to wordpress.com once again, that will show you as logged in and also display other useful information, if you are logged in. Behind the scenes, and I am guessing here, the entire operation would now move to an application server (probably the same server that handles the posting/editing backend) from the old set up which was probably serving a directory of files based on the host header. The other significant change is the authentication part, for which you can now use your Google account (for new blogs, not for existing blogs) or your old Blogger account. The logic there is quite mixed up and needs a lot of work.

That said, the new beta is a complete dud compared to WordPress.com. The interface is still the dated, clunky one and true to the beta label, some of the stuff is broken, like the new WYSIWYG layout editor that was spewing out Ajax debug information on to my screen when it was not functioning as intended. Access control is nice, but I did not see the option for controlling access per post and determining access on the blog level is not a fun thing to do.

The good points? Well, the archive links are laid out much better now and there are Atom feeds for posts and comments (per post too) now. There is also something called “labels”, which looks like a bastard child that resulted from a love making session between tags and categories. Pretty nice, but once again it is something they should have had yesterday.

But someone really has to get some new default templates into the system pretty soon. I am sick of seeing the same 10 all over the place. And the upgrade itself is symptomatic of how Google treats Blogger, more like a stepchild than as a product that deserves a whole lot more of attention and resources allocated to it. Yeah, I know, it is not easy to roll out features for a framework that supports a huge number of users, compared to something like wordpress.com that is new and had a clean sheet of paper to start with. But it can’t be that difficult either. After all, it is all just a data, pulled in and out of database servers and presented on web servers.

Technorati Tags: , , ,

Written by shyam

August 15, 2006 at 9:03 am

Posted in Blogging Frameworks, Blogs, Wordpress, crossposted

« Older Entries