Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JMAP for Calendars, Contacts and Files Now in Stalwart

stalw.art

Post reply on HN
Print view View original

11–20 of 204 posts

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#11

Post by refulgentis »

Anyone got a link to a better sales job on JMAP & friends?

It sounds awesome but the way it is intro'd here:

  Over the past few years, the IETF has been redefining how email, calendars, and contacts are synchronized and shared. Building upon the success of JMAP for Mail, several new protocol extensions have been introduced:

  JMAP for Calendars - A modern replacement for CalDAV and CalDAV Scheduling.
  JMAP for Contacts – A powerful alternative to CardDAV.
  JMAP for File Storage – A replacement for WebDAV-based file storage.
  JMAP Sharing – A modern successor to WebDAV ACL.
  JSCalendar - A clean, JSON-based evolution of iCalendar.
  JSContact – A modernized, JSON-native successor to vCard.
...gave me pause. A protocol I've never heard even though I hang out here for an hour a day, was so successful, that it launched 6 new projects?

Sounds more like the parts of the web dev that give me ick (new and shiny; rush to copy new and shiny in other contexts; give it a year; and all of a sudden only 1 of the 6 actually was successful)

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#12

Post by candiddevmike »

refulgentis wrote: post #11

Anyone got a link to a better sales job on JMAP & friends? It sounds awesome but the way it is intro'd here: Over the past few years, the IETF has been redefining how email, calendars, and contacts are synchronized and shared. Building upon the success of JMAP for Mail, several new protocol extensions have been introduced: JMAP for Calendars - A modern replacement for CalDAV and CalDAV Scheduling. JMAP for Contacts –…

JMAP and friends are very niche, none of the "mainstream" email clients (that ship with most computers/phones) support it. So this feature being available is unlikely to grow the userbase, IMO.

Now JMAP is quite a bit nicer to use than IMAP's API, but IMAP's gravitational field is too strong to be supplanted. IMAP is also becoming somewhat of a niche protocol, as the majority of users use vendor proprietary protocols for accessing their emails on Gmail, Outlook/Hotmail, etc. So why invest the time to add a niche replacement for IMAP when the entire protocol is a second class citizen to mainstream email clients.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#13

Post by WorldMaker »

9dev wrote: post #6

While JMAP seems to scratch every itch of a sucker for proper web API design, I’m wondering if the design space for new protocols should really be constrained to layers on top of HTTP. Is there really any new-ish binary protocol these days? Stuff like file sharing or groupware, mail, calendars, and so on—these things could be a lot more efficient and don’t really need the overhead of JSON as the message interchange f…

> binary protocol

Email was never a binary protocol. Notoriously so, it's why MIME types and MIME encodings get so complicated.

Most of the "old internet" protocols (email, FTP, even HTTP itself) were bootstrapped on top of built-mostly-for-plaintext Telnet. HTTP as the new telnet has a bunch of improvements when it comes to binary data, request/response-based data flows, and some other considerations. HTTP/3 is even inherently a binary protocol, it's lack of "telnet-compatibility" one of the concerns about switching the majority of the web to it.

vCard/vCal/iCard/iCal were also deeply "plaintext formats". JSON is an improvement because it is more structured, even more efficient, than those predecessors. JSON may not look efficient, but it compresses extremely well and can be quite efficient in gzip and Brotli streams.

I feel like "JSON over HTTP" is a subtle improvement over "custom text formats over telnet", even if it doesn't sound like "binary protocol efficiency" at first glance. Especially as HTTP/3 pushes HTTP more efficient and more "binary", and arguably "more fundamental/basic" with HTTP/3 even taking over more roles in the TCP/UDP layer of the internet stack. (Telnet would never try to replace TCP.) HTTP isn't the worst bootstrap layer the internet could use to build new protocols and apps on top of. Sure, it would be neat to see more variety and experiments outside of the HTTP stack, too, but HTTP is too useful at this point not to build a bunch of things on top of it instead of as their own from-scratch protocol.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#14

Post by drdaeman »

lifty wrote: post #8

It’s such a breeze to self-host your own email server using Stalwart. It has been a new era for email self-hosters like myself since these kind of fully integrated email servers like Stalwart appeared. Another good one but not as actively maintained is Maddy.

I'm setting up Stalwart right now, migrating from my current Maddy+Postfix+Dovecot+Rspamd setup. Not exactly my experience.

The documentation is not great - I'd say it's just about barely enough to get an overall idea, but there's no one proper single definitive overview of what options exist, what are their possible values, what are the defaults, and how they relate to each other. Maddy docs, despite looking a bit sloppy, were a lot easier to get through. IMHO Stalwart makes it unnecessarily difficult to write a non-minimal static configuration file, hooking everything up correctly.

To be fair, maybe there is a page like that but I haven't found it, despite trying.

I know the Web UI allows to do the configuration by clicking through the forms, but this approach conflicts with declarative deployment practices. In my case it's giving me nondescript 500 errors in the UI with "Failed to write local configuration" in the logs because the .toml file is read-only.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#16

Post by p_l »

WorldMaker wrote: post #13
9dev wrote: post #6

While JMAP seems to scratch every itch of a sucker for proper web API design, I’m wondering if the design space for new protocols should really be constrained to layers on top of HTTP. Is there really any new-ish binary protocol these days? Stuff like file sharing or groupware, mail, calendars, and so on—these things could be a lot more efficient and don’t really need the overhead of JSON as the message interchange f…

> binary protocol Email was never a binary protocol. Notoriously so, it's why MIME types and MIME encodings get so complicated. Most of the "old internet" protocols (email, FTP, even HTTP itself) were bootstrapped on top of built-mostly-for-plaintext Telnet. HTTP as the new telnet has a bunch of improvements when it comes to binary data, request/response-based data flows, and some other considerations. HTTP/3 is even…

A lot of the textual nature of older IETF protocols, including the CR LF line endigns, can be probably traced to how easy it was to bang out a bad implementation full of subtle problems that could be debugged by sitting an undergrad student at a teletype instead of spending time on having some binary serializer (that telecom companies definitely had money for)

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#17

Post by JoshTriplett »

p_l wrote: post #16
WorldMaker wrote: post #13

Earlier quoted context omitted.

> binary protocol Email was never a binary protocol. Notoriously so, it's why MIME types and MIME encodings get so complicated. Most of the "old internet" protocols (email, FTP, even HTTP itself) were bootstrapped on top of built-mostly-for-plaintext Telnet. HTTP as the new telnet has a bunch of improvements when it comes to binary data, request/response-based data flows, and some other considerations. HTTP/3 is even…

A lot of the textual nature of older IETF protocols, including the CR LF line endigns, can be probably traced to how easy it was to bang out a bad implementation full of subtle problems that could be debugged by sitting an undergrad student at a teletype instead of spending time on having some binary serializer (that telecom companies definitely had money for)

Yeah, a fair bit of email protocol reeks of "is this tolerant of `telnet mailserver 25` and whatever garbage that might produce".

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#18

Post by p_l »

JoshTriplett wrote: post #17
p_l wrote: post #16

Earlier quoted context omitted.

A lot of the textual nature of older IETF protocols, including the CR LF line endigns, can be probably traced to how easy it was to bang out a bad implementation full of subtle problems that could be debugged by sitting an undergrad student at a teletype instead of spending time on having some binary serializer (that telecom companies definitely had money for)

Yeah, a fair bit of email protocol reeks of "is this tolerant of `telnet mailserver 25` and whatever garbage that might produce".

A lot of old RFCs explicitly mention running on top of TELNET.

Additionally, as much people like to harp about "telcos focusing on connection-oriented protocols while we ran loops around them with packets", the reality is that NCP and later TCP pretty much focused on emulating serial lines around, and one of the earliest ways to access ARPAnet outside of machines directly on it was through calling into a TIP which set up bidirectional stream from your modem to a port on some host.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#19

Post by p_l »

WorldMaker wrote: post #13
9dev wrote: post #6

While JMAP seems to scratch every itch of a sucker for proper web API design, I’m wondering if the design space for new protocols should really be constrained to layers on top of HTTP. Is there really any new-ish binary protocol these days? Stuff like file sharing or groupware, mail, calendars, and so on—these things could be a lot more efficient and don’t really need the overhead of JSON as the message interchange f…

> binary protocol Email was never a binary protocol. Notoriously so, it's why MIME types and MIME encodings get so complicated. Most of the "old internet" protocols (email, FTP, even HTTP itself) were bootstrapped on top of built-mostly-for-plaintext Telnet. HTTP as the new telnet has a bunch of improvements when it comes to binary data, request/response-based data flows, and some other considerations. HTTP/3 is even…

Another point is that the use of HTTP for everything, outside of the issue of middle boxes breaking protocols for everyone, is that it's essentially capitulation to the wisdom of OSI multi-layered protocols - we replicate their feature sets by reusing bits and pieces of HTTP spec all the time.

Re: JMAP for Calendars, Contacts and Files Now in Stalwart

#20

Post by ggm »

refulgentis wrote: post #11

Anyone got a link to a better sales job on JMAP & friends? It sounds awesome but the way it is intro'd here: Over the past few years, the IETF has been redefining how email, calendars, and contacts are synchronized and shared. Building upon the success of JMAP for Mail, several new protocol extensions have been introduced: JMAP for Calendars - A modern replacement for CalDAV and CalDAV Scheduling. JMAP for Contacts –…

You may only just have heard of them, but the WG goes back to 2017.

https://datatracker.ietf.org/wg/jmap/history/

Bron is the principal of fastmail, who now own pobox. This is a serious activity.

Post reply on HN