
Show HN: NSMTP Monolith – Full-stack email-compatible communication - zombition
https://github.com/Zombition/nsmtp-monolith
======
zombition
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 :)

------
andrewrothman
Very interesting! What kind of use cases are you envisioning that this opens
up?

I'd love to see a screencast or some screenshots.

~~~
zombition
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. :)

