6 ms·

I was hoping to find at least some mention of JMAP [0] in this, but sadly, this is IMAP-only. While I an happy for this product, I'm disappointed at no converge

I was hoping to find at least some mention of JMAP [0] in this, but sadly, this is IMAP-only. While I an happy for this product, I'm disappointed at no convergence toward something more modern than IMAP which I've only heard derision towards by implementors. [0] https://en.m.wikipedia.org/wiki/JSON_Meta_Application_Protocol https://en.m.wikipedia.org/wiki/JSON_Meta_Application_Protoc...

Thaxll 4y ago
Who is actually using JMAP? I never heard of that, what's the point of implementing something that is not used at all.
- aloisdg 4y ago
  This is an chicken-egg problem.
- erk__ 4y ago
  It is used by Fastmail (who was also developers of the standard) I think it is not a great idea to say that it is not a good idea to not implement things that no one uses, because that is a certain way to not make more people use it. There are some servers that support it such as Stalwart [0], though I don't know about any older servers and/or clients that support it well. [0]: https://github.com/stalwartlabs/jmap-server https://github.com/stalwartlabs/jmap-server
  - tankerkiller125 4y ago
    Until Dovecot and systems like it support JMAP, I don't see it gaining the critical mass it needs to succeed.
    - lucideer 4y ago
      Well I can't see Dovecot devs deciding to implement it if they keep reading comments like this dissuading the effort...
      - catiopatio 4y ago
        What advantage would they gain by implementing it?
        lucideer 4y ago
        There's three considerations (a) is IMAP good / sufficient / fit for purpose (b) if not, is there a better alternative available (c) if there is, is it worth the development effort to support it. If we assume the answers to (a) & (b) are NO & JMAP, then the benefits are included in those answers & only question remaining is (c). The person I was replying to seemed to be only arguing that the answer to (c) is NO.
        tracker1 4y ago
        (a) No (b) JMAP (c) Long term, probably.
    - e12e 4y ago
      Cyrus is a system like dovecot?
- StalwartLabs 4y ago
  Mostly Fastmail but there are also a few open-source projects that support it https://jmap.io/software.html https://jmap.io/software.html
- lucideer 4y ago
  > what's the point of implementing something that is not used at all If this question made any sense we would never make anything new at all. How do you think new things get started?
mxuribe 4y ago
With all this recent attention on HN around imap, smtp, mail servers and the like....i also expected something more modern to be announced - either JMAP or somrthing else altogether. I'm not disappointed because the more, the merrier...but nowadays with so much of my time in the matrix world, i somewhat xpected to start hearing anouncements of alternatives to email.
- ThePhysicist 4y ago
  My prediction is that e-mail will still be around in 10 years, and Matrix will be mostly abandoned, because e-mail is mostly centered around protocols, whereas Matrix is mostly centered around specific libraries and clients (in my opinion). You can already see Matrix crumble under its own complexity, in a few years they will have added so much functionality that it will become impossible for anyone but Element to provide fully-featured client software. IMAP & POP3, by comparison, are so simple and haven't changed in decades, which is why they are so useful.
  - lucideer 4y ago
    My hope is that they're both around (& actively developed & used) in 10 years, but yes: email is much less likely to die than Matrix.
    - ThePhysicist 4y ago
      My prediction is that with further advances in networking, devices will be permanently online and asynchronous communication will become less relevant (because you can always directly reach your peer), so all these fancy E2EE crypto protocols will be replaced with TLS or a similar protocol.
    - Arathorn 4y ago
      I’m not sure you could kill Matrix now even if you wanted to? Heck, given people still run gopher & WAIS & fidonet servers today, so even if everyone runs away from Matrix, it’ll still keep burbling away somewhere :)
mikl 4y ago
Yeah, it’s a shame. IMAP is not a great protocol (to say the least), but jmap is nowhere near critical mass. At present, its not worth the effort to implement for pretty much anyone, so it’s only idealists like Fastmail who’ve done so anyway.
- the_duke 4y ago
  Wasn't JMAP initiated by Fastmail and initially mostly based on their internal implementation.
  - Mailtemi 4y ago
    Initially, the proposition relied on Fastmail protocol, which was/is superior to IMAP. It was pleasing that standardization began, as MS Activesync charged a few dollars per user just for the protocol. Even the Apache James mail server supported it as a draft. Despite becoming a standard make it better , but lost momentum. Still hope at least both will add push notification to 3th party apps. And a BIG hope for https://stalw.art/ https://stalw.art/
    - NetOpWibby 4y ago
      +1 for Stalwart
- lucideer 4y ago
  > its not worth the effort to implement for pretty much anyone, so it’s only idealists like Fastmail who’ve done so anyway. Worth mentioning that Fastmail use an open source backend: Cyrus[0] - which started adding JMAP support in 2015 (though I suspect that was Fastmail devs contributing the feature). [0] http://www.cyrusimap.org/ http://www.cyrusimap.org/
  - mikl 4y ago
    Yeah, but the target of Proton’s efforts with Gluon is the clients, since Gluon is part of the ProtonMail Bridge software. Their primary targets are Microsoft Outlook, Apple Mail and Thunderbird, none of which speak JMAP at present. So Proton has very little to gain from implementing JMAP, since only niche clients support it at this point. Classic chicken and egg problem, unfortunately.
catiopatio 4y ago
There’s no clear value proposition for a JSON-over-HTTP replacement for IMAP-over-TCP, especially for clients and servers that have already implemented IMAP. Why would dovecot want to add an entire HTTP server just to reproduce what they already have, with more layers of poorly fit abstraction, despite there being no significant mail clients that require it?
- calvinmorrison 4y ago
  JSON happens to be over JSON and HTTP, IMAP is over TCP and the IMAP protocol. both of those pieces are a relatively small amount of code to parse messages from rather than what to do with said messages. You can transport jmap over whatever you want theoretically.
- Mailtemi 4y ago
  Each JMAP server should include IMAP QRESYNC like functionality at least. Plus the ability to batch JMAP calls. For instance, if you have five folders with IMAP, it might take at least five hops to access them. With JMAP, it could be accomplished in just one call, returning the location of each new email in each folder.
  - alerighi 4y ago
    This really benefits when you first connect a client to a server that has to sync all the mail locally, and partially each time the client starts that has to check all the folders for new messages. But realistically when a client is opened (that is when you turn on the computer till you turn it off, if you turn it off and don't put it to sleep). Also most people has only a few folders, say less than 10.
elric 4y ago
At this point, JMAP is like Duke Nukem Forever or Winds of Winter. Why does email need JSON over HTTP? IMAP might not be the sexiest protocol, but it serves hundreds of millions of users just fine. JMAP, on the other hand, is hardly used, and it doesn't seem to solve any issues that users face, which means demand is never likely to reach critical mass.
- epilys 4y ago
  Because it was designed for webmail frontends, which can communicate with servers from the client side.
- tracker1 4y ago
  Well, if using the system... it makes serialization far less complex in terms of normalization. You can serialize/deserialize through what have become relatively standard libraries for pretty much every language under the sun. This can be utilized in/out of class/record based representations of the data in your language of choice, and acted upon directly. The use of HTTP is as sensible as anything else, as the HTTP actions and paths align relatively well to resource endpoints as well as a text based protocol. The abstractions and libraries available make this easier... if you look at IMAP it's byzantine by comparison.
- kitsunesoba 4y ago
  The biggest issue with IMAP is that writing a quality client for it that works on all possible permutations of the spec (especially with the botched Gmail IMAP implementation in the mix) is a huge, huge pain in the rear which is why there's a dearth of high quality FOSS mail clients… you've got the old standbys like Thunderbird and Claws and that's about it. Newer clients like Geary either die on the vine or get stuck in a somewhat spartan state because making it more full-featured takes knowhow, time, and manpower that's not generally available. On the other hand lots of devs know how to work with JSON-over-HTTP APIs and a lot of modern languages even come with JSON serialization/deserialization out of the box, with makes writing quality clients a lot more accessible to a lot more people.

Thaxll 4y ago

Who is actually using JMAP? I never heard of that, what's the point of implementing something that is not used at all.

aloisdg 4y ago
This is an chicken-egg problem.
erk__ 4y ago
It is used by Fastmail (who was also developers of the standard) I think it is not a great idea to say that it is not a good idea to not implement things that no one uses, because that is a certain way to not make more people use it. There are some servers that support it such as Stalwart [0], though I don't know about any older servers and/or clients that support it well. [0]: https://github.com/stalwartlabs/jmap-server https://github.com/stalwartlabs/jmap-server
- tankerkiller125 4y ago
  Until Dovecot and systems like it support JMAP, I don't see it gaining the critical mass it needs to succeed.
  - lucideer 4y ago
    Well I can't see Dovecot devs deciding to implement it if they keep reading comments like this dissuading the effort...
    - catiopatio 4y ago
      What advantage would they gain by implementing it?
      - lucideer 4y ago
        There's three considerations (a) is IMAP good / sufficient / fit for purpose (b) if not, is there a better alternative available (c) if there is, is it worth the development effort to support it. If we assume the answers to (a) & (b) are NO & JMAP, then the benefits are included in those answers & only question remaining is (c). The person I was replying to seemed to be only arguing that the answer to (c) is NO.
        tracker1 4y ago
        (a) No (b) JMAP (c) Long term, probably.
  - e12e 4y ago
    Cyrus is a system like dovecot?
StalwartLabs 4y ago
Mostly Fastmail but there are also a few open-source projects that support it https://jmap.io/software.html https://jmap.io/software.html
lucideer 4y ago
> what's the point of implementing something that is not used at all If this question made any sense we would never make anything new at all. How do you think new things get started?

mxuribe 4y ago

With all this recent attention on HN around imap, smtp, mail servers and the like....i also expected something more modern to be announced - either JMAP or somrthing else altogether. I'm not disappointed because the more, the merrier...but nowadays with so much of my time in the matrix world, i somewhat xpected to start hearing anouncements of alternatives to email.

ThePhysicist 4y ago
My prediction is that e-mail will still be around in 10 years, and Matrix will be mostly abandoned, because e-mail is mostly centered around protocols, whereas Matrix is mostly centered around specific libraries and clients (in my opinion). You can already see Matrix crumble under its own complexity, in a few years they will have added so much functionality that it will become impossible for anyone but Element to provide fully-featured client software. IMAP & POP3, by comparison, are so simple and haven't changed in decades, which is why they are so useful.
- lucideer 4y ago
  My hope is that they're both around (& actively developed & used) in 10 years, but yes: email is much less likely to die than Matrix.
  - ThePhysicist 4y ago
    My prediction is that with further advances in networking, devices will be permanently online and asynchronous communication will become less relevant (because you can always directly reach your peer), so all these fancy E2EE crypto protocols will be replaced with TLS or a similar protocol.
  - Arathorn 4y ago
    I’m not sure you could kill Matrix now even if you wanted to? Heck, given people still run gopher & WAIS & fidonet servers today, so even if everyone runs away from Matrix, it’ll still keep burbling away somewhere :)

mikl 4y ago

Yeah, it’s a shame. IMAP is not a great protocol (to say the least), but jmap is nowhere near critical mass. At present, its not worth the effort to implement for pretty much anyone, so it’s only idealists like Fastmail who’ve done so anyway.

the_duke 4y ago
Wasn't JMAP initiated by Fastmail and initially mostly based on their internal implementation.
- Mailtemi 4y ago
  Initially, the proposition relied on Fastmail protocol, which was/is superior to IMAP. It was pleasing that standardization began, as MS Activesync charged a few dollars per user just for the protocol. Even the Apache James mail server supported it as a draft. Despite becoming a standard make it better , but lost momentum. Still hope at least both will add push notification to 3th party apps. And a BIG hope for https://stalw.art/ https://stalw.art/
  - NetOpWibby 4y ago
    +1 for Stalwart
lucideer 4y ago
> its not worth the effort to implement for pretty much anyone, so it’s only idealists like Fastmail who’ve done so anyway. Worth mentioning that Fastmail use an open source backend: Cyrus[0] - which started adding JMAP support in 2015 (though I suspect that was Fastmail devs contributing the feature). [0] http://www.cyrusimap.org/ http://www.cyrusimap.org/
- mikl 4y ago
  Yeah, but the target of Proton’s efforts with Gluon is the clients, since Gluon is part of the ProtonMail Bridge software. Their primary targets are Microsoft Outlook, Apple Mail and Thunderbird, none of which speak JMAP at present. So Proton has very little to gain from implementing JMAP, since only niche clients support it at this point. Classic chicken and egg problem, unfortunately.

catiopatio 4y ago

There’s no clear value proposition for a JSON-over-HTTP replacement for IMAP-over-TCP, especially for clients and servers that have already implemented IMAP. Why would dovecot want to add an entire HTTP server just to reproduce what they already have, with more layers of poorly fit abstraction, despite there being no significant mail clients that require it?

calvinmorrison 4y ago
JSON happens to be over JSON and HTTP, IMAP is over TCP and the IMAP protocol. both of those pieces are a relatively small amount of code to parse messages from rather than what to do with said messages. You can transport jmap over whatever you want theoretically.
Mailtemi 4y ago
Each JMAP server should include IMAP QRESYNC like functionality at least. Plus the ability to batch JMAP calls. For instance, if you have five folders with IMAP, it might take at least five hops to access them. With JMAP, it could be accomplished in just one call, returning the location of each new email in each folder.
- alerighi 4y ago
  This really benefits when you first connect a client to a server that has to sync all the mail locally, and partially each time the client starts that has to check all the folders for new messages. But realistically when a client is opened (that is when you turn on the computer till you turn it off, if you turn it off and don't put it to sleep). Also most people has only a few folders, say less than 10.

elric 4y ago

At this point, JMAP is like Duke Nukem Forever or Winds of Winter. Why does email need JSON over HTTP? IMAP might not be the sexiest protocol, but it serves hundreds of millions of users just fine. JMAP, on the other hand, is hardly used, and it doesn't seem to solve any issues that users face, which means demand is never likely to reach critical mass.

epilys 4y ago
Because it was designed for webmail frontends, which can communicate with servers from the client side.
tracker1 4y ago
Well, if using the system... it makes serialization far less complex in terms of normalization. You can serialize/deserialize through what have become relatively standard libraries for pretty much every language under the sun. This can be utilized in/out of class/record based representations of the data in your language of choice, and acted upon directly. The use of HTTP is as sensible as anything else, as the HTTP actions and paths align relatively well to resource endpoints as well as a text based protocol. The abstractions and libraries available make this easier... if you look at IMAP it's byzantine by comparison.
kitsunesoba 4y ago
The biggest issue with IMAP is that writing a quality client for it that works on all possible permutations of the spec (especially with the botched Gmail IMAP implementation in the mix) is a huge, huge pain in the rear which is why there's a dearth of high quality FOSS mail clients… you've got the old standbys like Thunderbird and Claws and that's about it. Newer clients like Geary either die on the vine or get stuck in a somewhat spartan state because making it more full-featured takes knowhow, time, and manpower that's not generally available. On the other hand lots of devs know how to work with JSON-over-HTTP APIs and a lot of modern languages even come with JSON serialization/deserialization out of the box, with makes writing quality clients a lot more accessible to a lot more people.