ActivityStreams

From IndieWeb
(Redirected from as1)

activitystreams_logo.png

This article is a stub. You can help the IndieWeb 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 that eventually produced Activity Streams 2.0. Quick reference to AS types and verbs:

Post Types

For IndieWeb pages of specific post types, see:

IndieWeb Examples

Tantek

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

IndieWeb Support

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.

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
  • 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.
  • (Archived from Taproot) Originally I intended on using the activitystreams schema to store and represent all my content, the idea being that it would allow me to make listeners which could work seamlessly on all sorts of content types. In actuality, I have nowhere near as many content types as I anticipated, and want to treat each one very differently. In addition to this, I found some of the semantics within activitystreams irritating (e.g. displayName vs title, both horrible names) and the activity ~= object ambiguity confusing. Coupled with the fact that there is no activitystreams client, I decided to drop activitystreams as the basis for representing my data. --Waterpigs.co.uk 12:33, 14 June 2013 (PDT)
  • ...

Use with microformats2

Note: use of "h-as-*" (or "as-*") classes is now discouraged. For more see:

Commons Examples

Quitter se

Quitter.se is an install of GNU social

FAQ

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.

Issues

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.


Is this still true with the advent of Mastodon and the like? - Jacky Alciné

Lack of clients problem

As of 2022, this following is no longer true and should be considered historical - Jacky Alciné

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:

Specific concerns:

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

  • ...

Imposes unnecessary hierarchy

ActivityStreams objects inherit from each other, which often does not reflect the actual contents of an object. For example, Audio extends Document, but Article does not. Document does not even define any new properties. Where it may have made sense to define some media properties such as "duration" on a type that Audio and Video can extend from, instead, "duration" is defined on the root "Object" type, meaning it also applies to everything that extends "Object" such as "Activity" and "OrderedCollection".

Origins

  • 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.

Design Considerations

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 Notes

  • Facebook allows users to specify an activity along with their status update:

Historical Context

This section is a stub.

Origins

See Also

  • Activity Streams 2.0
  • ActivityPub
  • to-do: this page needs a bunch of cleanup to more clearly indicate AS1 vs AS2, AS1/Atom vs AS1/JSON. See citations from Martin Atkins for help distinguishing these
Retrieved from "https://indieweb.org/wiki/index.php?title=ActivityStreams&oldid=85095"