Hueniverse

New Adventure, Same Quest

Ok, the startup is over – now what? The first thing after deciding to end my startup was to figure out what I wanted to do next. I knew I wanted to stay in the web world, but given my wide range of past experiences I didn’t know what role I really wanted. This was new territory for me as it was the first time in 17 years that I didn’t already know what I wanted to do next (and had it lined up and ready to go). So I asked myself a simple question: what was the most fun part of working on Nouncer? To which I had a quick and easy answer: OAuth.

Working on the OAuth specification, talking about it, promoting it, helping others to understand and implement it, and most importantly being part of the community, were the most exciting tasks this past year. Since I didn’t think anyone will pay me to sit all day having fun writing OAuth, XRDS-Simple, and other related specifications, I was looking for opportunities where I would at least be able to continue working on open standards in a small part capacity. Turns out I was wrong.

It is therefore my great pleasure to announce that I will be joining Yahoo!’s Social Platform team in the newly created role of Open Standards Evangelist. Turns out someone does want to pay me to spend my days working on OAuth and other exciting open standards! The Social Platform team is lead by Michael Curtis and focuses on the social directory, social graph activation, the vitality platform, and the universal profile among other things. All this with the perfect timing of the Y!OS announcement (Yahoo! Open Strategy).

The Last AnNounce(r)ment

Two years is a long time, especially when spent building a startup from the ground up. My most exciting professional adventure to date has reached its conclusion last month when I decided to pull the plug on Nouncer, my attempt at building a microblogging web service. The Nouncer story started with an idea and hunt for logo, evolved into a business with some general directions about a financial model, and materialized into a big chunk of code – 150,509 lines to be exact.

Scaling a Microblogging Service - Part III

There used to be a big difference between API access and regular human-oriented HTML access: the speed in which requests are made. When a request is made via a browser, there is inherit delay from human interaction, browser response, page rendering, and fetching of images. Most of this is gone once a machine makes the call. However, with recent improvement in browser technology and the wide use of AJAX techniques on the client side, even the human-readable pages can make API calls to render pages.

Scalability plays a central role when designing the ways in which data can be requested from a service, be it via an API call or HTML page request. Both types fetch raw data, process it, and then format it into a presentation format such as HTML, XML, JSON, etc. In the case of a server-rendered HTML page, all the different requests are made internally, hidden from the user, and a single page is returned. If the page uses AJAX scripts, the browser makes multiple API calls to fetch individual data sets, but the server still has to fetch the raw data, process it, and format it. It is the size of the batch that makes the difference.

OAuth Discovery Draft 2 Released with Vendors Support

It’s always gratifying to announce new specifications or new drafts of existing efforts. OAuth Discovery has been in development for over five months and has matured a great deal since its initial introduction at the Internet Identity Workshop. I am happy to announce the availability of the OAuth Discovery 1.0 Draft 2 specification which is also the first implementation of the recently announced XRDS-Simple format.

What makes this announcement significant is that the new draft is already implemented and deployed by FireEagle (a Yahoo! Brickhouse service), Ma.gnolia, and Get Satisfaction – three leaders in the OAuth community. On the development tools front, Mediamatic will release initial support for discovery early next week with full support due early May in their OAuth PHP library.

         

Putting XRDS-Simple in Context

What are we trying to do?

XRDS-Simple is a protocol for service discovery. The level of discovery is kept intentionally simple to accommodate existing use cases and apply established patterns. Service discovery at this level is technically trivial. After all, how hard can it be to list a bunch of URIs and add some descriptions next to each one? The only issue is agreeing on some format that everyone can understand and implement. In developing a discovery protocol, we are trying to answer two questions:

1. How to find information about a resource through its URI?
2. What format is this information provided in?

Announcing XRDS-Simple 1.0 Draft 1

I’m happy to announce that XRDS-Simple 1.0 Draft 1 was released today. What started as an appendix to OAuth Discovery, quickly found life of its own in the form of a generic and simple-to-implement discovery protocol for web services. The specification is more about an editorial review of existing standards than an invention of something new, but written to remove the need to study other specifications. For more detail on XRDS-Simple check the post about XRDS-Simple in Context.

Scaling a Microblogging Service - Part II

When discussing microblogging scalability, the conversation includes scaling each individual service, but also scaling the network and relationship between services. Part I discussed the challenges of scaling a single microblogging site with focus on dealing with a large and constantly changing content database. In that post I mentioned that the proposal by some critics to build a distributed or federated microblogging service as a scaling solution will actually make thing worse. This second part will elaborate on that claim.

When discussing a distributed microblogging service, the conversation touches the long debate on the future of social networks and linking communities across individual walled gardens. After all, microblogging is one aspect of the social web, and status updates lives side by side sharing photos, videos, and other personal information and experiences. Being able to choose a social network and make friends from another without having to sign up for multiple accounts is one of the visions being offered. Another is the approach being advocated by the Data Portability group, which focuses on being able to move an entire experience off to another network instead, creating multiple identities.

Scaling a Microblogging Service - Part I

When it comes to Twitter, everyone’s a critic.

The irony is, the majority of the technical criticism written about Twitter reveals more about the lack of understanding of the author than anything about Twitter. Creating Nouncer - a developer platform for building microblogs and similar services - provides a firsthand understanding of the inner-working and challenges of microblogging sites. This post is not specifically about Twitter but as the leading microblogging service, it is the best working example of the challenges of scaling in the space.

People don’t seem to get what is so hard about scaling the Twitter service. Some think it has to do with Rails, while others look at the hosting company or other operating factors. Then there are those who incorrectly think a distributed or federated service is the solution (which will only make things worse). The idea that building a large scale web application is trivial or a solved problem is simply ridiculous. In a way it is surprising that there are so few companies out there dealing with commoditizing web developing scaling.

The War of the Ose’s

OAuth 1.0 and OpenID 2.0 went final one day apart. Each has a very well defined purpose and were designed to work well with each other. OAuth’s primary focus was a way to delegate authorization, mostly in the realm of APIs; and OpenID creates a distributed identity service. When put together, OAuth allows users to use their OpenID with widgets and other services, and that was one of the initial driving forces behind developing OAuth. For the most part, each protocol does its thing well, and plays well with its counterpart. But from a technology standpoint, we made a bit of a mess.

Something Borrowed, Something (Almost) New

It is always exciting when one project leads to another equally as interesting. OAuth Discovery uses XRDS as its document format. XRDS is a rich format for describing services, and was adopted by OpenID for its preferred discovery method. Simply put, XRDS provides a method to list services and their properties in a flexible way. On the ‘simple’ side, XRDS allows listing services in groups with their URL and type. So if an application is looking for a service of a particular type, it can find a match and use the associated URL. On the ‘complex’ side, XRDS offers a wide range of tools to chain multiple documents and build advance selection criteria. It gets pretty sophisticated. Sometimes too sophisticated.