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

61–70 of 204 posts

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

#61

Post by kridsdale1 »

bmelton wrote: post #49
NoboruWataya wrote: post #48

> They are robust, widely adopted, and battle-tested. Yet, their XML-based design is notoriously verbose, inconsistent, and difficult to implement correctly. Information is scattered across HTTP headers, XML payloads, and even embedded iCalendar data, creating endless compatibility and interoperability challenges between clients and servers. Can others confirm if these problems are widespread? I get that these protoc…

You're right to ask it Always relevant: https://xkcd.com/927/

One of the handful of xkcd numbers I recognize without having to open.

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

#62

Post by [deleted] »

frumplestlatz wrote: post #58
tjoff wrote: post #57

Earlier quoted context omitted.

Because IMAP is horrible, it is another driving reason why we are moving towards the dystopian world of webmail.

Horrible how, exactly? People say things like that, and I wonder if I’ve just been living in a gilded tower of using Apple Mail with decent IMAP server implementations. I’m also pretty familiar with the wire protocol and its implementation — it’s never struck me as particularly horrible. A new protocol isn’t likely to solve the problem of poorly implemented clients and servers — e.g. Google doesn’t really care about…

[deleted]

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

#63

Post by 9dev »

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…

It’s not that I cannot appreciate the improvements in the space, I’m just wondering if there might be a big part of the design space for widely used protocols that ends up unexplored because the default for almost anything now is HTTP. It has basically become OSI layer 8 at this point.

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

#64

Post by frumplestlatz »

kridsdale1 wrote: post #59

I worked on the iCalendar, CalDAV, and CardDAV parsers at Apple in 2010 or so, and I see no reason to believe that today’s Macs, iPhones, and Watches, are using anything more modern. I haven’t been there in more than a decade. I really am curious what the response in Apple (and Google) is to this spec.

Of all of their proposals, this is the most interesting part to me.

I researched what it would take to implement a full calendaring server once, and after reading all the RFCs, just backed away slowly from the whole idea and never thought about it again.

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

#65

Post by 0x073 »

audelair wrote: post #35
drdaeman wrote: post #14

Earlier quoted context omitted.

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 s…

Not sure if yours is setup different, but there are several key fields that need to be written to the config.toml file, and I've seen my file get updated when I make changes to the listeners or stores settings. But in general, I agree that it has not been a very smooth experience. Having messed around with maddy and mox, Stalwart has had quite a few gotchas. Despite being a single binary promising simplicity, I'm fin…

Is there a reason you use aws s3 vs the hetzner object storage?

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

#66

Post by mjrpes »

woodruffw wrote: post #27
sylens wrote: post #21

We need better client support for JMAP. Apple Mail, Thunderbird, Outlook (as if), and so on. I'm surprised some of the smaller ones like Canary or Spark don't implement it as a product differentiator.

Serious question: what’s the differentiator if major email providers don’t support it? (This should not be interpreted as a defense of IMAP.)

One big differentiator is JMAP allows one network connection to track new emails that may get delivered across different folders. With IMAP you need a connection open for each folder.

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

#67

Post by zzo38computer »

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…

> I’m wondering if the design space for new protocols should really be constrained to layers on top of HTTP

It shouldn't. For some cases it helps, but other times it doesn't. Sometimes it helps but there would be better ways to do it, making it on a simpler protocol or making an entirely new protocol (which might or might not use TCP; sometimes it is better to use TCP and sometimes not) depending on the specific case.

> 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 format, IMHO

I dislike JSON. I think it has many problems, and that DER is a better format.

(There are also the "small web" protocols such as Gemini and Scorpion and Spartan and Titan, which avoids some of the complexity of HTTP; I had considered using DER-over-Scorpion rather than JSON-over-HTTP. It is also possible to use SSH, although SSH does not have virtual hosting.)

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

#68

Post by zzo38computer »

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…

> Notoriously so, it's why MIME types and MIME encodings get so complicated.

I made up ULFI because I thought MIME has some problems.

> JSON may not look efficient

Efficiency is not the only issue; there is also the consideration of e.g. what data types you want to use. JSON does not have a proper integer type, does not have a proper binary data type (you must encode it as hex or base64 instead), and is limited about what character sets can be used.

(Also, like other text formats, escaping will be needed.)

> I feel like "JSON over HTTP" is a subtle improvement over "custom text formats over telnet"

I think it can be, depending on the specific use; sometimes it isn't, and will make it worse. (HTTP does have the advantage of having URLs and virtual hosting, although I think it adds too much complexity more than should be needed.) However, I still think that DER is generally better than JSON.

> HTTP isn't the worst bootstrap layer the internet could use to build new protocols and apps on top of.

I think it depends on the specific application. However, even then, I think there are better ways than using HTTP with the complexity that it involves, most of which should not be necessary (even though a few parts are helpful, such as virtual hosting).

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

#69

Post by woodruffw »

mjrpes wrote: post #66
woodruffw wrote: post #27

Earlier quoted context omitted.

Serious question: what’s the differentiator if major email providers don’t support it? (This should not be interpreted as a defense of IMAP.)

One big differentiator is JMAP allows one network connection to track new emails that may get delivered across different folders. With IMAP you need a connection open for each folder.

Okay, that's a great feature! But I guess I'm asking what the differentiator is if major email providers don't use it.

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

#70

Post by zzo38computer »

frumplestlatz wrote: post #56
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…

HTTP is also a large, complex stack for any server/client that isn’t already a web server or a browser.

Yes, this is the other issue with using HTTP.
Post reply on HN