Thunderbird as a Web App revisited

[Paul D. Fernhout]

Hi all. Kent pointed me to this group a few hours ago and I signed up.
Here is a Thunderbird-related proposal for feedback, revision (it's
CC-BY-SA licensed), or action that I wrote the other day and then edited
a bit afterwards. It's about making a "Thunderbird Server" as a complex
webapp hosted locally by Node.js and supporting plugins to extend it
into a social semantic desktop. That proposal was written in response to
the thread on Mozilla Governance about Mitchell Baker's 2015-11-30 email
related to Thunderbird's future.
http://pdfernhout.net/thunderbirds-are-grow-manifesto.html

Some more details on the proposal and me (by way of introduction since
it is my first post) are below. Thank you to everyone here for all you
have done here to keep Thunderbird useable for so long and help chart
out a course for the future.

--Paul Fernhout

== More details

Hopefully you can overlook the silly "ThunderbirdS Are Grow!" motto and
other Thunderbirds references in the proposal like to International
Rescue -- I was a big "Thunderbirds" fan as a kid, plus I also like
gardening as a software development metaphor. :-)

I have used Thunderbird all the way back to near the beginning and it
has served me well for over a million received messages and about 20K
sent messages.

So, as I've done before for other lists, I copied all the mailman
archives from tb-planning and then gunzipped them and cat-ted them
together and put them into Thunderbird (no doubt there is a plugin to do
that somewhere). I've been enjoying looking around at some of the past
discussions here. When searching on whether a server had been discussed
before, I found a discussion started September 17th by Kent James about
"Future Planning: Thunderbird as a Web App". So this local Thunderbird
web server idea is obviously not new.

In case it is of use, the proposal I wrote includes suggestions about
how such a project will benefit Firefox itself. Some of those are in the
form of quotes from other commentators in the governance thread like
Niklas or even some names I'm starting to recognize in the tb-planning
archives. :-) I generalized those further and added some more related
ideas around the contrast of local data exchanged peer-to-peer versus
central data accessed client-to-shared-server. I suggest peer-to-peer is
the soul of the web and even what sustains it, and that is why
Thunderbird is so important (including to Mozilla with its current
"laser-focus" on Firefox).

That proposal could use a lot of help by someone familiar with the
codebase in coming up with a more reliable estimate of what it would
take to get a Thunderbird Server running to the point where it was
useful to most people. So, it is really just a starting point.

In the proposal I suggest a much grander "social semantic desktop"
vision for Thunderbird Server than just handling email (or even just
being another Slack clone). That larger vision is what motivated me to
spend the time writing that up.

The proposal has some more specifics as to technology choices I would
use if doing such a project just on my own. I have recently finished a
first version of a good-size single-page multi-user FOSS webapp called
NarraFirma with about forty virtual screens, including graphs and quite
a few scrolling tables. I started that webapp in JavaScript, Dojo,
Dijit, GFX, and dgrid and (after a lot of evaluation of alternatives as
complexity issue grew) the webapp ended up in Typescript, Mithril, D3,
and with my own simpler grid. About 99% of the code is in the webapp,
and about 1% is in the backend. The backend can be either Node.js or
WordPress. Being tooled up, I'd enjoy working on a Thunderbird Server
project that used similar technologies -- but for pay though, as we just
blew all our spare cash/credit writing NarraFirma. :-)

Anyway, we can dream even if our dreams may not come true any time soon.
I had applied this week on Wednesday to Mozilla as a Growth Engineer
suggesting improving Thunderbird, and I got rejected Thursday, which
seems like some new record in HR turnaround. :-) Although I've applied
to Mozilla a couple of times before, including over four years ago for
the Thunderbird team (also suggesting the social semantic desktop idea,
and never hearing back that time that I recall). So, I'm probably in
some list somewhere, maybe even for a good reason unrelated to liking
Thunderbird a lot. :-)

Still, if just 5% of what Mozilla probably put into Firefox OS had gone
into Thunderbird, wow, what software the world might have today for
secure peer-to-peer data exchange of semantic information. :-)

I pointed this manifesto out to people on the Mithril mailing list, and
one person mentioned the Roundcube team has recently raised about
US$100,000 via Indiegogo to improve greatly. I added some comments at
the end of the manifesto about that and why it would still be a good
idea for Mozilla to be directly involved in a webmail/messaging/etc
project of its own as a way to grow Firefox and web standards related to
security and privacy and data exchange.

--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies
of abundance in the hands of those still thinking in terms of scarcity.
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

[Andrew Sutherland]

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

[Ben Bucksch]

Andrew Sutherland wrote on 13.12.2015 06:27:
> - I think anything that aspires to be a Thunderbird successor should be
> client-only with no proprietary server-specific bits.

Amen.

This is the key differentiator of Thunderbird to most other mail
clients. And why people use Thunderbird in the first place.

Ben

[Paul D. Fernhout]

Andrew-

Thanks for the reply. I appreciate the time of people here who know so
much about email and whose involvement no doubt would be essential to
making a new Thunderbird concept that really works well. I've started a
week-long sprint to create a proof-of-concept of a Thunderbird
Webapp/Server (which I really should not be doing, but that is another
story). That way I can "show" rather than "tell". After that
proof-of-concept is done, I hope you might be willing to look at a
working (if very primitive) system and then we could expand on these
discussions.https://github.com/pdfernhout/Twirlip2

In the meanwhile, here are some comments responding to points you
raised, especially the practical difficulty of running a local server on
a desktop when people expect seamless desktop apps.

== What Thunderbird does now

I think I have not explained the Thunderbird Server idea well enough and
so caused some confusion, sorry.

Right now, Thunderbird Desktop has essentially a web browser internally
(95% of its codebase) that talks to an email application (5% of the code
at most) via custom internal function calls in C++. I'm just talking
about essentially the same thing, except the email application runs
under a local webserver and the client part is the standard Mozilla
Firefox, and the protocols in between are JSON.

Those protocols are admittedly, as you point out, likely custom
protocols. However, the traffic across them is at least inspectable and
presumably documented. Those APIs are potentially callable by other
clients -- something presumably in practice the current Thunderbird
internal adhoc protocols defined by C++ functions are not.

So it seems to me like what I propose is still a step forward from the
current situation? Even if it is not perfect? Still, involvement by
people here in designing (or finding as with JMAP, thanks!) good
protocols could help a lot. One issue I'm pondering is how to send
search queries to get subsets of emails. I wonder if that is something
JMAP could help with? So, leveraging that sort of thing might be a big
win to save time, thanks again for pointing it out.

The only proviso I'd say is that I'm interested in integrated messaging
-- so, email, IRC, RSS, whiteboards, note taking, and more, all
together. A standard email protocol, even a better one like JMAP, might
not provide everything needed to support a full feature set. But I guess
I need to learn more about them.

The system will not be perfect at the start. I plan to put in some
arbitrary protocols to do the minimum needed for a proof-of-concept.
But, in an iterative way, I'm very open to someone who knows existing
email protocols well (which is not me), saying, look, you could leverage
that an have one less non-standard part in the application specifically
here. That would be valuable advice.

== Not a regular email server, but it could be

Such a server could of course also support direct IMAP, POP3, or JMAP
access from existing clients perhaps as plugins -- but that is not the
main intent. Actually, until you mentioned it, I had not even thought of
doing that. Thanks! :-)

== Local servers are just another way to modularize software

The confusion may be in my choice of the word "server". Is there a
better one to use here? Maybe I should say "Thunderbird Webapp" instead?

People in general are just not used to running local servers. I've
gotten used to it because I'm using Node.js more and more for all sorts
of things, including just parsing data and transforming it. You are
right to point to the added complexity though.

== Using a server is the only practical way to get Firefox to work well

But the reason I feel that is the way forward anyway (for Thunderbird as
a Mozilla project at least) is because Firefox's support for local data
is a problematical afterthought (as with the ignored Firefox issue I
posted about that 1.5 years ago mentioned at the beginning of the
manifesto). To get Firefox to work predictably as far as same-origin
policy security restrictions, you tend to have to use Firefox to surf to
a live website (even if it is a locally hosted website). I hope that
situation improves through a deep rethinking by Firefox of what same
origin policy means for local applications and local files, and such a
Thunderbird Webapp project might drive such improvements, but that is
the current state as I've experienced it -- using Firefox without a
webserver involved is problematical (which is sad to me).

== Don't look into the Electron beam with other eye :-)

In the long term, hopefully Firefox will provide better support for
embedding apps in the way you can do with Electron/Chromium like
Automattic just did for WordPress/Calypso to run as a desktop app.

Now I could just suggest until then the Thunderbird Server project just
do the same thing as Automattic did and run Thunderbird Server with
Node.js bundled together with Chromium via Electron for easy install as
a standard-looking desktop app -- "but that would be wrong". :-)

So, please don't look here, whatever you do: :-)
http://electron.atom.io/
"Build cross platform desktop apps with web technologies ... Use HTML,
CSS, and JavaScript with Chromium and Node.js to build your app."

== Mozilla ignored a crucial need and now everyone pays the price

More seriously, as I pointed out in a post to Mozilla Governance:
http://pdfernhout.net/thunderbirds-are-grow-manifesto.html
"Beyond the value of such a communications platform itself, if Mozilla
had prioritized this need to improve Thunderbird four years ago, Mozilla
might have improved the Firefox platform in ways that helped keep up its
market share up because Thunderbird was showing a need that became
Electron and Phonegap and other similar software. Then
open-source-friendly companies like Automattic might not be turning to
Electron/Chromium for creating a desktop WordPress/Calypso app instead
of using the Firefox platform. In fact, if Mozilla has done such a
thing, is it possible that much of the time and money and attention that
has gone into WhatsApp, Viber, Line, etc. might have gone into an
enhanced Mozilla Thunderbird and Firefox instead? Maybe then Firefox
market's share and Mozilla's revenues might have even expanded rather
than contracted? Instead, by ignoring the needs of Thunderbird and the
internet users it serves, by not trying to grow in that area, Mozilla
missed a huge business opportunity. ... Frankly, as I see it, if you
look at the adoption trends, and consider the rapid rise of Slack,
between Firefox and Thunderbird, an expanded Thunderbird is actually the
more viable product concept long-term. :-) But I am sorry to have to say
that as a long-time Firefox user. :-( ..."

That post is still in the moderation queue and I wonder if it will see
the light of day. Probably should never post stuff at 5:30am after
staying up all night writing it. I added the text from it to the
manifesto near the end though.

== Benefits of the web server approach

A big benefit to of the webserver approach is the Thunderbird project
could stop maintaining a second copy of Firefox it uses internally
because it can just use regular Mozilla Firefox on the front end
(removing 95% of the Thunderbird codebase and much drudgery, patching,
and security issues). Switching from C++ to JavaScript for the entire
app could also reduce memory bugs and security issues. But that is not
the only benefit.

With the webserver approach, you could potentially also access your
email (and perhaps other communications like IRC chats, RSS feeds,
notes, and more) from any device on your local network (including
phones, tablets, watches). You could setup custom networked devices like
a lamp that lights up when you get a message from someone special.

It would also be possible to access your email outside your network
depending on your network configuration (although that is a risk).

Those are things you can't easily do with Thunderbird Desktop (unless
you do virtual screensharing over the network perhaps, but that is
tedious and impractical for a phone).

For me, I use POP3 and not IMAP. I have Thunderbird delete email from
the server (after a short delay in case of a hard disk crash). I don't
consider myself having an existing "email server" in the sense that I
see our email server just as a relay point, not something that stores
email. I can imagine someone who uses an IMAP (or JMAP) server regularly
might have different expectations though.

Some people would not use an IMAP server at a remote host in the way it
was intended for privacy/legal reasons, because files more than six
months old become easily legally accessible in the USA on servers. For
example:
http://www.mcclatchydc.com/news/politics-government/congress/article24779989.html
"If you’ve been remiss in cleaning out your email in-box, here’s some
incentive: The federal government can read any emails that are more than
six months old without a warrant. Little known to most Americans,
ambiguous language in a communications law passed in 1986 extends Fourth
Amendment protections against unreasonable search and seizure only to
electronic communications sent or received fewer than 180 days ago. The
language, known as the “180-day rule,” allows government officials to
treat any emails, text messages or documents stored on remote servers –
popularly known as the cloud – as “abandoned” and therefore accessible
using administrative subpoena power, a tactic that critics say
circumvents due process."

== Why this should be a Mozilla priority

People at Mozilla believe in web technologies. That part I loved about
Firefox OS and its approach -- as even knowing how to write Android apps
I'd rather work on cross-platform webapps.

Given that belief, making email accessible over the web, but stored
locally and accessed securely to increase privacy, seems to me like a
no-brainer for Mozilla.

Of course, one may then discuss priorities, but given 70% of user
accounts are either email or IM, by one estimate from The Radicati Group
I cite in that latest governance email, it seems supporting such
internet usages of email and IM should potentially have even higher
priority at Mozilla than improving access to social media accounts (the
other 30%). But Mozilla's current funding priorities, especially
defunding Thunderbird development, obvious do not reflect those
statistics. I just don't understand that. :-(

(Anyway, back to coding...)

--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies
of abundance in the hands of those still thinking in terms of scarcity.

[Paul D. Fernhout]

I hear what you and Andrew are saying about ease of use and installation
related to user expectations as a desktop app. But if a Thunderbird
webapp/server written entirely in JavaScript/HTML/CSS was wrapped for
easy deployment in some future Firefox-based equivalent of
Electron/Chromium (similar to WordPress/Calypso for the desktop), how
would people even know how it was implemented? Assuming performance was
still good (which is admittedly a reasonably concern)?

Meanwhile, such a web technology stack could also support mobile phones
and tablets browsing to the webapp on the local network if you allow
that as an option and have your desktop running to serve such requests
(or even browsing from outside your network depending on how you
configure your firewall). That feature also might make up for any
performance issues relating to the alternative web stack architecture,
if any. Since people do use webmail a lot, I have to expect a webapp
could be made to perform acceptably on a desktop somehow.

--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies
of abundance in the hands of those still thinking in terms of scarcity.

[Andrew Sutherland]

On Sun, Dec 13, 2015, at 01:18 PM, Paul D. Fernhout wrote:
> The confusion may be in my choice of the word "server". Is there a
> better one to use here? Maybe I should say "Thunderbird Webapp" instead?

Yes, I was placing and do place a lot of importance on the word server.
Webapp is a better term, but it can also be a bit fuzzy since it means
many things to many people.

In the context of Firefox OS we have the notion of a "packaged app"[1]
(https://developer.mozilla.org/en-US/Marketplace/Options/Packaged_apps)
which is basically a cryptographically signed zip-file that exists 100%
locally on the device. The apps can also be installed into Firefox via
the Web Runtime (some details at
https://developer.mozilla.org/en-US/Apps/Build/Architecture). These
apps are entirely server-less and they get their own distinct
origins[2].

The Firefox OS Gaia Email app is a packaged app (technically it's
certified, but modulo some experimental stuff, it could be privileged),
and it's my goal to get my "glodastrophe" efforts somehow similarly
packaged for Firefox desktop. I believe this execution model is a
desirable one, but I do, for example, develop using a local Apache
instance with a custom /etc/hosts entry to provide it with its own
origin. Significantly, these are static files; there is no
server-run/operated logic.

Most of my concern stems from the idea of the server doing anything
other than serving static files. I think it would be beneficial that if
you are mentioning an additional server of this type that it's made
clear it only serves the application itself and could be replaced
through the use of a packaged app solution.

Andrew

1: Note that these packaged apps are a Mozilla/Firefox OS proprietary
packaging format created in pursuit of standardization. Google's Chrome
Apps are the closest other thing out there. The current longer term
strategy for these is not known, but we do like the properties of
offline and cryptographically signed. Service workers will likely
handle the former, but the latter is still up in the air. My personal
suggestion is using the subresource integrity effort bootstrapped off of
a root signature reliant on some code-signing trust infrastructure. The
specific goal would be that someone hacking https://mailapp.example.com/
could not let them replace/compromise the app unless they also managed
to obtain a valid signature. The Firefox OS marketplace currently
provides this, but AFAIK we don't easily support alternate trust
roots/marketplaces and that needs to be addressed.

2: I believe the bug you reference in Firefox is in its treatment of
"file://" origins. The file protocol is troublesome for security and
consistency reasons and (to my understanding) is a non-priority other
than ensuring that there is no way for web content or file:// content
from different sub-trees on your disk to access and exfiltrate data from
your local filesystem. If you need to do local development, you likely
want to be using "localhost"/"*.localhost" since they receive special
treatment under https://w3c.github.io/webappsec-secure-contexts/ and are
allowed to be granted the same API access as "http" sites that only
"https" sites otherwise receive.

[Ben Bucksch]

Paul D. Fernhout wrote on 13.12.2015 19:18:
> But the reason I feel that is the way forward anyway (for Thunderbird
> as a Mozilla project at least) is because Firefox's support for local
> data is a problematical afterthought (as with the ignored Firefox
> issue I posted about that 1.5 years ago mentioned at the beginning of
> the manifesto). To get Firefox to work predictably as far as
> same-origin policy security restrictions, you tend to have to use
> Firefox to surf to a live website (even if it is a locally hosted
> website). I hope that situation improves through a deep rethinking by
> Firefox of what same origin policy means for local applications and
> local files, and such a Thunderbird Webapp project might drive such
> improvements, but that is the current state as I've experienced it --
> using Firefox without a webserver involved is problematical (which is
> sad to me).

If there's a rewrite of Thunderbird in HTML5/JS, it would need a local
runtime (similar to XULRunner, but for HTML5+JS, not XUL).

That runtime would need some features that a normal webbrowser does not
have. The absolute minimum that comes to mind is opening TCP sockets, to
allow IMAP/POP3 without proxying, and opening/saving files (even if only
in a certain directory on disk), to store emails persistently locally.
Probably I'm missing a few other things.

That's not outlandish. There are a number of projects which do exactly that.

That wouldn't be a "webapp" anymore. A webapp comes straight from a web
server and runs in a normal browser, that's its definition. We commonly
call webapps that do email simply "webmail". There's plenty and plenty
and even more of that, in all sizes, shapes and colors. We don't need
another.

Ben

[Robert Kaiser]

Ben Bucksch schrieb:

> That runtime would need some features that a normal webbrowser does not
> have. The absolute minimum that comes to mind is opening TCP sockets, to
> allow IMAP/POP3 without proxying, and opening/saving files (even if only
> in a certain directory on disk), to store emails persistently locally.
> Probably I'm missing a few other things.

Both exist in Gecko and have been implemented for Firefox OS (though
file access through DeviceStorage is somewhat awkward). They may not be
fully implemented on desktop platforms and/or enabled on Firefox but
that is a gap that Mozilla wants to close from all I know.

KaiRo

[Ben Bucksch]

Robert Kaiser wrote on 20.12.2015 03:51:
> Ben Bucksch schrieb:
>> That runtime would need some features that a normal webbrowser does not
>> have. The absolute minimum that comes to mind is opening TCP sockets, to
>> allow IMAP/POP3 without proxying, and opening/saving files (even if only
>> in a certain directory on disk), to store emails persistently locally.
>> Probably I'm missing a few other things.
>
> Both exist in Gecko and have been implemented for Firefox OS (though
> file access through DeviceStorage is somewhat awkward). They may not
> be fully implemented on desktop platforms and/or enabled on Firefox
> but that is a gap that Mozilla wants to close from all I know.

I know. There are several potential runtimes:
* XULRunner (without using XUL, and XPCOM only for those few APIs I
mentioned)
* FirefoxOS
* GeckoView in Android (offshoot of Fennec), with adding custom JS APIs
* NW using node.js

Either way, I would ship the runtime with the app, like Thunderbird
today ships Gecko with the EXE, and install and start it all together in
one go. Simply to make it easy for end users.

And also to avoid having to deal with 3 different HTML renderers in 15
different versions each (particularly on Android, where people still use
Android 4.0 etc.), and to official support them all. They still have
minor differences, and that's a major hassle in web dev. That would hold
us back.

---

To answer Paul directly: While technically possible to ship a server
with the app, there's no point in doing it either. It's just a further
indirection, so slower. And also additional trouble: if one of them
crashes or is closed, you need to ensure that the other is closed, too.
That's not as easy a problem as it sound, if you want it to work in case
of error situations. It's easier to build these few APIs directly into
the JS API of the runtime.

Ben

[Robert Kaiser]

Ben Bucksch schrieb:

> Robert Kaiser wrote on 20.12.2015 03:51:
>> Ben Bucksch schrieb:
>>> That runtime would need some features that a normal webbrowser does not
>>> have. The absolute minimum that comes to mind is opening TCP sockets, to
>>> allow IMAP/POP3 without proxying, and opening/saving files (even if only
>>> in a certain directory on disk), to store emails persistently locally.
>>> Probably I'm missing a few other things.
>>
>> Both exist in Gecko and have been implemented for Firefox OS (though
>> file access through DeviceStorage is somewhat awkward). They may not
>> be fully implemented on desktop platforms and/or enabled on Firefox
>> but that is a gap that Mozilla wants to close from all I know.
>
> I know. There are several potential runtimes:
> * XULRunner (without using XUL, and XPCOM only for those few APIs I
> mentioned)
> * FirefoxOS
> * GeckoView in Android (offshoot of Fennec), with adding custom JS APIs
> * NW using node.js

I personally actually think that Thunderbird should either run inside
Firefox as just HTML, or as a Firefox add-on using WebExtensions.

KaiRo

[R Kent James]

On 12/20/2015 8:45 AM, Robert Kaiser wrote:
> I personally actually think that Thunderbird should either run inside
> Firefox as just HTML, or as a Firefox add-on using WebExtensions.

See:

http://mesquilla.com/2010/06/01/lessons-from-google-thunderbird-as-a-firefox-extension/

:rkent