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

131–140 of 204 posts

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

#131

Post by cyberax »

p_l wrote: post #81
cyberax wrote: post #39

Earlier quoted context omitted.

It's also a reflection of the state-of-the-art at the time. Binary protocols were an unmitigated disaster, with standards bodies thinking that applying to the ISO for your organizational ID is a perfectly fine step that anyone does anyway.

That's why there was an entire section for unassigned numbers. Binary protocols just meant you actually needed to implement serialiser/deserialiser and similar tooling instead of writing dumbest possible riff on strtok() and hoping your software won't be used anymore once DoD internet becomes mature

> That's why there was an entire section for unassigned numbers.

That's also why the majority of OIDs in SNMP are rooted in the 1.3.6 hierarchy, which belongs to the DoD.

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

#132

Post by jeroenhd »

WorldMaker wrote: post #118
9dev wrote: post #63

Earlier quoted context omitted.

It’s not that I cannot appreciate the improvements in the space, I’m just wondering if there might be a big part of the design space for widely used protocols that ends up unexplored because the default for almost anything now is HTTP. It has basically become OSI layer 8 at this point.

HTTP/3 replaces parts of OSI layer 4 (TCP/UDP). There's a perspective that HTTP has been trying to lower its layer for decades. Especially the way that TLS originated as HTTPS but now is almost a "universal" vertical chunk of Layers 4, 5, and 6. In that perspective HTTP is probably the new Layer 6.

HTTP/3 uses QUIC as a layer 4 equivalent (which is actually just UDP with extra implications in practice). Not many services leverage standards-compliant QUIC other than HTTP/3, but you don't need to do HTTP to get the same protocol working.

If anything, HTTP/3 running on top of QUIC forced shitty middlebox vendors to de-ossify by permitting any QUIC-based protocol, as they cannot practically distinguish a new HTTP/3 connection from a QUIC connection.

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

#133

Post by miki123211 »

tbrownaw wrote: post #112
p_l wrote: post #18

Earlier quoted context omitted.

A lot of old RFCs explicitly mention running on top of TELNET. Additionally, as much people like to harp about "telcos focusing on connection-oriented protocols while we ran loops around them with packets", the reality is that NCP and later TCP pretty much focused on emulating serial lines around, and one of the earliest ways to access ARPAnet outside of machines directly on it was through calling into a TIP which se…

> Additionally, as much people like to harp about "telcos focusing on connection-oriented protocols while we ran loops around them with packets", the reality is that NCP and later TCP pretty much focused on emulating serial lines around, and The idea with packets is that you don't need to reserve N bit/s of each link along the route to whatever system you're talking to; instead you just repeatedly say "here's a chunk…

There's something in-between traditional (IP style) packets and traditional (TDM / ISDN style) circuit switching, where you use packets with no bandwidth guarantees, but address them by connection number, not endpoint address.

This still requires you to set up a connection beforehand, but doesn't require you to reserve resources you might not be using.

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

#134

Post by StalwartLabs »

audelair wrote: post #35
drdaeman wrote: post #14

Earlier quoted context omitted.

I'm setting up Stalwart right now, migrating from my current Maddy+Postfix+Dovecot+Rspamd setup. Not exactly my experience. The documentation is not great - I'd say it's just about barely enough to get an overall idea, but there's no one proper single definitive overview of what options exist, what are their possible values, what are the defaults, and how they relate to each other. Maddy docs, despite looking a bit s…

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…

This will get better soon. The next step on the roadmap is to refactor the configuration format and migrate most APIs to JMAP.

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

#135

Post by p_l »

tbrownaw wrote: post #112
p_l wrote: post #18

Earlier quoted context omitted.

A lot of old RFCs explicitly mention running on top of TELNET. Additionally, as much people like to harp about "telcos focusing on connection-oriented protocols while we ran loops around them with packets", the reality is that NCP and later TCP pretty much focused on emulating serial lines around, and one of the earliest ways to access ARPAnet outside of machines directly on it was through calling into a TIP which se…

> Additionally, as much people like to harp about "telcos focusing on connection-oriented protocols while we ran loops around them with packets", the reality is that NCP and later TCP pretty much focused on emulating serial lines around, and The idea with packets is that you don't need to reserve N bit/s of each link along the route to whatever system you're talking to; instead you just repeatedly say "here's a chunk…

And while certain telcos had packet network focused on that (Bell and Datakit, for example), and generally OSI cared about including QoS indicators, CLNS and its specific on-the-wire implementation CLNP is so similar to IP that IPv9 explicitly called it out in the proposal to replace IPv4 with it (because of ISO 160bit addressing)

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

#136

Post by p_l »

cyberax wrote: post #131
p_l wrote: post #81

Earlier quoted context omitted.

That's why there was an entire section for unassigned numbers. Binary protocols just meant you actually needed to implement serialiser/deserialiser and similar tooling instead of writing dumbest possible riff on strtok() and hoping your software won't be used anymore once DoD internet becomes mature

> That's why there was an entire section for unassigned numbers. That's also why the majority of OIDs in SNMP are rooted in the 1.3.6 hierarchy, which belongs to the DoD.

SNMP OIDs are in 1.3.6 because TCP/IP stack was once more well known as "DoD Internet".

And SNMP is explicitly a DoD Internet simplified alternative to CMIS

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

#138

Post by StalwartLabs »

heavyset_go wrote: post #52
dijit wrote: 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?

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

There is a new section in the documentation discussing upgrades:

https://stalw.art/docs/install/upgrade/

The goal is to stabilize the database layout/configuration format very soon so v1.0.0 can be released (hopefully before Q1/Q2 2026).

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

#139

Post by AndrewDavis »

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…

> Stalwart is essentially the first server implementation of JMAP

Just to clarify. Stalwart is the first to have JMAP contacts and calendars. Cyrus has had JMAP mail since the beginning of JMAP.

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

#140

Post by commandersaki »

Interesting I didn't know that JMAP for File Storage is a replacement for WebDAV. My experience with WebDAV is that it has traditionally been sluggish and clunky; I'm not sure if that's due to the protocol or the backend. I'm hoping this could be a huge improvement.
Post reply on HN