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

121–130 of 204 posts

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

#121

Post by indigo945 »

nine_k wrote: post #91
drnick1 wrote: post #79

Earlier quoted context omitted.

What good is a protocol like JMAP as long as common clients like Thunderbird, K-9 Mail, the iPhone email client and others don't support it? Without some concerted effort it will never take off. Then there is the question of what problem it solves that isn't already solved by existing solutions.

Next time an iCal event invitation screws up the time zone, return to this question.

iCal is timezone-aware, if something goes missing there, that's the fault of a broken implementation.

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

#122

Post by Mailtemi »

As a JMAP client implementer, there’s a big plus, beside JMAP, in having an integrated server for email, contacts, and files. Some setups take days even for email, so an easy, fast setup saves a lot of time.

Also, after code the CalDAV ↔ JSCalendar part, using only IANA time zones instead of scattered ones in CalDAV components makes things much simpler.

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

#123

Post by brongondwana »

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…

JMAP is only JSON over HTTP because that's what all the libraries support. Any data format which provides hashes and arrays would work fine, over any transport. So you could use CBOR or protocol buffers or whatever, over any channel you like.

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

#124

Post by brongondwana »

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.

That's not strictly true. IMAP has two things, UIDs which are mostly static (there's a UIDVALIDITY cache invalidation key to let a client know that UID information has been lost and recalculated); and message numbers.

UIDs don't change, but of course they can be deleted so it's a gappy list, meaning you can request even quite a large looking range of UIDs and get nothing back.

Message numbers change in every session, and also change every time you get an EXPUNGE. They're basically an ordered list without gaps, so you do a memmove at the offset of the EXPUNGE each time you get an expunge.

There are efforts like UIDONLY (RFC9586) to avoid having to keep that mapping at all, and there's OBJECTID (RFC8474) to let you cache a lot more even when UIDs are changed or when messages are moved between folders.

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

#125

Post by brongondwana »

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 the JMAP Calendars spec eventually.

The downsides of developing and testing this stuff as we were writing it up!

We've finished rewriting the objectid generation to give smaller sized and more sortable IDs (they're an inverse of nanosecond internaldates now, plus some extra magic on the low bits for IMAP appends to avoid clashes)... which we wanted to speed up and reduce disk usage for the offline mode.

Next up is indeed updating to the latest spec on calendars and contacts. Files might take a bit longer, I really want to do some desktop clients for the files system, we have a really nice files backend at Fastmail which is only accessible via our interface or WebDAV right now.

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

#126

Post by conradev »

solarkraft wrote: post #97

Stalwart is, from what I’ve read, an excellent JMAP server. JMAP is, from what I’ve read, a great protocol for building an E-Mail (and now also others) client on top of. Since I would like an innovative way to access my E-Mails, but do not want to self-host, I would find it interesting to use Stalwart as the server component of an E-Mail client : Data is somehow synced into Stalwart via the “ugly” protocols and I get…

I would just like to highlight the "excellent" bit here. It is a tour de force, a masterpiece. Beautifully factored software. They've done an excellent job incrementally building trust and delivering. Really cool project, and I'm so glad it exists.

I also did not realize it is… primarily developed by a single person? The author. Incredible:

https://github.com/stalwartlabs/stalwart/graphs/contributors

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

#127

Post by sureglymop »

aryonoco wrote: post #120
drnick1 wrote: post #79

Earlier quoted context omitted.

What good is a protocol like JMAP as long as common clients like Thunderbird, K-9 Mail, the iPhone email client and others don't support it? Without some concerted effort it will never take off. Then there is the question of what problem it solves that isn't already solved by existing solutions.

I think Thunderbird will implement JMAP at some point, because as I understand it their upcoming hosted mail service, Thunderbird Pro will offer it. I looked into adding JMAP support to Thunderbird but the client is so tied around the ideas and principles of IMAP, it needs surgical refactoring of many parts of it and I don’t love C++. So instead in my spare time I am developing a JMAP only gnome email client, using m…

Isn't their upcoming "Thundermail" service actually based on/using Stalwart?

Here is a quote I found on https://thunderbird.topicbox.com/groups/planning/T437cd854af...:

> We have been experimenting with this for a while now and are using Stalwart as the software stack we are building upon. We have been working with the Stalwart maintainer to improve its capabilities (for instance, we have pushed hard on calendar and contacts being a core piece of the stack).

However, unfortunately I am unsure whether this is a good source or official page.

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

#128

Post by Loic »

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…

Off-Topic: Thank you for not only providing a stellar service with Fastmail, but also for contributing back to the OSS ecosystem and the specifications/RFC work. This takes a lot of time and we all benefit from this work. It helps many people/small IT shops to run a system outside of the "big ones". Again, thank you.

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

#129

Post by quicksilver03 »

matesz wrote: post #15

Running Stalwart in production for ~20 heavily used accounts for some company and no problems so far! The simplicity for such a complex stack and flexibility of deployments is off the charts!

Can you share what's your solution for filtering incoming spam? I've had to abandon Stalwart because its spam filter is so ineffective and inconsistent.

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

#130

Post by matesz »

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…

> 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 somebody wants to build a big spam farm, of which as civilized Internet user I don't support. Obviously this might change, but even if you can always built multi-tenancy layer by yourself if you really need it - rest of the codebase is AGPL.

Post reply on HN