Show HN: nvlope.com, your mailbox with an API
nvlope.com
nvlope.com
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/
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.
IMAP does not reimplement XMPP, which I consider a feature. If you want instant messaging, you should use XMPP, and it's perfectly possible for a client to allow you to use both.
> Can you manage multiple inboxes with one IMAP account?
Yes, this is built in to the standard and every client can do this
> Can you do server side threading with IMAP?
Yes: http://tools.ietf.org/html/rfc5256
> Can you manage attachments and messages separately with IMAP?
Admittedly not, but again do you really want to? There are separate protocols for managing files and we already have dropbox.
> Can you upload attachments NOT using base64 using SMTP/IMAP?
Yes: http://tools.ietf.org/html/rfc3516
> Can you use labels with IMAP?
Google do it this way, but it's not standardised: https://developers.google.com/gmail/imap_extensions#access_t...
There are also user-defined flags
> Can you manage multiple domains under IMAP?
Yes, almost every client supports multiple accounts.
IMAP is a good candidate for the most often (and most badly) reinvented protocol around. There's plenty of reasons to expose parts off the current infrastructure over HTTP (Mandrill is really useful) but I think if your plan is "reinvent ALL the things" you need to be a lot clearer about what exactly is so backwards about on of the most well studied and well engineered pieces of infrastructure around.
the problem is that it is very complex, and features are not implemented consistently accross clients. Especially the newer, or not standardized ones you listed. You know that there is something wrong when an entire slew of RFCs can be replaced with a few simple api calls.
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.
(This obviously won't work for most end-users, sadly)
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.
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!
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!
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.
It only does the basic things:
* Listing folders/Maildirs.
* Retrieving messages from a named folder.
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.
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.
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.
[h] https://github.com/sup-heliotrope/heliotrope
[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.
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.
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.