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