9 ms·

Show HN: nvlope.com, your mailbox with an API

65 points by eaigner 13y ago

carlosdp 13y ago
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 13y ago
  Yes, we should definitely change that. Thanks.
balanceiskey15 13y ago
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.
- eaigner 13y ago
  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 https://www.authy.com at some point.
- dsl 13y ago
  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.
jluxenberg 13y ago
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.
wheaties 13y ago
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 13y ago
  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.
leepowers 13y ago
I'm getting a security warning in FF when subscribing to the newsletter: http://imgur.com/bMo0G4z http://imgur.com/bMo0G4z
- eaigner 13y ago
  Thanks for the tip
robbles 13y ago
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.
calpaterson 13y ago
> 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 13y ago
  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 13y ago
    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.
rMBP 13y ago
Enterprise option to keep it on our own servers and I'm sold. (Policy forbids SaaS and the like)
martinesko36 13y ago
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!
javajosh 13y ago
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 13y ago
  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.)
psquid 13y ago
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 13y ago
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 13y ago
  Yes, we run the mail and api servers ourselves.
mck- 13y ago
Just letting you know that the landing page is broken on mobile
e12e 13y ago
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 13y ago
  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/

65 points by eaigner 13y ago

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 13y ago
Yes, we should definitely change that. Thanks.

balanceiskey15 13y ago

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.

eaigner 13y ago
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 https://www.authy.com at some point.
dsl 13y ago
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.

jluxenberg 13y ago

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.

wheaties 13y ago

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 13y ago
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.

leepowers 13y ago

I'm getting a security warning in FF when subscribing to the newsletter: http://imgur.com/bMo0G4z http://imgur.com/bMo0G4z

eaigner 13y ago
Thanks for the tip

robbles 13y ago

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.

calpaterson 13y ago

> 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 13y ago
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 13y ago
  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.

rMBP 13y ago

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

martinesko36 13y ago

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!

javajosh 13y ago

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 13y ago
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.)

psquid 13y ago

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 13y ago

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 13y ago
Yes, we run the mail and api servers ourselves.

mck- 13y ago

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

e12e 13y ago

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 13y ago
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/