111–120 of 204 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
Yeah, a fair bit of email protocol reeks of "is this tolerant of `telnet mailserver 25` and whatever garbage that might produce".
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…
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 of data, send it to X". It's not really relevant that the typical thing to do with these packets is to build a reliable stream on top of them, what matters is that everything except the endpoints can be a lot dumber.
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 touc…
Never hosted Postfix / Dovecot stack, in fact this is the first time I host emails, but from what I understand Stalwart is designed to handle inbound directly.
For very high throughput inbound you could check out KumaMTA - it was designed specifically for that, but I think Stalwart doesn’t have bottlenecks in it’s clustered topologies which would require it unless you are doing something crazy.
They have very good docs in general IMO, here are docs on how to cluster - https://stalw.art/docs/cluster/configuration
Earlier quoted context omitted.
> 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…
Using cents instead of dollars sounds fine until you have to do math like VAT, you really need decimal math for that.
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 was originally thinking you'd need to go remote IMAP maildir Stalwart IMAP, which would be really complicated, but I think the IMAP IMAP should work fine.
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.
Earlier quoted context omitted.
> 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…
While the grammar is specified (that’s what JSON is, after all), the runtime representation is unspecified. A conformant JSON parser can parse “1” as 1.0. They can be backed by doubles, or singles, or arbitrary precision.
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…
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.
Earlier quoted context omitted.
I think that the point is this: You could literally use a telnet client to talk to all of those servers and it was considered a good thing, maybe even an essential feature. So protocol design was somehow influenced by the need to be fully plain text ASCII streams (and maybe that other options weren't adequately explored due to this restriction)
You can also telnet into port 80 and communicate with an HTTP server.
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.
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 many Stalwart libraries. Think Geary but Rust instead of Vala, GTK4 instead of GTK3 and JMAP instead of IMAP. It’s been mostly an excuse to play with Rust and gtk-rs and Relm4 (beautiful Elm inspired rust bindings for GTK4). Someday, it will be released.
Client support for a new protocol is never that quick, but I believe adoption will happen, at least outside of the big providers, who will never support it.