Aussies' fix for 'stagnated' email
smh.com.au
smh.com.au
I'm glad they're only aiming at a small group of people who actually have problems with email. The weekly "re-invent email" posts are getting quite tiresome, the majority of people have absolutely no problem with email, email is an incredibly simple concept and it works for almost everyone.
In short, email is fucking awful and the bane of my existence. At one point I was getting north of 200 emails a day from people demanding meetings, todos, updates, and pieces of information. Please someone... reinvent it!
So, exactly the people that any new e-mail solution won't be able to help because they're locked into a Lotus Notes/Exchange server with a bunch of backend integration and a proprietary client.
The good thing about the old subject line of an email is that you usually can tell whether it's something you need to look at now or save for later, move to another folder, or delete. You can also quickly see whether you are the main target or just CC'd.
Speed reading can also assist in processing email. Sometimes you just know whether you need to read something thoroughly, or can glance over.
Speed reading, as you suggest, would not be a good solution to finding mission-critical information. As far as I know, no collaboration tool exists that could handle the complexity that we were dealing with. We tried quite a few, and pushed SharePoint to its limit.
I have to agree that emailing has gotten worse since everyone and all has started using the internet and email. And then tools like Microsoft Outlook make it hard to quote in context and easy to reply above the original message. As a result almost no-one I have regular email contact with has a good email etiquette. If I compare my email conversations with programmers and computer scientists with that of my co-workers or family, the difference is huge. In the former case email is an efficient tool to communicate whereas in the latter case it becomes a pool of mis-communication fast.
http://techcrunch.com/2009/12/01/inbox2-one-inbox-and-commun...
And here is the desktop client which is now open-source: http://www.techshout.com/img/inbox2.jpg
People do not need this and will not leave their existing email clients because they simply do not see email as being 'stagnated'. It works and gets the job done.
There are lots of problems to fix around email, but a new inbox interface is not one of them.
My advice to you would be to go build on top of for example gmail. There are massive number of things that suck horribly. Yes, search is one of them.
Inbox navigation is another one, but keep in mind that there is a reason why the current line based inbox interfaces work.
The third one is attachments, but that is one I am already tackling with my new startup www.fileboard.com
I have no idea how successful Fluent will be at all those things, but it's just peculiar when a site says "we're tackling problems x, y, and z" and you come along and say, "your ideas suck, try addressing problems x, y, and z instead."
Having spent the last 3 years of my life tackling this problem I would say I am pretty qualified to say this solution sucks.
And they are totally not solving the problems I mentioned, they are building a new mail client. Which tends to be a completely different thing.
Anyways just my 0.02$
We calculated that it cost us about 1.20 euro do keep this up per user per month. And mind you these costs were primarily network bound so it doesn't matter if you have faster hardware.
There are some optimization techniques you can do to bring this down (for example use imap push) but with gmail you are looking at about 2K connections per IP, you do the math.
Actually you can do this (and we are doing this through partners) on the cheap but the experience you can provide will not be appealing unless it is an add-on experience on an existing product.
Do you mean that google only allows you 2,000 concurrent IMAP connections per client IP address, so you need to scale up your requesting IP pool along with your user count?
Looks very inspired by by Sparrow.app [2](OS X mail application). Though they have improved on the UI in some aspects.
Great that people are still trying to make email better.
[1] http://fluent.io
It was slow and had some UX quirks/bugs.
For a time I fired it up every once in a while as an email-backup solution, but I got lazy so I don't even do that now.
The stream view is an interesting concept, but we've found that many people don't have a nice inbox of messages as shown in the preview. In fact, it's quite the opposite: messages from friends, family, and coworkers are often overwhelmed by notifications, newsletters, and mailing lists. However, your Amazon shipping and Twitter notifications aren't spam, you just don't want to see them in the same context.
I'm working on Glider (http://glider.io), a fix for the mess in your inbox. You already know which kinds of emails are important to you, so instead of obscuring that information, we think the best solution is to sort and display emails by sender and context.
We did a soft launch on HN a few weeks ago (http://news.ycombinator.com/item?id=3519917), and would love to know what you guys think. Good luck as well to the Fluent team!
"You may revoke Fluent's access to your email box at any time..."
You should make this stick out, increase the font size, color it, bold it.
Really? Really?
I expect better from my fellow Australians, even if they are Sydney-siders.
However, we'll try to live up to Australian standards better in the future =)
Except for the journalists.
(What did you actually say, in your recollection?)
Regards, Ben Grubb (the journalist)
Kudos Ben on your quick rebuttal of the misquote claim. And for an article full of links to all the companies and technologies you're writing about.
Did they really have to editorialize and verb 'action' to make you sound cool? I think not. But, we have to 'sell the cool', right, SMH? I think this was a fail - it really makes you appear idiotic to say things like "action that email". Cringe++.
Besides that tender point, the idea of presenting ones email as a stream is an interesting - but not new - idea. I'd be rather more happy to see this idea, which in my opinion ought to be implemented as a GUI control for all mail clients possible, evolve into Mail.app and other mail clients.
Naturally the exception to this is an accessible human history, which Australia doesn't really have much of.
wikipedia puts it better: "Cultural cringe ... is an internalized inferiority complex which causes people in a country to dismiss their own culture as inferior to the cultures of other countries" http://en.wikipedia.org/wiki/Cultural_cringe
Check out the wikipedia link - it also has this gem: The cultural cringe can be expressed in the almost obsessive curiosity of Australians to know what foreigners think of Australia and its culture. A quick way to most Australians' hearts (unless they're counterculture hipsters) is to compliment the country... just make sure you sound sincere when you do it :)
(clarification: You're right to cringe at that, but it's the article displaying the concept known as "cultural cringe", not yourself)
Granted, you'd still be branded a corporate douche for actually talking like that straight-facedly here in the US; but "actionable" is live jargon and actually used by even savvy manager-types.
I must seriously not have the same problems. With gmail spam filters and priority inbox the last thing I need is to visualize my e-mails in a twitter like stream.
I can't be the only one one that jumps for joy when someone actually e-mails me something akin to a personal letter.
I like it how it is because filters and sensible organising of inboxes is not hard.
Not interested in email streams at all. I'd prefer to keep streams for the kind of information that doesn't require action or response frequently per item. Emails often require action or attention, and it's far better they exist as subject line items in a date-ordered list for easy retrieval, sorting and archiving all at once.
It's just a bit of message passing, why should email NOT also handle multiple participants and almost-real-time conversations well?
Twitter is a different beast, it's a public stream, but what does FB messenger offer over email, other than an improved user experience? (for some value of improved...)
The article revolves around email having stagnated, which pretty nicely fits the "no longer growing" part.
No central servers, just a single blockchain recording all encrypted messages on the network and shared over a bittorrent network, and an easy-to-use client that doesn't make normal people think too hard.
Encrypt a message with your recipient's public key, submit it to the network, it's accepted into the blockchain, and they decrypt it on the other end with their private key when the msg propagates to their client. Private (at least until computing power catches up with the encryption algorithm), decentralized email without ads, popups, etc.
Give it a nice Apple-ish/fluent.io-ish/sparrow-ish interface, transparent encrypting and decrypting, and some way of optionally associating email addresses with public keys so normal users don't have deal with intimidating hashes (optional only though, still want the ability to send directly to more anonymous public keys).
While you'd still need some method of preventing block chain forking, you wouldn't have to worry as much about double spending and transaction verification since you don't care whether someone sends the same message multiple times to different recipients (as you do with bitcoin).
One of the biggest problems would be dealing with exponentially increasing blockchain size. Bitcoin already has this problem and its transactions consist only of relatively terse amounts of data. With full emails (and attachments?) you'd have to implement a method of cropping and perhaps archiving the blockchain, or otherwise solving that problem, or it will quickly become unweildy and destroy the user experience (esp for people with slow connections).
Perhaps clients store the blockchain a certain number of blocks back, and then beyond that they only store their own sent and received messages? Not sure...
The genius of bitcoin is that it is a solution to a difficult algorithmic problem in distributed systems [1] which can be repurposed for other implementations. It is already being repurposed for a distributed DNS [2] and distributed voting systems for elections [3], why not a distributed encrypted email system as well?
Just throwing this out there without really thinking it through thoroughly atm... Thoughts? Feasible? Probably the biggest problem is knowing that one day all your emails would essentially become public domain when hardware catches up...
1. http://en.wikipedia.org/wiki/Byzantine_fault_tolerance#Origi...
3. ddg-fu failing me atm, will add this later.
But seriously, this would not scale. Using a central block chain as you suggest means that every node in the system receives a copy of every email. It's also trivial to DOS - just send tons of multi-megabyte messages to nonexistent receivers. The messages hang around in the block chain forever and the entire system dies.
Email is not a decision problem (unlike bitcoin, or potentially a DNS replacement). It is a delivery problem, and is local in nature. There are no global decisions to be made, unlike in bitcoin - there's just a sender and a receiver, and they need to find each other to exchange the message. Once they do, nobody else needs to know about any of this.
When you view things in that light, SMTP is a reasonable protocol for the job. It just lacks sender authentication, hence the spam problem, and is cleartext-by-default. It also relies on the DNS protocol for endpoint location, and is a 7bit protocol (making attachments needlessly inefficient). All of these things can be fixed without any kind of radical change to the protocol; just tack on a DHT (keyed on recipient public key hash?) for endpoint location, mandate 8bit-cleanliness, authenticate the sender somehow (this is a HUGE problem and one your hash chain system also fails to address), and mandate encryption.
If you want to also mask IP addresses as well, just toss in a standard mixnet, such as tor or I2P. This gives you endpoint location for free, as well.
As for sender authentication, mandating message signatures is an easy first step, but authenticating the sender key is a hard problem (key management always is). You need to have some kind of vetting process or spammers will just mint millions of keys; but at the same time people like to receive messages from people they haven't exchanged keys with. This here is the fundamental problem with spam, and not one that any purely technical solution can fix.
Your proposal basically sends all email to everyone (encrypted), which avoid the need for a DNS entry.
That model already exists, it's NNTP (a.k.a USENET). This basically sends an email (RFC822 body) to all participating servers in an efficient 'flood fill'. (A usenet post is almost identical to an email body).
So PGP+NNTP gives you the protocol side of what you want today.
The issue will be that "sending all email to everyone" probably won't scale, for NNTP or your system.
Namecoin's .bit domains already support Tor. Throw in some S/MIME or PGP on the actual messages and you're mostly done I think.
Other than the sexy UI of course :)
Yeah, when I mentioned the ability to associate email addresses with public keys, I wasn't very clear. I did't mean regular email addresses, but was actually thinking of bitmail-only email addresses. Perhaps ones based on Namecoin .bit domains.
But I wasn't suggesting interop with existing email infrastructure, this would be completely separate. In fact, the idea would be to disrupt and supplant the regular email we all know and love, at least for some use cases where privacy is paramount.
Everyone would have their bitmail client which they could use to send encrypted email, as well as their regular Gmail addresses and whatnot. Most people have multiple emails anyway, this would just be one more.
One nice thing about bitcoin, which would carry over to bitmail, is that despite the core technology (the official client) being completely outside and orthogonal to the current financial system, it's very easy to use for its fundamental purpose. Sending and receiving bitcoins is just simple. I envision the core bitmail client would work similarly and be similarly simple. No need for interop as long as there are specific optimal use cases for it (say, Arabs and others coordinating against oppressive regimes, stuff like that).
I think you could perhaps make it work with a bridging service between the networks?
The only problem I could see with this is one bitcoin will also eventually run into, but even moreso, which is scale. Average email size is going to be a lot larger than your average bitcoin transaction. That said there may be ways around it, perhaps using the usenet infrastructure as an underlying transport mechanism and piggybacking off that. It already has ridiculous amounts of data flowing through and being stored on it. Something to think on more, thanks for chiming in.
And here's another thought about that - just delete all messages from the blockchain after they're read, and only store them locally in the clients. As soon as the receiving client unencrypts the message, store it locally, then delete it completely from the blockchain. Unlike bitcoin, this wouldn't be an accounting ledger with the necessity of storing all transactions in perpetuum. All that needs to happen is the message get delivered to its recipient, once that is verified to have happened, it can be deleted. The clients can keep copies and organize them into conversations or whatever.
That wouldn't quite solve the issue of hardware eventually being able to brute force the encryption though, since an interested party could store a running record of everything put into and deleted from the blockchain. But it would have to be a very interested party to store that amount of data in the hopes of being able to decrypt it years or decades later.
Bitcoin wasn't really designed for deletions though, and that would also double the rate of blockchain diffs, so would have to think more about how or if that would work...
A small marketing firm I happen to admin the email servers for... sends 15 million marketing emails per month (all opt-in, CAN-SPAM / Australian Spam Act compliant). This alone is nearly 1.5TB of data. We only send marketing campaigns for about 8 national brands and about the same number of regional brands to a country of twenty something million people.
Now It might be suitable for a conversation or private chat room. It would work really well in an IRC / small group situation. But I can't imagine a single global system ever scaling past a few dozen people without some significant hardware.
As far as deleting things, the problem there is who is responsible for deleting and what if I don't? The number of bounces we get from campaigns from defunct mail boxes that have filled to quota is quite high. Who removes this email that no one reads? At the moment the storage problem is isolated, but a central chain makes it impossible.
The more I think about this makes me think you might get it to work with a block chain per domain... but then whats the point over simply setting up your own email server you trust and using encryption?
The problems with Pointers & de-dupe is that at least marketing emails are personalised, each are sent independently often with at least a minimum of personalisation, for example calling you by your name (people are more likely to read it if it calls them by name). You can do de-dupe, but your limited to the efficiency and overhead of your block size. Compression would also take the storage required down to ~ 1/10th (excluding attachments), but I don't think thats still enough. Even if deduping and pointers gave you a 500x storage saving, the data size for a few days email is still so unfathomable that it won't work as a single global system.
As far as trying to solve it with economics, its been tried (as a method to stop spam) but the question is who has to pay who and for what? Every such scheme has failed because you end up missing one of the big groups of users as it becomes un-economical for their mail pattern to continue. If you make the senders pay, few comercial entities want to play, and few people will provide free email. If you have to pay to store then how do you stop being billed for someone flooding you.
Eg. I am user@provider.com, I want a storage bin for this account. A storage bin could then be either someone who just has user@provider.com (say on a massive scale, the u shard for the provider.com domain) or someone who has the entire storage bin for provider.com, or someone who has the entire storage bin for .com
Couple this with open access to the storage bins from any and all (the more the better, the heavier replicated they are the easier / faster end users have access to their mail) and an economic incentive to participate in storage propagation (mailcoin? n mailcoins per n mb of storage, charge mailcoins for access to the storage bin, whatever model makes the most economic sense) and we might be onto something. It also handles deletion and allows users to "un-send" mail by deleting the mail from the storage bin it exists within. The blockchain in bitcoin does not allow for transaction deletion operations, but that does not by any means rule out the possibility of deleting the position in a storage bin where the spoolchain in mailcoin points to.
Besides, what's the point of the blockchain there anyway? Why not just have a distributed naming system (like namecoin) for the addresses and then simply integrate an MTA with the client, allowing simple P2P between users?
Maybe in a few decades time when it's normal for people to have static IPv6 allocations and permanently online machines in their homes, it will be trivial for people to run their own mail systems using existing protocols.
http://bitcoin.stackexchange.com/questions/1517/has-anyone-a...
I'll take an open source clone of Gmail, thank you very much, especially as they continue messing with the interface for the sake of it and with the privacy policy for kicks.
While we're at it, I'll also take an implementation of conversations in ThunderBird, to make it more like Sparrow, which is quite nice on the desktop.
That is how you rip through thousands of emails in insanely short times. Much MUCH faster then gmail.
I'd love to have rss/tweets/fb/g+ updates alongside emails for people I care about rather than maintaining increasingly complex methods of keeping up to date with each in different apps
I'm still searching for a decent desktop email client, something that looks like this and works on both Windows 7 and Mac OSX. It's a shame that this is a web app, it doesn't solve any problem that I have.
But I like and trust email because it is stagnate. How is this different than Buzz (dead) or my other 'streams' like G+/Facebook/Twitter? I don't want my email to be a stream, because if I miss one, that could be devastating. I don't want email to evolve, because it is the only thing I can trust that won't become realtime.
The feature where a panel slides in from the right allowing you to view more is such a great time-saving feature.
Great UI, I love the attention they paid to some details.
Google Wave anyone?
This is a people problem, not a technology one. Sorry, just don't see it 'fixing' a problem.
Given the influx of e-mails I get a day from listservs, friends, business contacts, customers and random services (Groupon et al.), I see this already busy interface getting cluttered very fast. That said, I only tried the demo and would be interested to see what it looks like on my actual inbox with real people.
Not what I'd call "fair dinkum", but...