14 ms·

JMAP: A modern, open email protocol

307 points by okket 7y ago

cvwright 7y ago
This is very exciting! It's been a long time coming. Should we take this IETF blog post as an indication that the standardization work is almost done?
- tialaramex 7y ago
  The core work is done, yes, draft-ietf-jmap-core-17 and draft-ietf-jmap-mail-16 [edit: fixed draft name] are in the RFC editor's queue, how long it takes to get through that queue can depend on a lot of variables. At the end it goes to "AUTH48" which is notionally 48 hours long but a few weeks is more likely in practice, and then it gets cut a number and becomes an RFC. The Working Group still has open items, including calendaring (because people never can build a mail system that doesn't involve calendaring for some reason), handling "read receipt" type features and because this is Current Year a mechanism to involve WebSockets. Either those will eventually also be polished into standards, or they'll be abandoned at some point and undelivered.
butz 7y ago
Does it solve SPAM problem?
- jolmg 7y ago
  I haven't read JMAP, but I don't think that's the problem it's tackling. Also, I think SPAM is as solved as it can be with blacklists, heuristics-based filtering software like spamassasin, and personal filtering with sieve scripts. What else would anyone suggest?
  - dcbadacd 7y ago
    Spam could be half-fixed with forcing DKIM, SPF, DMARC and TLS. The very least there would be no impersonation of other domain names (filtering the rest into a spam box will become much easier after that) and insecure transportation then.
    - ahje 7y ago
      How would sender authentication solve the problem? A large amount of spam is sent from throwaway domains with SPF and DKIM in place, and another large part of it is sent through hijacked web sites and email accounts.
      - dcbadacd 7y ago
        As I have said, it would very least avoid spam looking real from real domains, which is half of the issue. The throwaway part could be fixed by making spam illegal and actually cracking down on it.
    - tracker1 7y ago
      Simpler would be a callback mechanism that required at least a domain cert with TLS.. Server A => Server B : hey, I have a message for X from Y MessageId: Z SingleUseKey: K Server B disconnect Server B => DNS Entry for Y's domain Server B : hey, I want message ID: Z, Key: K Then you need not only DKIM, SPF, etc, but you need a server that responds to inbound requests to pick up an outbound mail configured and setup on the correct port.
  - Skunkleton 7y ago
    I handle spam by handing a unique email address to every entity that requests my address (domain wildcard). What would be better is if there was an initial "hello" where some entity requested permission to send me email, and I could approve, deny, or even revoke in the future. Basically, the issue is that senders cannot be reliably identified. If this were fixed, then spam filtering would be trivial.
  - acct1771 7y ago
    GPG exchange with trusted personal and commercial contacts being as easy (UX) to add to your keychain as adding someone into the contacts of your phone.
- detaro 7y ago
  Completely different part of e-mail (client to server), so no.
- toomim 7y ago
  Nope, that needs to be solved in SMTP. Unfortunately, JMAP only replaces IMAP/POP. I have personally been working on a new protocol that replaces both IMAP and SMTP. It's not ready yet, but the solution turns out to be quite elegant and I have great hope that it will work in the future.
  - nfoz 7y ago
    Cool, looking forward to the "Show HN" for your proposal!
jwr 7y ago
I clicked on this with a lot of hope — alas, this only seems to address the "mailbox access" part of E-mail. I think that part actually works fairly well today (not optimally, but well enough in practice). The part that really needs fixing is SMTP.
- Aissen 7y ago
  It actually addresses email submission, even if it doesn't cover server-to-server SMTP.
- jolmg 7y ago
  > I think that part actually works fairly well today (not optimally, but well enough in practice). I haven't done much with IMAP, but I did setup a watcher for my mailboxes that uses the IDLE extension. I consider it a flaw that I need to create a separate connection, each needing their own session, for each folder I want to watch simultaneously. Servers understandably limit the amount of simultaneous connections you can have, so that limits the amount of folders you can watch simultaneously. I don't know if JMAP fixes that, and I don't know if I'd prefer JMAP over IMAP as a protocol, but there are things that could be better with IMAP. > The part that really needs fixing is SMTP. What's wrong with SMTP?
  - hsk823 7y ago
    Being unauthenticated as a default certainly doesn't jive with modern security practices.
    - jolmg 7y ago
      SMTP is the protocol that's used to route email between servers. How is Fastmail supposed to authenticate with Gmail or Yahoo with Hotmail? Better yet, how is a new mail server in the internet supposed to authenticate with all existing mail servers? Really, authentication for all uses of SMTP doesn't make sense.
      - closeparen 7y ago
satyanash 7y ago
If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. That just leaves us with SMTP really. While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP).
- verisimilitudes 7y ago
  How disconcerting. >If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. IRC and FTP come to mind, but yes. It's as if email's being attacked at all angles, lately. >While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP). Using HTTP is a bad thing, I think, because it's a complex protocol and it's entirely unnecessary; JSON is a poor, ad-hoc format that isn't optimal for parsing. I don't believe developers ''prefer'' any of this so much as it's being forced on them. You can really only define things rigidly if you want to make much in the way of guarantees. Any system held together by conventions can have those conventions violated and this is a harrowing sign of things to come.
  - jolmg 7y ago
    > IRC and FTP come to mind They're niche now, though. HTTP and email protocols are probably the only open protocols that almost everyone uses. There's ssh, but it's also arguably niche in comparison.
  - groovybits 7y ago
    > IRC and FTP IRC and FTP have widely used secure counterparts. Meanwhile, STARTTLS did not gain the traction that everyone hoped it would. Edit: Additionally, we have secure working replacement protocols for IRC and FTP (such as Matrix and SSH/SCP).
    - 7y ago
ocdtrekkie 7y ago
One of the things I particularly recall reading is FastMail devs explaining that the standardization process led to changes and improvements. (Even their about page says that "JMAP was built by the community, and continues to improve via the IETF standardization process.") Really thrilled the FastMail team is working on this, and doing it in the way that changes to mail should be handled: Going through proper Internet standards bodies. It's in stark contrast to AMP4Email, which is being implemented by Google wholly without respect to Internet standards.
- tialaramex 7y ago
  The IETF's standardisation process almost can't help but improve whatever it is you're trying to standardize. Not only are you being shepherded by peers with expertise in whatever corner of networking you're excited about (the Area Directors for whichever Area your Working Group was assigned to) but you're obliged to put up with anyone who cares to offer an opinion mailing it in. Looking for consensus isn't a good way to run a restaurant kitchen, but it may be the best possible way to agree network standards. Even when contributors say something you believe to be completely stupid figuring out how to put into words exactly why they're wrong is likely to be instructive, and as often as not they're not /quite/ as wrong as you first thought. For example the TLS Working Group is polishing up a document telling people to cut it out with the TLS 1.0 after all these years and get to something at least vaguely modern like ten year old TLS 1.2 instead, (once upon a time named the diediedie draft, these days it has a more respectable name). Martin Rex offered the opinion that TLS 1.2 is _worse_ than TLS 1.0 and 1.1 because it doesn't smash SHA1 and MD5 together to produce a single hash. He reasons that if, somehow, SHA1 is broken enough to allow a preimage attack, TLS 1.0 is fine, whereas TLS 1.2 with SHA1 is now broken. Of course people said Martin is barking up the wrong tree. But much more importantly they took another look at their document, it didn't actually _say_ you should implement SHA-256 when you upgrade to TLS 1.2, but they all agreed you should do that, so probably the document wants to spell that out...
  - wmf 7y ago
    JMAP is still young; just wait until a plethora of non-interoperable optional extensions get added.
veritas_veritad 7y ago
automatic markdown formatting in all emails please!
westurner 7y ago
What are the optimizations in JMAP that make it faster than, say, Solid? Solid is built on a bunch of W3C Web, Security, and Linked Data Standards; LDP: Linked Data Protocol, JSON-LD: JSON Linked Data, WebID-TLS, REST, WebSockets, LDN: Linked Data Notifications. [1][2] Different worlds, I suppose. There's no reason you couldn't represent RFC5322 data with RDF as JSONLD. There's now a way to do streaming JSON-LD. LDP does paging and querying. Solid supports pubsub with WebSockets and LDN. It may or may not (yet?) be as efficient for synchronization as JMAP, but it's definitely designed for all types of objects with linked data web standards; and client APIs can just parse JSON-LD. [1] https://github.com/solid/information#solid-specifications https://github.com/solid/information#solid-specifications [2] https://github.com/solid/solid-spec/issues/123 https://github.com/solid/solid-spec/issues/123 "WebSockets and HTTP/2" SSE (Server-Side Events) https://jmap.io/ https://jmap.io/ JMAP: JSON Meta Application Protocol https://en.wikipedia.org/wiki/JSON_Meta_Application_Protocol https://en.wikipedia.org/wiki/JSON_Meta_Application_Protocol Is there a OpenAPI Specification for JMAP? There are a bunch of tools for Swagger / OpenAPIs: DRY interactive API docs, server implementations, code generators: https://swagger.io/tools/open-source/ https://swagger.io/tools/open-source/ https://openapi.tools/ https://openapi.tools/ Does JMAP support labels; such that I don't need to download a message and an attachment and mark it as read twice like labels over IMAP? How does this integrate with webauthn; is that a different layer? (edit) Other email things: openpgpjs; Web Key Directory /.well-known/openpgpkey/*; if there's no webserver on the MX domain, you can use the ACME DNS challenge to get free 3-month certs from LetsEncrypt. https://wiki.gnupg.org/WKD https://wiki.gnupg.org/WKD
- dragonne 7y ago
  > There's no reason you couldn't represent RFC5322 data with RDF as JSONLD. There's now a way to do streaming JSON-LD. Is there a reason you'd want to? I clicked all your links but I still have no idea what Solid is.
  - WhatIsDukkha 7y ago
    Here's another link to click - https://en.wikipedia.org/wiki/Solid_(web_decentralization_project) https://en.wikipedia.org/wiki/Solid_(web_decentralization_pr...
jerk-off 7y ago
I don't know if I want to find out what the J stands for...
voidcommonstock 7y ago
There is so much NIH going on in this protocol, it's as if the authors we're completely unaware of modern HTTP API design. They're not just doing IMAP over http, they invented their own error bodies, schema's , negotiation and RPC.
- greggyb 7y ago
  I think their goal is to have transport layer be a pluggable subsystem, divorced from their request-response protocol. They even essentially say that HTTP is not necessary to their protocol, so I think it's pretty apparent that HTTP is a utilitarian choice, but they're not trying to build email-over-http.
  - specialist 7y ago
    ”pluggable subsystem” SOAP had same rationalization.
upofadown 7y ago
Article uses the word "modern" 5 times, including in the title. Sort of a pet peeve of mine for this sort of thing. New does not imply better. Article also mentions that JSON is used...
- afiori 7y ago
  What drawbacks do you see in JSON here? For machine to machine communication it is a pretty good serialization format I would say (It is not great for many other things, but this sound like its strong point)
  - upofadown 7y ago
    It seemed to me that the article was only using the fact of JSON use as more evidence of modernness. It implied that JSON didn't map that well into their problem space but they overcame.
    - afiori 7y ago
      In a sense they are right. Modernness in the sense that it is a well understood format and not a DSL with non-trivial semantics and parsing.
popzq 7y ago
Unpopular prediction: Gmail will never implement JMAP, so it's already dead in the water.
- graffitici 7y ago
  But someone can write a proxy that exposes Gmail as a JMAP endpoint?
  - rakoo 7y ago
    There already is one, written by the people behind JMAP even, with a public demo instance at https://proxy.jmap.io/ https://proxy.jmap.io/ (don't use the demo with your own credentials of course, host it yourself)
- ocdtrekkie 7y ago
  Why wouldn't Google implement JMAP? Interestingly enough JMAP adds support for Gmail-specific behaviors like labels, which IMAP lacks. This would allow other apps and services to better integrate with Gmail's quirky behavior, improving the experience for Gmail users.
  - lucideer 7y ago
    IMAP doesn't lack Gmail's "labels", Gmail just never bothered implementing their labels as IMAP labels, leading to every IMAP client requiring horrible hacks to work around Gmail's inane implementation. Google are unlikely to implement JMAP for the same reason they've: - ignored pleas to implement IMAP properly going back to its inception - have IMAP disabled by default for new users, and for most corporate users (requiring a GSuite admin to explicitly enable IMAP if employees want to access their corporate email with a client). Google benefit massively from people not using IMAP clients and being forced into their product UIs. That said, I wouldn't call it dead in the water for this reason. Google's tactics here have reduced the overall usage of IMAP clients, but they also serve as strong motivation for that small niche of users to move away from Gmail.
- cotelletta 7y ago
flukus 7y ago
Looking at the request it contains properties like collapseThreads and sort, moving this sort of functionality server side is a regression. This is an API for hosted services, it's disingenuous to compare it to imap.
- crest 7y ago
  Do you see anything that should (or could) be done via IMAP but not via JMAP? Adding support for higher level operations to the protocol can be worth the complexity if it removes network roundtrips. Not everyone is lucky enough to have a reliable, fast, low latency link to his IMAP server.
  - flukus 7y ago
    > Not everyone is lucky enough to have a reliable, fast, low latency link to his IMAP server. This is a protocol from the 80's, I'm sure it doesn't require anything we'd consider a fast connection today, latency may have changed though, mail servers used to be geographically closer. > Adding support for higher level operations to the protocol can be worth the complexity if it removes network roundtrips. It also benefits SaaS providers by having the complexity on their end and potentially limits apps. In my example of "collapseThreads" why does this need to be an option at all instead of something like "parentId" and leaving it up to the client? More features also means more ways to abuse them, imagine google saying "yes we support JMAP in gmail" then ignoring certain features.
    - afiori 7y ago
      > This is a protocol from the 80's, I'm sure it doesn't require anything we'd consider a fast connection today, But it does require long lasting stable connections, which is what you want to avoid on a mobile that tries to connect for only a few second at a time and the go back to low-power mode.
xvilka 7y ago
Hopefully Microsoft Exchange protocol will become a thing of a past now. It is always the biggest problem of Linux desktop integration in Windows-only corporate ecosystem.
sjellis 7y ago
Getting a FastMail subscription over a decade ago really has been one of the best tech decisions that I ever made. They are a great mail provider, and I am very happy that my money helps fund work like JMAP.
Nasreddin_Hodja 7y ago
https://jmap.io/#push-mechanism https://jmap.io/#push-mechanism JMAP going to use rfc8030 push for mobile and EventSource (kind of http long polling) for desktop clients, as I understood. I don't like that idea, it's even worse than IMAP4 IDLE. Why not just WebSockets for mobile and desktop clients?
RZTHsY5jlFA7 7y ago
Almost all email clients are no longer actively developed. Hardly anyone is going to implement it.

307 points by okket 7y ago

This is very exciting! It's been a long time coming. Should we take this IETF blog post as an indication that the standardization work is almost done?

tialaramex 7y ago
The core work is done, yes, draft-ietf-jmap-core-17 and draft-ietf-jmap-mail-16 [edit: fixed draft name] are in the RFC editor's queue, how long it takes to get through that queue can depend on a lot of variables. At the end it goes to "AUTH48" which is notionally 48 hours long but a few weeks is more likely in practice, and then it gets cut a number and becomes an RFC. The Working Group still has open items, including calendaring (because people never can build a mail system that doesn't involve calendaring for some reason), handling "read receipt" type features and because this is Current Year a mechanism to involve WebSockets. Either those will eventually also be polished into standards, or they'll be abandoned at some point and undelivered.

butz 7y ago

Does it solve SPAM problem?

jolmg 7y ago
I haven't read JMAP, but I don't think that's the problem it's tackling. Also, I think SPAM is as solved as it can be with blacklists, heuristics-based filtering software like spamassasin, and personal filtering with sieve scripts. What else would anyone suggest?
- dcbadacd 7y ago
  Spam could be half-fixed with forcing DKIM, SPF, DMARC and TLS. The very least there would be no impersonation of other domain names (filtering the rest into a spam box will become much easier after that) and insecure transportation then.
  - ahje 7y ago
    How would sender authentication solve the problem? A large amount of spam is sent from throwaway domains with SPF and DKIM in place, and another large part of it is sent through hijacked web sites and email accounts.
    - dcbadacd 7y ago
      As I have said, it would very least avoid spam looking real from real domains, which is half of the issue. The throwaway part could be fixed by making spam illegal and actually cracking down on it.
  - tracker1 7y ago
    Simpler would be a callback mechanism that required at least a domain cert with TLS.. Server A => Server B : hey, I have a message for X from Y MessageId: Z SingleUseKey: K Server B disconnect Server B => DNS Entry for Y's domain Server B : hey, I want message ID: Z, Key: K Then you need not only DKIM, SPF, etc, but you need a server that responds to inbound requests to pick up an outbound mail configured and setup on the correct port.
- Skunkleton 7y ago
  I handle spam by handing a unique email address to every entity that requests my address (domain wildcard). What would be better is if there was an initial "hello" where some entity requested permission to send me email, and I could approve, deny, or even revoke in the future. Basically, the issue is that senders cannot be reliably identified. If this were fixed, then spam filtering would be trivial.
- acct1771 7y ago
  GPG exchange with trusted personal and commercial contacts being as easy (UX) to add to your keychain as adding someone into the contacts of your phone.
detaro 7y ago
Completely different part of e-mail (client to server), so no.
toomim 7y ago
Nope, that needs to be solved in SMTP. Unfortunately, JMAP only replaces IMAP/POP. I have personally been working on a new protocol that replaces both IMAP and SMTP. It's not ready yet, but the solution turns out to be quite elegant and I have great hope that it will work in the future.
- nfoz 7y ago
  Cool, looking forward to the "Show HN" for your proposal!

jwr 7y ago

I clicked on this with a lot of hope — alas, this only seems to address the "mailbox access" part of E-mail. I think that part actually works fairly well today (not optimally, but well enough in practice). The part that really needs fixing is SMTP.

Aissen 7y ago
It actually addresses email submission, even if it doesn't cover server-to-server SMTP.
jolmg 7y ago
> I think that part actually works fairly well today (not optimally, but well enough in practice). I haven't done much with IMAP, but I did setup a watcher for my mailboxes that uses the IDLE extension. I consider it a flaw that I need to create a separate connection, each needing their own session, for each folder I want to watch simultaneously. Servers understandably limit the amount of simultaneous connections you can have, so that limits the amount of folders you can watch simultaneously. I don't know if JMAP fixes that, and I don't know if I'd prefer JMAP over IMAP as a protocol, but there are things that could be better with IMAP. > The part that really needs fixing is SMTP. What's wrong with SMTP?
- hsk823 7y ago
  Being unauthenticated as a default certainly doesn't jive with modern security practices.
  - jolmg 7y ago
    SMTP is the protocol that's used to route email between servers. How is Fastmail supposed to authenticate with Gmail or Yahoo with Hotmail? Better yet, how is a new mail server in the internet supposed to authenticate with all existing mail servers? Really, authentication for all uses of SMTP doesn't make sense.
    - closeparen 7y ago

satyanash 7y ago

If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. That just leaves us with SMTP really. While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP).

verisimilitudes 7y ago
How disconcerting. >If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. IRC and FTP come to mind, but yes. It's as if email's being attacked at all angles, lately. >While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP). Using HTTP is a bad thing, I think, because it's a complex protocol and it's entirely unnecessary; JSON is a poor, ad-hoc format that isn't optimal for parsing. I don't believe developers ''prefer'' any of this so much as it's being forced on them. You can really only define things rigidly if you want to make much in the way of guarantees. Any system held together by conventions can have those conventions violated and this is a harrowing sign of things to come.
- jolmg 7y ago
  > IRC and FTP come to mind They're niche now, though. HTTP and email protocols are probably the only open protocols that almost everyone uses. There's ssh, but it's also arguably niche in comparison.
- groovybits 7y ago
  > IRC and FTP IRC and FTP have widely used secure counterparts. Meanwhile, STARTTLS did not gain the traction that everyone hoped it would. Edit: Additionally, we have secure working replacement protocols for IRC and FTP (such as Matrix and SSH/SCP).
  - 7y ago

ocdtrekkie 7y ago

One of the things I particularly recall reading is FastMail devs explaining that the standardization process led to changes and improvements. (Even their about page says that "JMAP was built by the community, and continues to improve via the IETF standardization process.") Really thrilled the FastMail team is working on this, and doing it in the way that changes to mail should be handled: Going through proper Internet standards bodies. It's in stark contrast to AMP4Email, which is being implemented by Google wholly without respect to Internet standards.

tialaramex 7y ago
The IETF's standardisation process almost can't help but improve whatever it is you're trying to standardize. Not only are you being shepherded by peers with expertise in whatever corner of networking you're excited about (the Area Directors for whichever Area your Working Group was assigned to) but you're obliged to put up with anyone who cares to offer an opinion mailing it in. Looking for consensus isn't a good way to run a restaurant kitchen, but it may be the best possible way to agree network standards. Even when contributors say something you believe to be completely stupid figuring out how to put into words exactly why they're wrong is likely to be instructive, and as often as not they're not /quite/ as wrong as you first thought. For example the TLS Working Group is polishing up a document telling people to cut it out with the TLS 1.0 after all these years and get to something at least vaguely modern like ten year old TLS 1.2 instead, (once upon a time named the diediedie draft, these days it has a more respectable name). Martin Rex offered the opinion that TLS 1.2 is _worse_ than TLS 1.0 and 1.1 because it doesn't smash SHA1 and MD5 together to produce a single hash. He reasons that if, somehow, SHA1 is broken enough to allow a preimage attack, TLS 1.0 is fine, whereas TLS 1.2 with SHA1 is now broken. Of course people said Martin is barking up the wrong tree. But much more importantly they took another look at their document, it didn't actually _say_ you should implement SHA-256 when you upgrade to TLS 1.2, but they all agreed you should do that, so probably the document wants to spell that out...
- wmf 7y ago
  JMAP is still young; just wait until a plethora of non-interoperable optional extensions get added.

veritas_veritad 7y ago

automatic markdown formatting in all emails please!

westurner 7y ago

What are the optimizations in JMAP that make it faster than, say, Solid? Solid is built on a bunch of W3C Web, Security, and Linked Data Standards; LDP: Linked Data Protocol, JSON-LD: JSON Linked Data, WebID-TLS, REST, WebSockets, LDN: Linked Data Notifications. [1][2] Different worlds, I suppose. There's no reason you couldn't represent RFC5322 data with RDF as JSONLD. There's now a way to do streaming JSON-LD. LDP does paging and querying. Solid supports pubsub with WebSockets and LDN. It may or may not (yet?) be as efficient for synchronization as JMAP, but it's definitely designed for all types of objects with linked data web standards; and client APIs can just parse JSON-LD. [1] https://github.com/solid/information#solid-specifications https://github.com/solid/information#solid-specifications [2] https://github.com/solid/solid-spec/issues/123 https://github.com/solid/solid-spec/issues/123 "WebSockets and HTTP/2" SSE (Server-Side Events) https://jmap.io/ https://jmap.io/ JMAP: JSON Meta Application Protocol https://en.wikipedia.org/wiki/JSON_Meta_Application_Protocol https://en.wikipedia.org/wiki/JSON_Meta_Application_Protocol Is there a OpenAPI Specification for JMAP? There are a bunch of tools for Swagger / OpenAPIs: DRY interactive API docs, server implementations, code generators: https://swagger.io/tools/open-source/ https://swagger.io/tools/open-source/ https://openapi.tools/ https://openapi.tools/ Does JMAP support labels; such that I don't need to download a message and an attachment and mark it as read twice like labels over IMAP? How does this integrate with webauthn; is that a different layer? (edit) Other email things: openpgpjs; Web Key Directory /.well-known/openpgpkey/*; if there's no webserver on the MX domain, you can use the ACME DNS challenge to get free 3-month certs from LetsEncrypt. https://wiki.gnupg.org/WKD https://wiki.gnupg.org/WKD

dragonne 7y ago
> There's no reason you couldn't represent RFC5322 data with RDF as JSONLD. There's now a way to do streaming JSON-LD. Is there a reason you'd want to? I clicked all your links but I still have no idea what Solid is.
- WhatIsDukkha 7y ago
  Here's another link to click - https://en.wikipedia.org/wiki/Solid_(web_decentralization_project) https://en.wikipedia.org/wiki/Solid_(web_decentralization_pr...

jerk-off 7y ago

I don't know if I want to find out what the J stands for...

voidcommonstock 7y ago

There is so much NIH going on in this protocol, it's as if the authors we're completely unaware of modern HTTP API design. They're not just doing IMAP over http, they invented their own error bodies, schema's , negotiation and RPC.

greggyb 7y ago
I think their goal is to have transport layer be a pluggable subsystem, divorced from their request-response protocol. They even essentially say that HTTP is not necessary to their protocol, so I think it's pretty apparent that HTTP is a utilitarian choice, but they're not trying to build email-over-http.
- specialist 7y ago
  ”pluggable subsystem” SOAP had same rationalization.

upofadown 7y ago

Article uses the word "modern" 5 times, including in the title. Sort of a pet peeve of mine for this sort of thing. New does not imply better. Article also mentions that JSON is used...

afiori 7y ago
What drawbacks do you see in JSON here? For machine to machine communication it is a pretty good serialization format I would say (It is not great for many other things, but this sound like its strong point)
- upofadown 7y ago
  It seemed to me that the article was only using the fact of JSON use as more evidence of modernness. It implied that JSON didn't map that well into their problem space but they overcame.
  - afiori 7y ago
    In a sense they are right. Modernness in the sense that it is a well understood format and not a DSL with non-trivial semantics and parsing.

popzq 7y ago

Unpopular prediction: Gmail will never implement JMAP, so it's already dead in the water.

graffitici 7y ago
But someone can write a proxy that exposes Gmail as a JMAP endpoint?
- rakoo 7y ago
  There already is one, written by the people behind JMAP even, with a public demo instance at https://proxy.jmap.io/ https://proxy.jmap.io/ (don't use the demo with your own credentials of course, host it yourself)
ocdtrekkie 7y ago
Why wouldn't Google implement JMAP? Interestingly enough JMAP adds support for Gmail-specific behaviors like labels, which IMAP lacks. This would allow other apps and services to better integrate with Gmail's quirky behavior, improving the experience for Gmail users.
- lucideer 7y ago
  IMAP doesn't lack Gmail's "labels", Gmail just never bothered implementing their labels as IMAP labels, leading to every IMAP client requiring horrible hacks to work around Gmail's inane implementation. Google are unlikely to implement JMAP for the same reason they've: - ignored pleas to implement IMAP properly going back to its inception - have IMAP disabled by default for new users, and for most corporate users (requiring a GSuite admin to explicitly enable IMAP if employees want to access their corporate email with a client). Google benefit massively from people not using IMAP clients and being forced into their product UIs. That said, I wouldn't call it dead in the water for this reason. Google's tactics here have reduced the overall usage of IMAP clients, but they also serve as strong motivation for that small niche of users to move away from Gmail.
cotelletta 7y ago

flukus 7y ago

Looking at the request it contains properties like collapseThreads and sort, moving this sort of functionality server side is a regression. This is an API for hosted services, it's disingenuous to compare it to imap.

crest 7y ago
Do you see anything that should (or could) be done via IMAP but not via JMAP? Adding support for higher level operations to the protocol can be worth the complexity if it removes network roundtrips. Not everyone is lucky enough to have a reliable, fast, low latency link to his IMAP server.
- flukus 7y ago
  > Not everyone is lucky enough to have a reliable, fast, low latency link to his IMAP server. This is a protocol from the 80's, I'm sure it doesn't require anything we'd consider a fast connection today, latency may have changed though, mail servers used to be geographically closer. > Adding support for higher level operations to the protocol can be worth the complexity if it removes network roundtrips. It also benefits SaaS providers by having the complexity on their end and potentially limits apps. In my example of "collapseThreads" why does this need to be an option at all instead of something like "parentId" and leaving it up to the client? More features also means more ways to abuse them, imagine google saying "yes we support JMAP in gmail" then ignoring certain features.
  - afiori 7y ago
    > This is a protocol from the 80's, I'm sure it doesn't require anything we'd consider a fast connection today, But it does require long lasting stable connections, which is what you want to avoid on a mobile that tries to connect for only a few second at a time and the go back to low-power mode.

xvilka 7y ago

Hopefully Microsoft Exchange protocol will become a thing of a past now. It is always the biggest problem of Linux desktop integration in Windows-only corporate ecosystem.

sjellis 7y ago

Getting a FastMail subscription over a decade ago really has been one of the best tech decisions that I ever made. They are a great mail provider, and I am very happy that my money helps fund work like JMAP.

Nasreddin_Hodja 7y ago

https://jmap.io/#push-mechanism https://jmap.io/#push-mechanism JMAP going to use rfc8030 push for mobile and EventSource (kind of http long polling) for desktop clients, as I understood. I don't like that idea, it's even worse than IMAP4 IDLE. Why not just WebSockets for mobile and desktop clients?

RZTHsY5jlFA7 7y ago

Almost all email clients are no longer actively developed. Hardly anyone is going to implement it.