Self-Destructing Email(medium.com)
medium.com
Self-Destructing Email
https://medium.com/future-tech-future-market/f0837a9ceef0
16 comments
I actually agree with you, I wrote the post not to work on it, but give context and inspire the giants gmail, microsoft and others to do something about it.
Problem is finding stuff in your inbox. This helps with the noise problem from emails that will never be relevant again.
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.
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.
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?
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.
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.
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.
Insignificant to you, maybe. But this is a big problem to me. Preventing life-threatening diseases is insanely important and I don't want to discourage anyone from working on it, but it doesn't mean other problems shouldn't be solved or worked on.
But a meeting invite from the past may contain other information I want in the future. Deciding what is useful to keep and what can be safely trashed is a very tricky (if not impossible) problem.
As for generic expiry of individual emails, Lotus Notes has been doing that for years and years. It doesn't provide expiry of emails that go outside of Notes, but that is not what it's trying to solve. Internal data retention policies become much easier to handle if it's enforced by every user's mail client.
As for generic expiry of individual emails, Lotus Notes has been doing that for years and years. It doesn't provide expiry of emails that go outside of Notes, but that is not what it's trying to solve. Internal data retention policies become much easier to handle if it's enforced by every user's mail client.
Isn't that what the delete button does?
I think it is a real problem when you don't own your email or its contents. I would love if something like this was officially supported by all the big players.
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/...
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.
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.
Nice find
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?
tl;dr -- We need jet rocket cars. Wouldn't those be cool?
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.
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.
I think you're confusing this with Outlook style message recall. The proposal here is about helping the receiver automatically cull out of date email. Of course you should be free to ignore any such flag. The point is that it would allow convenient filtering by some subset of recipients.
> 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.
Well… http://www.paulgraham.com/startupideas.html
Specifically:
> Live in the future, then build what's missing.
In this case, I don't think a mailbox that can be controlled by the sender of an email is missing.
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 [email protected] 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.
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 [email protected] 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.
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.
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.
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.
Wrong - the user may collect them to try to find patterns.
The user may do a lot of things. But that doesn't mean they do. You're bring up an edge use case at best in trying to disprove an idea for the mainstream.
The user may do a lot of things. But that doesn't mean they do. You're bring up an edge use case at best in trying to disprove an idea for the mainstream.
How about s/delete/archive, in gmail terminology (in other words, get it out of the inbox but have it still accessible in search).
I don't see this as a usecase for spam prevention, as you said, but for informational messages, offers, or activity digests that are superseded by later mailings it could be useful.
e.g. a notice about the elevator being out of order between 2pm and 3pm is not useful after that time. If I didn't see the message by 3pm or I was out of the office, there's no value in that message being in my inbox.
I don't see this as a usecase for spam prevention, as you said, but for informational messages, offers, or activity digests that are superseded by later mailings it could be useful.
e.g. a notice about the elevator being out of order between 2pm and 3pm is not useful after that time. If I didn't see the message by 3pm or I was out of the office, there's no value in that message being in my inbox.
> e.g. a notice about the elevator being out of order between 2pm and 3pm is not useful after that time. If I didn't see the message by 3pm or I was out of the office, there's no value in that message being in my inbox.
There absolutely is, if there's an elevator service level agreement (SLA). I want the maintenance emails for my records.
There absolutely is, if there's an elevator service level agreement (SLA). I want the maintenance emails for my records.
Right, but it'd still be in your archive, just not on the frontpage in bold.
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.
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.
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.
However, I agree that an advisory expiral date such as "Not-Relevant-After" could be useful if you're way behind your email inbox.
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.
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.
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.
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.
Invites and meetings probably fit in this category too. After the event happened, the message has lost a lot of its value.
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??)
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??)
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.
This is actually the worst post I've seen on medium so far.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
You can already do that with the auto-expire option in gnus with emacs.
Great idea.
Now _how_ does one bell that cat?
Now _how_ does one bell that cat?
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.