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

151–160 of 204 posts

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

#151

Post by styanax »

brongondwana wrote: post #125
vamega wrote: post #44

I really hope Fastmail implements the JMAP spec for calendars and contacts soon. They’ve had the mail part of the spec implemented for a while, but it still requires CardDAV/CalDAV for contacts and calendar access.

We're working on it. We still use an unholy set of earlier versions of JMAP internally for our contacts and calendars; in particular the caldav_sync code is gnarly - I wrote it over 10 years ago when I knew less about calendars than I do now! It's still using an earlier branch of what became the perl Net::CalDAVTalk library interally, even though our frontend API is an almost-up-to-date version of what will become th…

Aside, this bit that Neil and the team are working on is something I think is the 'next big thing': https://www.ietf.org/archive/id/draft-ietf-jmap-emailpush-01...

The next, next big thing would be the Chatmail relays[1] supporting JMAP based servers (right now it's Dovecot) and this new targeted push extension for faster notifications without battery drain on mobile. I can see how the Fastmail mobile client will benefit from this RFC as well (it's already incredibly battery efficient, thanks to the team).

[1] https://github.com/chatmail/relay

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

#152

Post by WhyNotHugo »

solarkraft wrote: post #93

Reading weirdly many “but there are no clients” posts. Of course something has to come first. You can’t really develop a client without a server implementation and Stalwart is essentially the first server implementation of JMAP. With Stalwart in place, there’s finally a reason to develop a client for JMAP. I hope y’all are aware that Mozilla’s new mail service will use it, so that is likely going to give JMAP a big p…

I implemented support for JMAP calendars in Pimsync recently.

You can now synchosise any combination of CalDAV, JMAP, and filesystem.

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

#153

Post by WhyNotHugo »

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.

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

#154

Post by WhyNotHugo »

whatevaa wrote: post #90
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.)

IMAP is a shit protocol in general. Notably, email UIDs are not guaranteed to be static across sessions (aka, next time you connect they may be different), which is just straight up dumb. You IMAP client has to do a lot of workarounds just for this, which leads to gnarly bugs and inefficiences.

> UIDs are not guaranteed to be static across sessions

Realistically speaking, does any server ever rotate its UIDValidity?

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

#155

Post by WhyNotHugo »

heavyset_go wrote: post #50
drnick1 wrote: post #40

Earlier quoted context omitted.

But is there any real benefit over Postfix + Dovecot other than "it's new and written in Rust?" Postfix and Dovecot have been around for decades and respect the Unix philosophy of doing one thing and doing it well.

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.

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

#156

Post by 7bit »

20after4 wrote: post #95
7bit wrote: post #83

Earlier quoted context omitted.

> Most of the "old internet" protocols (email, FTP, even HTTP itself) were bootstrapped on top of built-mostly-for-plaintext Telnet. That's just not true. Telnet and SMTP are built on top of TCP. They live on the same layer. They were originally both protocols that transmitted data with printable ascii, hence why they look similar. There are many other protocols like Telnet and SMTP that worked like that, auch as nnt…

I think that the point is this: You could literally use a telnet client to talk to all of those servers and it was considered a good thing, maybe even an essential feature. So protocol design was somehow influenced by the need to be fully plain text ASCII streams (and maybe that other options weren't adequately explored due to this restriction)

Yeah, I got the point. His statements are still factually incorrect and needed correction.

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

#157

Post by bruce343434 »

I tried to set up stalwart, but I didn't understand exactly what it wanted me to do. It's a webserver (for webmail and admin) and mail server in one, but I already run a webserver and I already have cert infra. So I couldn't figure out what dns settings to use and what ports to reverse proxy. And how to get it to play nice and share the certificate. Seems like stalwart has been designed as if it is the only thing running on a machine, with sparse documentation for any other setup. I tried getting help on the discord server but the tone seemed to be of a sort of "it's quite obvious, you should already know this". At that point, it's so much friction to reverse engineer it that it might just be easier to set up dovecot and postfix.

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

#158

Post by dotancohen »

funcDropShadow wrote: post #148
dotancohen wrote: post #78

Earlier quoted context omitted.

> JSON does not have a proper integer type What are the drawbacks to using the JavaScript Number (really a double float I think) datatype as an integer in an object representation language such as JSON? I've never seen a use case where e.g. 42 (int) could be confused with 42.0 (float). If your application needs specifically an int or a float, then the ingesting application knows that. If the answer is monetary values…

Even if we assume that JSON numbers are JavaScript numbers. There is the problem that some large natural numbers cannot be represented in double or float although some even larger numbers can be represented. This is very bad if you use these numbers as IDs. scala> (Long.MaxValue-1) val res4: Long = 9223372036854775806 scala> (Long.MaxValue-1).toDouble.toLong val res5: Long = 9223372036854775807 The fact that I used S…

But that problem is not inherent to JSON, which is a pain text encoding of those numbers.

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

#159

Post by dotancohen »

cstrahan wrote: post #117
dotancohen wrote: post #78

Earlier quoted context omitted.

> JSON does not have a proper integer type What are the drawbacks to using the JavaScript Number (really a double float I think) datatype as an integer in an object representation language such as JSON? I've never seen a use case where e.g. 42 (int) could be confused with 42.0 (float). If your application needs specifically an int or a float, then the ingesting application knows that. If the answer is monetary values…

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?

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

#160

Post by StopDisinfo910 »

candiddevmike wrote: post #12
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…

This is a circular self-defeating reasoning.

If you want to push a new technology, you need to start somewhere. That's exactly what's happening with JMAP. It was created by Fastmail to use as a bridge between their servers and their own apps a case for which popularity doesn't matter. It's basically a modern vendor proprietary protocol but done in the open.

From there, support is only a matter of someone being interested enough to implement it and manifestly it's working. There are now three servers (Apache James, Cyrus and Stalwart) and some clients.

Post reply on HN