I expected to get a kind of FLOSS lecture about #noemail, but instead I ended up brainstorming with Michael who immediately grasped what I’m after in the project — perhaps better than I do.

Michael reminded me of a Red Hat created open source Facebook challenger called, Mugshot, from back in 2006. Mugshot was more developed in my memory than Diaspora is now, but the project didn’t take off for whatever reasons. Parts of Mugshot are in Magnetism and maintained by Personas.com. Mugshot was a hyper aggregator and very nice and easy to use and accepted communications from most known social sites as well as a place you could hold a conversation about say a website or even a TV show.

In many ways, Mugshot would have been exactly what I’m looking for to deal with my activity streams.

Modern Times

But our talk quickly turned back to email. Michael sees email as a “enterprise service bus” that connects many applications via a common messaging format into a central processing unit. That CPU is YOU. You, dear human friends, are the processor that sorts out To Dos, Meeting Scheduling, Queries, Complaints, Referrals. In a fact, we probably spend more time sorting email than actually answering email. This is exactly the opposite of what one would like technology to do for us; we’re suddenly like Charlie Chaplin in Modern Times

What Michael and I are saying is not that communication has gone wrong and enslaved us, but that the wrong technology implementation is in place. Moving email out of the picture or at least away from the center toward the edge of our activities, moving the sorting operation out altogether, integrating existing apps and allowing for the integration of new and developing apps — open source or not — via open protocols, APIs, embedding and even referrals, how that might be done is one of the main goals of the #noemail project.

2 Comments

Finally! I concur. Email was designed for terminals and in the past three decades, it has not evolved so much as metastasized. Just as the original GUI “desktop” aped our real desktop (mostly a shelf used to layer important data to be searched for at a later time using the same methodology employed by archaeologists at a dig), email strove to emulate the metal box on a post at the end of our driveway (hello, junk mail).

Processor power, cloud computing, tagging, and high resolution imaging form the nexus of our re-imagined info-life: optimized for interpersonal connections and liberated from hard drives and housekeeping.

A message stream is a nice notion; I’ve long been a Smalltalk fan which Alan Kay says could better be called “message oriented” language than “object oriented”.

What I’ve been exploring recently related to the idea of a semantic desktop (just explorations, nothing polished or finished) is the idea of a stream of messages that can be thought of as “commands”. Commands are things like saying “create a circle with the name Paul Jones for this concept map” or “move this circle from here to there” or “change the color of this circle” or “add this chat message to this chat” or “delete this chat message from this chat” or “change the title of the email with this UUID” or so on. A key aspect of this social semantic desktop software rather than traditional regular desktop software is that multiple users can be adding commands to the same stream collaboratively, interacting either in real-time or asyncronously on the same documents. A set of commands related to some context like a chat session or concept map or email essentially define hypermessages or hyperdocuments that are human-level messages that seem like emails or blog posts or chat sessions or twitters or whatever, but as virtual documents with no specific existence as a file (unless a document version is cached or checkpointed for convenience in avoiding recalculation). For example, you could have a set of command messages that essentially define a human level message like an email (as in set the title to “Moving beyond email”, mark it as high priority, add Michael Tiemann to the list of people I want to read it, add a summary, fix a typo in the second paragraph, add an outline, annotate a link between it and a web page, link it to a twitter about it, link it to a blog post discussing it, add semantic metadata about key concepts, and so on, some of which email can’t do today especially after an email has been sent).

To play with those ideas and maybe someday produce something broadly usable (like to support Rakontu), I’ve been creating a Java front end with a CouchDB backend relay system for that (CouchDB can be used either peer-to-peer or more like a webserver). This command-oriented idea is to support creating desktop software that can either function peer-to-peer or that can use various interface modules to publish to the web, either with plain HTML pages or with blog posts or to various social media sites, or also with the existing email infrastructure as just one more channel, along with RSS feeds. There are other efforts in that direction (Apache had a start at a messaging client), this is just my own take on it. Why might this be useful? Your blog has no “preview button” on it, no integrated grammar or spell checker, no way to tag your entries in my own way, now way to automatically check the license of your blog post so I could easily send a copy to friends with my annotations, and so on — why should I not have a desktop system that could interface with your blog for me, something far beyond a web browser or RSS reader in scope?

Basically the idea of command messages is similar to writing desktop applications that have an do/undo/redo queue of command objects. You can tag commands with contexts (which can act like UUIDs defining a document but are a bit more than that), and when you want to reconstruct a document defined in the system, you retrieve all the commands relevant to that context and process them in some order to produce a document (or other experience like a video stream). Such a document defined by these command messages could be a “hyperdocument” or “hypermessage” that is like an emailed letter, or it could be a spreadsheet, or it could be an outline, or it could be anything else like a chat session or collaborative drawing. The advantage to this command paradigm over messages (given commands are indeed messages of a sort) is that it gets you to focus on the more abstract notion of incremental changes to shared state with your colleagues through producing commands together for a shared context. Incremental changes then support the idea of live real-time collaboration (as in a link I supplied in another comment mentioning Rakontu/Twirlip from today to a JavaScript collaborative concept map demo running on CouchDB). So while this system could interface with the web an email for you, it also have a live component that could operate outside that in a more peer-to-peer way (using CouchDB or even other systems).

Consider if someday ibiblio were to move to such a system in whole or in part. Each existing webpage would be added to some ibiblio stream as a command that defined it as is. Updates to the page would involve creating more commands When displaying the page on ibiblio server, code would fetch the related commands and synthesize the page at some point in time. To improve performance, cached copies of the synthesized pages could be kept around. Why bother with this when ibiblio works well now?Well, suddenly the site would have integrated version control and history. What’s more is that as with git and mercurial DVCS I could copy the history of some pages and then fork them and people could then send pull requests, like if I found and fixed a typo in your home page. I could easily fetch sets of content from ibiblio that relate to a common context (assuming the ibibio servers have indexed on some context UUID or keyword). And I could do all that with essentially the same tool that would enable me to send the equivalent of emails and blog post replies.

Of course, since people would be sending command messages around, you might want to interpret them in virtual environments for security reasons if they begin to include things like JavaScript code or Java or whatever. But, since in practice you have a history of all the commands that define a document for some context, you can always filter out commands in the stream that you don’t like the results of based on a white list or black list or whatever other system you want related to the document and your choice of who to trust for what purposes.

A key idea is that you could always send more command messages about something like a virtual email. No document ever has to be considered “finished” but is more like an organic growth with a version history. So a group could moderate emails up or down, label them as spam, post spelling corrections, or categorize them with tags and so on. If one person tags an hyperdocument in some way, everyone else in your workgroup or who accesses the related stream of updates gets that meta-information.

Anyway, I guess one might consider this as a sort of public disclosure to prevent others from patenting this idea, as well as trying to entice you to help implement it.

Sure there is lots of handwaving here. I’m sure there are lots of issues that remain to work out. And I’m sure there are lots of other good projects out there which overlap in various ways. Right now I’m wrestling with issues of overlapping commands and how to manage chained sequences of commands and related reconciliations. Key to success here would be to define some standards for these commands that everyone could adhere to. But it seems like one good way to define standards these days is to create adhoc standards implemented in FOSS applications and then later hope a standards body can get around to blessing them.

Anyway, I guess one could call what I am working towards as #noemail but it might be better to call it #muchmorethanemail.