
Show HN: nvlope.com, your mailbox with an API - eaigner
http://nvlope.com
======
calpaterson
> We want to be able to add new features that would exceed the scope of IMAP.
> Further, the current mail stack was just not built for a good mobile
> experience, and it's complexity provides a considerable barrier for emerging
> mobile clients. We want to cut off the legacy baggage and keep the entry
> barrier for users and developers as low as possible.

What new features? Current email infrastructure already implements everything
mentioned on this page. There's mention of the "limitations" of IMAP and SMTP
but it seems specious. Reading email is a pretty well solved problem now, and
I think every popular language has libraries for IMAP and SMTP.

On the topic of IMAP's performance on mobile: there is an installed base of
millions who use IMAP for their mail on their phones. There are many, many
good email clients for Android (I recommend K-9 Mail, which is FOSS) and they
work great. Presumably it is the same for iOS.

If they write a nice HTTP API for reading mail inboxes, that will probably be
a nice option for people who for some reason can't or don't want to use IMAP,
but there really is nothing here to move mail forward.

Mailpile is a lot more interesting (webmail and privacy features):
[https://www.mailpile.is/](https://www.mailpile.is/)

~~~
eaigner
Well, could you add instant messaging functionality to IMAP? Can you manage
multiple inboxes with one IMAP account? Can you do server side threading with
IMAP? Can you manage attachments and messages separately with IMAP? Can you
upload attachments NOT using base64 using SMTP/IMAP? Can you use labels with
IMAP? Can you manage multiple domains under IMAP? etc.

As for iOS client's there are exactly 3 that come to mind. Gmail, Apple Mail
and Sparrow (discontinued).

We realize that this product is not for everyone - but for those who want a
zero config, hassle free product.

Mailpile is for an entirely different audience.

~~~
untog
_As for iOS client 's there are exactly 3 that come to mind. Gmail, Apple Mail
and Sparrow (discontinued)._

There's a good reason for that- Apple won't let you check a mail server on the
client side. So you have to do what Mailbox did and set up huge server
infrastructure to check people's e-mail then send push notifications. It makes
it a _lot_ more difficult than just making a client app.

~~~
e12e
So, the "solution" is to have your users set up a .forward-filter that pings a
web service on new mail? Then have a really simple status server that simply
replies with number of new mails since last check (or something along those
lines...) - and have your email client poll (and reset) that counter... would
give a few false-positives, but probably be better than having to poll an
actual (variety of) IMAP/POP3-servers.

(This obviously won't work for most end-users, sadly)

------
jluxenberg
Google's products have been sapping my desire to build things. It used to be
that we had to build our own tools to do thing like edit code, send email with
a quick workflow, etc. Not so any longer.

I've found a Gmail-based email workflow that work really well for me (and
requires no browser extensions or custom code). I now own a Chromecast that
allows me to play music and video on my home AV system. It just works, out of
the box.

This looks really compelling if I was the kind of hacker that still hacked
tools. These days I hack my workflow and use existing tools because they've
gotten really good.

------
psquid
The (minor) bad first: your landing page is utterly broken without JavaScript
(I use NoScript, and while I whitelist most sites, a broken page before
setting that still leaves a bad taste if there's no reason for it to break),
and I can't see anything you do on it that couldn't at least gracefully fall
back. At the very least, if you wish to require JavaScript, you might want to
say upfront there that it'll be required.

As for the good: I'm liking a lot of where you say you want to go with nvlope,
and I can't say I particularly enjoy IMAP, from working with it, so your
planned API is more than a few steps up. :)

Can't wait to see how things develop!

------
grinich
This is really cool! Are you building both the mail provider layer and the UI?
(Not clear from the description.) Are you running your own mail relays?

I've actually been working on a new email platform with some friends for the
past few months. Our stuff sits on top of IMAP, so you can use it with
existing accounts like Gmail or Yahoo!, and the UI is super hackable
AngularJS. It's kind of like Rails/Meteor for email.

We're going to open source it in January/February, but looking for folks to
try it early while we're still writing docs. (Including OP!) Feel free to ping
me-- we're also going to ship it as a docker container so it's super easy to
deploy on whatever provider.

Sorry if I'm hijacking this thread! I just figured some folks here might be
interested. :)

Death to IMAP!

~~~
eaigner
Yes, we run the mail and api servers ourselves.

------
javajosh
Like the idea of normalizing email behind a web API, but don't see how this
can survive if there is any credible open-source alternative. I can't imagine
that the number of people wanting to write email clients is that large -
unless you consider bespoke applications that have some email functionality to
be a custom client.

In fact, if I had to guess, I'd bet a late night convo that went: "You know,
any sufficiently advanced application gets email," "Then we should build and
sell an email backend SaaS!" "Yeah!" And then the splash page went up and you
started hacking.

Good luck with this anyway.

~~~
stevekemp
Yes I wrote something similar, presenting a JSON API on the folders in
~/Maildir for all the local users of a server.

It only does the basic things:

    
    
      * Listing folders/Maildirs.
      * Retrieving messages from a named folder.
    

I didn't have a compelling use for it, but I was curious about whether it
would make sense to base my mail-client on an API rather than the filesystem.
(In the end my mail-client only reads/writes to ~/Maildir and I avoided the
API step in the middle.)

------
robbles
This sounds like an awesome idea, and a product I'd definitely use.

Just a tip though - I had to read halfway down the page just to find out what
nvlope.com _IS_ (an email client with an API). "It's time to move email
forward." is a nice sentiment, but it really doesn't explain your product at
all. You should think about adding a short descriptive tagline that actually
explains it before listing out a raft of features.

------
balanceiskey15
Love where this is headed. Could you comment on security with nvlope? I'm
curious in particular about two-factor auth, but anymore insight would be
great.

~~~
dsl
It looks like the mail exchanger is (currently) hosted on Digital Ocean in New
York.

They also use CloudFlare in front of the site, which means all your webmail or
API traffic will be subject to inspection and logging by a company based in
the US.

------
e12e
I welcome new projects into the email space -- especially those that
contribute something to the open conversation around email. Sadly you only
offer an api -- not an open server I can run myself -- but if your api turns
out to be reasonable -- that is a perfectly fine contribution!

I've been thinking on the email a lot the past few years(!) -- and I see we
all come to similar conclusions separately, me (just thinking), the author of
sup[s] with heliotrope[h] -- and mailpile[1] and now nvlope -- building on top
of IMAP probably isn't the best way forward, unless part of your goal is to
support IMAP clients. Another interesting (for the architecture and data
modelling at least) project is dbmail[d].

It will be interesting to see if codifying a json/rest api for email will be
useful in the end or not -- I certainly see how one could build an android
client on top of it -- I'm not convinced IMAP doesn't offer a better off-
line/cache story though.

At any rate, I'll be storing mail on my own server, so a service like this
isn't really for me -- but as I said -- I certainly appreciate seeing some
battle tested public apis. They will offer some insight into what kind of
design and architectural lessons you've drawn so far, making a responsive
email service that is centred around search and labels.

Wonder a bit about the "file management" feature -- it sounds like a bit of a
mis-feature to me. And I don't get the markdown composition -- do you then
send the markdown as the text-part? Then again, I never did get this
fascination for html-email. Maybe it's just getting (perfectly serious)
business responses prefixed with "my responses are in blue" and the like.

[s] [http://supmua.org/](http://supmua.org/)

[h] [https://github.com/sup-heliotrope/heliotrope](https://github.com/sup-
heliotrope/heliotrope)

[d] [http://dbmail.org/](http://dbmail.org/)

[1] Note, mailpile supports IMAP -- but not between the front-end (web) client
and the back-end(http) mail client. Obviously all email systems needs to deal
with email, so at some point someone must speak smtp for ingestion, and there
might very well be pop/imap between the "back-end part of the front-end" and
whichever server mails lands on via smtp. Or not.

~~~
eaigner
Markdown is a client feature. We send markdown as text and converted as html.
If you look at the API there are just text and html fields
[http://developer.nvlope.com/v1/mail/send/](http://developer.nvlope.com/v1/mail/send/)

------
carlosdp
Looks cool, but it hijacks my browser history with the "Signing In..." page
which doesn't seem to do anything.

On a side note, I'd recommend making the link to the API documentation more
prominent than a link mention in the write-up, as it is the core part of the
service.

~~~
eaigner
Yes, we should definitely change that. Thanks.

------
wheaties
You going to go enterprise with this? That is, "mailboxes for your website."
Would pay for that. Currently most email providers only send messages. I can
get that from Amazon. What I can't get is an inbox for users which I have some
control over too.

~~~
eaigner
Not sure if I completely understood your requirements, but you can add several
custom domains (number depends on the plan) to your account, create mailboxes
and aliases for them and can send and receive from those addresses as well.

Those are added to your account and can be accessed as individual mailboxes or
via the unified inbox. They are not separate accounts with separate logins.
Enterprise grade account management would be a feature to add at some point in
the future.

------
martinesko36
Guys, that's exactly what we need! Just launch now, seriously. Building a
backend for an email client is such a pain and I can imagine how this could
save lives. But we'd love to be able to put it on our servers. Good luck and
hope to try it out soon!

------
mck-
Just letting you know that the landing page is broken on mobile

------
leepowers
I'm getting a security warning in FF when subscribing to the newsletter:

[http://imgur.com/bMo0G4z](http://imgur.com/bMo0G4z)

~~~
eaigner
Thanks for the tip

------
rMBP
Enterprise option to keep it on our own servers and I'm sold. (Policy forbids
SaaS and the like)

