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