

Self-Destructing Email - rituraj
https://medium.com/future-tech-future-market/f0837a9ceef0

======
diego
This is a solution to a problem that doesn't exist. In the meantime, real
unsexy problems are ignored. It reminds me of this post:

<http://raganwald.posterous.com/why-the-fuck>

I meet too many startups in SV working on questionable incremental
improvements to social networks and communication tools. Not enough people
think about low-hanging fruit problems that affect the quality of life of
millions of people.

I'm trying to compile a list of some problems in that category, and I'll share
it at some point.

~~~
adrr
Problem is finding stuff in your inbox. This helps with the noise problem from
emails that will never be relevant again.

~~~
diego
Ok, it's not a problem that doesn't exist. It exists, but it's insignificant.

I think that working on the "email noise problem" when you could be building a
profitable business helping people prevent or cure life-threatening conditions
is a terrible use of brainpower.

~~~
betelnut
If you help doctors, researchers, and others working on life-threatening
problems get relevant information they need faster, then you are indirectly
helping with these efforts. Not everyone can be the person on the frontline of
these critical efforts, but if you can improve their working conditions then
surely you've helped out a bit?

~~~
wavesounds
These are precisely the people that should not be having emails deleted
automatically. "Wait which kidney was I supposed to remove" let me check that
email... oops

This idea would only be good for spam "buy now before its too late" type
emails (ie non-important information) which is not a problem that really needs
solving.

~~~
betelnut
Yeah, you're right. I was responding to the general problem of finding stuff
in your inbox as restated by others - not the suggestion of self-destructing
email. Sorry I was unclear.

------
dollar
Kleiner Perkins already funded this company... in 1999. This will be a hot
technology... in the year 2000. Unfortunately it will promptly go bankrupt in
2001.

[http://money.cnn.com/magazines/fortune/fortune_archive/2001/...](http://money.cnn.com/magazines/fortune/fortune_archive/2001/06/25/305429/index.htm)

~~~
rituraj
Nice find for sure. I think the issue with outside server technology is
adoption by both sender / receiver - the main hypothesis is based on sync time
management between both.

Like regular verbal communication (instead of messaging) happens over same
time. For us thats like water to fish. Implementing a time server function to
email systems would create a sync'ed communication system.

------
georgemcbay
This post kind of ignores just about everything about the way email works.
Even if a TTL (time to live) header was added to the SMTP protocol, good luck
getting every existing mail handling agent out there to respect it (not to
mention changing all the MX servers that passed a copy of the message to flush
their cached versions of it, etc).

tl;dr -- We need jet rocket cars. Wouldn't those be cool?

~~~
josh2600
This is exactly how I felt reading this post. It just seems to imagine a world
that's unlike the one we live in.

Nevermind the fact that this gives someone else control over my inbox, which
is sort of the point of hosting your own mail in the first place. I don't
think this idea has a prayer of catching on, and in fact most of what the
author is suggesting can be handled with server-side code.

~~~
goronbjorn
> It just seems to imagine a world that's unlike the one we live in.

Well… <http://www.paulgraham.com/startupideas.html>

Specifically:

> Live in the future, then build what's missing.

~~~
S4M
In this case, I don't think a mailbox that can be controlled by the sender of
an email is missing.

------
venomsnake
This is unworkable.

There are people like me which have policy of no byte lost. You have no way to
enforce on a system that user has root access deletion of anything. So if you
want the mail you send to be deleted - you cannot force it.

It also adds little value to the user - if you want autobot@spam-factory.com
messages to be deleted in 3 days it is the job of the client - this is a
simple script with simple rules.

But lets take the "classic" example of special offers of the week ... the
assumption is that after the expiry it has no value for the consumer. Wrong -
the user may collect them to try to find patterns. If something is not on
discount now but has been discounted 5 times in the recent year, chances are
it will be soon. Think steam sales - we know that Deus Ex: Human Revolution
will be 75% off, because it has been on every steam sale so far.

~~~
bowmessage
I think you're taking the metaphor a little too literally. My understanding of
the author's argument was that every email should have a date and time
attached to it, not for the client to delete it outright but for the client to
be able to sort by time and date, as well as keep separate folders of past
email and future email. I would LOVE this idea.

~~~
fatalerrorx3
I don't think that's what the author is saying..I think he's literally saying
the email will be deleted on the server if the time expiration occurs, unless
the user specifically says to store it anyway (even after expiration). This
would clear your inbox for things like invites to parties which have past
without the need to manually delete them.

~~~
bowmessage
Well my apologies then if I misinterpreted -- now I think the author is taking
his own idea too far then :). Deletion isn't necessary, just get it out of the
regular inbox, and leave it somewhere else for later consideration if need be.
That'd be the best of both worlds in my opinion.

------
h2s
Has this dude _really_ never looked at SMTP headers? He's proposing that we
add "the meta Time information to the email construct". Emails already contain
lots of time information about each step the email took in its journey to your
inbox. It sounds like what he's really proposing is some new "X-Delete-By"
header for mail _user agents_ to obey if they so choose.

Technical questions aside, this idea is very very bad. Self-deleting email is
the stuff of dystopian nightmares. This would be an unprecedented level of
restrictive DRM. On that basis alone I feel quite confident in strongly
rejecting the idea.

------
emillon
E-mail is a system to asynchronously deliver messages to a set of recipients.
That's it ; there is nothing you can do to force the messages to get deleted
(the same way read receipts don't work).

However, I agree that an advisory expiral date such as "Not-Relevant-After"
could be useful if you're way behind your email inbox.

------
thomasbk
Outlook.com has a related feature: it has a button that creates a filter which
automatically deletes any messages from that sender after N days, or only
keeps their most recent email.

------
huhtenberg
Do I get it right that he is suggesting _expiring_ emails?

If so, then it's a neat idea, but it won't see any adoption. Virtually all
time-sensitive emails are of promotional nature, so it's in sender's best
interest to keep it in the Inbox even if the actual email content is no longer
valid.

~~~
VLM
I'm really struggling to imagine a time sensitive email that I want to see...
it seems only useful in spam. Inevitable that "time sensitive" will be auto-
marked as spam before it expires itself. The only people using it will be
people who don't want to use it.

~~~
emillon
Invites and meetings probably fit in this category too. After the event
happened, the message has lost a lot of its value.

------
michaelmartin
Ignoring the technical difficulties others have mentioned, the fundamental
flaw to me is that other people set the response times.

This is akin to Outlook's priority markers. There's nothing wrong with
prioritising, but it needs to be you who sets the priority, not everyone else.

Your "queue" would always be poisoned with people wanting fast respones (And
who ever sends an email and hopes for a slow response??)

------
rdl
The only mail for which this is really appropriate is meeting invites, and
it's easy enough to just handle those within a calendaring system vs. in your
regular mailbox, at least within a business.

This is actually the worst post I've seen on medium so far.

~~~
rituraj
Speaking in terms of higher level of usage of language, meeting invites are
only one kind of coordination in language. You make a request for a meeting,
the other has a chance to Accept, Decline or Counter Offer the meeting.

Coordination is a major use case of email. Whenever you ask someone to do
something, or in another words say send you something - language wise you are
making a request - its the same construct as that of a meeting - the action is
different.

~~~
rdl
Meeting requests are the one type of request which has a natural time
component. "Find me some headphones" doesn't have an inherent time component,
it has a task completion goal. So, it doesn't make sense for it to auto-expire
based on time. Dealing with closing/deleting email based on these fuzzy task
completion goals cannot currently be automated, and you'd never want to delete
the record of completed tasks, either.

For more complex transactional issues where some parties may be using email,
there's ticketing/CRM. Once an issue is resolved, you close the ticket, which
may log somewhere else. Generally these systems are more one-sided, where an
individual interacts with an organization, and there isn't always much
visibility into the ticketing state from the outside.

------
blowski
The biggest problem with (human-written) email is that it's _so_ poorly
written. 20 action points, mixed with a bit of smalltalk, and lots of
tangential information, all on a reply to a totally irrelevant email. The kind
of people that send these emails either wouldn't use an 'expires' header, or
would set the expires header to be '5 minutes from now'. They're the same
people that have 'top priority' as the default setting on every Outlook email.

However, there are ways of adding functionality to email clients without every
single email client implementing it. Think YouTube previews in Gmail, and all
the other custom headers on Exchange servers.

~~~
rituraj
The problem with Client side time management is you cannot sync time across
the sender and receiver. Server side is where it would produce the max
productivity.

------
skimmas
I'm imagining opening an e-mail... marking it as unread because I'll want to
read it later, and when I come back it's no longer there because I forgot to
press the "DO NOT SELF DESTRUCT!!!" button. I believe we have the exactly
right amount of anoyance with spam, and familly relatives. Self destructing
messages would be the last drop. :P

------
jiggy2011
If I am an email marketer why would I want my emails to be auto-deleted at
all?

Even if you added some new legislation requiring me to add an expiry time to
email messages the standard practice would be to make this as long as possible
and to simply send new emails out the minute that the old ones expired.

------
jcoder
Why does the author think that a system having "Please respond by {date}" also
must self-destruct messages after that date? That's insanely silly. Just
continue to write "please respond by {date}" in your subject line if you need
to, and keep all your emails.

------
melipone
You can already do that with the auto-expire option in gnus with emacs.

------
bdunbar
Great idea.

Now _how_ does one bell that cat?

