After an incredible amount of time working with, and for, PostRank, I think I have finally landed on what I would like to do with their technology that would be useful to me.

Back when I was working a lot on their Google Reader Greasemonkey overlay, one of the features requested was “sort by PostRank”, which never made a lot of sense to me. Sort what by PostRank?

Buckets.

I want to read basically everything that comes through my feedreader, or at least see the headlines, but I may not care about it all at this moment. I don’t want an interestingness sort or filter, I want a bucketizer. I want to be able to say “I’ll read the best stuff right now when I’ve got a few seconds, and the rest later.”

I may never read the rest, which then amounts to filtering, but I may, and that’s different.

The best way to implement something like this would be to allow for “filtering” by PostRank ranges instead of having a max cutoff. That way I could have a 7+ feed, a 3-7 feed, and a 3- feed, for each feed. I’d then make (in my reader) a “Best” folder, a “Good” folder, and a “Bottomfeeder” folder. I’d process the content in “Best” a few times a day, “Good” at least once a week, “Bottomfeeder” whenever I had extra time to read stuff.

I actually really like this idea. A lot.

Many of your are familiar with my desire to discover where new tech overlaps with existing tech. I’ve thought for some time that µblogging was similar to existing stuff, but couldn’t quite place my finger on what the model would be to have the same experience in an existing system.

I think I now have it for IRC.

A µblogging site is an IRC channel where everyone is /ignore’d by default and where messages that would have been highlighted get through even if the user is /ignore’d.

That way, mentions/replies (and track!) get through from everyone, and people you un-/ignore you get all messages from.

First off, why would one want to do this? Well, cryptographic security is useful in communications medium other than email, and sometimes one may not have an email address for the person one is contacting. Also, a public key got from someone’s profile page is more likely to be their current key than the one got off a keyserver. Finally, if the discovery is done over TLS (or upcoming XRD signing techinques) then one can use the PKI to verify that the public key is, at very least, the one the owner of the URL claims. Which, for pseudonymous communications, may often be enough.

I will here propose three different ways to make this discovery work. Consumers must try all three. Publishers may publish more than one.

Content Negotiation

A public key represents a person. If a URL represents a person (such as on a profile page), then were that page’s data to be represented in the OpenPGP key format, one would get the user’s OpenPGP public key.

Send the header Accept: application/pgp-keys along with an HTTP GET request. If the Content-Type on the response is application/pgp-keys then the body is the user’s OpenPGP public key.

Links

If a GET or HEAD request is performed on the URL and in the headers is a Link header with rel=me and type=application/pgp-keys, then the URL of that link is the user’s OpenPGP public key.

If the Content-Type header of the GET request is text/html or application/xhtml+xml, then look in the page for <a> and <link> tags with rel=me and type=application/pgp-keys. If there is such a tag, then its href attribute is the URL to the user’s OpenPGP key.

LRDD+XRD

If LRDD discovery is performed on an endpoint, leading to the discovery of an XRD document containing a section like the following:

<Link>
<Rel>http://www.iana.org/assignments/relation/me;
<MediaType>application/pgp-keys</MediaType>
<URI>...</URI>
</Link>


Then the URI is the URI of the user’s OpenPGP key.

Security Considerations

The URLs used in all methods above should be either HTTPS URIs secured using TLS and a certificate issued by a CA known to the client, or data URIs.

Application to Other Crytography Schemes

Everything in this document applies equally well to public keys for any cryptography scheme, as long as the MIME types are changed appropriately.

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.

I’ve blogged numerous times about XMPP, SMTP, and communications evolution on the web.  I’ve suggested what I want ultimately and snippets of how we might get there.  Here, I am going to outline just briefly what I consider “next steps”.  The big ones.  Get these done, and you will have made a *huge* stride in online messaging:

1. Allow offline messages (type normal or chat) to be collected as “email”.  Gmail sort-of does this by presenting unseen offline messages in the web interface inbox.  I want IMAP access to these in the inbox and their archive.  Heck, store them in a Unix mailspool (have to store them somewhere anyway) and existing IMAP servers will just work for you!
2. SMTP messages are type=normal.  If you store offline messages in a mailspool and run an SMTP server on that spool, you’re mostly done.  Might be good to offer real-time deliver of those messages to the user of XMPP as well though.

That’s it! Sure, more can be done, but if you get the first one done I will be your biggest fan.  Do both and you’re well on your way to an evolution in how we deal with email (both from a user and a protocol perspective).  Yes, I’ve tried to build this.  I want to do it as an ejabberd module, but ejabberd is barely documented.  I’ll try again sometime if no one else does – maybe with ejabberd, maybe with someone else.