Show HN: nvlope.com, your mailbox with an API(nvlope.com)
nvlope.com
Show HN: nvlope.com, your mailbox with an API
http://nvlope.com
14 comments
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.
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.
> Well, could you add instant messaging functionality to IMAP?
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.
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.
I guess I didnt phrase this very well, with IMAP i mean cloud imap services.
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.
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.
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.
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.
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)
(This obviously won't work for most end-users, sadly)
Yes, but we run our own servers.
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.
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.
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!
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!
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!
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!
Yes, we run the mail and api servers ourselves.
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.
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.
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:
It only does the basic things:
* Listing folders/Maildirs.
* Retrieving messages from a named folder.
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.
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.
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.
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.
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.
2-factor auth won't be available at beta launch (it's a MVP, we still have to see if there's enough interest), but we'll probably add 2-factor auth using https://www.authy.com at some point.
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/
[h] https://github.com/sup-heliotrope/heliotrope
[d] 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.
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/
[h] https://github.com/sup-heliotrope/heliotrope
[d] 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.
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/
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.
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.
Yes, we should definitely change that. Thanks.
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.
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.
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.
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!
Just letting you know that the landing page is broken on mobile
I'm getting a security warning in FF when subscribing to the newsletter:
http://imgur.com/bMo0G4z
http://imgur.com/bMo0G4z
Thanks for the tip
Enterprise option to keep it on our own servers and I'm sold. (Policy forbids SaaS and the like)
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/