Note by @fastfinge

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

So because I have gone temporarily off my rocker, I'm working on an #xmpp client using #dotnet 10 and WPF, with artalk-xmpp for XMPP, libsignal for #OMEMO, and prism for screen reader output where needed. I'm only an evening into it, and I can already tell that OMEMO is going to be the source of complicated, inexplicable, and unreproducible bug reports for decades to come. It's still not as overcomplicated as #matrix, though.

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

OMG what am I even doing This is a huge project it's going to need Jingle and that needs WebRTC and then file transfers and voice messages and oh also localization and sounds and hotkeys and settings and multi-account support and Oh God. even with AI this will take fifteen years why did I get out of bed today and choose this for myself

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge there's always Delta Chat which solved almost all of these problems already :)

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld I dropped Jami and signal from my life for the same reason. “Just use the official clients” is not an open protocol. Not even if the client and server are open source.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge you're completely wrong we have third party clients and more coming all the time

github.com/trufae/parla

lambadalambda.github.io/estuary/

Unreleased tui client by @jae

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae Nope. These are just running deltachat-core or libdeltachat, from what I can tell. If I want a library in C#, there is none. If I want to write my own library in C#, without depending on deltachat-core, I can't. There's no list of RFCs I can look at, nothing like xeps or IRCV3 caps, etc. It's just "use our library".

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae there is no "library" to write. It's PGP emails and SMTP/IMAP. Go ahead and do it yourself, there's nothing proprietary being implemented. It's just emails.

Name a feature that you think is some secret proprietary thing

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae It's not, though. Deltachat does weird shit with email headers to anonymize everything. I couldn't just read a message from deltachat in my regular email client. And I have no idea how they're doing federation and key exchange and things. But it's all based on weird links that require deltachat's domains and servers to exist and be running. I can't just type an email in the chat client and send a deltachat message.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae

key exchange

It's Autocrypt, there's an RFC for it

Mime headers being encrypted? There's an RFC for it

The subject header being changed to [...] is a client / chatmail server implementation detail unnecessary

The Date header being smeared +- a few days is a client implementation detail too

None of that is required

All you needed to do to read the message in your email client is decrypt it. There are users reading messages in Thunderbird/Mutt/Proton Mail

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae Interesting that everyone uses libdeltachat or deltaachat-core, then. There is no ecosystem of standards compliant implimentations. And seemingly no clear idea what that would even mean to deltachat.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae because deltachat-core is a nice implementation of the core protocols in a simple Rust package and presents a clean JSON-RPC API for you to build anything you want on top of it. And none of that has anything to do with accessibility anyway, that's all in the UI. So as long as you have a UI you can control, you're fine

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae That's what we thought with Twitter and Reddit. Then they discontinued the API's. Those are just two recent examples of something that has happened dozens of times in the last 25 years. Slack discontinuing IRC is another. If I depend on an API that could be taken away at any moment, I have nothing. If there are no competing and interoperable implementations of the standard, you're just at the whims of the owner of the one true version.

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae If I don't like the c# library I'm using to build XMPP, I can rip it out and pick another one. There are like 6 to choose from. If they disable an API I needed, I can build it myself, or use a different library. Those are not options with deltachat.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae why aren't they options? You can write your own little core in C# with pgp/imap/smtp and do it yourself and have your own API forever if you really want

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae Because the only way to find out all the implementation decisions deltachat has made is to examine the code. They're "based on" the standards they list, not compliant with them. If I write a core just with those standards as written, It's not going to work correctly with the deltachat app.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae until it was disabled by default on relays relatively recently, plaintext emails completely worked. Group chats. Video/image attachments. There's nothing quite as special about it as you think. If the MIME header is in the encrypted part, it reads that one. If it's plaintext, it reads that one.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae you want to know what a group chat is? Subject is group name, chat members are just To/CC recipients. That's it.

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae And that's documented where? Not in the RFCs, certainly. Deltachat has changed the semantic meaning of certain fields, and thus how a deltachat interoperable client must present them to users in order to limit confusion and achieve feature parody. There's "What CC means in deltachat land" and "What CC means in email". From a UI and UX and feature compatibility perspective those are critical differences.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae name one field they changed

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae You just did. "CC" in deltachat land is "group chat". That's not how a normal email client uses it.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae I didn't say that, I said an email thread is a group chat. Just throw the recipients in to/cc and it works.

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae So what about the reply-to email address? What should my mythical interoperable client do with that? Or "on behalf of"? Do I mark large threads with the mailing list headers? Do I specify the msgid my email is in reply to in the headers or not? Are group chats expected to support threads or always be flat? A chatmail client can't be dfully compatible without documented answers to these questions. And the documents that answer those questions are usually, you know, the documents defining the standard.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae

So what about the reply-to email address? Or "on behalf of"?

why would you need to set a reply-to header? I guess you could but why?

Do I mark large threads with the mailing list headers?

it's not a mailing list and doesn't use mailing list style headers

Are group chats expected to support threads or always be flat?

Flat for now but it's possible to change the subject of a reply to make something that would be a subthread. Some email clients kinda work that way. I've asked but this isn't planned because there's no real RFC for this kind of thing. If you want a "subthread" you can literally just use the client functionality to clone that chat to a new one, set a new subject for the subthread, and continue there. It's basically a shortcut for starting a whole new group chat is all, nothing special.

You're overcomplicating it again.

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae There is absolutely a standard for this; usenet and email has had the in reply to header for years. But now we know chatmail doesn't use it, I guess.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae I think you misunderstand: what purpose would this header possibly be used for in a chat client situation?

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae Showing message threads, the way slack and discord do, and having multiple threads in a single chat.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae you would use in-reply-to and on-behalf-of for that ? For a message thread?

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae in reply to, yes. See: cr.yp.to/immhf/thread.html

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae I'm sorry I kept reading "In-Reply-To" as just "Reply-To" and I was like "Why would you want the other person to reply to some other address??????"

Yes, In-Reply-To is used... that's the normal MIME header for threads, it has the . Which I told you an email thread is just a group chat. Both In-Reply-To and References are used.

I've never seen On-Behalf-Of used anywhere (at all, period, in all my years of email usage). I just searched my email archive going back 20+ years (all MIME headers are indexed) and I don't have a single email with On-Behalf-Of.

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae And when this changed, how were the authors of third party clients notified? Was there an open discussion period at a standards committee or a request for comment? No, because the assumption is that everyone should just use libdeltachat. That's not how open standards work.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae that wasn't a client change that was a server change and people who didn't want it didn't deploy that server change.

you can still right now connect DeltaChat to regular email servers and send messages around unencrypted. I wouldn't recommend it but you can do it.

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae But my client connects to the servers. If they make a change it's going to just break my client without notice. That's a change that needs to be reflected by a new version of some standards document, somewhere.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae connects to which servers? if you choose to use someone else's server, yes, you get their limitations like how large of an attachment they'll allow.

nobody is forcing you to use any servers operated by DeltaChat or running the Chatmail configuration

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae And what if I send a message to another deltachat user on a different server from mine? How should that be handled? Will they refuse it if it's plaintext? What will I get in return, and how do I surface that to my user? I'm certain it's going to be different from how an email client would handle it. Either way, there's no, you know, standards document documenting these kind of implementation requirements for my third party client. And no infrastructure for warning me when they are about to change, so I can let my user's know we're only compliant with chatmail standard version 5, but an update to bring the new features and requirements of chatmail version 8 is coming soon.

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae Also, if I choose not to implement deltachat apps in my chatmail client, what is the method of capability negotiation that I should use to indicate that to the deltachat app, and let that user/app know what features I do and do not support? What if I create shiny feature X? How do I tell deltachat to indicate support for that feature? Without those bits, any third party chatmail client is going to just break randomly for users, and nobody on either end will know why.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae

Also, if I choose not to implement deltachat apps in my chatmail client, what is the method of capability negotiation that I should use to indicate that to the deltachat app

You don't have to do anything, like Parla for example doesn't support WebXDC apps at all because it doesn't have a browser engine to run them in. The app is just a zip file with a .xdc extension. You could choose to just ignore those messages or display the attachment for download or do whatever you want really

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae So then my grandmother gets strange inexplicable zip files from her cousin who wants to play a Wheel of Fortune game together. And neither my grandmother nor my cousin can understand why it's not working. My cousin, in fact, would have no way of knowing the app she sent did not run. That's a terrible experience all around.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae what client is your grandmother running? A custom one that you wrote and you didn't implement all the functionality yet?

I gotta say Samuel it sounds to me like you really want to reinvent XMPP and the XEP hell where you never know what the other person's client actually supports

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae But because the standards are defined, and capability negotiation is part of them, you always know what the other person's client supports, and what both of your servers will allow. With deltachat, that's impossible. And my grandmother uses the console and runs a text based client. She can never run deltachat apps. But her client can never tell any other client it interacts with about that limitation.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae

And what if I send a message to another deltachat user on a different server from mine? How should that be handled?

I don't know what you mean? It's just an email address, it gets sent by your email server like any other email.

Will they refuse it if it's plaintext?

They could, just like they can refuse a message with an attachment that's too big. But why are you trying so hard to send plaintext emails anyway?

Everything you've described today is like one-millionth as complicated as the mess you're dealing with in regards to multiple competing OMEMO standards and not knowing who has what, or trying to figure out which client has which XEPs

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae It's really not. To know what a server supports, you just ask it. And it will return the list of capabilities it has in a standard way. Same for other clients. Service and capability discovery are solved problems. Deltachat seems to just ignore them completely, because the expectation is that everyone should just use libdeltachat.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae you're talking about what a server supports, not what a client supports. How do you know if your friend's client can receive a call? That isn't communicated to your client in XMPP is it?

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae Yup, it sure does! XEP-0030 allows any client or server to be queried about exactly what features it does and does not support.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae but what if they didn't implement XEP-0030

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae Then they're not an XMPP compatible client, and servers should just drop them with an error.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae so there are non-optional XEPs that shouldn't be XEPs?

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae Why does the fact it's required mean it shouldn't be a xep? If someone wants to change how service discovery works, they can create a new xep. If everyone else agrees, after an open discussion on a standards mailing list, XEP-0030 can become deprecated, and the new service discovery xep will be the required one. Most current clients will probably implement both, but over the years new clients will only do the new xep, and eventually clients will slowly drop the deprecated one. This is how controlled transitions, and making changes to an open standard, work.

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae If you check the xmpp website, there are many xeps that are marked deprecated. And many others marked not yet widely supported. Developers should implement accordingly, with full transparency into what the standard is now, what it's going to be in the future, and what it was in the past. This is the only way you can get thousands of different people and organizations to build things that all interoperate.

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae Note that this is exactly how the fediverse works. Start with Activity Pub, then consult the list of feps. Nobody gets to say "just use libfediverse". The code is not the standard. codeberg.org/fediverse/fep

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae every Fediverse server has to implement the Mastodon quirks or you can't federate with Mastodon. If you want to know what they are I can share some, but we're getting way off course here

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae Yes, and that was because of exactly the same stupid thing I'm complaining that deltachat does. We let mastodon define the standard in code, and now we're all stuck with its crap. Hopefully, in time, Mastodon will be small enough that it has to be a good fediverse citizen and not just do whatever the hell it wants. I run an iceshrimp.net instance myself, I know all about Mastodon's nonsense.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae if you knew it was all a lie, why did you use it as a shining example? It's a terrible example and no, sadly, nobody is going to dethrone Mastodon. This entire network will die before then.

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae I did not use it as an example. I used the fediverse, and the fep infrastructure, as an example. That's how things should work. The way both Mastodon and Deltachat do things are the anti-pattern here.

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae Some xeps are optional, and some are required. The XMPP standards are quite clear about what's optional and what is not.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae that's incredibly stupid tbh

this whole thing is terrible.

So XEP-0030 is only required by XEP-0073: Basic IM Protocol Suite, but that has been obsoleted and superseded many many times by XEPs which have become called:

XEP-####: XMPP Compliance Suites YYYY

So they kept rolling the expected core list of XEPs into new XEPs.

Except all the old ones are OBSOLETE and the latest one (XEP-0479: XMPP Compliance Suites 2023) is marked EXPERIMENTAL

So now people have to chase experimental XEPs to be part of the modern XMPP network. No stability?

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae You don't have to conform to XEP-0479. You can (and should) conform to the previous one. But you should also be working on the stuff in XEP-0479, because eventually it's going to not be experimental, so you should be thinking about how your client can be ready for that. Instead of having some random person make a configuration change, and surprise! The standard is now different in a way you didn't have like seven years to prep your code for.

Only 3 Easy Payments of $19.95 @feld@friedcheese.us

@fastfinge @jae why should I conform to the one that's OBSOLETE though, this is just stupid

🇨🇦Samuel Proulx🇨🇦 @fastfinge@interfree.ca

@feld @jae Because none of the xeps it lists are obsolete, so you'll have to do that, anyway, just naturally as a side-effect of writing an xmpp client or server that other people will federate with and talk to. That list is just a useful resource.