activity streams
introduction
As people use various different web sites to blog, update their status, post their location, or photos, sites and tools have emerged to aggregate these various actions into a continuous eclectic stream of activities.
Such activities typically involve a subject (the person doing the activity), a verb (what the "doing" is of the activity), and often a direct object (what the activity is being done to or with). Activity stream aggregators typically republish activities in reverse chronological order, independent of type of activity.
Friendfeed was perhaps the most well known web site that does cross site activity aggregation/publication, and Movable Type has (had?) built-in support for aggregation/publication of activity streams as of v4.1.
For more examples, see the DiSo wiki activity streams page (see also the other DiSo wiki, not sure which to use).
problem statement
The type and variety of activities that services support and publish is growing every month. Services like Friendfeed and tools like Movable Type must either be continuously updated with one-off per service implementation support, or provide nothing more than lowest common denominator feed aggregation and publication.
If activity streams were published in an open standard format then activity stream aggregators that supported such an open format would automatically support any new standards supporting activity stream services without having to play the continuous one-off proprietary API implementation catch-up game. In addition, new activity publishers would be less beholden to trying to reimplement others' proprietary APIs (and all the giving up control to a likely competitor problems that arise from that practice).
existing standards
Feeds (and related formats, RSS, Atom, hAtom) solve most of the problems of activity streams. Movable Type 4.1's activity stream publishing support already supports hAtom today for example.
The subject of an activity is nearly always the author of a feed.
The direct object of an activity is typically an item or entry in a feed.
Sites that publish different kinds of objects/items in their interfaces often present those items/posts differently depending on the kind of object. Activity Streams thus has a set of object-types that represent these kinds of objects, based on their research on existing object type publishing examples in the wild.
apparent need and focus
Thus key pieces that seem worthy of standardization are:
- the verb aspect of an activity
- the object-type of an item or post
Per the microformats principles, by focusing on these smaller parts of the problem (verbs and object-types), we may be able to more quickly solve the larger problem of representing activities and activity streams.
Thus, per the microformats process:
And:
rejected brainstorms
The following brainstorm proposals have been found to be problematic for various reasons.
activity object brainstorm
Previous brainstorm thoughts and proposal:
Strawman brainstorm (to be archived as a past attempt activity-object-brainstorming) : for now, try simply re-using the Activity Streams set of object-types as class names, preceded with "h-as-", as a microformats2 poshformat for representing different Activity Stream object-types in hAtom. Use these object-type class names to "subclass" the "h-entry" class in hAtom, e.g. where you might publish
<div class="h-entry hentry">
With this strawman proposal, for blog posts you might publish:
<div class="h-entry hentry h-as-article">
Or for little tweet/text notes:
<div class="h-entry hentry h-as-note">
And RSVPs (as brainstormed) :
<div class="h-entry hentry h-as-rsvp">
sites implementing activity object brainstorm
See: http://indiewebcamp.com/ActivityStreams#Use_with_microformats2