4 ms·

> 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 l

> 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/ 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 12y ago
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 https://github.com/sup-heliotrope/heliotrope [ed: I suppose the canonical repo is https://github.com/wmorgan/heliotrope https://github.com/wmorgan/heliotrope -- but afaik they are the same (and both appear dead)] Is the code on: http://jmap.io/server.html 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).
- robn_fastmail 12y ago
  > Is the code on: http://jmap.io/server.html 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 12y ago
    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 https://groups.google.com/forum/#!forum/jmap-discuss/join (ie: group-url+/join), or by emailing <groupname, spaces replaced with dashes>+subscribe@googlegroups.com. 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-subscribe-to-a-google-mailing-list-with-a-non-google-e-mail-address 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 ;-).
- rakoo 12y ago
  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 https://github.com/rakoo/imaptrope
  - e12e 12y ago
    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/ 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).

e12e 12y ago

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 https://github.com/sup-heliotrope/heliotrope [ed: I suppose the canonical repo is https://github.com/wmorgan/heliotrope https://github.com/wmorgan/heliotrope -- but afaik they are the same (and both appear dead)] Is the code on: http://jmap.io/server.html 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).

robn_fastmail 12y ago
> Is the code on: http://jmap.io/server.html 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 12y ago
  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 https://groups.google.com/forum/#!forum/jmap-discuss/join (ie: group-url+/join), or by emailing <groupname, spaces replaced with dashes>+subscribe@googlegroups.com. 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-subscribe-to-a-google-mailing-list-with-a-non-google-e-mail-address 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 ;-).
rakoo 12y ago
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 https://github.com/rakoo/imaptrope
- e12e 12y ago
  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/ 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).