Thunderbird as a Web App revisited

Andrew Sutherland asutherland at asutherland.org
Sun Dec 13 05:27:01 UTC 2015


Disclaimer: I am client-side biased since I work on a purely client-side
HTML/JS email app (the Firefox OS Gaia Mail app).

Especially given the points made about local data, I was a little bit
surprised about the emphasis placed on involving an (additional) server.
 One of my concerns about mailpile has been that it involves an
additional server that is not the user's actual mail server.  This
introduces logistical and cost issues that complicate things and beg the
question of whether an additional server is needed.

Which is not to say there aren't things that are best done on the
server.  But if they are best done on a server, why not the one the user
already uses (/ switches to from their previous provider)?  It's easy to
technically hand-wave that they can be co-located or an existing mail
server integrated or written, etc., but these are not trivial issues. 
And they especially matter because email is largely a cost-conscious
domain.  Most users do not seem willing to pay for high quality service,
and mail providers are not rushing to provide it for those users. 
Things that seem fundamental like IMAP support or valid TLS certificates
are far from dominant.

Traditionally, the rationale/argument against this is that one can't
depend on all servers to implement the features one needs or implement
them well so one needs to implement them oneself.  This, combined with
Thunderbird's POP3 support and general assumption of a desktop-class
machine with bountiful storage, is one of the reasons why Thunderbird
efforts in 3.0 and 3.1 were focused on local search instead of
improvements to search-on-server.

But things are changing!  Fastmail, which uses and actively (helps)
develop the excellent open source Cyrus IMAP server has been actively
proposing a new protocol, JMAP (http://jmap.io/).  This provides a sane
and lovely API that guarantees many things that have never been safe to
assume about an IMAP server (unless you saw the post-login CAPABILITY
string).

Now, this does not mean that we can assume mail providers out there will
upgrade to the latest Cyrus, but it does mean:
- There's a production-grade open source server that exists and is able
to run sufficiently cost-efficiently that Fastmail can make money.  If
users want this nice server, there is already at least one provider they
can feasibly pay to get it.  If they want to run it themselves, they can
do that too.  The introduction of an additional server presupposes that
they are willing to do one of these things.
- There's an actively developed open source mail server trying to make
things better and that is actively invested in the needs of its users. 
(Note that I'm not saying others don't exist, I'm just not aware of any
others interested in JMAP adoption at this time.)
- Using the wants-to-be-a-standard-and-looks-like-it's-going-to-be JMAP
for client-server communication is way better for the email ecosystem
than a Thunderbird web app/server implementing what amounts to de-facto
proprietary APIs.  (Obviously, the Thunderbird API need not be
proprietary, but standardization requires adoption/multiple
implementations and if everyone is just making up their own APIs and
ignoring other standardization efforts then it's still proprietary.)

Summarizing:
- I think anything that aspires to be a Thunderbird successor should be
client-only with no proprietary server-specific bits.
- Server-specific needs can and will exist, but they should be addressed
by working on/with IMAP/JMAP/other standards.  (And in many cases most
needs can probably be addressed by using ANNOTATE or something like
that, although it looks like JMAP does not require ANNOTATE support but
will allow it.  I need to do more research there.)

Andrew



More information about the tb-planning mailing list