Singpolyma

's Profile

Author Archive

Surviving the Luddite Rebellion

Posted on

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:

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.

Beasts of the Standards World

Posted on

Working in the realm of standards (on the web or elsewhere) you eventually realise that there are a lot of terms, not all of which mean what they may initially seem to, or what they are always used for.  This post is an attempt to simply explain some of these common concepts.

Specifications

Or ‘specs’. These are formal documents describing a technology, protocol, or other pattern that may be standardised. A standard cannot exist without a specification, but a specification is not automatically a standard of any kind. Specifications are key in allowing interoperability.

Examples: OAuth, OpenID, EAUT, PortableContacts, HTML4.01, XMPP

Interoperability

Is when two or more implementations of a specification can “talk to” each other, without prior knowledge of the other implementation.

Examples: Psi and Google Talk, Firefox and Opera, USB keys

Implementation

A product, service, or similar that conforms (or claims to conform) to a particular specification.

Standards Body

Or standards organisation. A self-proclaimed shepherd of standards. These bodies hold different amounts of influence with different implementors, based on their membership. Some of these bodies provide resources to those working on specifications they have claimed as “their standards”.

Standards bodies get all of their authority from their membership. These organisations may claim specifications are standards that no one outside them considers to be standards.

Examples: W3C, IETF, OASIS, ISO, ECMA

Open Specification

A specification that has been released to the public under a liberal license.

Standards Community / Open Community

A community that has rallied around a specification or set of specifications. The community seeks to promote and maintain the specifications, and often refers to them as “standards”.

Example: PortableContacts Initiative

An “open” community operates in the open, with transparency into all aspects and discussions. Usually operate on mailing lists and IRC channels.

Example: microformats community

Standard

Not everyone agrees what comprises a “standard”, but many people agree that the term is overused and abused. I will here state my own interpretation of “standard”:

  1. A standard has a specification
  2. The specification has multiple, independant implementations
  3. One or more of these implementations is interoperable
  4. One or more of these implementations is libre software
  5. One or more of these implementations is “popular”
  6. There is an implementation for each relevant platform (OSs, browsers, etc)

Notice that the blessing of a standards body or community is not necessary.

Examples: RTF, HTML4.01, XMPP, H.262

Open Standard

A standard whose specification is an open specification. In addition, the specification should be clear of all patent encumbrances (may be necessary to be considered an open specification).

Examples: OpenID, OAuth, XHTML1.1, microformats

See also: On Language Extensions (in Haskell and Elsewhere)

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.

profile_services:

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 .myopenid.com). 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).

action_streams:

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.

Microblogging: The Open Wall

Posted on

I first experienced the beginnings of the “social web” in highscool.  My friends all had Xanga sites, which were basically blogs about nothing.  One practise of theirs, which annoyed me and seemed not to be present on the rest of the blogs I found, was that they abused comments horribly.  Comments were never about the content of the post.  Rather, to contact someone, you would comment on their most recent post.  To reply to someone’s comment, you would comment on the most recent post on their site.

This is exactly how Myspace profile comments and the Facebook “wall” are intended to work.  Facebook even built the “wall-to-wall” feature to show conversations back and forth across this odd system.

Now think of microblogging. Think of how you use it. Yes, there’s a publication aspect to it for sure (I say what I want people to hear).  There is also, however, this element of public conversation people seem so interested in.  Back-and-forth between two or more people, on their own pages, archived publicly.

What’s even better about this realization? I hated the Xanga comments, I hate the Facebook wall (and their new “comment on status” feature), but I love @replies.  So it wasn’t the concept of public conversations I wasn’t getting, but merely an implementation detail.  @replies are piped through a good notification system (which for Twitter these days involved scraping a feed and re-posting it to a fake identi.ca account so that I can get them via IM) so that they can be near-real-time when I have time, and are still there for me if I don’t.

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