Archive of "DiSo"

Archive for the "DiSo" Category

POSHstream, a POSHformat profile of

Posted on

This is just a post to describe a proposal for a POSHformat that profiles the ActivityStreams ATOM extension.

It only really makes sense to use these fields in the context of hAtom, and the fields of hAtom are used in the same way as the equivalent ATOM fields are used by the ATOM extension. In other words, this is an “hAtom extension”.

Object Identifiers

Object Identifiers (for types and verbs) can be specified using descriptive text (such as “link” or “weblog entry”) but a more unambiguous IRI MAY be specified using the value class pattern. Descriptive text SHOULD conform to agreed-upon, or at least published, type names, similarly to how ActivityStreams Object Identifiers should be defined in published specs.


The content of the object-type field MUST be an Object Identifier.

This field specifies the type of the Object described by this entry. An entry MAY have more than one object-type or no object-type.

Activity feed processors SHOULD use the most specific Object Type that they understand within each entry. The processor MAY use other information to infer the Object Type if it cannot understand any of the Object Types given.


The content of the verb field MUST be an Object Identifier.

This field defines the verb for this activity. An entry MAY have more than one verb but MUST have at least one.

Activity feed processors SHOULD use the most specific Verb that they understand within each entry. If none of the Activity’s Verbs are understood by the processor, the processor MAY use other information to infer the Verb, or the processor MAY use the content of the hAtom title, summary and/or content to obtain a sentence describing the Activity.


This class MUST appear along with one or more others that describe another POSHformat or microformat OR appear on a tag that inherently describes an external resource, such as <a>, <object>, or <img>. The object data is extracted according to this other format.

An additional object-type SHOULD be inferred from the other class(es), type attribute, and/or tag name present on this element.


The target field contains information about the target of the activity, for verbs that support a target. The target is the object that the action was done to. This field MUST appear along with one or more others that described another POSHformat or microformat OR appear on a tag that inherently describes an external resource, such as <a>, <object>, or <img>, similarly to class=object.

The precise meaning of the target as relates to the activity depends on the verb in use, but its meaning is somewhat similar to the English preposition “to”. The target extension element MUST NOT be used for indirect objects that are not targets.


The actor is taken from the class=author hCard present in the hAtom container. An additional class “actor” MAY be added to the hCard in keeping with the ATOM extension.

The ‘post’ Verb

This verb has IRI and descriptive text “posted”.

If the language of the activity is not English, the IRI or descriptive text should be provided using the value class pattern.

This Verb describes the act of posting or publishing an Object on the web. The implication is that before this Activity occurred the Object was not posted, and after the Activity has occurred it is posted or published.

If an activity using this verb has a target element, the target object is the collection in which the item was posted.

An example

	<div class="hentry">
		<span class="author vcard">
			<span class="fn">Geraldine</span>
		<span class="verb">posted</span>
		a <span class="object-type">photo</span>
		on PhotoPanic
		@ <span class="published">2008-11-02T15:29:00Z</span>
		<img class="object entry-title" alt="My Cat" src="/geraldine/photo1.jpg" />

My Ultimate Aggregator

Posted on

I want a feedreader that is also a mublog client and an activity stream aggregator. That is, like Bloglines+Socialthing+Tweetdeck, as a desktop app.

Content could be categorized (automatically, by source, or by metadata from the source) as “short” (like twitter/, “medium” (like tumblog-style stuff, or content from backtype), and “long” (blog posts etc), as well as by any actual categories/tags on the content (including hashtags on tweets, etc), and by source.

The left pane could let you filter by only certain categories (select one or more sources/categories/lengths, union each kind and then intersect, ala (source1 union source2) intersect (category1 union category2) intersect (length) ). Each kind of category would be separated by a line or something, with lengths at the top (there’s just three), then sources, then categories. Unread counts next to all of them.

Right pane in river-of-news (or, more like tweetdeck) style. Style should be smartly selected based on item. Tweets/mublog posts should link the username, @replies and #, etc, and show the avatar. Feeds with mediaRSS show thumbnail lieu of avatar. Feeds with a feed image show that. Otherwise, show favicon. Keep all items the same size, with snippets, etc, and click/otherwise select to expand.

Action links associated with each kind of data. Comment links for feeds with a <comments> tag on items, “show comments” for ones with wfw:commentRSS, long-term it’s be great to post a comment from the feedreader. “favourite”/”reply”, etc for the mublog, “bookmark too” for, etc.

Allow the user to associate multiple authors together (also try to do automatically) and maybe assign an avatar if there isn’t one: so that all of one person’s content displays and archives in a consistent fashion.

*Keep archives*! Make it easy to search through, or browse through, read content by category/author/source. Allow the user to file content under custom categories.

Have awesome keyboard shortcuts. j/k/space/enter/n/d… check out gmail/greader/mutt/trn for inspiration.

Be modular. Don’t just hardcode all the services/formats you want to support: take a hint from libpurple and others and just make *everything a plugin*. That way I can have NNTP support and you don’t have to care.

Support feed:// … I know it never took off, but supporting it isn’t hard and may yet prove useful.

Provide sane import/export of all data.

Provide posting support. In the plugins that implement it, of course. This means being able to update my mublog, bookmark to, etc 🙂

*Be portable*! It’s really not that hard to do 80% of your work in a cross-platform manner, so just do it already! Use a cross-platform GUI framework for your initial GUI and add native UI plugins for some platforms (looking at you, Apple fanboi’s) later.

Would I pay for this? Yes. I mean, it would have to be libre software (I’m not going to pay you to restrict my freedom!), but I would pay quite a bit for something like this. I dunno, if I were to pick a number, $40? Something like that. If I don’t figure it out and write it myself. GUI programming is not exactly my strong suit, but I’m playing around with it.

Describing Actionstream Sources

Posted on

I mantain wp-diso-actionstream, a plugin heavily inspired by MT Action Streams.

Early on, one of the things that made these two plugins so cool is that they share a config file format.  It’s YAML, which I’m not a fan of, but there was one big advantage to using it when I started: I was guaranteed someone would be interoperable with me, because I was using their format.

I’ve changed that YAML file quite a bit, but I’ve not added many “extensions” because I want MT Action Streams, at any moment, to be able to take the extra sources I’ve described and add them in.

There are essentially two parts to describing any source.


Yes, that’s the highest-level YAML heading for the first part.  Underneath is a list of simple hashes, described like so:
This is relatively straightforward. The source_identifier is a unique string (it must match what is used in the next part) identifying the source.  The name is a human-readable label for the source.  The url is a template for the profile URL, with %s where the user identifier goes. At this point you really have all you need.  With a service identifier and user identifier you can contruct a URL, and vice-versa.  There are three optional parameters that help make the UI nicer looking.   ident_label provides the human-readable string users would be used to seeing associated with this particular identifier (ie, Username, Screenname, etc).   ident_example is an example identifier (I usually use my own username on the service in question).  ident_suffix is any text a user might be used to seeing come after the username (such as This first part is relatively uncontroversial.  There are rarely multiple ways to map a user and service to a profile URL.  Ideally, I would love to see services hosting this YAML fragment somewhere and making it discoverable in some standard way (whether <link> tag or YADIS).


This section varies a bit more, since not everyone will agree on the right place to get data from, what data needs to be parsed, or how it should be output in an actionstream. Here is an example description:

The high-level identifier (here, twitter:) must match the source_identifier from the previous section.  Because one profile can have multiple sources of actions associated with it (for example, tweets and favourites), there is another lever of nesting where you give the identifier for the content type.  This is currently pretty arbitrary, but I’d like to see it move towards being the “standard” activity verb.

The name is the human readable label for the kind of content in this stream.  Description is more optional human-reabable information about the data.

html_form is any XHTML, with [_1] being replaced by the action owner, [_2], etc, being replaced with the n+1st field from html_params.

url is the URL to get the stream content from.  If not present it is assumed to be the profile URL. RSS/ATOM feeds can be detected on this endpoint if the content to be parsed is such a feed.  {{ident}} here is the same as %s in profile_services. I would like to deprecate this and switch to %s everywhere in a future version.

The final parameter describes how the data is to be parsed.  You may use atom:, rss2:, or xpath:.  RSS/ATOM feeds automatically have fields for their most popular elements (title, created_at). Any extra fields you wish are given a name and an XPath expression to use in parsing.  A more complete discussion of these field names, ones currently being used, and how I would like to see this progress can be found in this pastebin.

Moving Ahead

If the above two YAML snippets were made available by most sites with actionstream content, then the plugin could easily provide a nice set of defaults that kept themselves in sync with site evolution.  Users could override anything locally, of course.

There is one thing that neither of these describe, however: private items.  While a feed could be protected by OAuth, and the plugin could then authorize to pull in the data, this seems like going about it the wrong way around.  I’d really like to see some way of telling a site: “push my activity over there” and having it discover and hit a callback with the activity data.

Permissions 0.01

Posted on

Over the course of working with Will, it was decided that the ability to show certain data only to certain viewers, based on permission settings, was more general than just profiles.  All permission logic and UI had previously lived in the diso-profile plugin.  Other plugins, however, such as actionstream, supported using the functionality if it was there.  It was reasoned that someone might want to use permissions on their actionstream (or anywhere else! just wrap the output up in an if statement and call diso_user_is(‘relationship’) ) without having the profile plugin installed.  Will nicely extracted the functionality into a separate plugin which I have now packaged for download at the DiSo code site.

Download the plugin

XRDS-Simple Plugin Update

Posted on

Just a note that my XRDS-Simple plugin has undergone some major refactoring as part of the DiSo project. It now lives at WordPress Extend.