

My crazy idea for making email better - jrussbowman
http://joerussbowman.tumblr.com/post/8950098782/my-crazy-idea-for-making-a-better-email-server

======
madhouse
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.

~~~
jrussbowman
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.

~~~
madhouse
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.

~~~
jrussbowman
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!

------
mooism2
> 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.

~~~
jrussbowman
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.

~~~
mooism2
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.

~~~
jrussbowman
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.

