6 ms·

Is it too late for any significant improvements to email? It seems like, to our lament, we're headed in the direction of proprietary instant chat services and p

by YPPH 4y ago

Is it too late for any significant improvements to email? It seems like, to our lament, we're headed in the direction of proprietary instant chat services and protocols. Also, you can't overlook that a significant number of people use Gmail/Google Apps and Outlook.com/Office 365 which each use a proprietary communication protocol that is unlikely to change in the future. So, it does make me wonder, who does JMAP benefit?

mcint 4y ago
JMAP benefits people who want to use broadly accepted, open standards. Especially standards better adapted to present and future needs: mobile use - lower latency & fewer round trips, lower end-user device power usage. JMAP benefits FastMail (and others). The CEO of FastMail is also a heavy-lifter in standardizing JMAP, Bron Gondwana. It's probably appropriate to mention he's also a lead developer of the Cyrus IMAP free-software project, so it's hard to accuse him of making a private moat for his company. Self-hosters, and small businesses, who can run software, and possibly contribute, but not write their own email software from scratch—-benefit. JMAP is targeting email, and soon calendar, contacts, and maybe more general messaging, to run better suited to current network and user conditions. https://jmap.io/ https://jmap.io/ https://www.ietf.org/blog/jmap/ https://www.ietf.org/blog/jmap/ Who does TCP benefit, JSON, .well-known? who does vcf/vCard benefit, or .ics (even if it started as a proprietary format)?
- mcint 4y ago
  The multiplexing of requests has me pretty interested. If I made myself the spare time, or had a business model, I would love to implement chat bridges (for personal, self-hosted) small-scale use, using JMAP. I like, I'm hopeful for the potential of, the promise of, REST-ful state transfer but with multiplexing of requests internal to the protocol. Think of the protocol as sending a git-patch to modify state, instead of sending a diff per file, "resource". Analogous to how QUIC (which is still adding standardization features) works around the problem of head of line blocking on TCP connections (and on http2's HTTP sequentially multiplex-able response streams), a core theme supporting in existing JMAP for email & attachments is multiple application requests per web-request, on-the-wire payload. Said another way, I appreciate the multiplexing in: - per web request, - per application request (JMAP adds multiplexing here) - per resource, accessible to the user, on the server, - you can create, read, update, delete, move, etc.
- brongondwana 4y ago
  Thanks for the callout :) I'm not doing so much development on Cyrus any more - I still attend the weekly team meetings and do code and design review, but trying to keep my focus more on company operations and standardisation work. JMAP core and email standards haven't changed in the past few years because they're done! In the JMAP working group at the IETF we're currently heavily focused on getting the calendaring and contacts bits finished. That unlocks significantly more benefit for a JMAP client because you don't need multiple different authentications. As for email clients - yeah, it's been slow going, partly because when COVID hit we all shrank back into our shells a bit, and certainly my travel and networking was cut back! It's good to see how it's perceived from outside our little bubble where JMAP is doing great and we're moving more and more of Fastmail's internal APIs to be JMAP-style because it's so easy to multiplex requests together and route them separately through our middleware into different systems, then combine the results back to together in a single response to the calling system or browser.
  - soco 4y ago
    Bringing the documentation up to date would be then a logical step.
    - sacul 4y ago
      Cannot overstate the significance and value of documentation.
- throw0101c 4y ago
  > Especially standards better adapted to present and future needs: mobile use - lower latency & fewer round trips, lower end-user device power usage. IMAP development started in the 1980s (RFC 1064), and was run over POTS modems for many decades: I find it hard to believe that it can't handle the 'low-end' of things. The fact that many clients assume high-end / high-speed links is not a fault of the protocol.
georgyo 4y ago
> Also, you can't overlook that a significant number of people use Gmail/Google Apps and Outlook.com/Office 365 which each use a proprietary communication protocol that is unlikely to change in the future. All of those support IMAP currently, an open standard. Exchange has MAPI as well. Email is the best federated system we might ever have, and it has thousands of clients that can work with nearly any provider. JMAP has not taken off, but there is a chicken and egg problem. Most clients don't support it so there is no pressure on services to support it. Though I imagine if Gmail supported it then suddenly all the clients would support it
- josephg 4y ago
  > All of those support IMAP currently, an open standard. Exchange has MAPI as well. Gmail supports IMAP, with custom extensions to support threading. As far as I understand it they use a custom protocol for their own gmail apps because of IMAP's shortcomings. Its basically impossible to build a modern email app directly on top of gmail's public APIs. You can do it - but only by mirroring and re-indexing all the email.
Gigachad 4y ago
Email has already largely become a newsletter and notification distribution system. Average people don't write or read emails anymore outside of some work settings but even then its usually Slack or MS Teams. Technology and people move quickly so fossilized systems such as email get left behind. There is too much friction to improve a system which has a large number of different implementations. Where any change is hotly debated and people still resist features added to email over a decade ago. Naturally the proprietary systems win when they can roll out a new feature and have it universally work on day one.
- alberth 4y ago
  > Average people don't write or read emails anymore outside of some work settings but even then its usually Slack or MS Teams. Do others believe/experience this? I ask because this sounds like a very Bay Area comment.
  - Gigachad 4y ago
    I'm Australian and have worked for a variety of companies and its been over a year since someone internal at the company sent me a non broadcast newsletter email. Email is much like SMS these days, you use it to arrange job interviews or talk occasionally between businesses but you would never email someone you know directly.
    - alberth 4y ago
      Do you mind if I ask how many employees (order of magnitude) these companies have. Eg 100, 1000, 10000, etc.
      - Gigachad 4y ago
        Previous was 50, current is 500. All communication is over MS Teams now.
    - wildfire 4y ago
      I'm Australian and have the direct counter experience. Most of the business I've worked for consider Slack as ephermal. Email is for significant communications. Outside of work, I'm using daily for things like booking bands, talking to strata, etc. While email in a lot of large companies might tend to be becoming a one-way distribution system; it is still vibrant and heavily used in smaller enterprises.

by YPPH 4y ago

mcint 4y ago

JMAP benefits people who want to use broadly accepted, open standards. Especially standards better adapted to present and future needs: mobile use - lower latency & fewer round trips, lower end-user device power usage. JMAP benefits FastMail (and others). The CEO of FastMail is also a heavy-lifter in standardizing JMAP, Bron Gondwana. It's probably appropriate to mention he's also a lead developer of the Cyrus IMAP free-software project, so it's hard to accuse him of making a private moat for his company. Self-hosters, and small businesses, who can run software, and possibly contribute, but not write their own email software from scratch—-benefit. JMAP is targeting email, and soon calendar, contacts, and maybe more general messaging, to run better suited to current network and user conditions. https://jmap.io/ https://jmap.io/ https://www.ietf.org/blog/jmap/ https://www.ietf.org/blog/jmap/ Who does TCP benefit, JSON, .well-known? who does vcf/vCard benefit, or .ics (even if it started as a proprietary format)?

mcint 4y ago
The multiplexing of requests has me pretty interested. If I made myself the spare time, or had a business model, I would love to implement chat bridges (for personal, self-hosted) small-scale use, using JMAP. I like, I'm hopeful for the potential of, the promise of, REST-ful state transfer but with multiplexing of requests internal to the protocol. Think of the protocol as sending a git-patch to modify state, instead of sending a diff per file, "resource". Analogous to how QUIC (which is still adding standardization features) works around the problem of head of line blocking on TCP connections (and on http2's HTTP sequentially multiplex-able response streams), a core theme supporting in existing JMAP for email & attachments is multiple application requests per web-request, on-the-wire payload. Said another way, I appreciate the multiplexing in: - per web request, - per application request (JMAP adds multiplexing here) - per resource, accessible to the user, on the server, - you can create, read, update, delete, move, etc.
brongondwana 4y ago
Thanks for the callout :) I'm not doing so much development on Cyrus any more - I still attend the weekly team meetings and do code and design review, but trying to keep my focus more on company operations and standardisation work. JMAP core and email standards haven't changed in the past few years because they're done! In the JMAP working group at the IETF we're currently heavily focused on getting the calendaring and contacts bits finished. That unlocks significantly more benefit for a JMAP client because you don't need multiple different authentications. As for email clients - yeah, it's been slow going, partly because when COVID hit we all shrank back into our shells a bit, and certainly my travel and networking was cut back! It's good to see how it's perceived from outside our little bubble where JMAP is doing great and we're moving more and more of Fastmail's internal APIs to be JMAP-style because it's so easy to multiplex requests together and route them separately through our middleware into different systems, then combine the results back to together in a single response to the calling system or browser.
- soco 4y ago
  Bringing the documentation up to date would be then a logical step.
  - sacul 4y ago
    Cannot overstate the significance and value of documentation.
throw0101c 4y ago
> Especially standards better adapted to present and future needs: mobile use - lower latency & fewer round trips, lower end-user device power usage. IMAP development started in the 1980s (RFC 1064), and was run over POTS modems for many decades: I find it hard to believe that it can't handle the 'low-end' of things. The fact that many clients assume high-end / high-speed links is not a fault of the protocol.

georgyo 4y ago

> Also, you can't overlook that a significant number of people use Gmail/Google Apps and Outlook.com/Office 365 which each use a proprietary communication protocol that is unlikely to change in the future. All of those support IMAP currently, an open standard. Exchange has MAPI as well. Email is the best federated system we might ever have, and it has thousands of clients that can work with nearly any provider. JMAP has not taken off, but there is a chicken and egg problem. Most clients don't support it so there is no pressure on services to support it. Though I imagine if Gmail supported it then suddenly all the clients would support it

josephg 4y ago
> All of those support IMAP currently, an open standard. Exchange has MAPI as well. Gmail supports IMAP, with custom extensions to support threading. As far as I understand it they use a custom protocol for their own gmail apps because of IMAP's shortcomings. Its basically impossible to build a modern email app directly on top of gmail's public APIs. You can do it - but only by mirroring and re-indexing all the email.

Gigachad 4y ago

Email has already largely become a newsletter and notification distribution system. Average people don't write or read emails anymore outside of some work settings but even then its usually Slack or MS Teams. Technology and people move quickly so fossilized systems such as email get left behind. There is too much friction to improve a system which has a large number of different implementations. Where any change is hotly debated and people still resist features added to email over a decade ago. Naturally the proprietary systems win when they can roll out a new feature and have it universally work on day one.

alberth 4y ago
> Average people don't write or read emails anymore outside of some work settings but even then its usually Slack or MS Teams. Do others believe/experience this? I ask because this sounds like a very Bay Area comment.
- Gigachad 4y ago
  I'm Australian and have worked for a variety of companies and its been over a year since someone internal at the company sent me a non broadcast newsletter email. Email is much like SMS these days, you use it to arrange job interviews or talk occasionally between businesses but you would never email someone you know directly.
  - alberth 4y ago
    Do you mind if I ask how many employees (order of magnitude) these companies have. Eg 100, 1000, 10000, etc.
    - Gigachad 4y ago
      Previous was 50, current is 500. All communication is over MS Teams now.
  - wildfire 4y ago
    I'm Australian and have the direct counter experience. Most of the business I've worked for consider Slack as ephermal. Email is for significant communications. Outside of work, I'm using daily for things like booking bands, talking to strata, etc. While email in a lot of large companies might tend to be becoming a one-way distribution system; it is still vibrant and heavily used in smaller enterprises.