My crazy idea for making email better | Hacker News Reader

My crazy idea for making email better

joerussbowman.tumblr.com

1 pointjrussbowman8 comments

So, there'd be another layer of indirection, and not only would I have to download the email, I'd also have to fire up a browser?

And the link would point to something that's never guaranteed to remain there, or remain the same? Something next to impossible to archive or download for later reading?

No, thank you.

If I want a collaboration platform, I will use something that's designed to be one. I want my emails as emails. Something I can store on my computer, something that does not change. Something I can archive, and quote from later.

Building plugins for major email clients would be a necessity. How to get people to install those plugins would be a bigger challenge than building them.

Right now I'm thinking that at least for read messages, archives of revisions would need to be kept. If a message was never read I'm not sure it's necessary to keep a revision of it though.

It's still a pain to archive, and requires extra network roundtrips even in the best case. I not only need to be able to access my mail host, but wherever else the link is pointing to aswell.

When I'm checking my mail on my mobile phone, I'm sure as hell do NOT want to make extra network roundtrips just to be able to see my mail.

It's also far harder to index, sort and search in the proposed scenario: while I can quickly file an email under any label or folder I choose, and be sure that it will stay there, have the same contents forever, and I can search it easily, the proposed scenario does not allow for that. While I can still file and label the emails that have the links, I cannot easily search in the contents, unless I archived that separately, or I go online.

Again, a lot of indirection for no real gain. I can already use something like http://gist.github.com/ or the various pastebins, and a multitude of other solutions if I have a particular problem where they are appropriate.

But for everyday mail? Why would I want to do that? It just makes things more complex, for no purpose or gain at all in the vast majority of cases.

I didn't even consider mobile access, which of course these days should be one of the first things considered.

You've given me a lot to think about, thank you very much for taking the time to respond.

I'm still convinced I can turn this into a marketable product, but the challenges will be bigger than I first thought and it definitely will not be for everyone.

Maybe I should approach it more of being a collaboration platform that can use email as a form of initial discovery for participants rather than as an enhanced email platform. Then I could also expand it to include other delivery methods as well. Want to collaborate with someone on Twitter and don't know their email, send it to them via Twitter.

Thanks!

> Read receipts wouldn’t be dependent on the client supporting them and the recipient agreeing to send it.

From the recipient's point of view, that's worse.

> ... allows the sender to go and edit or even delete the email after sending it.

From the recipient's point of view, that's worse.

For some cases, yes. For most cases, I'm not so sure. I will state that this is probably not a solution for everyone and for many cases the traditional functionality of email may be not only preferred, but necessary.

On point 1, how often, for the practical purposes email is intended for, does the average person not what the sender to know they've received their email? It's a messaging platform and acknowledgement is part of communication.

On point 2, does the recipient really need to see the message as it was first sent, or do they need to see the message the sender intended to send?

Working as a sysadmin myself, I can see where it may be necessary to keep a revision history of the message. I'd of course have to disclaim that up front to parties using it for sending.

But, thinking about that, it also means server side I'd have a bit more control over controlling it as a spam delivery platform. The only thing sent to recipients is a link. If there's spam or malicious content within the body of the message I could delete all the messages server side. No more worrying about they guy who's on vacation that comes and clicks on the link when he gets back. On that front it might make sense to build the server as a commercial product at some point, though really this functionality could easily be baked into Exchange, Zimbra and other products if the Enterprise went with webmail interfaces only.

I usually don't mind the sender knowing I've read their e-mail, but I do mind them knowing exactly when I read their e-mail, and I mind them being able to infer when I read e-mail in general.

I mind the sender being able to delete messages from my mail archive. The sender being able to update the message they sent me is fine, so long as I can still get at the original message and forward it to my boss.

If you can remotely delete spam after spammers have sent it from your server, then spammers can update all your sent messages to be spam as soon as they break into your server.

I see your point on the first item. Going to have to give that some thought.

Archive history for any messages read will probably be necessary no matter what. I'll basically have to version all edits and make sure access can be granted in some cases to archived messages both for the sender and recipient.

As for the last point, that can basically be done on any email provider that allows you to store messages on the server.

Reply on news.ycombinator.com