Microformats, opposed to explicit ActivityStreams verb/object types

No New Activity Objects; Microformats Instead

In GNU social, as in other ActivityStreams-based systems, the activities of users are published as verb:noun (or, action:object) data pairs. For example, when a user posts a notice the server publishes an activity composed of a Post action (verb) of a Note object (noun); likewise, when a user joins a group the server publishes a Join:Group activity; when a user follows another user the server publishes a Follow:User activity, and so-on.

Every GNU social server understands a set of core action types — Join, Follow, Post, Delete, Share, and Favorite — as well as a set of core object types: Group, User, Article, Note, Comment, and Activity. However, GNU social is extensible via plug-ins, which may enable the server to publish new types of actions and objects. The current stable release comes with a number of plugins (mostly unused) supporting a variety of Postable objects (Poll, Bookmark, Question, ...), as well as a few special actions related to those types (Vote, ???).

The problems with this approach to extensibility are: first, as GNU social is written in PHP, plug-ins must necessarily be written (at least partially) in PHP as well, which may be an unpalatable course of action for programmers unfamiliar-with or opposed to that language; second, user activity only propagates between servers that have been augmented to handle the same action and object types. For example, if a user posts a Poll on his server, his followers on other servers which do not have the Poll plugin enabled will not even receive notification that a Poll has been posted — and they will certainly not be presented with the opportunity to vote on that poll.

The users of the GNU social network would be better served by a small set of generic, universally-supported activity types which could be extended with microformats[1] in their content. The benefits of this approach are:

  1. The server need never be augmented in order to store, retrieve, or publish any kind of activity. This ensures...
  2. ...consistent functional capability across servers. By way of analogy: your email provider may limit the size of messages you are able to send/recieve, but there are no limitations on the *types* of message+attachment which can be sent/received. We should expect the same kind of content-neutrality on GNU social nodes.
  3. The responsibility for handling different types of data would fall on the client instead of the client *and* server.

[1] I'm using "microformats" generically, here. The microformats specifications are certainly a good place to start, but with the introduction of HTML 5, custom elements of the <x-*> type and attributes of the data-* type provide a powerful mechanism for defining data objects inside valid HTML. Ideally, all microformatted post objects would degrade to text so that a client which does not provide a viewer/interface for a particular object type could simply display the text content of the object.


I propose that the Article object — which is a core object type already supported across all StatusNet and GNU social servers — be used for new post types which would be entirely contained within the <content> element of the activity object. For example, the Polls plugin could be obviated by implementing polls as Articles containing HTML/microformats, such as:

  <content type="html">
    <div class="h-poll">
      What's your favorite colour?
        <li class="p-option">Crimson</li>
        <li class="p-option">Vermillion</li>
        <li class="p-option">Chartreuse</li>

Poll responses could simply be Comment objects with free-form contents, but with the vote selection microformatted in the text:

  <content type="html">
    Pretty limited choices. Of those offered, I guess I like <span class="h-vote">Vermillion</span>. 

The mechanism for making sure that poll responses are coded as h-votes (or whatever) would be the responsibility of the client, as would tallying of the poll. Clients may provide a variety of presentation or interaction features for microformats they understand, and fall back to treating articles as simple HTML posts for those that they do not.

With the server-side plugin system, both the server and clients need to be extended to handle different activity types. With this kind of microformatted content inside generic Article objects, only clients need to be extended.

Deprecate "Favorite", implement "Tag"

Favorite is a very specific activity, and one that invites the question of why there is not a corresponding "Hate" activity.

Functionally, Favorite adds an activity to a list of favorites. The question raised by that is: why do we only have one special-purpose list? Why not an infinite number of lists?

Now, I realize that *I just recommended* that no new activity types be added, but this is a special case because.

+The next question is: do we need a new Tag action? Or, could we simply use the Share action.+

+A tag action would be useful as each tag would be its own database record, and users could tag/untag activities as they+ +sers need only Share a post with tags added to the <content> of their share. not only could we enable extended functionality like galleries or "pinboards", but we could obviate the Favorite action while providing+

Deprecate the Share activity?

- Could be obviated in two ways: - 1. Post a new notice that links the old one as an attachment. - 2. - The immediate obejection to the first approach might be that it starts a new conversation thread, disconnected from the original notice. No new post types on the server; all post contents are XML, implementing microformats ----------- Follow, Unfollow -> User Join, Leave -> Group Post -> note, comment, article, +poll, bookmark, question, etc...+ +Favorite -> Activity+ Tag -> Activity +Repeat -> Activity+