FastMail is behind this protocol and from what I've read JMAP has evolved out of their web interface.<p>I've been a happy customer, even though lately I flirted with going back to GSuite for my personal email, but after a trial realized that Gmail does many things well, except for being a good email service. So I went back to FastMail and renewed for another 2 years.<p>Seeing this new protocol is exciting, because JMAP is being standardized at IETF. A breath of fresh air to see a new standard being developed.<p>Also from what I understand JMAP should be friendly for mobile usage. They kept notifications out of it, you're supposed to implement notifications using whatever the mobile platform provides. Interacting via JMAP is via plain HTTP requests, which is super cool.<p>I can totally see myself implementing a simple email client for automating online services. For example if you implement a commenting system for a website, you might want to do replies by email. That would be a cool project for me to try out.<p>I wonder if FastMail exposes JMAP publicly yet. Haven't seen any mentions in their admin or docs thus far.
<i>>JMAP is a REST API so it uses HTTP requests and responses to issue commands and get the results. Almost all requests in JMAP are to the same URL using an HTTP POST to submit a JSON body of “methods”.</i><p>Describing this as REST is really strange. Defining your own operations over an HTTP POST is what SOAP and other RPC style web services do and specifically what REST isn't. But I guess that a lack of a standard behind REST ended up with the term being used for everything.
I really want to see some innovation in the email space. The landscape is like a sea of false promises and dashed dreams. SMTP is one of the bread-and-butters of the internet, yet it just doesn't seem to be moving forward (maybe that's for the best), and no one's building extensions on top of it.<p>Maybe I'm naive in thinking it was possible but we could have avoided this whole "make an account on X messenger so we can talk", if someone had just jammed XMPP and SMTP together.<p>Every few years I'm tempted to try and write a SMTP server (MX) myself but then realize that postfix has been around so long and is the go to choice <i>for a reason</i>. I don't have 20 years of figuring out how X mail server interprets SMTP to be as reliable as postfix. I settled for trying to wrap it[0].<p>[0]: <a href="https://gitlab.com/postmgr/postmgr" rel="nofollow">https://gitlab.com/postmgr/postmgr</a>
The main failure in mail standards is a lack of explicit utf8 clean support lhs@rhs -if this got fixed (it's often called universal acceptance) a lot of things about mail as an ecology would improve.<p>I have view on the spam thing. The whole "your idea will not work because" meme is hugely destructive of innovation in email. It sucks energy and mindshare. It's classic old timer put down.<p>What would (imnsho opinion) have fixed spam is sender pays. I've debated this with a lot of people. We're 50/50 on it. Fifty agree with me, fifty million don't.<p>Jmap is utf8 clean btw.<p>(I used to do email for a living in the eighties when life was simple and bang!chains!worked)
To give some context on why JMAP is relevant today, you might want to read this answer in the conversations FAQ [1]. It basically states that XMPP powered Apps are having trouble fighting against the battery saving software because XMPP is stateful. JMAP, on the other hand, is stateless.<p>As protocols are meant to connect different implementations and bringing more protocols for the same task quickly hurts the interoperability (before bringing some improvements in the long-term), I am skeptical to the effects those new protocols bring to the ecosystem. I am aware that JMAP was born more out of the RESTful requirements of an HTTP based App, but in general, I am wondering where this road will lead us.<p>[1]: <a href="https://github.com/siacs/Conversations#but-why-do-i-need-a-permanent-notification-if-i-use-google-push" rel="nofollow">https://github.com/siacs/Conversations#but-why-do-i-need-a-p...</a>
Last time I looked at IMAP, I was a little peeved that servers didn't accept messages added to the "Outbox" folder and send them, instead requiring that clients talk SMTP and then (or not) save a copy of the same message to the "Sent" folder.<p>Could JMAP replace SMTP as well as IMAP?
The article mentions that JMAP does calendars as well. Anyone have a quick status update on how it compares to CalDav and if it's supported by any of the major calendar clients or servers? I did a quick google and looked at the JMAP site but couldn't find any info.<p>Background for this is that I implemented a calendar client and a calendar server (with SabreDAV) last year and I'm wondering if I should be adding support for JMAP anytime soon.
Post is about JMAP (Fastmail's IMAP/SMTP replacement), by the author of a newish webmail client called Cypht that has just recently implemented support for JMAP. Cool! Keep going!<p><a href="https://cypht.org/" rel="nofollow">https://cypht.org/</a>
Loved this bit:<p>> Internet: Do you think JMAP will really take off?<p>> Me: JMAP is an open, smart, modern, and powerful E-mail protocol, so probably not.
I've started to migrate 18 years of email history to Fastmail, after running my own mail infra for almost 2 decades.<p>I am not impressed. Folders moved in the webinterface show up unmoved in Thunderbird. And vice versa.<p>Sometimes it works, sometimes it doesn't. They're investigating the problem at the moment, but the updates they've given me don't give me much hope.<p>I'm looking at migrating away to another provider that just does plain old imap.
From experience, Exchange's Outlook API ("EWS") is pretty decent. It's XML-SOAP, sure, but there are libraries for it that can be readily used. The only thing they <i>did</i> fuck up is the three different kinds of IDs for an object (esp. confusing when accessing delegated team mailboxes/calendar events) but once you get it how it works, it's straightforward and allows you access to anything from email over calendar to address-book.<p>I just do not know if EWS is an "open standard" that could be replicated by a third party server or if it is only "open documentation" and licensed for Exchange only :(
> JMAP is not designed around a persistent network socket, so it’s perfect for webmail clients that connect, do stuff, then disconnect (which is exactly NOT how IMAP is supposed to be used)<p>WTF? So, webmail was limited by the fact that it was running in a browser and thus had to use HTTP, which has semantics that don't really fit the needs of an email access protocol. Now, we do have stuff like websockets that would make it possible to run a protocol from the webmail client that actually fits the needs, and instead people invent a new protocol that inherently doesn't match the needs of the application?
Very interesting:<p><i>> JMAP is not designed around a persistent network socket, so it’s perfect for webmail clients that connect, do stuff, then disconnect</i><p>This would allow implementing JMAP in serverless architecture, e.g. self hosting on AWS lambda. That should be <i>very</i> cheap and significantly lower the barrier to self hosting (not needing to manage a box, just providing aws credentials).<p>Think of what it takes to truly decentralise email. There are technical hurdles, but also some fundamental ones:<p>- other providers mark you as spam because you’re unknown<p>- you need an always on server to actually get your incoming mail<p>This would at least solve the second problem. If we can develop a product like mailinabox (Which has its flaws but it’s the right idea), but instead of asking for a fresh vm, it just asks for aws credentials, that could be pretty solid.<p>Hopefully one day we can give the people back their control over their means of communication. This seems like a step in the right direction!
So, you say that it doesn't maintain a persistent connection, but that poses a problem - it needs a way to do push notifications still I assume? Those need an open socket somewhere - does JMAP allow for it or does it make you rely on a 3rd party?
I recently thought about email being based on such an old standard and then I wondered if maybe it didn't matter anymore, because most of the web is moving to gmail, and my guess is (and somebody please correct me) that when I send an email from gmail to gmail, that no actual SMTP is involved? I'm assuming that they have some internal protocol that is just adapter'd to "Email" at the very end?