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.

class=object-type

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.

class=verb

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.

class=object

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.

class=target

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.

actor

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 http://activitystrea.ms/schema/1.0/post 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>
		<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" />
	</div>

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/del.icio.us/notifications), “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 #hashtags, 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 del.icio.us, 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 del.icio.us, 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.

They all suck.  I’m not kidding.  I’ve tried Qt, GTK+, Tk, even Shoes.  Shoes is the best of the lot so far, but none of them seem to get right the one thing I’ve come to take for granted on the web: layout.

Take the following HTML snippet, for example:

<div>
<input type="checkbox" />
<span>label</span>
<div style="display:inline-block;margin-left:40px;margin-right:40px;">
<div>name</div>
<div>description</div>
</div>
<span>HAI</span>
</div>

You may crtisize the form of this snippet, but it’s pretty clear what it does: one row with a checkbox, a label next to it, a two-line element with a name and description, and finally the text “HAI”.

In Shoes (the one that makes this easiest) this is almost:

stack {
flow {
check
stack {
para 'name'
para 'description'
}
para 'Free'
}
}


Though apparently I need to know the width I want for the name/description pair up front (in pixels or percents) or it will try to take up the full window and thus wrap to a seperate line.

The thing is, though, it’s not really the toolkits’ fault. Layout isn’t a thing they’re supposed to be good at, and they’re certainly not used to use fluid-layout types who care what happens when the window gets resized (with all fairness to toolbars, which handle that ok). Most simple apps are designed to have their main window one size and not changed, which makes absolute positioning of everything possible. Toolkits have enough to deal with drawing widgets and interacting with the desktop environment and OS to get events.

The thing is, widgets are a solved problem. Really. If I want to throw some widgets on a window and hook up event handlers, I have umpteen choices available to me. Yet another new toolkit is not the answer, since it too would likely get bogged down with the same details, and if it didn’t have good bindings to a lot of languages might end up like shoes, which is bound to its own custom VM.

I think, then, I have something that may begin to resemble a solution. Why not use a syntax that is much better at expressing the nature of a layout? Why not, in fact, use XForms (with some lightweight subset of CSS)? Then we just need scripts to convert the layout descriptions into the widget and positioning code for each different toolkit. Then the developer can wire up events using their favourite toolkit, regenerating the widget part of the code when changes are made to the UI.

The current OpenID delegation model is great.  One adds some simple discovery code to one’s homepage and poof! you have an easy to remember OpenID that remains the same even if one changes providers.  That’s all great, and I’ve been using it almost since OpenID came out.

But I think we can do even better.

When I’m at home on my own computer I like to use myopenid.com.  Among other things, it lets me sign in with a client-side TLS certificate, which is much more secure than a password.

When I’m at school in the labs, I don’t want to install a certificate there. Nor do I want to use a password by itself.  Myopenid.com no longer provides the best featureset for what I would like to do, but rather the OpenID-Jabber bridge at http://myid.asemantics.com is likely much closer.

So one solution is to add both OpenIDs to services I use, and then I can use the URL for the one I want, when I want.  The problem with this solution is (1) the abstraction is horrible, and all the benefits of delegation go away (2) not all services I use let me associate multiple OpenIDs (I’m looking at you, PostRank).

So how do we solve this?

I would love to add the delegation discovery information for both providers to my homepage.  Then, when logging in, the RP gets the list of providers I use, and presents me with a menu asking which one I prefer.  Providers not yet upgraded to have this new functionality would just keep using the first one they found, so it degrades quite gracefully.

I’m very interested to see feedback from the community on this idea.  Post comments below, or tweet @singpolyma 🙂

The Luddite Rebellion is coming. It may not come literally, and we may yet stop it, but we will not stop it by sitting idly by.

What is the Luddite Rebellion? Well, a Luddite is someone who stands opposed to technology and freedom, not because they are against them per se, but because they are afraid. They may have good reason to be afraid: malware, spam, privacy invasions, stalking, and all manner of danger can come from allowing technology to be used freely.

Hackers are on the other side of this struggle. Hackers stand for tinkering that leads to innovation. This tinkering and innovation cannot happen without free access to technology. Not all hackers agree on what "free" means, but the restrictions the Luddites would like to see are certainly the opposite of freedom. Hackers tend to form communities, and staying connected to one or more hacker communities may just be key to surviving the Luddite Rebellion.

What will an unfulfilled Luddite Rebellion look like? It will look like the end of net neutrality. It will look like the limitation of general purpose computing platforms. It will look like widespread computing with no hackability. It will look like education that teaches security through ignorance and through a lack of access to powerful tools.

What would a fulfilled Luddite Rebellion look like? Well, first it would look like an unfulfilled one. Then it would move to a purposeful oppression of hackers and technologists in general. A general anti-technology sentiment ultimately culminating in a forceful out-putting of technologists and technology of all kinds, possibly violent.

I don’t know if the Luddite Rebellion will ever be completely fulfilled, but the roots are starting now. The balance of this article will talk about ways hackers, sympathizers, and our society can survive.

Keep an Active Passport

This may seem to be the most obvious. I do this anyway, just as a general good practise. Never let your passport expire, or you may find yourself stuck where you’re at.

Libre Software

Sometimes also called "free software", this body of work by the BSD projects, GNU projects, and others is dedicated to hackable software. Software that is published in hackable form. No matter what happens regarding lock-downs in the Luddite Rebellion, this hackable form (usually the "source code") will be taken by hackers and preserved, it will not be locked down. Even non-hackers will be able to get access to the freedom-supporting versions of this software. If you run libre software now, you are contributing to this body of work and preparing yourself for a future where it may be the only software that respects your rights.

Archive

Backup your data! Not just your offline data, but your online data as well. You never know when access to it may be taken away. Store it in simple, hackable formats. No matter how "open" a format may be, it’s ability to survive the Luddite Rebellion really relies on it being simple and hackable. Open Office documents may be very "open", but they are much less hackable than (X)HTML, plain text or WikiText, (La)TeX, or RTF.

Backup your communications especially! Email, IM logs, Microblogging content, bookmarks, and other forms of online communication can all be backed up to simple, text-based formats.

Backup other people’s data as well. Data that you may find useful in the future, especially to survive the Luddite Rebellion. All that educational and reference material you can "just link to and find later"? Download it to your personal archive.

Keep your archive in more than one place. If you only have it on your laptop, and you lose that laptop, what good is it to you?

Personal Brand

Keep a strong personal brand. This brand may be anonymous (hard to tie to the "meatspace" you) or real. Being easy to get in touch with is crucial in surviving the communication crackdowns that the Luddite Rebellion may bring.

Thing may enter your person brand on purpose, or by accident. The trick is recognising them and keeping them there.

My brand:

• Stephen Paul Weber (all three names)
• singpolyma (my very unique handle, keeps me easy to find across communication platforms)
• The colour orange (my website, my shoes, my coat, several of my shirts)
• My avatar: http://www.gravatar.com/avatar/3ab4d3a66e470ce10eb7ec812fab3c46
• My PGP key /public.asc (more on below)

PGP

PGP is a technology that allows people to communicate securely, and to be sure of who they are communicating with.

• Have a PGP key (if you need help getting set up, give me a shout).
• Make sure your PGP key is well published (I have mine on key servers, a link from the mail page of my site, and a link in the headers of every email I send).
• Sign all emails (so people know it’s you, and get used to verifying).
• Memorize and publicize your key id and/or fingerprint as well. There are different mnemonic programs out there to help. My key id is: nerve perfume pogo (or 913D04EB).
• Understand the PGP Web of Trust and build yourself a trust network.

Wrap-up

These are just a few key ways that hackers, technologists, sympathizers and others can prepare themselves to survive, and maybe prevent the complete fulfilment of, the Luddite Rebellion.

Registered Commons page for this article.