glodastrophe: the very in-progress experimental desktop front-end to the gaia email backend

Andrew Sutherland asutherland at
Fri Sep 18 05:16:55 UTC 2015

As promised in my other message from the "Future Planning: Thunderbird 
as a Web App" thread, I just want to provide some quick pointers and 
context for those with some level of interest.  This ended up more 
wall-of-text than I was hoping, so levity has been injected where possible.

== Disclaimer

None of this is something you would want to use right now.  None of this 
is remotely a replacement for Thunderbird.  None of this is likely to 
ever be a direct replacement for Thunderbird.  None of this will not not 
not not help with understanding double negatives.

== Context/factoids

About Gaia / Gaia email:

* Gaia is the name of the Firefox OS UI/UX project.  It lives here:
* The gaia email back-end v1 was message-centric because of time 
constraints, the expected limited resources of devices, and concerns 
over the level of resources services could provide to provide an 
acceptable conversation-centric UI.
* We are currently refactoring the gaia email backend to make it 
conversations-centric.  This means that the back-end fundamentally 
thinks about things in terms of conversations.  All messages/drafts must 
belong to a conversation.  (It's possible to show the messages in a 
folder on their own, but it would require creating an additional index 
and would be unable to leverage storage locality.)
* The back-end was designed based on lessons learned from hacking on 
Thunderbird, gloda, improvements to gloda, and the deuxdrop messaging 
project.  The refactoring builds on lessons learned from the v1 gaia 
email backend as well and having time to pay down technical debt.
* Right now the back-end has sync engines for Gmail (leveraging gmail's 
conversation logic as exposed to IMAP), Vanilla IMAP (using gloda-style 
conversation strict threading logic), ActiveSync (with all messages 
living in singleton conversations because of ActiveSync limitations), 
and POP3 (using the same gloda-style conversation strict threading logic.)
* ...but the refactoring is still in progress.
* The back-end runs in a DOM Worker and communicates with the front-end 
UI over a postMessage-bridge.
* The back-end is offline-first.  All manipulations are applied locally 
first and then subsequently replayed to the server when we're online, etc.

About Glodastrophe:

* I named it!  I'm notoriously bad at naming projects!  But there is a 
joke about gloda in the name if you look for it[1]...
* It's implemented using react.js.
* I've been actively thinking about how to make it feasible for 
extensions to replace or augment things.  Happily, react.js' encourages 
healthy encapsulation and delegation idioms that make this quite natural.
* The gaia email back-end is flux-like in nature in that you request 
changes, the back-end applies them locally, then you get events that 
propagate through to the front-end so the UI can always reflect the 
state of the database.

== Glodastrophe screenshot and code links

Here's a screenshot of what glodastrophe looks like in its "3-pane" mode:

The conversation list is notably an efficient virtual list 
implementation that is height-aware and allows random access seeking to 
any/all known conversations without having all conversations in memory.  
Conversation summaries include up to 3 "tidbits" on unread messages in 
the thread.

* The router for the 3pane is at:

* The conversation list is:
* The actual conversation display widgets in the list:

* The message list is:
* It farms out many things to sub-widgets (which are intended to 
potentially be replaced by extensions).  They can be found in 
* For example, the star widget (which is reused by both messages and 
conversation summaries):

The glodastrophe repo and and active branch is

== Gaia backend code links:

The gaia conversations branch is 
Note that there is some dead code in there that has yet to be migrated / 
destroyed.  Assume anything that looks dumb/ill-advised/you don't like 
is dead code that is going away!

API to the front-end:
* The API exposed to the front-end/consumers is rooted by the MailAPI 
instance found at
* All of its helper classes/etc live under:

Example sync code:
* This is the steady state sync task of Vanilla IMAP:
* Its documentation is at
* It doesn't actually synchronize the messages itself.  It generates 
tasks that perform the actual message sync:

* Conversations are actually summary objects derived from the messages 
that make them up.
* This logic generates the core state the back-end assumes all consumers 
want and which is necessary for core features:
* Front-ends also get to contribute their own logic.  The display of 
tidbits is a UI decision, including how many to display, so glodastrophe 
provides that logic at 
(The name "felam" is a play on the Dr. Scholl's "gellin' like a felon" 
ad campaign, universally agreed upon as the highpoint of human 
television.  (We call the mail backend "gelam".))


1: Admittedly, you don't have to look very hard.

More information about the tb-planning mailing list