Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Tray.io - powerful email assistant (tray.io)
147 points by vacipr on Sept 9, 2012 | hide | past | favorite | 64 comments


Their pitch stole the show on a recent TWIST. http://youtu.be/W_6h8XWfUO8?t=57m23s

I was recently asking people for a way to translate emails into SMSs, so I could route my system alerts (from various places) to a single email and ensure I always get by SMS. It's a surprisingly hard problem right now, which Tray looks like it would solve elegantly if they get SMS right.


You could use http://zapier.com for that:

  1) set up a Zapier mailbox as the trigger, send direct or forward to.
  2) set up an SMS (or Gtalk or whatever) action.
We let you set up filters which you can use to control flow or routing. I even set up an easy template for this: https://zapier.com/zapbook/mailbox/sms/2424/inbound-mailbox-...


For those who don't like 3rd parties looking into mail and only have IMAP access to mail server, there is something called imapfilter. Basically, it acts as a headless e-mail client with Lua interface.


This reminds me a lot of the server-side procmail [0] and Sieve filters [1]. Perhaps this was even the inspiration for such a project, who knows?

But tray.io looks like it can handle far more advanced rules (or at least those somewhat comparable to procmail, and without having to do a bunch of manual scripting!), but in a more user-friendly, graphical way. And if it can automatically generate machine-learned rule suggestions based on user behavior, that would be even more fantastic.

The only major downside is that you have to be willing to let a third-party have access to your e-mail (and I know that when I've written server-side procmail scripts that have misbehaved, I've managed to unintentionally lose e-mail at least once or twice in my lifetime; of course, I didn't know that I had even lost the mail, since the server silently discarded it due to my malformed rules).

[0] http://www.procmail.org/ [1] http://wiki.dovecot.org/LDA/Sieve


How does the authentication work with email providers? Does the application access email through POP or IMAP? Does it have arbitrary access to my email account?

I fear I'll never benefit from apps like this as my email account is the skeleton key to my online identity. I'm not sure I could trust any other human being with the password.


At the moment the private alpha is just Gmail, because gmail provides OAuth Authentication, a much more secure/elegant way than requesting a users IMAP credentials.

Work is being done on supporting other email providers, which will obviously require storing the users credentials in a secure way & there is also a white label/internally hosted version in the works for the enterprise that mmahemoff mentioned..

Security for email is definitely our biggest issue so far, but we want to make sure we have it nailed before we go public...


They will have a good opportunity to provide a self-hosted instance for the enterprise, for this reason.


I'm not sure how they compare, but a friend of mine's company does something similar: http://www.awayfind.com

They provide similar filters and suggest filters from your communication behavior. E.g., you consistently respond to Peter Norvig quickly, perhaps you want an alert.


I'm I the only person who is reluctant to add a service hosted by a startup to your email process? What kind of plans do you have for when they close/exit/pivot/whatever were calling it these days? How is this not going to be another Sparrow or Fluent?


I'm I the only person who is reluctant to add a service hosted by a startup to your email process?

No, you're not.

When I'm choosing businesses to work with, one of the first things I consider is longevity. Of course there's always a possibility that another business will close down after you start working with them, but there's not much point building a relationship with a business if you actively expect that to happen in the near future.

I think this is something that a certain part of the start-up culture doesn't really take into account yet. The current popularity of acqui-hires and the obvious goal of some founders/investors to just get the company sold at the earliest possible opportunity make me very wary of dealing with small, young companies that have taken a lot of investment or were started by "serial entrepreneurs".


I suppose you go back to doing whatever you were doing before you used the service. Annoying yes, but it's not like they're hosting your mail and you have to rush to find a new host.


In this case? Hope you have a record of all your filters, then re-implement them using Python's POP or IMAP library. If they fold after demonstrating significant market interest, I'd be happy to set up a competing service with improved usability and monetization.

It's not something I'd try to launch otherwise. I'd be more about a B2B service which aims to improve issue tracking, response times, and accountability. If that does well, go on to work on knowledge retention and retrieval, which is pretty much a giant black hole you can play in forever.


Off topic, but what do you mean about Fluent? I though it was chugging along, and I've been waiting on an invite.



Interesting. I'd love if this integrated with SpringPad (which I prefer over Evernote), either by formatting for their e-mails or preferably through their API. IFTTT does neither.

If this allowed anonymous analytics in order to discover and suggest useful rules, either at the personal level or in aggregate over all users, that would be awesome. Likewise if you can publish, clone and fork useful rules then modify them for one's account. The less a user has to come up with their own rules, the better.

And there are things that IFTTT doesn't do for e-mail that this might do. And there are API's that IFTTT doesn't support (the big one for me is springpad).

As for time sensitive, this could potentially learn what you respond to immediately upon viewing, and what you wait on or don't view, (and even analyze that as a function of day, time, sender, etc.) If it had permissions to analyze e-mail texts and had enough users, it could use machine learning to learn what phrases were likely to prompt immediate action, IE "By tomorrow morning" vs. "By Tuesday morning" on a Wednesday.

As for non Oauth accounts, A browser plugin that stored your credentials locally could still be possible. I seem to recall reading about somebody working on a clever way to do this involving passing session information using a proxy and encryption or something like that, but my memory isn't great.

All in all, I wish them luck.


Thank you - I'll get springpad on our list. We are working on analytics currently, I'd love to hear of any other API's you'd like to see hooked up please feel free to email me: rich (at) tray.io


I usually check email in the evening before going to bed. It's working marvelously since I can take an hour out of my day to handle everybody - really solves the problem of forgetting to respond to people.

The only problem are time-sensitive emails. For those I still need to periodically check my inbox to see if something urgent's come up.

If there's a way to tell Tray "If time-sensitive email, send me a tweet", that would be superbly magnificent. The landing page doesn't seem to indicate this.


Time-sensitive is so subjective that it'd be difficult to say the least if not impossible to properly implement. The only 100% guaranteed way of making sure a rule gets applied to time sensitive emails would be to train senders to add a word or code to the subject or body of the message. But again, this is based on my subjective definition of time sensitive. To me, time sensitive means someone I know sends me an email and they need a reply or at least my attention right away. That leaves out things like leads coming in from NetSuite or Salesforce (as mentioned in other replies) or automated emails that cannot be trained. It also means that I'd have to train a lot of people to do this and I may leave out some people by accident and then I'd have to train every new contact to do it on top of deciding whether or not the contact is important enough for me to allow them to send me emails that'll alert me instantly.

There's just so much to it that it seems like something only a human could do. That said, the guy from tray.io who replied with a potential solution seems to be on the right track. Its not a perfect solution but it's good enough and sometimes good enough is all you can do.


we are working with our current alpha users to find the right sort of rules that help them with their email.

The idea would be that you could setup custom rules based on the people who email you, or other web services you use, for example if a hot lead in sales force emailed you while your in a meeting, then forward it via SMS.

Being able to pickout a "time sensistive" email would really depend on what you consider time sensitive, but im sure we could provide something that would help.. email dom at tray.io and we can talk more about how tray could help fix your issue..?


Is there any intention to add machine learning to the system so it can realise I never read email from particular people, but that something from a particular user I'm all over it?


yes, there is going to be machine learning and analytics processing.. Eventually rules would be suggested to you, and some rules would take advantage of all the information that has been learned about your account


I would have serious privacy concerns about this. You are basically allowing a 3rd-party to read your email.


You are basically allowing a 3rd-party to read your email.

4th party. Most of their target audience is probably on GMail and has no privacy concerns to begin with.


Fair point. I don't disagree. It just bothers me to see how what little privacy we have left continues to erode.


I don't see an architectural alternative for such services yet. You'd need a client side app sandbox which allows servers to schedule routines to run locally on secret data, without leaking back data which the server can decrypt. It would also need to be cross-platform and have the same user accessibility as the web browser.


You'd need a client side app sandbox [...]

Or you could use, you know, a native client. It may increasingly become a foreign concept to the "facebook generation" but your computer is still fully capable of running a mail client on its own.

Of course you don't get to sell SaaS-subscriptions when you implement tray.io as a procmail GUI...


A native client without a user data sandbox doesn't solve the problem of networked applications leaking private data and spying on the user at all. The code needs to be open source, versioned, vetted, and only obtained via a trusted repository for every application the user wants to run each time it is updated. The user is no longer instantly able to access the latest version of the application by simply typing in a URI.


I meant it tongue-in-cheek when I said "facebook generation", but it seems we really have a generational gap here.

The code needs to be open source, versioned, vetted, and only obtained via a trusted repository

http://www.procmail.org http://www.mozilla.org/en-US/thunderbird/ http://www.mutt.org/

The user is no longer instantly able to access the latest version of the application by simply typing in a URI.

Yes, that actually bothers me a lot. Can you imagine the crazy effort that I go through every time I update my mail-client?

It takes the better part of 5 minutes every time (I'm not exaggerating here) and last year I had to do it twice!


Would you be comfortable explaining to relatives, aquantainces, and the elderly in a casual conversation:

How to install, use, and maintain linux. How to install, use, and maintain their own mail server and spam filters. How PGP works. How to setup and use thunderbird+enigimail or mutt.

Compared to visiting a URI, would doing so be more technically demanding or less technically demanding for users who have not specialized in computing? Is the proportion of society which inevitably chooses not to specialize in a computing inherently more deserving or inherently less deserving of the benefits of encryption and privacy?

I think the gap in our perspective is most likely attributable to A) how widespread we wish to see encryption used by the general public in the future, or B) our expectations of the of the technical stamina of the general public when confronted with unfamiliar tasks, rather than generational effects.


Nobody talked about encryption. Nobody talked about "elderly acquaintances".

The conversation was about a product aimed squarely at GMail "Power-Users" who willfully run all their e-mail through one or more third partys.

And besides, you don't need to linux to run a mail program.


+1 for procmail and having the sense about you to manage these things yourself rather than trading your privacy for a bit of convenience.


I can't say you're wrong about privacy eroding but at the same time we always have a choice. If this service offers enough value then I'll choose to deal with the privacy intrusion because that's what I'm comfortable with. I'm trading a bit of privacy for the value the service offers. I can live without the service if I value my privacy more. If one really wants a service like this and there isn't another way to get what they offer without sacrificing privacy then the only options are to go without it or trade in privacy.

When you sign up for an account on most sites it's implied that you're giving up some bit of privacy for the convenience of having someone else handle your data. The alternative is building and maintaining your own system which isn't always realistic and the vast majority of people on earth cant do it.

I get that privacy is important to a lot of people and that the fact that sometimes protecting your privacy means making things difficult for yourself but I don't know if there's any way around it (actually, I don't believe there is). For example, some people Who are very concerned with privacy refuse to use Facebook and because of this they are missing out on connecting with friends, colleagues, and even potential customers because those people rely on Facebook so heavily to communicate. I've seen the people who are left out in the cold because of this then become even more vocal about privacy issues (not saying you're one of them, just in general) but in the end we all still have a choice.

Choosing to protect your privacy these days means potentially sacrificing a lot more in its place. Some people argue that this fact proves that we don't have a choice but I disagree. We may not like the consequences but the choice still exists.

Personally I'm all about privacy but not to the point of blocking cookies or other tracking on websites or avoiding services because they can potentially see my data. I think at a certain point you either have to trust that nothing is likely to go wrong by simply using a service or just not use it. I mean, there's always the risk that your personal information may fall into the wrong hands but that's life - its risk. You just have to be smart and/or realistic about it. I'll accept the risk I take storing my payment information with Amazon and I'll accept the risk of having some information willingly stored in Google's services and even be tracked by Analytics. I'll be more cautious with the risk of letting a new service like tray.io potentially reading my emails.

I don't think there's a way to offer a service like this without giving up some privacy. Do you know of a way to alleviate privacy concerns while still offering the kinds of services that, as you rightly point out, erode our privacy? The person who comes up with that could definitely profit!

Please believe me when I say I get your concern. I'm just kind of a weirdo around here. I don't hold many strong positions one way or the other on most issues. I tend to be in the center on most things. I'm a very moderate HNer which I feel is unusual but I'm definitely glad there are people like you who lean more toward either end of the spectrum instead of being in the middle on a given issue. It may turn out that my nonchalant attitude towards privacy will bite people like me one day and people like you will be there to change things (and say "I told you so" :)).


Isn't Gmail a second party? If so, they are a third party.


Second party are the people with whom you're interacting, that is, the people you send emails to.


What is the typical number of rules someone has to write if they get, say, 100 emails per day from any combination of 1000 contacts?

If you have 100 common contacts (as opposed to the other 900 who email once and a while) and I need, say, a rule or two for each to cover the basics... and a rule or two to cover groups of people (because one-to-one emails are the exception in business not the rule)... isn't that hundreds and hundreds of rules?

Not having seen the alpha, that feels like an insurmountable first threshold, UX-wise.

Also, just out of curiosity, other than general ease-of-use (which seems much nicer in your 3 examples), how is this better than typical filters (which I don't use)?


It really depends on how you manage your inbox, one of the drivers behind us building Tray was the customisation it offers. The triggers that define the rules can cover as many or as few contacts as you wish ie 'anyone I have a meeting with in the next 48 hrs' can be a trigger, or simply based on email content, pre-defined contact groups etc. In most cases this is a handful of rules.

Email rules that are setup within the client or service restrict filtering to contact, folder, content (in some cases). We can react to data that's outside of your inbox, anything from your relationship to the contact based on another web service, to accessing, storing, and sharing with services you use regularly. Beyond this triggers such as time, email load (driven from analytics), location can all come into play. We are really just getting started with the possibilities, a way to interact with custom web apps would be great for developers/companies that use bespoke tools.


I can't decide whether to focus on the interesting aspects/potential of your tool, or the fact that you circumvented the concern I presented, but thanks for the answer nonetheless.

The ease of this tool is inversely related to the need for it. i.e. — the more complex/high volume your inbox, the more you suffer while trying to set it up.

Maybe it would be worth implementing some "starter rules" or a "wizard" that allows the first-timer to leverage many basic rules at once, immediately.

It's the Pinterest approach, if you will. :) "Pick 5 things you like" and then they auto-follow 50 people based on your choices. Voilá! Good first experience.

Remember that features ≠ power ≠ satisfaction.

I apologize for the unsolicited suggestions; you hit my area of interest right in the middle. ;) Good luck with everything and congrats on getting to the alpha in the first place!


I'd add type="email" to your input to make it easier to sign up on mobiles.


Great heads up - we'll do this. Thank you


Actually, it might be just me, but I find this incredibly annoying. I use swift-text on android and while usually when I start typing my email address I get a suggestion for my long email address, but when type=email I don't get a suggestion, just a little @ key at the bottom. Might not be this way for all keyboards though. Just a thought.

Edit: Oh and great job on the app! I think this is an awesome idea and if some of the privacy and longevity concerns were addressed, I would use it all the time!


Have been trying it out for a month or so. Love it to bits.


+1 on this, I probably haven't used Tray to the full potential but the simple features such as putting all attachments into Dropbox and sending me an SMS for server test notifications.


Is it possible for me to join in during the private beta?


Sure signup to the landing page, we are releasing invites in batches.


already done, can't wait to try it, this looks pretty useful. good luck :)


Great startup from the SpringBoard program! Recently we interviewed Tray.io co-founder Dom Lewis http://howtowriteabusinessplan.com/2012/07/tray-interview/

Check it out! During the interview Dom talks about startingup, their pivot and shares advice to aspiring entrepreneurs.

Job lads!


This probably sounds negative but isn't this just adding needless complexity to something that's simple? I've tried rules in mail clients before, but in the end the best filter is myself scanning the from and subject columns.


This may be overkill for some people, but if everyone could just easily scan from and subject columns then there wouldn't be a global email epidemic that lots of people are trying to solve. Tray is trying to allow you to define how you use your inbox, rather than assuming that your like the next 100 people...


I love the ability to notify people that if they reduce the email length I am more likely to respond quickly. Awesome work. Keep coding.


IFTTT for email.

Tray is awesome. Met these guys in London on their demo through our accelerator exchange program.


Really great idea, integration to non-oauth email providers seems like a hurdle though. Requiring full credentials is a less good idea.

If they add post-read-filtering of the inbox it would handle some sorting after the work is finished as well. For example, filter all mail from X flagged with label done to that customers folder.


We've just added some google labels support, so we'll be able to handle this in the not to distant future. There isn't enough time in the day to code fast enough :)


Sounds really neat, I've solved it for my own personal needs with some imapfilter scripts, but the thought crossed my mind to make a service out of it. The reason not to was the tricky part of needing customers imap credentials and store them safely.

Integrating to tightly with gmail would perhaps make it harder to support other imap platforms, since gmail can do more in some areas.

Good luck with your project!


Please figure how to do this for exchange. Then proceed to take over world.


Some later versions of Exchange have a SOAP API (http://msdn.microsoft.com/en-us/library/exchange/dd877045(v=...). I wrote this npm module to grab a user's current emails: https://npmjs.org/package/exchanger.


Would probably be better to use IMAP for this. Then it will work for Exchange systems, GMail, and nearly every other mail system out there.


Unfortunately, I don't think IMAP isn't enabled by default in Exchange. And, at least at my work, enabling it isn't an option.


Why isn't it an option? If you work in the sort of environment that wont enable IMAP, you probably also work in the sort of environment that doesn't want you giving up access to your mailbox to a random third party.


Using ActiveSync to access Exchange would probably be the best way to pull it off (though there are probably patent-related concerns). A lot of Exchange admins aren't going to like opening up IMAP, but nearly every Exchange installation today has ActiveSync enabled and exposed to the Internet.


Nice service, of course... Waiting for the launch of the stable version.


Isn't this just IFTTT for email?


Seems that way. Is that a bad thing?


Isn't that just a snarky comment?


"just"




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

Search: