Skip navigation

email — mixing its metaphors?

With email, we’ve got a problem. Never mind about authentication — what about conversation? Email provides us with two abstractions with which to handle multiple recievers and multiple senders — lengthy ‘To:’ fields and mailing lists. Neither works very well — the lengthy ‘To:’ field is inflexible, since adding a new user doesn’t really put them in a position to view prior posts; and the mailing list, with its flexible membership, does the right thing but in a way so slow and cumbersome that setting one up is a chore at best.

I’d like to see the ‘conversation’ — as opposed to the ‘message’ — emerge as the fundamental abstraction of email. We can think of conversations as a sort of ad-hoc mailing list. Merely sending a message is enough to get one started. As long as the conversation is uniquely addressable — not a challenge these days — then people can be added to it or taken away. The conversation can be folded into other conversations as time goes by.

A conversation is fundamentally a message and its replies. The replies are themselves conversations — there is a nested structure here that is sort of like a headed list, only having a long tail. What you do with all these conversations is you put them up on the web behind a big authentication & authorization system. Users may perform certain modifications to the conversation — adding replies, for example — asynchronously; then the ‘conversation server’ ties together all the changes so that people get a consistent view of the conversation.

Email is built on a ‘push’ model with metaphors derived from the good old U.S. Postal Service — email, Post Office Protocol, postmaster — whereas the really heavy lifting in mail clients and web services is done by the thread. Add access control to the thread and, voilà, you have the ‘conversation’ described above.

Conversations allow for fine-grained expresssion of interest, as well as better access control. The notion of posting a conversation and then inviting people to it is basically a pull approach to messaging. Spam becomes both more transparent and less voluminous in pull approaches — users may opt not to accept the invitation, by not reading the post; and whereas auditing email is a chore at best, since it’s not supposed to stick around, auditing conversations is easy and only needs to be done once, at the source. Complaints can be directed against a conversation and the offending converser can have their conversating privileges revoked.

Conversations, by sticking closer to the bone in electronic communication, allow for more natural use of email and better approaches to email security.

Advertisements

One Comment

  1. Posted March 2, 2007 at 05:50:19 UTC | Permalink

    Howdie, Jason. You’re quite the natural blogger; you might consider notifying your brother of this blog, if you haven’t already. I think he might, despite mutual differences, get a slight bit out of it.

    On the matter of conversations: the canonical “ReplyTo:” field provides a well-proven, well-established mechanism for constructing ad-hoc conversations. (I certainly make excessive usage of this field… Am I the only one, I wonder? “mutt,” the mail-reader what sucks slightly less than the rest, implicitly threads all e-mail on the basis of this field.)

    That being that, we merely require a mechanism for conveniently, simply publishing a flat list of plain-text e-mail files; all together, the list composes what we mean by a “conversation,” so long as each textual e-mail file in the list maintains the invariant property of having a “ReplyTo:” field referencing the parent e-mail file of that file. This can be guaranteed by structuring these e-mail files as a tessellated file hierarchy, whereby the root e-mail for that conversation resides at the file root for that conversation, and subsidiary, child e-mail reside at sub-paths of that root. Then, given such a structure, one could simply inject the “ReplyTo:” field, as needed, into a resultant flat list of those files; this guarantees the
    invariant property – and also provides a convenient, file-based mechanism for navigating the conversation.

    SVN, the grand favorite, or Darqs, my bold, new favorite, are two such mechanisms; which would need a happy front-end, I imagine, for the matter of conveniently posting to and pulling from a “conversation.”

    Thoughts, thoughts, thoughts. Back to the Google-study grind!

    Humbly yours,
    Brian


One Trackback/Pingback

  1. […] 4th, 2007 Previously, I’ve criticized email for having the wrong underlying metaphor. I’d like to a see the conversation replace […]

Post a Comment

You must be logged in to post a comment.
%d bloggers like this: