Live data from Hacker News

JMAP for Calendars, Contacts and Files Now in Stalwart

stalw.art

71–80 of 204 posts

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

#71
post #65

Earlier quoted context omitted.

Not sure if yours is setup different, but there are several key fields that need to be written to the config.toml file, and I've seen my file get updated when I make changes to the listeners or stores settings. But in general, I agree that it has not been a very smooth experience. Having messed around with maddy and mox, Stalwart has had quite a few gotchas. Despite being a single binary promising simplicity, I'm fin…

Is there a reason you use aws s3 vs the hetzner object storage?

I heard some second-hand accounts that Hetzner's object storage was pretty slow even in the same location. For email, that sounded not too ideal.

Also, I only have 5 mailboxes right now holding less than 15GB of data total... S3 is still cheaper than the minimum at Hetzner since I don't need anything close to a TB.

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

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

What resource constraints allow you to apt-get but not docker pull? It’s the same resulting stack isn’t it?

I am most curious

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

#73

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.

Of all of their proposals, this is the most interesting part to me. I researched what it would take to implement a full calendaring server once, and after reading all the RFCs, just backed away slowly from the whole idea and never thought about it again.

Yeah. It’s a super messy domain. You never know when the parliament of Brazil will pass a law changing the time zone definition.

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

#74
post #55

Earlier quoted context omitted.

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.

I do have to hand it to the developer though. This is some serious longterm commitment to an open standard that has simply never taken off beyond one company (Fastmail). Current JMAP implementation is pretty much nonexistent, and I am back to using IMAP/WebDAV with Roundcube and plugins with Stalwart. To me, this is an exercise in patience and waiting for an eventual payoff that may or may not come in the next two years. Having followed the project closely for over a year and gone through a few upgrades and followed the community, I'm still optimistic and happy to be along for the ride.

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

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

How much overhead do you think fetching emails over http takes? Fetching text documents with HTTP seems like the prime usecase for it. And it's the only way you could have something that works in web clients.

I'm struggling to think of any real benefits to not using HTTP other than it would be more interesting.

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

#76
post #57

Earlier quoted context omitted.

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…

Gilded tower? Are we living in separate universes?

Shameless plug for a client with true offline-first IMAP support:

https://marcoapp.io

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

#77
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!

Out of curiosity do you front-end SMTP with postfix to have many queues/MX entries and a battle hardened front-end or is Stalwart handling inbound connections directly? Im thinking of moving from Dovecot to Stalwart so family members have more modern features on my fallback domains about half of my domains do not use Fastmail. In multiple companies I had several Postfix inbound servers to keep the internet from touching Exchange directly and have multiple nodes for companies to quickly hand off to in multiple locations.

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

#78

Earlier quoted context omitted.

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

> Notoriously so, it's why MIME types and MIME encodings get so complicated. I made up ULFI because I thought MIME has some problems. > JSON may not look efficient Efficiency is not the only issue; there is also the consideration of e.g. what data types you want to use. JSON does not have a proper integer type, does not have a proper binary data type (you must encode it as hex or base64 instead), and is limited about…

  > 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, then those should never be floats, and should not be represented in JSON as such. E.g. a dollar and a half should be represented as 150 cents. This follows even for sub-cent precision.

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

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

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.

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

#80
post #37

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

Fastmail supports it, and it sounds like Thundermail will too

Thundermail will be built on Stalwart, so yeah :)
Post reply on HN