Desktop App for All Your Email
inky.com
inky.com
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.
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.
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.
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.
Hushmail were forced by their government to backdoor their system for this purpose. What's stopping the same thing from happening to Inky?
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....
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?
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.
Which is, not-so-coincidentally, why my next project is 100% open source.
Is it http://inky.com/mail/ wrapped around with Chromium Embedded Framework (CEF), with web page javascript calling native Python scripts?
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'll definitely try Inky :) I'll let you know how it goes.
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.
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.
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.
spoygg@Yggdrasill ~> wine --version wine-1.5.19 spoygg@Yggdrasill ~> cat /etc/*-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=12.04
Could you give us a bit more details on the ML algorithm ? How is supposed to work and measure ?
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.)
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...] |
+------------------------------------------+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?
>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
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.
Found this: http://us.linkedin.com/company/arcode
Looks like they are going to make their money by improving the email user experience.
* 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.
how many times have we heard that... you mean you're going to sell ads or my data. Thanks, but no thanks.
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.."
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
Settings > General Settings > Address Book > "Mark automatically added contacts important" : "After 5 sent messages"
Is that what you wanted?
I guess its just a matter of preference.
Any people I have emailed at least once within the last two weeks, plus any people I have emailed at least 5 times ever.
- 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!
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]
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.
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.
Totally stoked to have something new to check out in this space though. :)
The design is nice though.
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.
I also can't for the life of me figure out how to add a second email address.
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.
> 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?
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)
> 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?
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.
- 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.
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...
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.
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).
The key bindings are all configurable (by us, for now, maybe by everyone eventually -- if anyone wants that). We'll work on improving them.
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"
Command line though, and you need to pick a frontend. Definitely not for everyone. http://notmuchmail.org/
- 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.
Looking for where I can delete my account.
You could even sync the encrypted keychain between installations.
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?
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?
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 ; )
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?
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.
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 :)
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.
You may have younger eyes than I do.
Example of what I mean: http://i.imgur.com/DlsEy.jpg
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.
Geary is the closest thing to date but I don't think it's production ready.
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.
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.
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.