I wish there was an easy auto-update process for Stalwart. is anyone hosting an apt repo for it? edit: we use it on very resource constrained environments, the container version is too much overhead.
JMAP for Calendars, Contacts and Files Now in Stalwart
41–50 of 204 posts
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#42I can understand why JMAP instead of IMAP given the latter's antiquated design. I don't see the advantage to clients in replacing WebDAV though, and the others are a bit iffy too. They'll need to make a way better sales pitch than 'JSON vs XML' (serialization ain't tough, XML is supported everywhere). I guess contacts/calendar follows JMAP naturally when the clients already implement it, but that only applies in the…
However, doesn't stalwart already also support WebDAV though?
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#43We 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.
I’ve got a friend who’s been pitching me on building a new email client for years. “I’ll do it if we exclusively use JMAP.” “okay does that include Gmail and Apple/iCloud accounts?” “Nope.”
I could sort of see dual-supporting Gmail's proprietary API and JMAP, but unless the #2-5 competitors support it… what’s the point? (sorry to put on the pessimism hat)
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#44Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#45I wish there was an easy auto-update process for Stalwart. is anyone hosting an apt repo for it? edit: we use it on very resource constrained environments, the container version is too much overhead.
Where is the overhead in a container? It is just a regular process. (Ok plus a container runtime process, but that is negligible)
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#46I wish there was an easy auto-update process for Stalwart. is anyone hosting an apt repo for it? edit: we use it on very resource constrained environments, the container version is too much overhead.
isn't it a static binary? Can't you do it the old-school sysadmin way and pull down a binary from github releases and update a symbolic link?
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#47Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#48Can others confirm if these problems are widespread? I get that these protocols are probably a pain to develop for but given they are "robust, widely adopted and battle-tested" it seems that is probably a solved problem. It's better to have one standard that is used everywhere than to have to choose between two standards.
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#49> 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…
Always relevant: https://xkcd.com/927/
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#50It’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.
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.
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 in one tiny binary.
Downsides: some features are gated behind an enterprise version and I think the dev team is one guy, or at least it was a while ago.
Having ran both for a long time, I'm sticking with Stalwart from now on as long as development continues.