
Email made me miserable, so I decided to build my own email app from scratch - dmbaggett
http://www.slate.com/articles/technology/technology/2015/02/email_overload_building_my_own_email_app_to_reach_inbox_zero.html?wpsrc=sp_all_native_by-section
======
plehoux
"Maybe the dream of an email-free future isn't dead; maybe it just means a
future in which email is merely a sliver of our communication rather than the
whole pie."

Email is victim of its own success, like cars & highways in America.

Highways are not bad per se, they were and are an incredible revolution. But
too much of them means the value we collectively subtract constantly diminish.
We need alternatives: walkable neighborhoods, bike lanes, tramways, trains,
bus, etc.

It's the same with email, we need alternatives. Chat services like Slack &
HipChat are good examples for internal communication.

Email's decentralized nature and ubiquity mean it's the perfect tool for
external communication. I don't see why this would change.

~~~
plehoux
Last week I did a visualization of all email clients in time from '79 to now
([http://email-apps-timeline.missiveapp.com](http://email-apps-
timeline.missiveapp.com)). It shows that there is a lot happening in the email
space right now, even if the technical barrier to entry, as the author
implies, is so high.

~~~
whatever_dude
Great chart! Some of those new email clients look great. I wonder if any of
them will become solid and popular enough.

~~~
baldfat
I am still waiting for the application that kills email and the need for
clients..

~~~
simoncion
Given that the set of folks that are interested in and capable of making
_widely used_ end-user communcations software, and the set of people who are
_not_ interested in making walled gardens appears to have no overlap, you're
going to be waiting for approximately forever. :(

~~~
baldfat
ONE DAY MY TIME WILL COME!

~~~
simoncion
:)

Just as long as part of your glorious future is a fully open and Libre
protocol, federated servers, and -at a minimum- feature parity with email I'm
100% okay with it. :D

------
camgunz
The most remarkable thing about this article to me was that a journalist with
moderate programming ability was able to build an email client. I think as
coding becomes more accessible we'll start to see truly novel approaches and
applications. People say C succeeded because of UNIX, and JavaScript succeeded
because of the web. I'd guess the next language will succeed because it makes
true software development fully accessible to people who haven't spent years
learning how to do it.

~~~
tim333
Reading his background ([http://cperryk.com/](http://cperryk.com/)) it says "I
built my first website as an 11-year-old." "I earned my first dollars building
websites for family friends and fellow students' parents." So he may be a bit
more experienced than the impression he gives in the article.

------
dmbaggett
Chris Kirk, the author of this piece, interviewed me briefly. I have to admit
that when he told me he was writing his own email client for the story, he
became my tech journalism hero.

~~~
stevekemp
It does sound pretty impressive; I've written a (console-based) mail-client,
and between fighting with different approaches to UI, scripting, and MIME
issues, I've a lot of respect for somebody tackling the problem.

------
ForHackernews
Am I the only person in the world who thinks email works pretty well? Maybe I
just get less mail than many people, but I just delete (or mark "read" and
ignore) most of the marketing ham mails I get. I read and respond to the
actually-important messages I get for work or from personal contacts. Actual
spam is pretty well filtered.

I vastly prefer email to Facebook messages, or Slack notifications, or any of
the other purported "solutions" to communication.

Why do people hate email so much?

~~~
wpietri
As the author explains in the first few paragraphs, he was basically fine with
email until he was thrust into a job with a much higher email volume. That's
been the story I've heard from most people who hate email.

~~~
creeble
Exactly, the problem isn't email, it's the level of communications you believe
you are expected to maintain. Maybe you are expected to maintain this level,
in which case you have a problem that no level of email-client fixes will
solve.

------
vpeters25
I find very interesting how the author describes some of the shortcomings of
IMAP. The article seems like a nice starting point for requirements to create
a new email protocol.

Like the author, for years i've been bothered by email, but as someone who has
been maintaining mail servers for 20+ years my biggest issue is the server
side of things.

SMTP, POP and IMAP have served their purpose way beyond their original scope.
I think going to the drawing board and coming up with a replacement is long
overdue.

~~~
jimktrains2
I started typing out the requirements[0] I'd want as a user. It's only a start
and doesn't have any implementation, but any discussion would be appreciated!

I wanted to focus initial on the things I hated as a receiver: spam filters
(too many false-positives that don't correct when I report them as such),
dropped messages (I cannot get messages from [http://www.eternal-
september.org/](http://www.eternal-september.org/) on gmail because of reasons
only $DIETY could extract from google.), lack of encryption and
authentication.

[0]:
[https://github.com/jimktrains/email_ng](https://github.com/jimktrains/email_ng)

(For IRC just use the same channel i registered for discussion on a new http
(freenode @ #http_ng)
([https://github.com/jimktrains/http_ng](https://github.com/jimktrains/http_ng))

~~~
simoncion
> ...lack of encryption and authentication.

PGP (or the MSFT-specific equivalent) handles this. [0] I know that people
love to pile hate on the UX of PGP, but Engimail has worked perfectly fine for
me for _ages_.

[0] Yes, I know that PGP doesn't -and can't- encrypt addressing information.
We _could_ address a big chunk of that by creating informal groups of
sysadmins who configure their email servers to _only_ speak over TLS-encrypted
channels to other servers and clients.

~~~
jimktrains2
Yes, but I can't even get technical friends to use PGP:-\

I'm proposing it be tied more tightly into the protocol. Some of which is so
that there is infrastructure to "vouch" for a sender address (for a period of
time) so that they can send you things that would bypass spam checks. (Think
password resets, or account notices from a bank).

------
tunesmith
I've always thought an effective if brutal strategy might be the one that
won't even deliver your email to you if you're not at Inbox Zero, and then it
delivers a day at a time so you might end up days or weeks behind. And maybe
it would give you clues, like, "you have 47 additional emails waiting from
this sender", so if they're spammy, you could just unsubscribe right there and
it would delete them upstream without you even having to look at them.

~~~
patates
do people really have this problem? I never remember being bombarded by a
single source (be it a person or a service), email becomes a burden because
there are many sources and the level of urgency is alternating even for the
same source through time

~~~
LoSboccacc
Yeah I manage that by treating all mail as low priority and every chat as high
priority. People chatting for spam or to bring attention to a low priority
inbox gets told to send an email. This way I'm sure not to miss critical
messages without relying on pepople self tagging

------
jrapdx3
A few years ago I wrote a webmail client to access my mail on the server host.
I had developed a web server (in Scheme no less) that was/is running (now on a
VPS) and at the time it seemed only natural to extend it with webmail
functionality.

The effort was successful (for some definition of success), though it proved a
to be a daunting task. It taught me a lot about email, that it's riddled with
arcane protocols and dark corners, these "features" pretty much without
consistency or order. On top of that there was constructing the UI needed to
actually use the thing.

Would I do it again if starting from scratch? I don't think so, it sure seems
the hard way to go about it. No doubt I could recommend it as a great learning
exercise, but for creating a product I don't think it's the pragmatic way to
go.

I've considered publicly sharing my project, but not before refactoring some
prodigiously opaque, obscure and convoluted parts, and who knows when I'll
have the time (or courage) to tackle it.

Email remains at once a great wonder and horror, yet for all that email
continues to be widely used, and remains essential to most everyone. I still
use my email client most every day, despite its warts. I guess it's proven its
worth after all.

------
aaronem
Why use email as a to-do list, when it's obviously so poorly suited for the
role? Why not use email for things email's good at, and use one of the wide
variety of to-do list tools for task tracking?

When you need to refer to an email from a to-do item, there's ways to do that;
some clients support direct hyperlinks, and others can be dealt with by just
including the date/time and sender or subject of the email in the to-do item's
notes, so that you have the information you need to quickly find the message
via search. You can also include excerpts from email, or even whole messages,
directly via copy-and-paste; after all, it's not as though they are going to
change once received, so there's no sync problem to manage.

Granted, this might seem like being more effort than just mapping task list
semantics onto email. But the article under discussion here chronicles its
author's essentially having reinvented every task abstraction all the way up
to the project, solely in order to overcome the inherent drawbacks of trying
to use email as a task list. It seems impossible that this could be easier
than just finding a task list tool that has the features you need, and
learning to use it alongside your preferred email client.

~~~
creshal
> Why use email as a to-do list, when it's obviously so poorly suited for the
> role? Why not use email for things email's good at, and use one of the wide
> variety of to-do list tools for task tracking?

I've no idea. Some mail clients even give you one-click ways to directly turn
emails into todo tasks (ex.: Thunderbird with Lightning, and I think Outlook
as well).

~~~
smacktoward
Because email is a tool you already have.

"Go get a proper application for that" entails a lot of work, including things
that can be cognitively difficult like sifting through the giant sloshing sea
of half-finished code that is the Internet to pull out a few good candidates.
So it's not hard to understand why using a tool you already have (and already
understand) would be more appealing.

~~~
aaronem
I suppose it doesn't have to be a proper application; I've seen people manage
to-do items in Windows Notepad and it seemed to work for them, God knows how.
I tend to think in terms of task list management tools because I've gone to
the trouble of setting up a CalDAV server and integrating all my computers and
devices with it, but the general point could (and, as you point out, really
should) be less "you need to go find an app" and more "try thinking about to-
do lists in _any_ terms other than email, because anything else will probably
be less painful".

------
oever
The repo is here
[https://github.com/cperryk/slatemail](https://github.com/cperryk/slatemail)
I've no idea how to run the app. It seems to be a graphical node.js
application.

~~~
chrkirk
Hey guys — I'm Chris Kirk, the author. It's an nw.js application (formerly
known as node-webkit). Nw.js is basically a framework for building native
desktop clients with Node.

Unfortunately I haven't been able to give the client much attention since
writing this article. Slate was amazing for giving me a month to work on it
and report on that experience, but it's not in the email business. I come back
to SlateMail from time to time, but right now the app is not exactly in a
usable state. Nylas N1
([https://github.com/nylas/N1](https://github.com/nylas/N1)) is similar -- an
extensible email client based on Web technology. Nylas has a whole team of
people on it, and it's in active development. So if SlateMail interests you, I
recommend you check Nylas N1 out!

~~~
grinich
Thanks for the kind words about N1! I'm one of the Nylas co-founders. :)

I'd love to get your take on N1, especially given that you've dug so much into
email the past few weeks! Shoot me a note? mg@nylas.com

Edit: Just saw this article was actually written in February :P

------
golergka
May be the author is a bad programmer — but undeniably, he's a great tech
journalist.

~~~
randyrand
Hah, very true. Though, we all start off as bad programmers =P

------
egometry
He dwells too much upon the age and cruft of email, but this article reads
more like a layman learning for the first time about Hofstadter's law, general
programming project mis-scoping, and dealing with technical debt he himself
created... which is kinda cool to hear about from "the outside".

~~~
dmbaggett
To be fair to him, though, pretty much every programmer I know since I've been
working on ([http://inky.com](http://inky.com)) has asked me why it's hard.
Email is partly hard because of the historical cruft, but there are genuinely
difficult design/abstraction challenges with email as well, and even
experienced developers tend to mis-predict how hard it is to make a "real"
mail client.

The one exception to this was Carl de Marcken, one of my co-founders at ITA
Software, and chief scientist there. He predicted -- correctly -- that it
would take us 4+ years to get to an MVP.

~~~
plehoux
I agree, at Missive ([https://missiveapp.com](https://missiveapp.com)) it took
way longer than we originally thought to get to MVP, ~around 1.75 year (and we
only support Gmail/Google app for the moment)

~~~
dmbaggett
Wait until you get to IMAP and Exchange -- you'll learn that you're only 5%
done. :(

~~~
Estragon
What are some of the most surprising complexities?

~~~
dmbaggett
There are at least 75 nontrivial problems, each of which is worth of its own
startup-amount-of-effort. A few random examples:

\- sanitizing HTML email: you must eliminate XSS while preserving the
appearance; this requires real HTML and CSS parsing; we do this on the end
user's phone at MB/sec rates, which is not easy

\- conversation threading: any email in a conversation that's been sent with
Outlook will have stripped the standard threading headers and added the
proprietary Thread-Index header, so in practice you _must_ rely on heuristics

\- properly mapping the IMAP/Exchange/POP "database" onto UI views is
immensely complex in a real client, and requires exactly the right set of
abstractions (which are very subtle)

\- it is a vast understatement to stay that the IMAP protocol is a mess; it is
also plagued by some really bad design choices (such as relying on message
sequence numbers which vary _by connection_ rather than exclusively using
UIDs, which don't).

\- instant full text search over a million message inbox is hard, but this is
a real-world use case

\- converting arbitrary MIME emails to HTML for rendering purposes is a huge
rathole

\- making offline mode really work (supporting search and modification of
cached mails) is complicated, and most clients punt on it (because they are
implemented server-side and therefore require a network connection for
anything to work)

\- implementing everything server side is (relatively) easier, but requires
you to scale bandwidth per user and mailbox, which is expensive; on the other
hand, doing everything client-side like Inky does is much harder because
you've got tremendous variation among hardware platforms and operating
systems, and it's a really heavyweight app

In general, an email client subsumes many other highly nontrivial subproblems,
somewhat like a browser does. Just doing the security-related stuff alone
properly -- TLS, certs, revocation, encrypted email -- is really labor-
intensive.

~~~
dugmartin
I think sanitizing email is a solved problem with this:

[https://github.com/cure53/DOMPurify](https://github.com/cure53/DOMPurify)

I'm not the author but I've used it in the past. According to the readme it is
what Fastmail uses.

~~~
dmbaggett
Probably not fast enough for us, but it is a very nice library. (We use
libxml2.)

The reference we test against, by the way, is Mike Cardwell's excellent Email
Privacy Tester:

    
    
      https://emailprivacytester.com/
    

Try it on your own mail client!

~~~
nmjenkins
We have no speed problems using this in production at FastMail (we're kind of
known for our speed in fact…). We use it at render time, both on desktop and
mobile.

------
rokhayakebe
Perhaps Email serves its purpose perfectly: send/receive messages. For
everything else, we could either extended it via plugins or create different
tools SMS/Chat apps/etc...

~~~
pmlnr
This.

Email is pluggable, on client and on server side. The basic idea of email is
done and finished; everything that extends it should be a plugin.

------
CaptSpify
keeping up with email became a snap for me once I discovered mutt and
procmail. This post definitely falls under "reinventing the wheel", but I
can't say that's a bad thing. Unfortunately, most people's workflow is so
different, that having one email workflow/interface just won't cut it, and
sometimes it takes a custom solution.

~~~
pmlnr
Why procmail, why not Sieve on the server side?

~~~
rakoo
Which mail providers provide Sieve support ? I see Fastmail does, but Gmail
doesn't.

~~~
pdonis
_> Which mail providers provide Sieve support ?_

Nobody really does, which I find extremely frustrating since sieve is supposed
to be the Internet standard for mail filtering.

Fastmail sort of does, in that they use sieve rules; but last time I looked,
they didn't have a managesieve interface, which means I can't just upload the
sieve rules I have spent a lot of time creating on my home email server. I
have to create them from scratch using Fastmail's rather clunky (IMO)
interface.

As far as I can tell, no other email provider uses sieve at all.

~~~
dasyatidprime
They do allow you to provide Sieve scripts as text, but you do have to use the
Web interface to upload them, under Advanced → Rules, so changes aren't
readily automatable AFAIK. Unfortunately, I don't remember exactly where the
enable button is for people who aren't using it already, since I'm already
using it.

~~~
pdonis
_> They do allow you to provide Sieve scripts as text, but you do have to use
the Web interface to upload them, under Advanced → Rules, so changes aren't
readily automatable AFAIK._

Not only that, but I can't upload them using my email client, which has
managesieve support already built in.

------
larksimian
Liked the article but it produced a weird dissonance in me. On the one hand I
totally empathized with his frustration/excitement at building a cool bit of
software for himself. On the other hand I've never had problems managing my
email inbox, mainly because I don't get that much relevant email.

In particular, since the Gmail tab redesign I've not had an issue keeping my
Inbox unread count at 0(though with my Promotions/Updates/Forums tab unread
count in the who-knows-how-manies). I guess this confirms his point about
email protocols being dinosaurs, since the way Gmail implements its tabs is
tied into their client implementations and doesn't work in other email
clients.

The overall impression I ended up with was that Slate is simply using email
for workflows it was never meant to support and is not very good at
supporting. Email chains are not a good way to do project management/planning.
It's good that they've started using Slack for chat-like communication. They
should adopt some sort of project management app to manage projects. If you've
got a user that's used to Gmail, they can learn Trello, for instance, in about
an hour.

I tend to think about 3 levels of communication: chatting(text, audio, video);
email; project related. Each level requiring additional structure and being a
bit more cumbersome to use than the last when writing, but easier to use when
reading/searching for information.

In that sense it makes sense to use 3 (sets of) tools for 3 different types of
communication. The main downside is that it's somewhat complicated to transfer
a conversation from one channel to another. However doing all 3 in one
application leads to the risk of making a simple use case too complicated or a
complicated use case impossible.

The ideal integrated communication app would need to provide IRC-like chat
power, Hangouts/Skype like chat simplicity(+audio/video support), Gmail like
email usability and auto filtering, and more than Trello-like project
management/collaboration tools(for instance, having Google Doc-style shared
documents properly integrated into it). All usable in interfaces designed for
the particular level of communication you are engaging it at the time, but
allowing you to move 'threads' of conversation up or down the hierarchy
easily. I've not encountered anything that does this right. Heck just being
able to properly integrate Gmail, hangouts chats and google docs/google doc
comments between each other isn't possible and all those are made by the same
company.

------
jakejake
Having built several in multiple languages, I'd recommend for anyone to build
their own email client.

It's quite easy to get the basics up and running but quickly becomes tricky
getting all of the messages to display consistently. Then you can add embedded
images and attachments to the mix. The list goes on and on. But, you really
will learn a lot about protocols, parsing text & binary data, working with
legacy formats and just all kinds of interesting stuff. Even if you don't wind
up with an amazing client, it's still a lot of fun!

~~~
stevekemp
I'd second that. The basics are easy, but there will be constant niggles
relating to RFC2047 header-parsing, MIME-issues, and issues relating to
handling some crazy mails that people will send.

I've written my mail-clients in C++, but I suspect Perl, Python, or Ruby,
would be fast enough with the massive caveat that you need to have decent
libraries/interfaces for the low-level parts.

------
noddingham
The most salient point he makes is when he says there's a difference in what
email was designed and how we use it today. And it sounds like Slate needs
better tools.

Do you even Confluence / JIRA (or insert your preference here)? If you'd stop
trying to use email as the one tool for everything, you'd stop (or
significantly reduce) the times you run into it's supposed shortcomings.

~~~
jethro_tell
the problem with a lot of those tools is that they use email as a notification
system. When they should run something more like the notification system for
iOS or android. (you have seventeen new notices from jira in 3 issues).

You look at it once, then it is gone and you go to the site to check it out.

------
afarrell
Isn't Nylas ([https://www.nylas.com](https://www.nylas.com)) supposed to fix
this problem?

~~~
Silhouette
It's hard to say. That web site is so buzzword-driven and content-free that
after reading a couple of the pages I still have literally no idea what it
does or why I might need it.

~~~
grinich
Hey-- I work at Nylas.

Would love any feedback you have for the site! There's a bit more info on our
"Features" page: [https://nylas.com/features/](https://nylas.com/features/) In
particular:

> Nylas brings email into the 21st century with modern tools, RESTful
> developer APIs, and open source code. Integrating with Gmail or Exchange now
> takes minutes instead of months. Nylas is the easiest way to build an email
> app.

Pretty much this means we talk IMAP/SMTP/ActiveSync/MIME so your app doesn't
have to. Plus there are some nice new features, like a transactional "delta"
endpoint and webhooks, which makes writing mail processing code a breeze.

If you're a developer, the easiest place to dig in might be our docs:
[https://nylas.com/docs/platform](https://nylas.com/docs/platform) or the open
source sync engine: [https://github.com/nylas/sync-
engine](https://github.com/nylas/sync-engine)

We also shipped a new desktop email app this fall, which started as a fork of
Atom. You can see that code here:
[https://github.com/nylas/n1](https://github.com/nylas/n1) Our website is
sorely in need of a refresh, but right now our team is busy scaling and fixing
bugs like crazy. (Relatedly, if any designers are looking for a job... feel
free to email mg@nylas.com !)

~~~
Silhouette
_Pretty much this means we talk IMAP /SMTP/ActiveSync/MIME so your app doesn't
have to._

My first suggestion would be to try putting things like that statement front
and centre, and then ruthlessly dump about 90% of the distractions you
currently have. That one sentence told me more about what your system
_actually does_ than the home page, features page, and a few other areas I
scanned combined. Following it with more specific information about how your
system can be used and what concrete benefits it offers over what I'm probably
doing instead today seems like a good idea.

From the pages I read before, I get that you have a tool that wants to be
developer-friendly and fully buzzword-compliant. Of course, so does every
other online service whose web site I visit. Unfortunately, aside from being
something about e-mail, contacts and calendars, there is _literally nothing_
on the pages I saw that tells me what your particular service is for or why I
might want it, which is kind of a dead end.

Another point you might like to consider is that your docs repeatedly talk
about things like integrating with some e-mail related service. However,
"integration" is an empty word here. The back end code for various projects I
work with already sends transactional mails via some service provider's mail
servers just fine with the usual one-liners. It probably already integrates
just fine with some well-known mailing list management services for larger-
scale communications, too, again with close to one-liners. So we come back to
what does the integration your service offers _actually do_ with mail and
calendars and contacts? Systematically process incoming mail? Manage a mailing
list? Send lifecycle mails when someone new signs up? IMHO, something needs to
say, very clearly and very early, what your USP is.

~~~
kkoomi
Completely agree, a bit frustrating guessing at lines like 'Nylas removes the
pain of integrating your app with email ...'

------
hackuser
Another, much longer and more technical view of the complexities of email
clients:

Why email is hard by Joshua Cranmer of Mozilla:

[http://quetzalcoatal.blogspot.com/2013/09/why-email-is-
hard-...](http://quetzalcoatal.blogspot.com/2013/09/why-email-is-hard-
part-1-architecture.html)

------
slowmovintarget
I couldn't help thinking of Google Wave while reading this. There was one
missing feature that made a handful of my friends and I stop using it: regular
GMail in the same client.

If we didn't have to switch back and forth, Wave would have slowly grown to
dominate most electronic conversations I had with friends and colleagues.

Sigh.

~~~
0x445424
That's exactly why I actually liked Buzz... It was integrated with Gmail.

------
siscia
We are working on this same problem providing unlimited, disposable, email for
all.

We are getting close to something similar to an alpha version, feel free to
subscribe: mailroad.co/

~~~
abluecloud
The CSS negative margin you've applied to `.row` is causing your page to add
vertical scrollbars. You should remove the padding from `.container-fluid` and
apply margins to the inner elements to stop it. It looks naff.

~~~
mod
Can you explain 'naff'?

I looked it up (I've never encountered it) and it seems to be a (British)
verb.

~~~
rosser
[http://www.urbandictionary.com/define.php?term=naff](http://www.urbandictionary.com/define.php?term=naff)

------
listic
Aren't there already email solutions out there that treat email as a to-do
list, divide it into discrete projects and so on? I believe there should be
some, based on Allen's GTD method, if nothing else.
([https://en.wikipedia.org/wiki/Getting_Things_Done](https://en.wikipedia.org/wiki/Getting_Things_Done))

------
clscott
This is an interesting read, when I saw a few of the comments here ask "how
hard can it be?" I was reminded of this presentation by Rik Signes at YAPC::NA
(2008)

Email Hates the Living

[https://www.youtube.com/watch?v=4s9IjkMAmns](https://www.youtube.com/watch?v=4s9IjkMAmns)

------
barbs
> _I found the process frustrating, humbling, and strangely fun. I imagined I
> was on CSI—but instead of a person, it was my app dead on the floor, and I
> had to find out who killed it and how_

What a great way to think about bug-fixing!

------
aplorbust
How is Slack different from IRC or using netcat on a LAN?

~~~
codezero
managed permissions, built in history (doesn't rely on you being connected to
get a log of a conversation that happened when you were gone), great full text
search, integrated rich content (posts, videos, images) which are also
searchable in the same way, adding context to conversations, built-in system
for notifying people, channels, and groups, with centralized options to tailor
those notifications to yourself, a fully featured mobile application that
synchronizes with the desktop app seamlessly.

Slack basically removes the requirement for you to have an IRC server, client,
and a suite of IRC scripts and bots. It unifies the experience across the
team, which, yes, does remove some levels of customization you would get from
your personal IRC client, but in practice, it's been a highly productive work-
chat tool.

I've basically replaced Dropbox as my source for important files, instead,
putting them into a Slack channel. That way what ever made that file relevant
is surrounded by the chat that necessitates the file.

It's not for everyone, and I don't think anyone would claim it should be, but
if you work on a team, especially a distributed one, Slack brings a lot to the
table "batteries included."

~~~
rocky1138
Yes, but what happens when Slack goes away?

~~~
codezero
We'll move to another tool.

Do you still have your IRC logs from 15 years ago? That's a loaded question. I
know some people do, but most people don't and most people don't need them.

We put things all over the place that include "what ifs" – what about files in
dropbox, or emails in gmail?

Everything includes some level of trust and some level of acceptance of
ephemerality or potential loss.

Personally, everything in Slack is work related, not personal, so it can go
away, just like I could get fired, or quit, and never have access to it again.
If there's something I want to keep, I'll keep it somewhere I believe is safe
and permanent, that's up to me, not Slack, or the tools I use.

I also have a reasonable expectation that Slack would provide some sort of
export/dump of data, similar to what twitpic did, or any other business does
when they sunset. This doesn't always happen, and it's not fair to assume it
would, but I trust Slack because they've done a very good job at being
responsive to their customers' needs thus far.

------
z3t4
I still believe that multi-part e-mail conversations can be cleaned up with a
few "diffs" and presented in a chat-like view.

------
collinmanderson
"When Gmail launched as a public beta in 2007" \- Wasn't it April 1, 2004?

------
nodivbyzero
Discover Emacs with powerful Gnus.

~~~
copperx
I have stayed aways from Guns because I thought it was a newsreader, and I
have no interest in Usenet. Is it a good email client too?

~~~
teddyh
Short answer: Yes.

[http://gnus.org/manual/big-gnus.html#Getting-
Mail](http://gnus.org/manual/big-gnus.html#Getting-Mail)

------
Murk
Addspam;DR

