@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.
@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
@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.
@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.
@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
@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.
@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.
@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.
@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.
@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
@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.
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
@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.
@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?
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?
@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.
@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.
