Activity Streams is a JSON-based format for representing social networking and other online activities. It provides a machine-readable vocabulary for expressing messages like "Martin likes this photo", or "Ermintrude plans to attend this event".

An activity looks like this when expressed as JSON:

History

In early 2008 I started to work on an HTML microformat for representing social objects, but ended up not completing it in this guise. (As it turns out, Facebook later went on to invent something very similar, as part of turning their social network into a social aggregator of content from around the web.)

At the Internet Identity Workshop that year I chatted to several others about my general desire to add metadata to social activities to enable richer aggregation than was possible with RSS or Atom alone, and found that others were interested in this idea too. I later met up with Chris Messina, Will Norris and David Recordon to brainstorm about ways to achieve this, and shortly afterwards I penned a first draft of Atom Activity Streams, which was an extension to the Atom syndication format to allow it to be used as a transport for descriptions of actions rather than just content. The rationale for building on Atom was to attempt backward-compatible progressive enhancement of existing systems that were already producing and consuming RSS.

A long-haired me presenting the first draft of Atom Activity Streams at the first Activity Streams meetup in the Six Apart office on Jan 8th 2009.

Although there was initially some traction around this form of the specification, the community grew frustrated with the Atom container format and so began an effort to separate the fundamental model of activity transmission from its serialization as Atom.

The result was JSON Activity Streams, which I co-designed and co-authored with Will Norris, Chris Messina, Monica Wilkinson and Rob Dolin. Eventually the Atom serialization was completely separated and James Snell did a final rewrite and simplification of the document before it was released as version 1.0.

The activity streams data model and serialization were later used as the basis of several federated social web protocols, sadly none of which have gained much traction as of this writing.

Passing out a new draft of the spec for discussion at a later Activity Streams meetup at the Stanford campus on Sept 5 2009. John also recorded an episode of The Social Web TV that day, starring myself along with Chris Messina and Joseph Smarr.

Retrospective

It has been several years since the publication of JSON Activity Streams 1.0, and I think it's fair to say that enthusiasm for the idea has waned in the mean time. James Snell has been keeping the dream alive by working on a follow-up version that is currently an IETF draft, but otherwise much of the former community has dissipated.

The genesis of the idea that became Activity Streams was a desire to make a social web out of personal websites. Atom Activity Streams was, in my opinion, a pragmatic extension of the online publishing practices of the day: RSS and Atom feeds containing the most recent posted items.

The sudden interest of some big players like Facebook, Google and Microsoft gave the initiative some credibility early on, and certainly the individuals who represented those companies were a great asset to the process, bringing with them a personal passion to build something for the greater web.

With the benefit of hindsight though, the interests of those companies would seem to have been a distraction. What had been an effort to connect together the long tail of the social web instead became an effort to design interop APIs for the social web's biggest silos. The biggest uses of the Activity Streams data formats were in private integration deals between these big players and their carefully-selected publishing partners.

It is clear to me now that incumbents do not inter-operate through open specifications but rather through contracts, partnerships and custom development. With the notable exception of HTML itself, there has rarely been an example of big company use-cases driving a specification that is used for anything other than point-to-point partnerships with big companies.

The "indie web" movement has recognized this and explicitly discounted the use-cases of big social networks, preferring to merely exploit social network silos for distribution rather than attempt to interoperate with them on an equal footing. This means that at the present time the indie web seems to reach largely only technologists and enthusiasts, but this movement recognizes that the indie web coexists with the silos rather than replacing them -- and thus continuing to participate in silos is important to hear the diverse set of voices represented within them.

Activity Streams seems to live on as a record of research into various social web use-cases, and although the format itself hasn't gained wide adoption I believe the process of designing and documenting it has been a foundation for several other efforts, both in terms of identifying important use-cases and in terms of identifying retrospectively-unimportant ones.

The Activity Streams design process has also been held up several times as an example of both patterns and anti-patterns in community development of grass-roots systems, and I think that alone is a fine legacy. I know I personally learnt a lot from the process of collaborating on this set of specifications, and it would appear that the community did too. For that I am pleased.