zombition

Ah right. I was meaning something more like this so that you can skip the quoting business entirely and have the visual hierarchy match the conceptual hierarchy: https://s3-us-west-2.amazonaws.com/zombition-static/20151208...

Clueless developers and users around the turn of the millenium then somehow didn't understand the purpose of providing you with a quoted version of the email you replied to, and started putting the reply above the quoted mail, thus ending up sending a copy of the mail they just received back to the person they received it from ... and nobody seemed to notice how idiotic an idea that actually is, and so it became sortof the new norm in large parts of the internet to attach large blobs of completely useless and often close to unreadable text to every mail, up to the point where some people even invented justifications for the behaviour that mostly tend to describe how this "feature" allows them to work around the lack of proper thread handling in their mail clients.

Yes, I think the rationale must run something like "What if user A deletes the entire conversation they were having with user B, and user B replies to the deleted conversation, but user A doesn't know what the reply is about because they deleted the entire conversation, have a terrible memory, and are too embarrassed to ask user B to explain what's going on? Let's just send the entire conversation as quoted text every time."

Actually I didn't know; thank you for telling me! (That also makes me realize that I could likely do it in a much easier way than I currently am...) What are the email clients that allow that kind of behavior?

Thank you! I'm envisioning a future where email is a web application framework, so that the internet as a network of machines becomes a background detail, and application development happens at a higher level--on a protocol for a network of people. For example, if you're a developer and you want to be able to do something in your email conversations that you can't already do, you could write a plugin that performs that task (assuming you couldn't find a pre-existing plugin that did what you want), and then you could use it with everyone that you can communicate with via email because it would be directly integrated into your conversations. No server-side coding would be necessary, and you wouldn't have to bother with getting people to use your application because it would already be in a convenient place for them.

Coming back to your question: I see the potential use cases for this as primarily a superset of the current use cases for email. For bulk mailing and automated notifications, SMTP remains superior by nature of its simplicity (mostly... though this application edits self-generated notification messages to append notifications when there are multiple in a short time period). Email clients for personal use tend to have an immense number of bells and whistles, but if you assume that those will inevitably creep into this application as well over time, it should eventually be wholly practical for personal email.

Business emailing needs can be significantly more specialized, but they're also more likely to want advanced capabilities from their communication software. Assuming that some additional plugins offering desirable features are created, this could be very useful in a business setting.

I've added some gifs to the README that show editing, adding an inline reply, and adding a plugin. I know the flow to add a plugin is pretty gnarly at this point. I'm planning to pull them more directly into message content in the near future, because I tend to forget they're there when I have to click a button to even see that area. :)

Why, as a user, do I give %#@%! what the underlying transport is? I don't understand: Receiving messages on any of the transports is done every day and billions of platforms. After receiving, loading the messages into a common database, including mapping metadata such as sender, date, etc., seems relatively simple. Once in the database, sorting and filtering are simple.

I agree with this completely--so much so that I decided to make my own communication protocol (and client-server implementation) that would do whatever I wanted and still be backwards compatible with email. You can see the results here: https://github.com/Zombition/nsmtp-monolith. So clearly it's not impossible.

What am I missing?

The biggest difficulty isn't from pulling out metadata and mapping it to whatever you store locally. The specifications of different protocols determine the user behaviors that are possible with each protocol, and mapping behaviors between different protocols in a way that makes sense to end users is much more difficult if you want to retain quality communication with users who are not using your software to pull everything into one place. What I found from implementing a new protocol that aimed to be backwards compatible with SMTP was that maintaining backwards compatibility with SMTP guided 99% of my decisions for making the new protocol. If I wanted to add a feature, but it would be confusing for end users who might be trying to communicate with regular SMTP users (or the SMTP users that they were trying to communicate with), the only practical solution is to axe the feature or rehash it in a way that would be less confusing for communication between the two.

In practice this is quite difficult, because you have to balance awareness of both protocols with awareness of how data sent through one can be meaningfully translated to the other, and while you're considering those things, you also have to consider what the user experience is going to be like for people on both ends of the software. If you're trying to maintain compatibility with a widespread protocol like SMTP, there may be an enormous number of different client interfaces that can add a significant amount of variation to the user experience. It's a bit like unfolding a fractal.

SMS is used to send tiny chunks of text, and SMTP can be used to send message content in HTML format and rich text in addition to plaintext. I haven't worked much with rich text format, but HTML format for sure would be relatively impractical via SMS (XML adds a lot of characters, so you would have a lot of little chunks to send if you wanted to send HTML over SMS).

I tried some similar things when making Zombition, but I found that blurring the line between email and instant message mainly results in a more complicated UI and more details for end users to remember. For example, with instant messages you generally have some status information about whether or not the other user is online, whether or not they may have read whatever you just sent them, and whether or not they're typing a reply. If you want to add that into a email interface, how do you indicate to your end users that another user will never have associated status information because their account is on a server that is incompatible with the method you proposed?

Plus the behavioral differences between email and instant message didn't blend well: was I going to wait in a mixed email/instant message conversation for a response, or was I going to move on to the other conversations in my inbox and send a reply or archive each so that I could move on to doing other things? And if I wanted to temporarily leave an instant-message-like conversation so that I could deal with some more email-like conversations, would the person I was chatting with know whether or not I would return?

Eventually I stepped back to look at what additional value a user gained by blurring instant message and email in this way. Fundamentally they're both asynchronous text-based communication, and the things you can actually do with them aren't strikingly different. The biggest difference is in the expectations that a user has for each.

Anyway I still wanted to "innovate in the email space", so I decided to go a more extreme route, and I made my own pull-based protocol (superficial similarities to IM2000 - http://cr.yp.to/im2000.html) that retains backwards compatibility with email while adding abilities like stateful plugins (JavaScript apps/widgets) that can share data through the new protocol, editing messages after they're sent (SMTP recipients receive the new version after the update), and inline replies to parts of messages to enable nested conversations. If you're interested, I posted it earlier this afternoon here (https://news.ycombinator.com/item?id=10693535).

Hello world! I've been reading HN frequently for the past few years, and a recurring theme I noticed was frustration regarding email (intriguingly, it's only the people on HN who seem to dislike email; everyone else seems to universally adore it). So at the start of this year I decided to fix email by creating a new protocol that overcomes some of email's shortcomings while remaining backwards-compatible with email. Anything short of a new protocol struck me as lipstick on a pig, and anything that failed to maintain compatibility with email struck me as Google Wave.

This repository contains a full-stack implementation of the new protocol, so you can clone the repository, start up a vagrant machine and immediately connect via your web browser to try it out (though if you actually want to use it for sending and receiving emails, you won't get far by running it on a network with port 22 blocked). At the moment I don't have instructions for setting it up outside of Vagrant, but I'm also not sure how many people would actually be interested in running it themselves in a production environment. It's still quite rough around the edges, so it's not quite production-ready anyway, but most of the roughness is in the UI and edge cases in protocol handling which I've worked out logically but haven't yet implemented.

Protocol ambitions aside, I wanted to learn a lot from this experience--previously I had done some PHP and WordPress development, and I just wanted to try using Node and React to mash a Trello-like app together with email somehow, and things started happening so fast... Mainly I wanted to see how far I could go with one of my "crazy" ideas, because up until now I had always assumed that there would have to be something besides running out of time and money that would fundamentally stop me. Among the many things I learned, I discovered that it really does just boil down to the time and money! :) So now I'm looking for work.

That said, I am planning to continue development on this for my personal use (and possible work use later), so I'm open to suggestions, feedback, pull requests.... I know an open demo would be the bees knees. I'm planning to make such a demo in the near future, but for announcing this I did not want to. If you're interested in trying it out in a live environment rather than in Vagrant, I'm running this stack on zombition.com, and you can contact me at "tom" at the aforementioned domain for an invitation. Assuming nothing blows up :)