[swartkrans]

That's great to hear. Regarding the Android app having just checked it out, my first request, if you're taking them, is multiple account support. I can only log into one fastmail.com account at a time with what is here now. The reason I have two accounts is because I have two domains that get emails. Otherwise seems like a solid app. I'll probably start using this as my calendar app. :)

http://jmap.io/ seems pretty awesome, I guess I can use that to build my own fastmail app integration?

Thanks for all the hard work on fastmail!

[robn_fastmail]

> That's great to hear. Regarding the Android app having just checked it out, my first request, if you're taking them, is multiple account support. I can only log into one fastmail.com account at a time with what is here now. The reason I have two accounts is because I have two domains that get emails.

Yep, its high on the todo list for a future update.

> http://jmap.io/ seems pretty awesome, I guess I can use that to build my own fastmail app integration?

That's the intent, though we're not there yet.

[e12e]

JMAP does indeed look very interesting. In my (very, very slow) path towards writing my own email client, I've also come to expect that a new, simpler protocol is probably a better bet than imap. Partly this belief is bolstered by the fact that the creator of sup went on to make heliotrope: https://github.com/sup-heliotrope/heliotrope [ed: I suppose the canonical repo is https://github.com/wmorgan/heliotrope -- but afaik they are the same (and both appear dead)]

Is the code on: http://jmap.io/server.html actual code? If so what kind? Lua? It'd be great if you could publish some test cases, even if you don't have implementations to go (open source) with it at this time.

I'm sure fastmail can bring a lot of real-world testing and experience to the table when/if designing a new protocol for email -- and I'd be very surprised if we actually need more than one... (at least considering we already have smtp, lmtp, pop3, imap and maildirsync over ssh, along with rsync/unison -- that cover a lot of use-cases already).

[rakoo]

Regarding heliotrope: wmorgan has left the field a long time ago to our great despair. He did start heliotrope, which I hacked a bit because it looked cool. I even started a heliotrope-to-imap bridge [0]. After a while the community decided to create a common repository to host them, at which time I abandoned heliotrope because its client was still too buggy and sup was already working very well, and I needed a working MUA.

So the current state is: heliotrope kind of works, the client a little less, we are now fully working on sup. If you want to hack on heliotrope though, feel free to ask -- but there will most likely be no code from me.

Sup, on the other hand, works like a charm ! Visit us at supmua.org !

[0] https://github.com/rakoo/imaptrope

[e12e]

I think I'd probably gravitate more towards notmuch and friends, if I were to use a (in notmuch's case, almost) "ready to go" mua. However, I've yet to find a mua that's simple enough, and also does what I want (Steve Kemp's lumail is another interesting project[1]).

So far, the back of my envelope contains clojure, or possibly something else[2] that is pleasant to code in and feasible to both get to run (well) on Android and in the console, possibly web and/or desktop (GUI, that is -- not a great priority for me, but "advanced" features such as displaying image attachments in-line could be nice -- and is a natural fit for Android anyway), and a sync (possibly push) solution.

It's in the sync part, that heliotrope and jmap come in -- mostly as an alternative to either making my own, or just trying to shoe-horn everything into couchdb/puchdb etc.

Personally I don't really need IMAP (as I control both the server and the client), and I'm unsure if it's worth the effort; maybe with some clever hacks like sticking some meta-data in "special" mail-folders...

Other than that, I suppose caldav/carddav can handle contacts (or perhaps make an embeddable ldap-thing... but like imap it sounds like overkill...) -- the only remaining problem is quick search, which means good full-text search, which means multi-lingual stemming etc... mostly I'm thinking the server should do the indexing, and the client should be able to sync both index and content. Tricky part is making it incremental, so I can keep X GB email with full-text search on the server, and not need a significant % of X GB space on the Android device to get off-line access to the last month (or whatever) worth of email along with good search over that subsection...

[1] http://lumail.org/ [2] So far my short-list has clojure (pleasant, start-up time and possibly resources seem to be a (real) issue on Android), kawa scheme (try to keep the interesting stuff in somewhat "standard" scheme, either use kawa scheme everywhere, or try to stradle two scheme implementations...) and kotlin (it's a better java, but not sure if I'd call it pleasant).

[rakoo]

You must be aware that notmuch is only the search backend, and for a full MUA you need frontends. I believe the official one is the Emacs one, so it should be fairly usable. There's also a web one [0] you should be able to play with.

Another contender in the space (label- and search-centric) is mu and its ui, mu4e [1]. Something else to have in mind.

Now if you want something that works on desktop and mobile, something worth a look would be using SQLite and its built-in full-text search... see how far you can go with that. SQLite is available pretty much everywhere, Android even allows full-text search. Now what you have to do is synchronize SQLite dbs. It "shouldn't" be too hard to remove old emails from the db so you can keep X MB worth of it. You can even shoehorn it into couchbase-lite [3][4] so that sync is automagically taken care of.

JMAP looks cool (definitely more interesting to implement than IMAP) but it seems to be more a query API than a sync API, although there are facilities to "get changes since last time" (a HUGE improvement from IMAP as deployed everywhere). OTOH if you can shoehorn it into couchbase-lite, you can use a generic sync protocol that can be used for other things too (caldav/carddav).

Heck, you've piqued my curiosity, I see something doable here. I'd love to hear more. I might even hack something just for fun.

[0] https://bitbucket.org/wuzzeb/notmuch-web

[1] http://www.djcbsoftware.nl/code/mu/mu4e.html

[2] https://github.com/couchbase/couchbase-lite-android

[3] https://github.com/couchbase/couchbase-lite-ios

[e12e]

Hm, we're too deep it seems. So replying to myself.

> You must be aware that notmuch is only the search backend, and for a full MUA you need frontends.

Absolutely. I tried to imply that with my wry parenthesis; but it's absolutely worth pointing out clearly to unwary readers. In no way is it fair to either notmuch or sup to compare the two as equals.

I'd probably lean towards mutt-kz[mk] for an out-of-box "notmuch" mua (but... mutt. Meh ;-) There's also "alot"[a].

> Another contender in the space (label- and search-centric) is mu and its ui, mu4e [1]. Something else to have in mind.

Right. See also:

http://dev.gentoo.org/~tomka/mail.html

Recently discussed on hn:

https://news.ycombinator.com/item?id=8519643

> Now if you want something that works on desktop and mobile, something worth a look would be using SQLite and its built-in full-text search... see how far you can go with that. SQLite is available pretty much everywhere, Android even allows full-text search. Now what you have to do is synchronize SQLite dbs. It "shouldn't" be too hard to remove old emails from the db so you can keep X MB worth of it. You can even shoehorn it into couchbase-lite [3][4] so that sync is automagically taken care of.

I've considered sqlite for some of these reasons. But couchbase-lite != sqlite, right? (Or does it use sqlite in a meaningful way; ie: can/should one use sql to interface with the stored data?). Btw, looks like you're off-by-one, in your references ;-)

If using sqlite, there are a couple of schemas one might use for inspiration, such as dbmail:

http://dbmail.org/dokuwiki/lib/exe/fetch.php/dbmail-er-model...

Or archiveopteryx:

http://archiveopteryx.org/db/schema

The main sticking point, is do we really want(need) to re-index everything everywhere, how do we transparently do search local-first, while supporting hits from the server along with fetching hits/mails that are missing locally (what k9 calls "cloud search") - how do we consolidate/sync data (the two hard things in computer science is caching and naming things...).

I'm not entirely convinced sqlite+built-in full text search is the best approach (I envision a useful search across some gbs of mailing list threads -- not convinced about the ranking -- but I could very well be the victim of premature optimization. And I'm a little wary of abandoning maildir for storage (on the server) -- but that might be useful anyway.

> JMAP looks cool (definitely more interesting to implement than IMAP) but it seems to be more a query API than a sync API, although there are facilities to "get changes since last time" (a HUGE improvement from IMAP as deployed everywhere).

Yes, that's pretty much what I gathered from the heliotrope story, that syncing was a bit of a mess.

> OTOH if you can shoehorn it into couchbase-lite, you can use a generic sync protocol that can be used for other things too (caldav/carddav).

Exactly. All the hard work done! For free! But seriously, couchdb was born from the ashes of lotus notes, and at least in spirit it was made for this kind of stuff... so couchdb sync, and some kind of half-assed search might be the way to go (on the server, elastic-search would probably work fine... not sure about on something like Android).

> Heck, you've piqued my curiosity, I see something doable here. I'd love to hear more. I might even hack something just for fun.

Great :-) If you do, please feel free to drop me an email (see profile).

[mk] https://github.com/karelzak/mutt-kz [a] https://github.com/pazz/alot

[robn_fastmail]

> Is the code on: http://jmap.io/server.html actual code?

No, just pseudo-code.

Right now we don't have a lot of real JMAP code. FastMail's implementation technically isn't JMAP. To write JMAP we took our current protocol and filed off a lot of the pointy edges. We're working to update our own implementation, and we're also working on open-source reference servers and clients.

There's a mailing list just starting here:

  https://groups.google.com/forum/#!forum/jmap-discuss

You might like to sign up and lurk there. I'll be posting to it soon (maybe tonight) to get the ball rolling on a few things.

[e12e]

Thanks, and for those, like me, that want to sign up with a regular mail account (say, like a fastmail account;) -- one can do that via the web at:

https://groups.google.com/forum/#!forum/jmap-discuss/join (ie: group-url+/join), or by emailing <groupname, spaces replaced with dashes>[e-mail].

The [ed:first, doh!] I tried (make sure you log out of google's estates first) -- the second I haven't tried, but works according to: http://webapps.stackexchange.com/questions/13508/how-can-i-s...

Note, that if you send a subscribe email, you'll be subscribing the from-email in the mail you send (I usually subscribe with unique addresses to lists and accounts, so that I can more easily see which are harvested/given away for spam abuse. So far linked-in, and adobe are top (the latter presumably due to the big account leak) -- and that's a bit of a hassle as all email clients suck ;-).