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:
Current indie web implementations:
JSON ActivityStreams (latest spec)
Atom + ActivityStreams namespaced markup:
- Tantek Çelik on tantek.com - discoverable Atom + AS object-type for notes, articles. Replies 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
- activitystreams-unofficial supports ATOM as well as JSON format.
- 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 activitystreams-unofficial as a common backplane for each new IndieWeb use case.
Use with microformats2
- activitystreams-unofficial converts from ActivityStreams to microformats2 JSON and HTML. See microformats2.py.
- 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 (note related 2011 post about "as-*" classnames), 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 FSWS2012 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)
- In practice I found no need for "h-as-reply". They're just notes that I can display specially as replies if they happen to have a rel-in-reply-to link. Tantek 09:03, 25 June 2013 (PDT)
- I'm leaning towards removing all h-as-* class names as they don't seem to have helped with anything, and less is more. UIs are also moving away from explicit post typing. Tantek 12:44, 15 March 2015 (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) ----
- User:benwerd.com: I'm using "h-as-note" and "h-as-article" in idno, with more to follow. I'm particularly interested in h-as-event in combination with webmention attendance reports.
- User:jeena.net: I'm using "h-as-photo" in addition to h-entry for my photo entries.
See also: http://microformats.org/wiki/activity-streams#activity_object_brainstorm
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?
A: Check out the guide on How to set up your realtime feed for best practices and tips for publishing feeds.
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
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.
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
- Facebook allows users to specify an activity along with their status update:
Various post types: