JMAP for Calendars, Contacts and Files Now in Stalwart • Hacker News Board

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

#201

Post by seec » Mon, Oct 27, 2025, 7:48 PM UTC

WhyNotHugo wrote: post #153

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.

JMAP is great for thin clients, like webmail, or clients which can’t store any state to disk. For regular desktop software, I’m not sure that it’s really an improvement over existing protocols.

I agree. For what I read quickly, it seems to be mostly the same stuff but "modernized". It's like the flavor of the day for email technology. Fundamentally it hasn't really changed much which is why I am a bit skeptical. Sure, you have a "better" and more efficient protocol that is easier to work with/implement but then what? It's still just email with most of the inherent flaws built in.

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

#202

Post by heavyset_go » Sun, Nov 02, 2025, 8:48 AM UTC

WhyNotHugo wrote: post #155

heavyset_go wrote: post #50

Earlier quoted context omitted.

It's one tiny binary that does everything you could possibly need for hosting a mail server, including an admin UI, and you get a bunch of modern and convenient features for free. For example, it automatically handles Let's Encrypt certs for you. You get JMAP, CalDAV, WebDAV, CardDAV, IMAP4rev2, DKIM/SPF/DMARC, MTA-STS, DANE, spam filtering, SQL+blob+object storage backends, search, clustering, OpenTelemetry, etc all…

What you’re describing sounds like one huge downside to me, not and advantage. The only way to adopt Stalward is to drop everything else and use a single monolithic do-it-all? Messages are stored in a bespoke format and not easily accessible directly? It doesn’t sound like it’s made to be usable with other software. This isn’t an advantage in my book.

The features are toggles or allow you to slot in your own infrastructure where need be, from what I can see. It's not that you have to use it, it's that it's there if you want it, and I want it.

Suits my needs, but I can see why it wouldn't suit everyone's.

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

#203

Post by heavyset_go » Sun, Nov 02, 2025, 8:50 AM UTC

matesz wrote: post #130

heavyset_go wrote: post #50

Earlier quoted context omitted.

It's one tiny binary that does everything you could possibly need for hosting a mail server, including an admin UI, and you get a bunch of modern and convenient features for free. For example, it automatically handles Let's Encrypt certs for you. You get JMAP, CalDAV, WebDAV, CardDAV, IMAP4rev2, DKIM/SPF/DMARC, MTA-STS, DANE, spam filtering, SQL+blob+object storage backends, search, clustering, OpenTelemetry, etc all…

> Downsides: some features are gated behind an enterprise version I treat this as an insurance policy. Even in this thread people mentioned how Maddy, which is an alternative modern full stack email solution in a single binary, lacks development efforts. This is why we have this fantastic release for Stalwart - free shit. Also as of now enterprise is for $0.2 per account per month which is extremely cheap unless some…

Agree with your points, it's a downside if you're cheap like me and don't want to pay a penny for email at all.

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

#204

Post by cstrahan » Sun, Nov 02, 2025, 2:10 PM UTC

dotancohen wrote: post #159

cstrahan wrote: post #117

Earlier quoted context omitted.

JSON numbers are not JavaScript Numbers. While the grammar is specified (that’s what JSON is , after all), the runtime representation is unspecified. A conformant JSON parser can parse “1” as 1.0. They can be backed by doubles, or singles, or arbitrary precision.

That's exactly my point. If one needs an integer or a float, the parser converts it. I ask under what use case is there ever ambiguity?

> If one needs an integer or a float, the parser converts it.

Which parser? That’s the problem: if you’re using JSON as a data interchange format, you’ll need to carefully control both the serializers and deserializers, and whatever libraries you use, they will need to (at least internally) hold onto the number in a lossless way — I am not aware of any libraries that do this. They all parse the number as an f64 before any deserializers run. If your input JSON contains a u128, then you’ll have a loss of precision when your type is deserialized.

If you can set up (de)serialization to work the way you need it, then there’s no problem. But if you share your JSON serialized data with other parties, then you/they may be in for a bit of a surprise.

You might find it a worth while exercise to try parsing JSON containing an arbitrary unsigned 128 bit integer in your language of choice.