This article is a stub. You can help the IndieWebCamp wiki by expanding it.
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:
Origins
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.
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:
Issues
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?
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:
Specific concerns:
- 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)
- ...
Indieweb perspectives
- 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
- ...
Use with microformats2
- User:Tantek.com: One thought is to use microformats2 root class names for object types as we publish them. I've been using "as-note" and "as-article" on my "h-entry" elements for some time, but as of 13:27, 12 October 2012 (PDT) was considering switching to using h-as-note and h-as-article instead (as they're really indicating "subtypes" of an h-entry), and as of 2012-10-26 have done so per the FSWS Summit session on ActivityStreams and microformats2. Tantek 09:13, 30 October 2012 (PDT)
- I'll likely add "h-as-reply" and "h-as-rsvp" as I add those post types. Currently they're just styling hooks, though one could conceivably use them as part of a h-entry -> ActivityStreams(Atom or JSON) converter. - Tantek 11:31, 9 May 2013 (PDT)
- User:Waterpigs.co.uk: I am publishing my notes and articles with h-as-note and h-as-article, as well as using u-as-downstream-duplicate for downstream duplicate URIs (example) ----
- ...
See also: http://microformats.org/wiki/activity-streams#activity_object_brainstorm
See Also
Post Types
Various post types:
