Hacker News new | past | comments | ask | show | jobs | submit login
Desktop App for All Your Email (inky.com)
158 points by tortilla on Dec 26, 2012 | hide | past | favorite | 152 comments



So, uh, I guess we're not in stealth mode anymore...

I'm the founder; here are answers to some questions people have asked here. By way of background, I'm a hacker who (long ago) co-wrote Crash Bandicoot (1&2) and co-founded ITA Software, which was sold to Google in 2010.

Q: I'm really busy; why should I invest 5 minutes trying this? A: Inky lets you sort your mail by relevance to you; you can train the ML algorithm, but it does a pretty good job for most users out of the box. Inky knows about many kinds of emails, like daily deals, social friend requests, etc., and lets you view these in special folders. Inky's design is minimalist, but don't be fooled: it is a real IMAP/POP client capable of doing virtually everything Thunderbird, etc. can -- and in some cases more (e.g., it makes adding new accounts trivial, and offers a unified inbox on the desktop). Finally, we've architected Inky to preserve your privacy: your email never touches our network, so our employees can't see your mail.

All that being said, you really need to try Inky for a few days to see what makes it (in our view) great. We've invested a lot of time, thought, and iteration into improving the core email reading experience. You'll see, after a while, that essential features that nobody really thinks about like account setup, recipient auto-complete, and unified inbox just work better in Inky.

Q: Is this web site packaged as a native app? A: No. It is a native app with a portable UI built using web technologies. Many hackers assume that because it uses HTML/CSS/JavaScript for the UI, it's not running native code. It is; look in your process table. However, the same architecture does support deployment as a plain web site; that's part of the motivation for using web technologies for the UI.

Q: What do you mean it's cloud-enabled? A: Inky stores your settings -- including authentication information for your mail servers -- in the cloud. This means that when you install Inky on a new computer and log in, it automatically knows about all your accounts. (Security wonks: please see our FAQ page or email us at hi@inky.com for how we do this safely.) Of course, your mail is also stored in the cloud; email is perhaps the oldest mainstream "cloud-based" service in this sense.

Q: It doesn't discover <major provider>! A: That's a bug. Please report it to feedback@inky.com. Inky's auto-discovery will discover almost anything, including minor providers and mail servers people like me host themselves. But there are still bugs. Please help us find them by reporting them to us.

Q: It didn't work! A: Please report this via feedback@inky.com (yes, we know it's ironic if you have to use another mail client to send the email). It does work for many people, but there are still bugs, and targets (e.g., WinXP) we don't support perfectly yet.

Q: The scrolling sucks! A: We know; we're working on making the scrolling work natively.

Q: How are you planning to make money? A: That's really putting the cart before the horse. We're focused on solving the fundamental problem, which is that email clients are dumb and complicated, when they should be getting smarter and simpler. There are many ways to make money in the email space; we're not worried about making money right now.

Q: But seriously: you're going to data-mine my email and sell the data, right? A: No. Seriously. There are lots of ways to make money in the email space that don't involve systemic privacy invasion.

Q: I tried it, but <thing-I-don't-like>! A: Please email us at <feedback@inky.com>. We're hardly out of alpha at this point and are focused primarily on fixing bugs. Email is complicated; our goals are ambitious; our team is small -- please help us by reporting specific bugs so we can fix whatever problems you encounter.

Q: What about mobile versions? What about exchange support? What about a Linux version? Retina support? Chat? Calendar? Doing my laundry? A: We'd like to get the kinks out of the present desktop version before talking about major new ports. But, of course, your email client is most useful when it runs seamlessly across all your devices, and syncs with all your favorite providers.

Q: Are you just going to be acquired by Google and get shut down? A: No. This is about fixing email; it's not about building something to flip. My last company fixed travel search, and it took 10+ years. (Assuming you even consider it done, which I'm sure the 500+ employees at ITA Software do not.)

Q: I would like to know how it works. A: We will talk more about the architecture and tool chain, which are somewhat novel, at some point later.

Q: Why did you launch if there are still bugs? A: We didn't. People found us hiding in plain view.


Since my other comment got downvoted for unknown reasons I'll attach the WARNING here again:

Be aware that Inky uploads your imap password to their servers (see their FAQ). This is probably due to incompetence rather than malice but if you care about your e-mail password you should refrain from installing this software. If you have already entered your imap password into Inky you should change it ASAP.


The password is encrypted client side!


That's meaningless. It opens a whole range of attack vectors for absolutely reason. No least your inky password (which they presumably use as the key). They allow a minimum length of 6 chars on that, which can be brute forced within hours on todays hardware.

They very clearly have no idea what they're doing (security-wise), consequently this is very likely not the only fatal flaw in their implementation.


Easy account sync between devices is a good enough reason for me. It can be implemented securely, so in general I don't see a problem. Hey, Google Chrome syncs saved passwords, online password vaults like LastPass do this too, are they security-incompetent too? Don't know what hash function and encryption they use, but I think it's possible to pick/configure them so that brute-forcing even 6-character passwords is impractical.


If you're willing to gamble your imap password on their undocumented process then that's fine.

I posted my warning because I think most users are not even aware that they're sending their password to inky and the implied risk. Also inky does nothing to educate them (a handwavy marketing-blurb buried in the FAQ does not count).

Sorry but comparing inky to LastPass and Google is laughable. Google is trusted because it's Google. LastPass is trusted because their process is extensively documented. If you plan to casually juggle your users crown jewels for a convenience-feature then you'd better fit into one of these two categories.


Yep, the process needs to be transparent, documented and verifiable. Until it is, good idea to warn others!


Client side encryption is only useful when the application is open source. Otherwise, we've no idea if there is a back door in the application and a signal that their servers can send back to the client to inform it to send over all of your login details.

Hushmail were forced by their government to backdoor their system for this purpose. What's stopping the same thing from happening to Inky?


Right, but they also store the decryption key -- your Inky password. Which is (presumably?) encrypted… somehow? Maybe?


This would be nice to know, because they're serving as a password-management app for all of your email passwords.

Presumably, they would not store your Inky password as well -- instead, they'd store a secure hash, not MD5 or SHA-1, which are built for speed, not security....


It's more complicated than that. Please see my comments on security elsewhere in the thread. We store a password verifier object -- that's akin to a secure hash, but our authentication model offers better guarantees about protection from man-in-the-middle attacks.


See my comments on security elsewhere in the thread.


Q: How are you planning to make money? A: That's really putting the cart before the horse. We're focused on solving the fundamental problem, which is that email clients are dumb and complicated, when they should be getting smarter and simpler. There are many ways to make money in the email space; we're not worried about making money right now.

Can you expand on this? I agree with your premise that email clients should be getting smarter and simpler (or at least I accept that as a valid premise). Really, though, how do you plan to make money? How do we know this won't disappear/be no longer supported in six months or a year when you get tired of not having any revenue?


My previous company (ITA Software) made enough revenue to (rather comfortably) justify the ~$700M valuation Google paid for it. ITA never took in a single cent of advertising money or money derived from selling users' data to third parties.

I believe a vastly better email platform has inherent value, just like a vastly better travel planning system has inherent value. Look at the dozens of ways companies are currently earning their keep in the email sector. It's not the same as Twitter or Facebook, which only have usability value to consumers, and which can only succeed at massive scale.


Do you really have to ask this? If it isn't open source, the answer has to be "no", or at best, "maybe".

Which is, not-so-coincidentally, why my next project is 100% open source.


Yes please answer this because it sucks when software goes away. I want a great email client as long lived as vim will be.


This, precisely. What's in it for you? If you plan on keeping your product free for your users, then you are obviously planning on monetizing your users in a different way. I'm very curious to find out how exactly.


> No. It is a native app with a portable UI built using web technologies.

Is it http://inky.com/mail/ wrapped around with Chromium Embedded Framework (CEF), with web page javascript calling native Python scripts?


It would seem like it since it has libcef which contains the definition for 'cef_browser_create'. Furthermore, it seems that they have added other Javascript libraries into it like CKEditor (http://ckeditor.com/)


Yes, it embeds Python and uses CEF. But there's a lot of other native code running there as well. As I said above, mail is complicated.


Wait. You co-wrote two of the best games ever and now you built a mail client? Ah well, choices in life :) I'll try Inky just because of your credentials. Although it's probably futile; basically the only email client able to handle my 29 gb, ~20 year old inbox is Gmail, the rest (cloud or desktop) just loads forever after importing.


Many people ferociously criticized Crash Bandicoot when it launched in 1996 as well; people just don't remember that.

Please let us know how Inky works for your huge inbox. Like you, some of us (including me) have enormous inboxes, and we've worked hard to make Inky's indexing use very little resources on your box.


I didn't know it in '96; I got to know it much later when I picked up a PS1 on queensday in the Netherlands; it included Crash 1 & 3 and I've been a huge fan ever since (I own all Crashs on all platforms). I play it on my openpandora a lot. For me (and a lot of people I know) the gameplay is better than most stuff out there now.

I'll definitely try Inky :) I'll let you know how it goes.


Inky connected to imap.gmail.com using IMAP, but authentication could not complete. port 993 using TLS: 'ascii' codec can't decode byte 0xe4 in position 1: ordinal not in range(128)


If you have another email account, please add it to Inky, try to discover your GMail account again, and "Report a Problem" using the menu in the lower left corner. Obviously GMail should discover properly; this is a bug.


How long did it take you guys to build inky as it is now?


I really don't want to see ads, but that's preferable over selling my data for a free option. I'd still recommend you give people an ad-free trial (and please make the trial only count days you actually open the app, like Beyond Compare). I'm a free software guy at heart, so the more generous you are with your trial, the more willing I feel to turn a blind eye to opening my wallet for software. Suggestions for how I'd be willing to pay:

1) $20-40/yr for a web service. Most of the world is Windows, so if I'm on the go without my OS X laptop, my phone has died, and I want to check my email I'd have to remember my other email passwords to login to their own services after I got in the habit of using Inky... that wouldn't be good. I'd still want data security, so I'd expect any data that hits your servers to be strongly encrypted in a manner similar to SpiderOak's approach (though I'd prefer Scrypt over PBKDF2). If you open-sourced your client and just sold the service I'd pay more. 2) $50 for the app itself. Less if you want me to pay every year for upgrades.


Thanks -- this is helpful feedback. We agree that Inky will be be most useful when it's available on "all screens," and we're working towards that goal. The architecture is designed with that specific goal in mind.


Great. I gave this some more thought and what I'd actually like, along with a great universal experience, is an email provider that I can really trust. Or rather, an email provider that I don't have to trust. By that I mean that it'd be great if I could get all of my email through Inky and that I'd have the option of having you keep a strongly encrypted copy of those emails while deleting the emails you collect from external providers' servers.

I could have my email everywhere with less worry over wanton snooping over my email archives this way. That would be a very valuable service.

It might require some compromise on data security if I wanted to be able to perform search on my archive via the web service though. Perhaps for people who are willing to give up zero-knowledge you could upsell a service which allows the data to be decrypted server-side in an in-memory store while they're logged in only. I'd be happy without search when using a browser client though.


I can only say that, as a matter of company culture, we are committed to being trustworthy. That's the part of the rationale for "safe" in our "smart, simple, safe" motto. We hope to earn your trust over the coming months.


It's laggy at the first run. and I don't under stand why I must sign up then log in to add my mail accounts?

Like BIS (my good old Blackberry ), I am in China, and be told the BIS service of China Mobile, they will store your email in the database, in plain text. I can't be sure if this is true, though I did not doubt too much. So, as a desktop app, if means "sign up" then will store my email contents on your server? and how about my emails' passwords?

I love the UI but the icons are ugly, I believe you will change them before long.

when I first time to input my gmail address it poped up some dialog warned me that my gmail account was not recognized(?), and suggested me to enable my gmail's IMAP option, of course it's already enabled for years. so I ignored that and entered my password and connected, it also lag a little while, then things went well.


Q: Any chance of providing a link to the Windows build from the not-supported message? I'd at least like to try running it under wine (unsupported and all), and I note that your Windows download div has a small link that lets you download the OS X dmg.


Breaks while loading http://i.imgur.com/AU2mg.png it just hangs there. Tried with XP and Win7

spoygg@Yggdrasill ~> wine --version wine-1.5.19 spoygg@Yggdrasill ~> cat /etc/*-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=12.04


Great job! really like the concept.

Could you give us a bit more details on the ML algorithm ? How is supposed to work and measure ?


What has the response been like over the past day or two in terms of downloads and traffic, etc.?


Could you please add an option to minimize Inky in the taskbar? Thank you!


Here are some clarifying points on security issues. We wrote up a FAQ for the website, but it's not in the prod version of the site yet. Short version: we really care about this stuff, have worked with cryptography and other security experts, and are happy to explain what we're doing. The analogy to LastPass elsewhere in this thread is apt; our techniques are similar and we'll document what we're doing so you can evaluate them. Here's a thumbnail version:

Inky uses SRP (http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol) to authenticate to the server that stores your credentials. This means that Inky proves to the server that you know your password without actually sending any bits of the password. Deriving the password from the stored password verifier object is thought to be a computationally hard problem, in a similar (number-theoretic) sense that, say, RSA is thought to be hard to break without knowing the password.

Your IMAP/POP passwords and other secure information are encrypted with a key derived from your Inky password. Since we don't know the Inky password, we don't know your IMAP/POP passwords. To add entropy to the encryption key, we use PBKDF2 key stretching. (As an aside: we can't reset your password since we don't know it; that's why we let you set up security question that lets you reset it from that machine only)

About not warning about self-signed certificates: this is obviously a trade-off between on-boarding simplicity and security. When you approve connecting to a site (which we tell you involves sending your password), you implicitly accept the site's X.509 certificate if it fails to validate. From that point on, however, we require the signature to match the certificate you accepted when you added the account; otherwise, we won't connect and we'll put up a warning. I'm personally interested in Tervor Perrin's work on TACK as an alternative to the well-known problems with the TLS trust hierarchy. (These problems have been discussed here extensively.)


Thank you for clarifying this. Your notes make me feel much better about sending you my password, and I'm glad you thought about self-signed SSL certificates too.

I still would like a warning to show up before I allow connecting to the server if it presents a self-signed certificate. Even something like this could get the point across:

    +------------------------------------------+
    | ======= Inky security warning ===========|
    +------------------------------------------+
    | Nobody's verified the identity of the    |
    | people who operate this mail server. Are |
    | you sure you want to send your password  |
    | to this unknown mail server?             |
    |                                          |
    | [Yes, send my password, and remember     |
    |   this mail server's fingerprint in the  |
    |   future]                                |
    |                                          |
    | [No, do not continue]                    |
    |                                          |
    | [More details...]                        |
    +------------------------------------------+


We'll certainly make it clearer. We've gone back and forth on this internally (design/simplicity vs security/clarity). I agree it should give you some kind of indication that it's not a CA-signed certificate. I'd also like to show EV certificates differently, though I'm not sure many providers offer them yet for mail servers.


From the FAQ: "How much does Inky cost? It's free!"

How are you planning to make money? Coz if you don't make money, then either you are going to sell my data (not acceptable), or you are going to shut down future development.

So again, how are you planning to make money?


Ads. It's pretty clear if you read their TOS[1] or Privacy Policy[2]. In particular from the privacy policy:

>Arcode displays targeted advertisements based on personal information. Advertisers (including ad serving companies) may assume that people who interact with, view, or click targeted ads meet the targeting criteria, such as a particular gender, age group and geographic area.

[1] http://inky.com/termsofuse.html [2] http://inky.com/privacypolicy.html


Seeing as how the former option is the current precedent in software, they are probably going to sell your data.

In my opinion, this is totally "acceptable," and even preferable: my personal information is abundant, and is infinitely and trivially "replicable." My money is incredibly scarce and finite. (And being righteously indignant is too expensive.)

Edit: Also, I agree with the general sentiment that this should be a native app, not this wrappered pseudo-web app thing.


Came here wondering the same thing. I think I will pass on this one.

Found this: http://us.linkedin.com/company/arcode

Looks like they are going to make their money by improving the email user experience.


Here are my first impressions as a keyboard-heavy email user:

* Created account and added my google apps account. Detection worked well.

* Tried to switch to my google apps inbox by pressing Cmd-2 like twitter clients and other apps with a left bar. No dice.

* Pressed '?' to see a hotkey popup. No dice.

* Pressed 'c' to compose a new message. That worked.

* Tried to figure out how to get back to the inbox. Had to use the mouse.

* Scrolled down, it was slow.

* Closed and reopened inky, and apparently it's not taking my password (20 characters long and containing the characters ";*{~?").

I have no idea what my password is actually set to (it seems to have accepted the password but modified it before saving?) and can't log in anymore. Which is fine, because inky's not for me. Lots of promise I think, but the UI is just not responsive enough yet, and I'm pretty happy with GMail's web UI.


You mean a new Mac email client that isn't just a LaunchRock signup page & some tasteful Dribbble shots? Amazing :)


Which means it will be acquired and shot in the head by Google soon to avoid losing Gmail eyeballs.


better than vaporware


Seems like there's something broken on that site. There is a mac download link at the top and a windows download link way at the bottom.


If you open the website on mac, it shows windows download link at the top and mac download link at the bottom.


"we're not worried about making money right now."

how many times have we heard that... you mean you're going to sell ads or my data. Thanks, but no thanks.


Yes. Got to that point and closed the site.


Constructive criticism:

1. I tried adding my @outlook.com email address and I had to manually allow SMTP and POP3 servers. A newbie mom or dad user is not going to know what to do and ultimately dismiss your app. Make it much cleaner so it works "at once" with Outlook.com email addresses.

2. Scrolling is very slow and annoying. Can you make the scroll use the current default speed on my machine? (Using Windows 7 64 Bit)

3. Visual bug in the search bar area: http://i.imgur.com/ybO7G.png

4. Clicked on an email and it's stuck on Retrieving for a very long time... still stuck there... :(

5. BREAKING BUG: I added my Outlook.com email and get this notification:

pop3.live.com told Inky this: "-ERR Exceeded the login limit for a 15 minute period. Reduce the frequency of requests to the POP3 server.."


I respectfully disagree about 1. Because of the autodetection, you can't be sure that the server you're connecting to is the right one. You have to double check this before you send your password to a potential attacker.


I don't think there should be special cases for certain email addresses. I think the instructions on what to do should just be as clear and detailed as possible.


Hotmail/Outlook servers have serious issues about usage limits. We're working on fixes (or work-arounds, depending on your perspective).


I'm liking it.

couple of observations

- The interface is very clean and very intriguing. I find myself going "I wonder how the decided to do that ... didn't think I'd like it, but it seems to work alright"

- I wish you chose a more attractive font to render emails in. My emails looked alright in postbox but they look crappy in Inky :\

- I would ask that you offer the option to set the threshold at which we "Automatically add recipients of sent messages to the address book". email clients over the years have made my contacts completely worthless with this email-once-add-to-contacts-feature because there are tons of people I email once or twice and never speak to again, but at some point (5 emails in perhaps) ... its a good idea to add that person to your contacts.

- memory usage is about 327MB (Real memory column on OSX), we'll see how it does in the next week or so. Postbox is at 815MB, which is one of the reasons I've fallen out of love with it ... that and the Postbox team's seeming mindset that they've gone as far as they can with it.

- Will also to see how big the index size gets, and how it impacts my cpu usage. Postbox uses 10GB of storage for my 3 email accounts and has my cpu fan constantly blowing hard on cpu idle.

Good first impression. Its seems like a decent email client right now, but I Can't wait to see if you can actually do something truly mindblowing/innovative with it


> I would ask that you offer the option to set the threshold at which we "Automatically add recipients of sent messages to the address book". email clients over the years have made my contacts completely worthless with this email-once-add-to-contacts-feature because there are tons of people I email once or twice and never speak to again, but at some point (5 emails in perhaps) ... its a good idea to add that person to your contacts.

Settings > General Settings > Address Book > "Mark automatically added contacts important" : "After 5 sent messages"

Is that what you wanted?


Its close but not quite the same. I'd like them not to get into the address book at all until after x sent messages.

I guess its just a matter of preference.


Perhaps an even better solution might be:

Any people I have emailed at least once within the last two weeks, plus any people I have emailed at least 5 times ever.


That's a cool idea; thanks for the suggestion.


I'm the founder of Peek, where we made a mobile device/app for doing email better. The main comparison at the time was Blackberry and eventually Android. We were a low cost smartphone centered on email and stuff. So with that backdrop, some comments. <pre> TRIED IT, LIKE IT

- hosted gmail account - set up easily for me

- sucked in my mail fast too

- prioritized the inbox pretty ok, but will have to try in the AM when I have more BS mail not just late night 'real' mail

- UI is a little slow I guess. You need a ? shortcut to prompt keyboard shortcuts

- I like the approach: just be an alternative UI to the gmail engine. You can coast on their infrastructure. Others are doing this too like Handle, AltoMail, others

TAKE IT FROM ME...

- Peek also got constantly dinged to "hey, support Exchange!" but we never got far with corporate users even when we bent over backwards to support them

- gmail was the vast majority of users

- outlook/hotmail is actually large and super annoying to support. you need a special partnership license with msft and we went and got one. email me if you want help/access. amol at peek dot ly

- yahoo you can use imap back door. also very large

- power users: we were a cheap, simple gadget so power users would criticize us on the one hand but then not use us since they weren't going to abandon their blackberry anyway (or android, later). In this case though, it seems Inky needs to work well for power users. So this performance stuff people are complaining about needs to be better

SUGGESTIONS

- weird that you didn't start with a mobile app

- a bit weird to create a 'desktop client' that is actually just a web app container (that's what it is right?)

- efforts like thunderbird or postbox at least "get your mail on your pc" which has a neat quality to it. Inky doesn't do that. What's the advantage of being a desktop app here?

- the overall betterness of Inky isn't apparent. The UI does resemble the "3.0" looks of a bunch of other mail apps as commenters have mentioned. There are some usability tweaks but also some steps back. I am most excited about the relevance and smart views -- this is the area nobody is doing well yet. The "algo for your email". I guess I need to use it more to see this benefit? </pre>

I'm excited to find my next mail client. I really don't like Gmail and the death of Thunderbird was sad for me. I want you guys to make something awesome!


Thanks for the shout-out. It's always nice to hear from someone else who's crossed the email Rubicon. Can't disagree with any of your advice. (Did you try to add a Yahoo! account?)


I was about to register for an account, but after I read that it stores my authentication information in the cloud I've held out. I just don't feel comparable with that, so I've decided not to do it. It would be great if there was an option, not to do this.


"capable of doing virtually everything Thunderbird, etc. can -- and in some cases more"

Dude, just no. Don't be one of those founders. Don't get drunk off your own Koolaid. I'm a heavy daily thunderbird user with 10 accounts and at this point in time, with this release, Thunderbird literally does everything better than Inky. Everything. From account setup, to available options, to information density, plugins, sorting collumn options, UI and collumn flexibility, customization, massive options, and about 35 other things. Email is broken not because it isn't pretty, it's broken because there's too much email, too much spam, and a lack of good threading. Common let's be honest, you made email pretty. You mac-afied it. Took out Spam filter and replaced it with Relevant/Not Relevant.

Your design, name, logo, URL are amazing.

However, Inky couldn't connect to my custom domain inboxes like support@mywebsitename.com and hangs on the "discover settings" page even after I specify the pop and smtp settings. Gmail works fine though. I'm sure you'll fix that quick so I'm not judging you on it.

Also, Inky has a bad case of the "looks over functionality" flu and "hide everything off the screen and call it minimalization" disease that's been going around. Information density is really low. Every message takes up too much space. With thunderbird my inbox fills up my whole monitor and I could skim through my entire inbox in 15 seconds. With Inky every little message takes up so much visual room it takes forever to check my mail. And everything takes more clicks than usual to complete. And clickable icons like checkboxes etc... are too small.

Not to mention, where is the spam button?

If you sing on your own merrits you'll always find fans, but when you compare yourself to Whitney Houston you're just asking for a backlash. Likewise, had you not compared Inky to Thunderbird you would have been fine.


    It is the pervading law of all things organic and inorganic,
    Of all things physical and metaphysical,
    Of all things human and all things super-human,
    Of all true manifestations of the head,
    Of the heart, of the soul,
    That the life is recognizable in its expression,
    *That form ever follows function*. This is the law. [1]
[1] http://ocw.mit.edu/courses/architecture/4-205-analysis-of-co...


A rule of thumb is not a law. Form doesn't always follow function even in nature and evolution: http://www.youtube.com/watch?v=cO1a1Ek-HD0

Also styles and fads like "minimalism" and "flat design" are forms that do not follow function but are really forms that enforce function. Which is why they're fads and go away after enough people jump on the bandwagon and realize the fad's flaw and limitations.


Relax Chris, I'm sure it was meant to be inspirational rather than legislative. It's simply the poem that coined the famous cliche 'form follows function'.


I'm still fine. :)


I like the idea of a better mail client, a lot.

I like the discovery/enrollment process.

Not a big fan of the UI itself, or performance after sign up, at least as it is right now. The only element which seems visually distinct to me is the far left menubar; everything else kind of blends together in a too-widely-spaced collection of random boxes, not even lists. I like native OS widgets. This isn't a video game, don't make me figure out some new convention just to scroll a list.

Search is nice (which is the only reason I still use anything on gmail). Inspires me to try to get lucerne working on my own mail again.

Also not really a fan of giving my login credentials to a cloud service for no particular reason. There's no reason I shouldn't be able to keep them within a client only, and just go through the setup each time.

Realistically I'm unlikely to move off mutt (for intensive email use) or gmail (for infrequent use from other machines), but I'll try it again someday.


You lost me at "email is broken". Email isn't perfect, but contending "The system is broken, so we built another layer on top of it" makes me think you haven't given this a lot of thought.


Indeed. Of all the mechanisms i use to communicate, email is by far the least broken. It's not a walled garden, it's not tied to a device, it doesn't cost anything, nobody blocks it, and the concept of somebody not being on the email network is unthinkable. If only everything could be as awesome as email.


Would love to hear more about what it's really going to cost me. Ever since Sparrow stopped working as well as I wanted it to, and didn't seem to have any hope of improving, I've been back to gmail's web interface. How are they going to make money?

Totally stoked to have something new to check out in this space though. :)


I was planning on using it as the mail reader for a very active mailing list I'm a member of. It doesn't open up threads correctly, so I'm stuck going backwards and opening each individual message.

The design is nice though.


I really don't like the trend of apps installing to the user profile. Chrome does this too, and I think it's a mistake.

I'm still using Thunderbird because I can't find a nice client with true threading (not the 'conversation threading' that seems to be popular recently). This client appears to be no exception.


This looks neat. I've always wished I had a way to sign into all my email accounts without having to set them up individually one at a time. This app definitely needs some work though. It is crazy slow and appears to be a web-app-pretending-to-be-native. Not that that is necessarily bad, but this one seems slow. Also, I can't get it to work at all. I've got my email account set up and it knows how many unread messages I have, but it never loads them. It has been sitting like this for about 30 minutes: http://dl.dropbox.com/u/23745600/Screenshots/oxNi.png and restarting doesn't help.

I also can't for the life of me figure out how to add a second email address.


that would be the green plus on the left of your screen shot


Can you offer a paid version? And could you please revolutionize PGP usability so that my grandmother can use it?


TL;DR: Devs, please read below for my SSL concerns. Everyone else, give Inky a try; it's a surprisingly nice and full-featured email client hiding behind a deceptively simple UI.

I'll bite. I'm a sysadmin who gets gobs of email per day. Maybe I'm not part of your target market ("Simple! Just works!"), but I'll offer my thoughts in hopes that they're useful.

I've tried it for a bit. Here's what I like about Inky as a mail client:

- Vi default keyboard shortcuts :)

- The dialog for adding arbitrary IMAP servers is outstanding. Leagues better than Thunderbird. For those who haven't tried it, you type in your email address, then it looks up the servers in the MX records of the email's hostname. You click an "Allow" button next to the server that you actually intended to send your password to, and it starts using that server. Excellent.

- AUTOMATIC UNSUBSCRIBE BUTTON. Dude. Maybe this is common in other mail clients but I just spent like ten minutes unsubscribing myself from useless things. Click, click, click. It's catharsis in a box. This alone made my brief spin with Inky worth my time.

- Nice UI for viewing and editing settings. Surprisingly advanced options for eg. caching, displaying and downloading messages, keyboard shortcuts, and so on hidden in the settings.

- Didn't interfere with my other email clients, as promised.

Security issues that I don't like:

- You didn't even warn me when I added my mail server with a self-signed SSL certificate. Sure, the UI does imply that you're not sending my password to that server before I click the "Allow" button, but there's no way for me to even check the SSL certificate fingerprint before I do that.

- You also didn't let me know whether I'm using an SSL/TLS connection at all.

I expect any decent email client to loudly complain about security issues like these. Inky is a broken email client until it does so.

- Storing my IMAP password on your cloud server is not OK. I know my passwords are encrypted with my Inky password, but that's exactly what I'm sending you whenever I log into my Inky account. Thus, Inky employees can access my email if they watch me authenticate with your servers. I'm not convinced. You've ensured that adding new mail accounts is stupid easy, so why are you "helpfully" keeping a copy of my password for me? At least give me the option of storing passwords in my OS keyring. I'd like to know more about the security of this system and your motivations for doing this.

UI things that I don't like:

- Bug: I add a server, then I click on "Compose message," then I add another server, then click back to my message that I previously started to compose. You don't list the new second server in the "From:" dropdown menu, so I thought I didn't add the new outgoing server properly. I have to scrap that message and start composing a new one before both servers show up in the "From:" dropdown.

- You treat an email thread as a linear list of messages. Email threads have inherent hierarchy and structure. I can't see who's replying to who without expanding the quoted parts.

- You group emails together by subject. I have 1,000 nightly automated server emails per each server accumulated over the past five years. Please don't group them together like that.

- In mailing lists, it's conventional to have "Reply All" as the default action, not just "Reply." I'd love if you detected that.

- Please infer my address book from people in my inbox who sent me things. I don't want to type all that again, and it looks like there's no visible way for me to import contacts. Slurping up contact details when I send messages to people would also help with this.

- In threaded email lists, there's so much whitespace that I can't tell where a message ends and where the next one begins. For example, how many emails are visible on the right side of this screenshot? http://i.imgur.com/92cKQ.png

- There's also way too much whitespace in the message list. I could only see 10 messages in my screenshot, which really hurts when I'm scanning through search results. (EDIT: I accidentally clicked on the date header and it gives you more layout options to condense things down)

- This is currently a free product. How are you making money?

It doesn't work on Linux, so I can't use it day-to-day. That said, I really like what you're doing here, and it's certainly a great start. Until then, I'm headed back to Notmuch ( http://notmuchmail.org/ ) for the time being.


Thanks; this is great feedback. A couple responses:

- See security comments elsewhere. Inky does not send our servers your Inky password.

- Grouping emails by subject: email threading information is pretty broken in practice; many clients don't populate References: properly, and Outlook uses its own thing called Thread-Id. So we have to use heuristics in many cases.

- Email thread structure: you're the only person who's ever asked us for this. GMail's pretty much killed real threading as a design.


Thank you for addressing my security concerns. I'm glad you've thought about these issues, and that's more than enough to make me strongly recommend Inky to others.


Im interested in this space as well so I am curious to poke your brain for a bit, if you dont mind:

> you type in your email address, then it looks up the servers in the MX records of the email's hostname

The MX records store the server receiving mail (i.e. an smtp server). How does this relate to the imap server?

> AUTOMATIC UNSUBSCRIBE BUTTON

This sounds interesting, but how would this work? Often times there are forms that the unsubscribe link leads to, how would it be able to correctly populate and send it?

Furthermore, in my experience, these links dont usually work and the better solution is to forward all mail from that source directly to junk mail. Is your experience different?

> Nice UI for viewing and editing settings. Surprisingly advanced options for eg. caching ...

Do you actually use these? Do you really care how long a message is cached for? I feel like most of these confuse the average user (obviously not you) and provide little value for the more advanced users.

> Didn't interfere with my other email clients, as promised

Is this an issue? How does this happen?

> You didn't even warn me when...

What is the average users response to such a warning? Heck, would you know if there were a man in the middle given the warning? I think that this is one of the shortcomings of the PKI: most warnings are false alarms which lead to mistrusting the system.


> The MX records store the server receiving mail (i.e. an smtp server). How does this relate to the imap server?

It's useful information to guess what the mail servers may be before displaying options to the user.

For example, doing an MX lookup against the domain of postmaster@ycombinator.com would show that the domain is hosted on GMail.

Doing an MX lookup against inky.com returns smtp.arcode.com. Now if you do DNS lookups against mail.arcode.com and imap.arcode.com you'll find they both have A records. imap.arcode.com is listening on port 993 (IMAPS) whilst mail.arcode.com isn't listening on any imap port. So you might want to display imap.arcode.com as a possible option.


Sorry; hit down arrow when I meant to hit up. You are absolutely right.


Automatic unsubscribe can work for example via the RFC 2369 List-Unsubscribe header. For example Gmail uses that to show a unsubscribe dialog when you mark a message as spam. Of course you need to use your own judgment on which messages to trust enough to even try unsubscribing from.


Sure! I don't mind.

> The MX records store the server receiving mail (i.e. an smtp server). How does this relate to the imap server?

My IMAP and SMTP server happen to be hinding on the same IP, which is mentioned in the MX record. Inky seems to have detected this. Port scanning? Trying common names like smtp.$domain and imap.$domain ? I'm not sure how it does this, but someone got very frustrated when coding it :) and it works quite well as a result.

> In my experience, these [unsubscribe] links dont usually work and the better solution is to forward all mail from that source directly to junk mail. Is your experience different?

I'm not sure how Inky discoveres the presence of an unsubscribe link, but the experience is outstanding. Here's a quick walkthrough. Say I want to unsubscribe from this message: http://i.imgur.com/XlB3X.png

This message happens to contain a "List-Unsubscribe: <http://.../>, <mailto:unsubscribe@...>" header, but lots of the ones in my mailbox do, so either it's common or Inky has other special sauce going on.

After clicking the unsubscribe button, it offers to unsubscribe via "automated email" or "via the web": http://i.imgur.com/c7KXj.png

If I click the first, it offers to send this message for me: http://i.imgur.com/c63fY.png

If I click the second, Chrome pops up with the unsubscribe link: http://i.imgur.com/DUGGk.png

I don't know if this works just for messages with a List-Unsubscribe header or if it's scanning the body text of the email. For the record, that mail had "If you do not wish to receive further communications like this, please unsubscribe [here.]"

Other mail clients: Please copy this mercilessly!

> Do you actually use these? Do you really care how long a message is cached for?

Sure, they're confusing for average users; that's why they're in the settings. No average user ever opens the settings, but I like that they're there. They've thought about a lot: if I send mail to people who use terminals and text-mode email all day, I appreciate being able to turn off settings like "Convert dashes to unicode characters" and "Convert emoticons to images as you type." Lots of people who use mailing lists will gladly appreciate the "Put new text below quoted text in replies (bottom-post)" setting. And I can turn off sounds and notifications so I don't get distracted by my mail client.

Yes, having these really does provide value for advanced users. (Erm well, for me anyway)

>> Didn't interfere with my other email clients, as promised

>Is this an issue? How does this happen?

I've tried mail clients that download all the mail, mark it all as read, and then promptly delete it from my server's inbox, either due to misconfiguration or poor design. Inky is a "thin" IMAP client, so there's no reason to add much client-side state. Everything you do to a message is immediately applied to that message as it exist in the server's copy -- marking it as read, moving it around, and so forth. This has the disadvantage that it probably won't work if I disconnect, but I like the uncompromising philosophy of not touching my mail unless I tell it to.

> What is the average users response to such a warning? Heck, would you know if there were a MITM?

It's the burden of the mail client to word the warning in such a way that it tells users what's happening without scaring them away. For example, I'd love if clients say something lighthearted in the warning message like "If you're at a coffee shop right now, please wait until you get home to check your mail; something phishy could be going on..." to give people an intuition of what they should do while encouraging them use their heads.

The reason why people trust PKI more than they should is because we teach them to click through scary certificate warnings. Thunderbird throws "UNTRUSTED CA" jargon at your users' face. They just want to check their mail, so before long, you've conditioned to treat the "Confirm security exception" button as a "Make my problem go away" button. It takes them to your inbox without any visible consequences, so they think to themselves that the scary certificate warning must not have been a big deal.

Still, though, any warning is better than nothing. At least if someone's account gets stolen because they clicked through a PKI warning, they might have some idea when it happened.

Right now, Inky does not warn me if I add a NEW server with a self-signed SSL cert. If an attacker can be there right when I'm setting Inky up, I've just given him my password. (Read dmbaggett's security clarifications elsewhere in the thread though; it's not as bad as I originally thought it was)


Wow, thanks for the insight and the effort in the response!

> terminals and text-mode email all day, I appreciate being able to turn off settings like "Convert dashes to unicode characters" and "Convert emoticons to images as you type."

Emails are normally sent with a mime type of multipart/alternative with two subtypes of text/plain and text/html. Therefore, for your terminal using friend it would simply look at the text/plain version instead of the html version. Im sure you already know this, but what I am trying to illustrate here is that I believe that all of these details should be managed by the technology as in this case: the client which has a hard time displaying images etc should use the text/plain version.

> "Put new text below quoted text in replies (bottom-post)" setting.

This is interesting. I remember when I was in a corporate network I got about 300 emails/hour from one mailing list. Now, the client I was using then had a view that looked like a forum where you could see an email and its responses below and indented. When I wanted to follow a thread, having bottom posting was annoying because I'd have to scroll through the quote. On the other hand, If I were jumping between threads, then it was useful. I wonder if there might be a better approach which separated the quote from the response and allowed the client to display the quote when necessary.

Do you understand my line of thinking or am I entirely crazy? Are there any options that you feel cannot or should not be managed by the client? Do you believe in this idea that the client should do as much as possible?

As far as the security stuff, I'll try to break down my thinking.

Variables to account for: valid/invalid, same as known/different from known, self signed/trusted signer/untrusted signer/unsigned.

Errors in each variable mean different things and have a different chance to occur under normal conditions. For example, if the cert is plain invalid (e.g. the trusted signers signature is incorrect) this almost certainly indicates malice as opposed to the cert being different than what is currently known. This is opposed to having an untrusted signer or a self signed cert where it is possible (and almost likely) to have occurred either out of ignorance of the issuer or their simple denial to pay large sums of money for a valid cert. Furthermore, it isnt entirely uncommon for servers to switch their keys due to some security hole such as a problem in the key generation algorithm. Since the PKI provides no express way to state: this server is switching its keys, we simply take it on faith. You might think that this is unnecessary since we trust the signer, but CA's have been compromised before.

The problem of no visible consequences I feel is also mishandled. If you get the initial warning at a cafe and you click through and then later at home, you get a trusted signer different from what you had at the cafe, a warning should pop up that your information was probably stolen at the cafe so you can at least change your passwords.

There is a hidden problem here of dns hijacking. This is actually done commonly at "pay-for-your-wiki" places. They do not have the intention of stealing your information, but they will case security problems since they will pretend to be google.com or whomever else until you pay for the internet. I suppose that the browser should check the entity of the cert and if different from the requested entity, treat it as a redirect. This whole situation, however, requires more thought.

All in all, I feel like technology is burdening the user by trying to make the user understand the technology and not the situation. Sorry if I rambled too much, but what do you think?


Going to give this a try... however it appears you do not have native exchange support?

I'm a bit skeptical of the UI though, so will need to give it a try. What looks good to a UI designer may not necessarily be a boon to my productivity. I.E. There is a lot of wasted screen real estate in the example image I see on the Home page, thus the info density of that email list is low.

Anyway - Ill give it a go and see what its like.

Will there be a mobile app to compliment? If I like the UX of this, maybe I'd want the same UX on my phone...


Re: information density: you can actually change the font size in the message list to get more rows visible. You can also opt for a paginated UI where the message list takes up the whole screen, and you only see the preview pane when you drill down.


Adding Exchange Web Services support to an email client for the sake of supporting one extra server seems like a lot of extra work for very little benefit. Especially when that server can be configured to allow IMAP connections like the rest of the World uses.


People still use IMAP?


How do you get your mail? HTTP? Telnet?


Exchange worked for my University's exchange server, but my university appears to be running some kind of IMAP/SMTP gateway so "mortal devices" can connect to it. I don't know whether that's a common way of setting up Exhcange, but you might get lucky.


Small nit: auto-discovery doesn't ask for your full name, so outbound emails headers will not include your name, which (in addition to looking woefully unprofessional) also is a spam trigger.

Fancy suggestion, related: since firstname.lastname@provider.com seems to be a convention these days, consider automatically setting the user's full name during auto-discovery if it conforms to that syntax.


Thanks for the feedback. When you compose a message, if you don't have a full name set, Inky will suggest some options. We didn't prompt for full name during the on-boarding process simply to streamline things.


Nicely executed tour and feature set. I like! A couple suggestions:

1. Some Gmail shortcut issues:

- 'o' and <enter> should open a message if I'm scrolling the message list. They should expand or collapses a conversation if I'm in message view.

- 'y' should not delete. It's a context-sensitive "remove from current view" in Gmail, which in message list mode means archive. In any context, it never means delete.

- 'p' and 'n' should go to previous and next conversation when in message view.

- Several others: http://support.google.com/mail/bin/answer.py?hl=en&answe...

2. There's a slight disconnect between what I can do with keyboard shortcuts and mouse. The one that bothers me most is I can click in the right (message) or left (message list) panels, and the shortcuts will now be focused on that context (e.g. if focused on left, j/k scrolls the message list, but if focused on the right, j/k scrolls the message). However, there doesn't appear to be a way to switch focus between left and right using the keyboard; instead, it appears you must switch to full window message view to get the message view keyboard shortcuts to work, and switch back to side-by-side view to get the message list shortcuts to work.

Two ways to solve this:

- Have a setting for whether opening messages goes full window or stays side-by-side. This way, when I press <enter> or <right>/<left> (or 'o' with Gmail shortcuts), the message list will stay to the left but the focus will switch to the right. This is what appears to happen when I click my mouse in the message area while still in side-by-side view.

- Or, have a new keyboard shortcut to switch focus between message list and message focus. This way users can also process email in the side-by-side view (scroll message list, open message but stay in side-by-side mode, scroll message itself, jump back to message list, etc.). They can also continue to use the current method of opening messages to a full window.

3. Might be tough to make cross-platform, but have a setting to register a global hot-key to bring Inky to the foreground (and minimize if active). This is one feature that makes it soooo easy to make a desktop program that I need to go in-and-out of often a regular go-to product (notes program, music player, desktop switching, etc).


Thanks; these are great suggestions. You can see all the keyboard shortcuts with F1. (We'll make ? work for this as well.)

The key bindings are all configurable (by us, for now, maybe by everyone eventually -- if anyone wants that). We'll work on improving them.


'?' works for me on Windows. Though please allow me to press escape or '?' again to hide the shortcuts. And switch focus to the popup and let me scroll it with j/k and up/down.

Another suggestion: 2 clicks for "Load Remote Images" is a bit annoying, particularly because on other email platforms it's one click, and I have a fair amount of senders where the "from" email address changes with each email, making it impossible to select load always. And for some senders I selectively decide to load images. The popup every time with text and settings is too heavy. Make this a single click link ("Load Remote Images"), and next to it add a gear icon with the drop-down settings and "Why is remote content risky?" info. If a user presses the "Load Remote Images" link, load the images and change that link to a label for the image loading settings gear, e.g. "Remote Image Settings"


The only features I need an email client to have is extreme speed and nice search. No desktop clients for mac have both right now. This isn't fast enough but i'll keep it installed and check for updates in a month.


I use mu [1] (via mu4e) on my Mac, and it's plenty fast and has great search. Admittedly, it doesn't look like Mail.app, but it works great.

[1] http://www.djcbsoftware.nl/code/mu/


If you want a commandline mail indexer, Notmuch has both. It's like Mutt but it uses a fulltext database (Xapian), so it's super fast (eg. subsecond fulltext searches on my 80k emails).

Command line though, and you need to pick a frontend. Definitely not for everyone. http://notmuchmail.org/


Glad to see a DC-area startup get a mention here on HN! I had the pleasure of meeting Dave (Inky's CEO) at a Microsoft meeting not too long ago. He's a real smart and friendly guy. I wish him and Inky great success.


Issues I noticed:

- when creating inky account, typed in my desired login name, it said it was already taken, then changed to ok on its own.

- notes view didn't recognize my notes taken with notepad on an ipad, and tagged with "Notes" in gmail.

- wasn't clear how to enable the different views when you're not in the tutorial.

- email threads don't include my responses, is that intentional?

Some other thoughts: Zimbra had some interesting ideas around deeper inspection of email, like looking up part number in inventory databases if they appeared in the email. They also allowed you to write plugins to parse and do interesting things with the email.


Didn't work for me. Added account, and sent a welcome email, but I wasn't able to actually look at my inbox in the app. Loaded folder structure correctly, but no actual emails.

Looking for where I can delete my account.


I made an account, it worked okay, but it's just not as pretty or useful to me as the Win8 Mail app on my Desktop. Also looking for where to delete my account, but I can't find it...


Please add PGP and S/MIME support to your TODO list. All the major desktop clients have support for both of these, either natively or via plugins.

You could even sync the encrypted keychain between installations.


+1 for that feature. I think that the niche for good-pgp-support email client is still not completely occupied. Only couple of programs/extensions are doing this job: 1. Enigmail (thunderbird plug-in) 2. Prolly Outlook 3. Mailvelope (chrome extension, AFAIK)


I would like to see the source code for this.

It looks like JavaScript files are archived (maybe encrypted?) in binary files, resources.dat, f_0000a-f_00009, and maybe in data_0-data_3.

Anybody wants to take a look?


the f_0000x files are different resources, the first one is a PNG file, the next few appear to be javascript. None of them however are archived or encrypted in any format.


>Easy Sorting and Filtering

Inky's sorting and filtering is easy, requiring only two controls in comparison to the complex table layouts seen in other email clients.

And yet, the complex table layouts are nowhere near sufficient for me, and I still get a couple hundred poorly-filtered emails daily. How does your two-control one handle a few thousand emails per day?


"How does your two-control one handle a few thousand emails per day?"

A few thousand emails per day?

You're sooooo the target demographic.

They'll be able to show you ads for products able to deal with the problem that getting thousands emails per day is ; )

Seriously: you're 0.000000000001% of the people using email and I don't think they should focus first on solving your issues ; )


Probably not. Work at a small, software-based company and you end up dealing with lots of email, period. Server notifications, bug reports, user feedback, third-party service provider emails of all kinds, and all that happens before personal emails or ones between employees.

But, outside of that, my 5 accounts tend to get a few dozen per day, a handful more if I don't do any filtering. And they're specifically targeting people with multiple accounts. If this doesn't include work volumes, what does it include, and why do they have multiple accounts? It's not targeting the 99%, period, because it's not part of the OS or Office suite, so who are they targeting?


I've felt for a few years now that server notifications, bug reports, etc, should almost never go to email clients.

Sure you can use email to generate the ticket, but they need to go into a CRM / bug tracking system of some kind. Otherwise everyone ends up overwhelmed with meaningless repetitive emails, like it sounds is happening with you.


These are server notifications and bug reports that have gone through a couple bug tracking systems, and the new and/or exceptional exceptions generate emails. They (and I) could do better at filtering, and some tracking services are better than others, but it's one of those infinite time sinks that has generally not paid off beyond where I am now.

While great in theory, I haven't yet found a single bug tracker that provides reasonable deduplication that doesn't e.g. cause a new issue when the SLOC generating the error changes, just because you added a method to the class. Even allowing me to group two apparently-distinct bugs together manually would be an improvement, both for tracking history and severity, but I haven't found any. They're all too aggressive at grouping X, Y, and Z when they shouldn't, and make 20 piles of A. They are infinitely better than receiving an email for every single one, but still a headache, and they still generate too many false alarms to hook directly up to automated systems.

Then there's also that outright failures that need to immediately be fixed, and semi-unexpected things like insane responses from Facebook, are all useful to track. Unexpected rises in relatively normal Facebook errors can denote problems on either end, possibly fixable in some situations, while seeing a jump in quantity might imply something. If you don't track them continuously, you don't even know if it changes, so 'fixing' / suppressing them completely is hamstringing yourself. So ideally whatever I use would track fix-this-now and investigate-if-it-changes. I haven't found any that do.

Not that I've looked at too many, much less subjected them to large-enough workloads to be sure they're actually an improvement. Wiring up a new bug tracking and notification system (possibly from multiple sources and languages, and setting up paging when major problems happen, etc) is pretty non-trivial. But if you have suggestions, I'd love to hear them, and might even try one or two out professionally this year :)


Can you port this to Metro? Would love to sitback on my couch and reading through all my emails on my Surface.


It's urgently worth knowing that "for security reasons", the folks at Inky will refuse to "delete or deactivate your Inky account," even at your request. I find that completely and utterly unacceptable.


Hi Mike,

I replied via email to you as well, but it's worth stating the same publicly for the record, and so others know.

There are really two cases we need to handle here when a user wants to delete his/her account:

1) the user knows his/her Inky user id and password 2) the user doesn't know one or the other of these

In the first case, we can give users the ability to permanently delete their accounts by adding a control in the settings panel. We haven't done this yet, simply because it's dangerous, and we want to make sure we get it right (both in implementation and design) so users don't accidentally delete their accounts — or worse, introduce bugs where Inky corrupts our database and deletes or damages some else's account. We'll put this capability in at some point; we just haven't done it yet. (We were not really intending to launch yet; that sort of happened without our expecting it, because we got a bunch of press that we weren't looking for yet — which is good in some ways, but bad for things like this where we frankly aren't quite ready.)

The second case is trickier. If the user doesn't know his/her Inky user id or password, we have the security issue of needing to verify the person's identity when they ask us to delete the account. Ultimately we'd like to use two-factor authentication for this, but that costs money (for the associated text messages to/from the user's phone) and involves some implementation work as well.

In either case, we could try to manually modify our database and remove the user's account. But we don't have a process around this yet, and my worry is that it could potentially damage the database when someone makes a mistake.

What we're telling users now is that if you remove all your email accounts, you leave a shell Inky account that has no sensitive information left in. Our hope is that this is sufficient until we figure out the right long term solutions here. (Note, too, that we can't reset your account password if you forget it, because it's encrypted with your Inky login password, which, by design, we can't get access to.)

We know this isn't ideal, and we're going to work on fixing it. But we're really not trying to be nefarious here. In fact, unlike virtually all other companies offering consumer internet communications tools, we've made privacy and security one of our three primary principles — it's part of the "safe" in our "smart, simple, safe" motto.

EDIT: we'll make this a FAQ on our site as well.


This is not a good situation to place the user in, but, given that, this is the best answer I could've expected.


They should add more info on email protocol support. It only says "Add Any Account", and mentions IMAP and POP. But it has a picture of an MSN Butterfly, is there deltasync or Exchange?


No Exchange support.


My school's exchange server also listens for IMAP connections. It worked fine for me.


Is that UI supposed to be "Metro"? Because I don't care much for it.


It looks awesome, and only by the screenshot I can tell it's way better than any other alternative for windows. I'll surely give it a try. Nevertheless, it's downloading at 10kb/s...


Font rendering is horrible and I don't like lack of contrast.

You may have younger eyes than I do.

Example of what I mean: http://i.imgur.com/DlsEy.jpg


Blurry as heck on my Retina screen. :(

Also freezes after I add my Gmail account, saying "Loading..."

I DEMAND A REFUND!!!!!!!!!111

I kid, I kid. I'm going to stick with Sparrow for now, but will revisit this in a few months.


My two cents? I think this takes the "flat" aesthetic too far.


How is this cloud-enabled? It just looks like an email client.


Based on their feature list, it stores your email addresses and passwords encrypted on their servers, with your inky account password being the decryption key. The idea being that you can just login to your inky account on any computer and it loads all your email accounts.


Not at all a fan of this. I guess it sets them up to do a web service later on, but it's seems a little aggressive and unnecessary.


How is email not cloud-enabled?


They don't let me use my iPhone on the airplanes.


I just don't see the point of storing my email settings on your servers (even if encripted). I'd rather pay for an application that keeps everything on my device.


No Linux support? Aww.


I know. Can we not get ONE email client for the desktop that isn't Thunderbird? I'd pay money for this if it was on any Linux distro.

Geary is the closest thing to date but I don't think it's production ready.


Do you like commandline mail programs? There are several good ones. Stringing them together is a lot like like clicking together lego blocks: one for downloading mail, another for editing new mail, another for sending mail, another for searching mail, ...

Takes a while to set up, but I'm far happier with my offlineimap+notmuch+emacs+msmtp mail stack than I could ever be with Thunderbird.


I was never able to stick with the terminal for email. The last time I tried though was with Pine in 2003 (ha) so maybe I'm due for a 2nd chance.


Tried to use it, but even if I type all IMAP and SMTP information, it did nothing after showing the "Inky is trying to discover your settings" message.


Why would I switch to Inky from my current email client? I love the idea but I don't see the value. Good luck though!


It's pretty good. Needs to be a bit more sleeker and designed nicer, but looking forward to trying it out.


The problem I have with desktop email clients now is the lack of rapportive and boomerang.


Hmm, I have IMAP enabled and this isn't connecting to my Gmail. Any possible fixes?


How does it store mail locally? standard Unix mboxes or some proprietary format?


It doesn't. This is a pure IMAP client; ignoring the cache, mails are not stored locally on your machine.


Obviously you don't ignore the cache.


If it's a minimal cache, though, you might as well.

This is probably the single main concern I have about this -- I've spent chunks of time away from home where I find an internet cafe, sync up email (send and collect new email), and go -- then take the time to read and write email later (while offline). This method would be pretty broken if long conversations were missing most of their history.

If the vast majority of my email is actually unavailable when I'm offline (or experience connection problems, etc.) that at last partly defeats the purpose of having a native email client at all.


There is no download link if javascript is disabled on a User's browser.


Mac client _really_ needs full screen support before I'll use it.


Features are great, but looks a bit blurry in retina display.


love playing with this on the desktop...any hope of an iOS client anytime soon?


Where's the download link?


this looks awesome - going to give it a whirl.


I was going to try it out but they have no Linux version... sad


This came out of nowhere and looks cool. What happened to http://dotmailapp.com by the way?

EDIT: WTF this is not Retina and when I hit Create Account, it freezes at "Inky is starting up" screen. I think app is not native, seems like it has a webview inside the application. I get Back&Forward options when I right click. LOL.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: