Live data from Hacker News

JMAP for Calendars, Contacts and Files Now in Stalwart

stalw.art

51–60 of 204 posts

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

#51
post #46
post #33

Earlier quoted context omitted.

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?

yes, but that’s not as simple as apt automatic upgrades

want me to write the script out for you?

1. systemd timer

2. curl github api

3. if new release, fetch, verify checksum

4. update symlink

5. restart service

i don’t think repackaging is actually easier here, for main services of a system is ok to skip the package manager.

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

#52
post #33
post #24

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.

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?

They make breaking changes to settings (and possibly data stores, but I forget) between versions, so to go from, for example, x.y.1 to x.z.5 might involve doing migrations between x.y.2 through x.z.5 just to use the latest version.

This is not the case for all versions, but I've found it to be common enough that I have to read all of the release notes between point versions when upgrading.

It can definitely be improved.

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

#53
post #51
post #46

Earlier quoted context omitted.

yes, but that’s not as simple as apt automatic upgrades

want me to write the script out for you? 1. systemd timer 2. curl github api 3. if new release, fetch, verify checksum 4. update symlink 5. restart service i don’t think repackaging is actually easier here, for main services of a system is ok to skip the package manager.

You will eventually break your email setup by doing this, see my other comment.

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

#54
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.

There isn’t really a great motivating feature or use-case driving client or server adoption.

To be honest, I’m not sure why end-users would want JMAP for e-mail access.

It would be interesting if they do successfully roll out all of these additional RFC proposals providing a cohesive “groupware” protocol covering calendering, contacts, file shares, etc, we see notable server implementations, and interest is enough to drive client support.

That’s a lot of “ifs”.

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

#55

Earlier quoted context omitted.

I tried very hard to get it to work, but I simply couldn't get it to connect with my Stalwart instance over JMAP. I do have the permissive CORS and end-points and proxy-protocol seemingly working with my test HTTPS requests, and I also successfully got JMAP to work with the Mailtemi app, but no luck yet with Cypht[0].

Darn. This looks like the open issue: https://github.com/cypht-org/cypht/issues/931

Yeah that is kind of issue had me flintch when thinking of using stalwart. As much as it is so nice to install it as a server and ideologies behind it. Looks like gonna just stick with wildduck for now. Just don't like to hedge our email bets on mongodb community edition.

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

#56
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…

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

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

#57
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.

There isn’t really a great motivating feature or use-case driving client or server adoption. To be honest, I’m not sure why end-users would want JMAP for e-mail access. It would be interesting if they do successfully roll out all of these additional RFC proposals providing a cohesive “groupware” protocol covering calendering, contacts, file shares, etc, we see notable server implementations, and interest is enough to…

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

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

#58
post #57

Earlier quoted context omitted.

There isn’t really a great motivating feature or use-case driving client or server adoption. To be honest, I’m not sure why end-users would want JMAP for e-mail access. It would be interesting if they do successfully roll out all of these additional RFC proposals providing a cohesive “groupware” protocol covering calendering, contacts, file shares, etc, we see notable server implementations, and interest is enough to…

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 good IMAP support, so they’re unlikely to care much about JMAP, either. They just want you to use their webapp.

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

#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.

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

#60
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.

I don’t think JMAP Calendar spec has been ratified yet.

https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/

And Contacts was only 10-months ago.

https://www.rfc-editor.org/rfc/rfc9610.html

Post reply on HN