ActivityStreams (AS) is a standardization effort to define common types of objects and actions (verbs) taken on various social media sites. Quick reference to AS types and verbs:
- 1 IndieWeb Examples
- 2 IndieWeb Support
- 3 Indieweb perspectives
- 4 Use with microformats2
- 5 Commons Examples
- 6 FAQ
- 7 Issues
- 8 Origins
- 9 Design Considerations
- 10 Silo Activity Design Research
- 11 See Also
Atom + ActivityStreams namespaced markup:
Tantek Çelik on tantek.com - discoverable Atom + AS object-type for notes, articles. Replies, RSVPs so far are just "notes" in the AS representation. Mostly I've done this as an attempt to at least *try* to use ActivityStreams before working on an alternative, and learn by trying in the hopes of creating a better alternative. - Tantek
- http://tantek.com/updates.atom - ATOM ActivityStream of home page updates
Additional indie web implementations:
JSON ActivityStreams (latest spec)
- granary is a library and REST API that converts between Facebook, Twitter, Google+, and Instagram and ActivityStreams 1 (and also microformats2 HTML, JSON, and Atom). It uses the silos' APIs to fetch and also publish posts, comments, likes, retweets, etc. and supports Activity Streams ATOM as well as JSON format.
- Sandeep Shetty: The RSSB stuff on sandeep.io is lot like AS and trivially maps to it and was done as an exercise to understand AS:
- Tantek: I'm looking to AS as a good place to mine previous research rather than adopt wholesale. When the AS wiki documents real world examples, and/or an object type makes sense for a post type I'm implementing with its own design/UI, then I'm considering adopting it. If there is no real world documentation of an object type or verb on the wiki, then I don't care that it's in a "spec" - it's theoretical and deserves to be dropped. Tantek 13:24, 12 October 2012 (PDT)
- See also: my list of object types by shortcode.
- Current explicit AS object types I'm using (in order of most often first) with respective shortcode/description
- note - 't' for plain text note
- article - 'b' for blog post
- User:benwerd.com: I'm using ActivityStreams as a handy abstraction layer, not because I think anyone's necessarily reading it. All new content posted in idno has an AS object type; plugins can then observe post events based on that object type, intercept the object, and (eg) syndicate it to third-party sites. That way the syndication plugins don't have to be dependent on any specific content plugins.
- Ryan is currently focusing on connecting the IndieWeb to existing silos, and he uses ActivityStreams via granary as a common backplane for each new IndieWeb use case.
Use with microformats2
Note: use of "h-as-*" (or "as-*") classes is now discouraged. For more see:
- Activity Streams 1.0 Atom / XML
- Activity Streams 1.0 JSON
How do you add discoverability of an ActivityStream
Q: What would the best practice be to add discoverability of an ActivityStream to an indie web site?
Lack of selfdogfooding
There appears a lack of selfdogfooding of ActivityStreams by the editors of the specification.
- Please provide examples of selfdogfooding of ActivityStreams by the editors. This would be great to see.
Past spec editor Will Norris said in irc:
The fact that I am no longer involved is any actual AS implementation (either personally or at Google) is the main reason I try and stay out of current discussions.
Lack of clients problem
We never saw anyone even try to build a client. So most of what we need or might want is sort of untested and will be until such a thing gets built.
Until AS consuming clients are built that show different UIs for different types/verbs, we're not going to know how useful (or not) AS types/verbs/properties are. I.e with ATOM, you can look at your feed in some feed readers and immediately see what is being displayed where. There are no equivalent AS readers.
This may be part of the larger problem of feed readers in general being abandoned.
If no one is developing feed readers, why would anyone bother developing a new specialized AS feed reader?
- User:Martin.atkins.me.uk: I actually implemented four different activity streams clients over the course of working on the spec, as part of trying to build a decentralized social web node application. The first was super-generic and aimed to support any verb and object type thrown at it while having nice renderings for the standard ones, but that was excessively complex. Later attempts included supporting only a small set of verbs but supporting any object type using the specified fallback behavior. In the last iteration I noted that the streams I was trying to read only contained "post" and "share" events anyway and focused on just rendering objects well. I'm sorry to say that by the final iteration of all of this my collaborator convinced me that we could get better user experience by just going directly to proprietary APIs and just "know" that e.g. flickr items are always photos. If I were doing this over again for indie web, I'd focus on objects and forget about verbs.
Too many object types and verbs
While there is the generous presumption that the object types/verbs do reflect something in some product someone is shipping, there are specific concerns that the long list of 33 object types and 78 verbs is too many - from the official lists:
- Ephemeral and/or experimental: currently defined AS types/verbs are bigco-centric or silo-centric products that don't last long, are more experiments in practice rather than anything sustaining.
- Lack of UI examples/screenshots for each object type and verb. Ideally each type/verb would have screenshots of specific web sites using those concepts in their UI, even if not in their markup. Without the screenshots of applications showing different UIs for object types or verbs, it's not clear each can be justified.
Verbs vs just posts
Are verbs even necessary? How far can we get with just using the implied post and object types as necessary?
- One higher level problem is the concern about abstracting verbs being separate from posts. I prefer to see everything as just a different kind of a post. I'm not sure that making verbs explicit is that helpful in practice. They're all posts really. Tantek 13:24, 12 October 2012 (PDT)
- Separating out activities and objects makes sense to me in contexts where an object is going to be acted upon regularly/frequently, e.g. a wiki-like oft-edited article. In such cases not only are there syndication/frequency issues (e.g. how many “Barnaby updated X Article” notes are people prepared to put up with) but also possible UI enhancements (e.g. building an edit history for an object based on update activities relating to it). --Waterpigs.co.uk 13:32, 12 October 2012 (PDT)
- Note: Whilst I stand by this as a potential use for ActivityStreams, I decided the pain:value ratio was too great and am now storing article edit histories within the article, not in an activity meta-table --Waterpigs.co.uk 14:52, 17 November 2012 (PST)
Activity vs h-entry
Activities are an indirection, an additional object that contain triples, whereas when we markup h-entry with an h-card and a verb (like, repost, comment) we don't have that indirection. Put another way, AS implies an additional feed (a stream of activities), whereas most of us on the indieweb just have the posts feed. --Sandeep Shetty
- See http://martin.atkins.me.uk/activity-streams/ for how ActivityStreams started.
The genesis of the idea that became Activity Streams was a desire to make a social web out of personal websites.
- User:Martin.atkins.me.uk: Not sure who found/linked this but I guess this implies some interest in the "process" that went into Activity Streams as both example and counter-example. When I was mining some old hard drives I found the proposal that kicked off the discussion that led to Activity Streams, which might also be of some historical interest. In particular it's interesting to note how "quaint" some of my object descriptions seem in the current context, which I think demonstrates the folly of trying to calcify social web culture -- a constantly moving target -- in specifications documents.
Different UI for different types verbs
The point of every verb and object type in AS is to allow consuming applications to provide a different UI for different types of data and different actions (verbs). Every different object type and every different verb is supposedly there because *some* application somewhere wants to present the information (and a UI) somewhat differently than just a generic "post" of some text.
- IMO, there is more to it than providing a different UI especially for verbs. Verbs give different signals to the reader (see Like vs. Repost and Quote vs. Repost) -Sandeep Shetty
Research for types and verbs
Typically the types/verbs are modeled after something in some product someone is shipping. Some of these have been researched and documented on the ActivityStreams wiki:
Silo Activity Design Research
- 2012-10-12 #indiewebcamp IRC discussion - basis of this page.
- DiSo Wiki: original Activity Streams examples (before separate ActivityStrea.ms site was created)
- Activity Streams Schema on Github (where most of the activity takes place)
Various post types: