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

MostlyBlindGamer @MostlyBlindGamer@dragonscave.space

Software development, LLMs

@fastfinge and this is why LLMs can’t really make software. What you’re dealing with are problems of architecture and product and project management. Coming up with and managing a feature backlog, prioritizing, planning ahead…
The issue is that you actually learn to do these things by being involved in them - with other humans - which LLMs won’t and can’t do for you.

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

Software development, LLMs

@MostlyBlindGamer I’m comfortable with those things. It’s just that shock of going from something that connects and saves messages to something actually useful and the work involved

Jack-Frostodon @jackf723@mastodon.social

Software development, LLMs

@fastfinge Looks like a Brigove SDK release recently landed, with libbrigove.batteriesincluded which ought to provide some simplification.
borogove.dev/docs/
Not sure how directly it would work with servers other than Snikket, but I imagine not too badly given it's based on the XMPP protocol as it is.

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

Software development, LLMs

@jackf723 Looks like this would involve writing dotnet bindings myself, though. And then publishing them to nuget etc. Not sure if this is a better approach than using a library like artalk written and intended for DotNet.

Jack-Frostodon @jackf723@mastodon.social

Software development, LLMs

@fastfinge Oh, definitely not in its current form so it would seem. Not worth it over more stable libs when about the only truly Snikket-specific thing Brigove likely handles more directly is invites. Everything other than that is plainly standards-driven already.

Andre Louis @FreakyFwoof@universeodon.com

Software development, LLMs

@MostlyBlindGamer @fastfinge Wait, they can't? Did I just dream the last three months of my life then? How odd.

James Scholes @jscholes@dragonscave.space

@fastfinge Do you know how many posts come across my timeline to which I want to unproductively respond to with "Aye, good luck with that?" Not that this is related in any way. Don't know why I'm even bringing it up.

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

@jscholes The problem is that I want this to exist, and nobody else is doing it. And I'm tired of the many broken things about Miranda's XMPP support.

plzupgrademe @plzupgrademe@fedi.txw.ca

@fastfinge @jscholes same I was tired of there being no nice client on MacOS for me. Fluxx looks nice, but has no omemo.

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 But it’s an electron app. With no open standards process to develop a third party implementation. So if deltachat decides to stop caring about accessibility some day, I’m screwed. They control the protocol from end to end. If it’s not an open standard I’m not interested. I’ve been betrayed by too many organizations at this point. Especially nonprofit open source ones.

🇨🇦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".

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

@feld @jae If I would like to propose a change to the standard, the only way I see to do it would be submitting a PR to libdeltachat. There doesn't seem to be any standards process outside of that. That is not an open, standards-based protocol. That's just "using someone's thing and building on it".

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

@fastfinge @jae if you want a change, write an RFC. That's why Autocrypt v2 is an RFC.

Emoji reactions? Its an RFC.

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.

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

@feld @jae Or if it is, it's not developer friendly at all. For XMPP, I can look at the list of xeps to know exactly what my client needs to implement to achieve various levels of compatibility with the standard: xmpp.org/extensions/

Same for IRCV3, the list of rfcs and extensions is all right there: ircv3.net/irc/

I have no idea where any of this info lives for deltachat. The website and github don't make it obvious. What parts of email do I need? What parts of PGP do I need? I guess I need to do autocrypt based on your message. But what is the name of the standard that deltachat is even targeting? Chatmail, I guess? What do I need to have to be a "chatmail compatible client"? Are there test suites I should pass?

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

@fastfinge @jae the main website says "built on internet standards" and links here:

github.com/chatmail/core/blob/main/standards.md

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

@feld @jae And that document is either out of date or false. Deltachat's misuse of subject lines, date smearing, etc, are absolutely in violation of the RFCs. Notice they never claim they follow or comply with the standards. They're just "based on them". Just following those standards will not result in a client that in any way can be used seamlessly with other deltachat users, or is guaranteed to interoperate with them.

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

@fastfinge @jae

Deltachat's misuse of subject lines, date smearing, etc, are absolutely in violation of the RFCs.

No it's not. The subject and date headers are that way because we've found mail servers that will not accept completely removing them even though that's fully supported by RFC 9788. If you have never heard of this RFC before, it's what allows you to disregard ALL plaintext headers and put them all inside the PGP encrypted part.

datatracker.ietf.org/doc/rfc9788/

ᴏᴏᴍ-ᴋɪʟʟᴇʀ: 333[𝟱𝟬𝗽𝘀𝗶 𝘁𝗼𝗶𝗹𝗲𝘁]™ @jae@bsd.cafe

@fastfinge @feld most of the docs are out of date. its something i wanted to fix but didn't work out so i stopped trying to hop the gatekeepers

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

@feld @jae And there's not even any mention of the weird peer to peer app package stuff they do. If I want to fully interoperate with deltachat, it seems like I need that for stuff like voice calls and other future Realtime things (typing indicators?).

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

@fastfinge @jae

the peer to peer apps are WebXDC, also a standard: webxdc.org

That's literally what the "web apps in chats" link on the main webpage goes to. It's not hidden. The p2p functionality is not special or hidden, it's just Iroh which is also documented on the webxdc site.

voice calls

it's just WebRTC, nothing special. You will need a STUN/TURN server most likely though. Chatmail relays provide one to clients with a password accessible under an IMAP METADATA command, otherwise you can point your client to any TURN server you want

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

@feld @jae I'm glad you know this stuff. Wake me up when there are multiple independent chatmail implementations that I can pick from, and what I decide to use is completely transparent to the people I'm chatting with. Until then I'm just not interested in getting my friends and lovers to switch to something that could be ripped away from me at any second, because deltachat decided it didn't want to do an RPC API anymore, and everyone should just shut up and use their client.

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.

🇨🇦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

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 If someone cannot write a fully interoperable client, without examination of deltachat code, it's not an open standard. It's just a reference implementation.

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

@fastfinge @jae just want to be sure: have you ever seen this ? It was linked from the standards list

github.com/chatmail/core/blob/main/spec.md#chat-mail-specification

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

@feld @jae I did. But I submit that that's not enough for someone to go off and develop their own chatmail client, and then expect it to just work with deltachat. Whereas I can (and have) developed my own IRCV3 clients and had them "just work" without reference to anyone else's implementation, and am currently (though I'm using one of many libraries) developing a client that I can expect to "just work" on XMPP. For features I can't or don't want to implement, I can communicate to other servers and clients that users of my client don't have those features, I can know if another client supports a particular feature and give my user a friendly error if not, and I can do it all based on a normal looking jabber ID without requiring enormous web URLs that depend on the continued existence of deltachat's domains and servers. And my accessibility needs don't depend on the decisions and good intentions of some other organization.

Honestly, I like the idea of deltachat. I don't like the massive electron app, and I don't like being dependant on deltachat as an organization to do the right thing for accessibility. So I won't build any important workflows or relationships around it, or be part of any community that requires it.

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

@feld @jae Heck, just last week I contributed a pull request to this, as I was using and testing it to figure out what the ecosystem is like for third party clients and bots on deltachat: github.com/Simon-Laux/hermes-deltachat-platform/pull/2

ᴏᴏᴍ-ᴋɪʟʟᴇʀ: 333[𝟱𝟬𝗽𝘀𝗶 𝘁𝗼𝗶𝗹𝗲𝘁]™ @jae@bsd.cafe

@fastfinge @feld thanks for the pr on that repo, i pulled it in as well. @treefit and i are doing some interesting things with #hermes and #deltachat i've also started an xmpp integration, but i'm stuck on #omemo implementation which i always seem to trip up on that xep

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

@jae @feld @treefit I’ve done xmpp and Hermes’ already: github.com/fastfinge/hermes-xmpp-plugin

ᴏᴏᴍ-ᴋɪʟʟᴇʀ: 333[𝟱𝟬𝗽𝘀𝗶 𝘁𝗼𝗶𝗹𝗲𝘁]™ @jae@bsd.cafe

@fastfinge @feld @treefit just wired it up to both agents. works nicely. may have a pr for you with some ideas soon

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

@jae @feld @treefit I would love prs. Data forms interactions also need love. I don’t use those features myself so they’re not battle tested.

ArcaneChat @arcanechat@fosstodon.org

@fastfinge

without requiring enormous web URLs that depend on the continued existence of deltachat's domains and servers

this is actually a misconception, there is no need or dependency on any delta chat URL, the invite links i.delta.chat are just a nice clickable representation of the actual invite link that is a openpgp4fpr:... link and you can easily convert an i.delta.chat link into openpgp4fpr

@feld @jae

ArcaneChat @arcanechat@fosstodon.org

@fastfinge

If I don't like the c# library I'm using to build XMPP, I can rip it out and pick another one

which already implies they each have different features or lack thereof, which is exactly the exact same situation you have in XMPP with a lot of fragmentation,

in fact, it is better if people don't create their own chatmail core implementation

if Delta Chat becomes evil, the core is open and you can just fork it and keep using it, no one can take anything away from you

@feld @jae

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

@arcanechat @feld @jae If deltachat doesn’t want people indipendantly authoring libraries that use its protocol it is not an open standard. End of story.

ArcaneChat @arcanechat@fosstodon.org

@fastfinge if you don't want to have a shared-effort security-audited implementation that everyone uses, but instead waste resources with several people re-implementing the wheel and causing incompatibility between clients, assuming people want to have to deal with "ah Paul your client don't support this and that"

then in fact, you will only make more damage than help the chatmail ecosystem, please, keep ruining xmpp 🙏

@feld @jae

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

@arcanechat @feld @jae Deltachat is just as much of a poison to openness as Bluesky and threads. All marketing and vibes to capture users.

ArcaneChat @arcanechat@fosstodon.org

@fastfinge not at all, but you are free to have your own wrong opinions, have a nice day

@feld @jae

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

@arcanechat @fastfinge @jae if XMPP's design by committee process was in any way conducive to producing good results we'd have multiple high quality cross-platform XMPP clients right now that would make nobody care about Telegram or Signal or Whatsapp because literally all the same functionality is implemented (the XEPs are there, it should be possible!) and it would have the largest network effect because zero lock-in, so there would be no excuse to not be using XMPP

But there's zero high quality cross-platform XMPP clients because this process doesn't work

and then Delta Chat makes the right decisions:

- build a quality core everyone can use which guarantees compatibility and an even playing field of security (not even Signal can claim this -- e.g., each app has a completely different networking implementation)

- build an app for each major platform and make them as identical as possible -- originally built off a good design that users are comfortable with: the actual Telegram client

- publish them all under the same name/logo because modern users think of "platforms" not "protocols"

- do the groundwork to be prepared if the app ever gets blocked/banned or Merlinux sued/shutdown so the same Delta Chat app can be published under a different name by someone else

- work hard to produce RFCs that are useful for everyone, not just Delta Chat (e.g., AutoCrypt v2 is meant to be used for ANY protocol, not just Delta Chat / email -- which is also co-published by someone from IETF/ACLU, an active OpenPGP member, and a Delta Chat member)

- provide a ton of documentation and user support resources

- provide a realtime feedback channels to all interested parties who are running their own Chatmail Relays

- bend over backwards to provide extensive backwards compatibility

- be actively involved with helping real groups of disadvantaged people around the world who suffer under oppressive governments, actually fly to remote places and provide information and training

- provide more details of the project's funding methodology than probably any other open source project that has existed

- actually go to court to fight for users' rights (e.g., Delta Chat in Russia last summer)

but this is just not enough for some people and either the project is considered too opaque/proprietary, or gets complaints that they shouldn't be using email this way

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

@feld @arcanechat @jae Those all sound like intentionally promoting lock in to me. The long and short of it is: tomorrow deltachat could wake up and decide it doesn’t care about screen readers anymore. When they do, I’m locked out. That makes deltachat a danger to me and my community, and is just not possible to lock us out of xmpp in the same way, even if people wanted to. Until that changes, I have to treat deltachat the same way I treat any other hostile closed protocols: don’t depend on, promote, or trust it.

ᴏᴏᴍ-ᴋɪʟʟᴇʀ: 333[𝟱𝟬𝗽𝘀𝗶 𝘁𝗼𝗶𝗹𝗲𝘁]™ @jae@bsd.cafe

@fastfinge @feld @arcanechat i have macular degeneration. im moving to screen reader mode more frequently and eventually totally as its rapid. this affects me also now that ive had time to digest this very short thread

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

@jae @feld @arcanechat I should clarify that deltachat is currently really really good about accessibility. But so was Twitter, once. Organizations change. And if you have a disability, you always have to have a plan for that, for every tool you use. When accessibility breaks, you need to be certain you have a way out. Preferably one that doesn’t involve forcing all of your friends to change apps, yet again. I don’t care how much they love you: you can probably get them to change once. But not twice.

wafflesies @wafflesies@infosec.exchange

@feld @fastfinge @arcanechat @jae isn't whatsapp just xmpp in the backend? Could be mistaken but maybe the solution is throw billions of dollars at something and it'll come out popular and polished

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

@wafflesies @feld @arcanechat @jae I think it’s signal not xmpp.

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

@wafflesies @fastfinge @arcanechat @jae correct, WhatsApp is just XMPP in a trenchcoat

Same with iMessage. And all push notification stuff on iOS/MacOS (APNS) is also just XMPP messages.

There's a bunch of IoT stuff out there using XMPP as well (and in some rare cases Matrix, but why would you do that, it's a blockchain essentially, what a huge misuse)

Tons of XMPP out there in the world, but mostly for specialized use cases or proprietary messenger implementations because clearly trying to work with the standards body means you won't get to deliver anything to users until next decade instead of today

edit: Yes Whatsapp is XMPP, it was ejabberd running on FreeBSD servers

Johnny Peligro @mischievoustomato@tsundere.love

@feld @fastfinge @arcanechat @wafflesies @jae xmpp shines when its anything but decentralized
cc @anemone

rakoo @rakoo@blah.rako.space

15h

@fastfinge
Deltachat doesn't care that you're doing your own independent implementation. You can do your own, just like you can do your own http implem or json implem. The balance here is on where you want to bring value: to the ecosystem first, or to the users first. The claim is that for the same you can't prioritize both at the same time, for the same amount of work you either truly push on one side or the other or make mild improvements to both.

A high-quality C# core would certainly be high value. I can't stand rust and I can't even compile chatmail core, it takes too much resources. The ecosystem would greatly benefit from your work !

@feld @arcanechat @jae

ᴏᴏᴍ-ᴋɪʟʟᴇʀ: 333[𝟱𝟬𝗽𝘀𝗶 𝘁𝗼𝗶𝗹𝗲𝘁]™ @jae@bsd.cafe

10h

@rakoo @fastfinge @arcanechat @feld even on a strong machine compiling rust core causes a fever. fastfringe if so inclined could likely add a lot of value in the user side.

ArcaneChat @arcanechat@fosstodon.org

@fastfinge you are comparing a web API of a central server to a local API of a library

which is completely wrong, for your information, ArcaneChat uses its own core that is a fork of the official chatmail core with some modifications and additions

you can do the same and of course you could implement a chatmail core in C# if you wanted to but it is a lot of useless uninteresting work reinventing the wheel while you didn't deliver anything useful to the users

@feld @jae

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

@arcanechat @feld @jae And what happens when the local library is discontinued in order to force everyone onto the official clients? From what I can tell no other viable library exists. I never build on an app or library controlled by the same organization that controls the protocol for that reason.

ArcaneChat @arcanechat@fosstodon.org

@fastfinge for that first the whole client needs to become proprietary, and as said you can always fork it, as we are already doing, at that point then the community can keep developing the chatmail core

it will only mean a different group of people continuing the project, people don't last forever anyway so this is something that has to happen one way or another

@feld @jae

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

@arcanechat @feld @jae But when deltachat includes proprietary features your fork is screwed because the protocol won’t allow capability negotiation. So deltachat still effectively controls you.

ArcaneChat @arcanechat@fosstodon.org

@fastfinge my friend, this can and is done all the same in xmpp

can your lil xmpp client communicate with WhatsApp or all the many custom proprietary xmpp platforms out there???

if Delta Chat does some "proprietary"-something at that point they will likely even turn off federation, I would not care to be compatible with them at that point, and the current federation of chatmail servers will continue to work all the same by voluntaries

@feld @jae

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

@arcanechat @feld @jae Watsapp is not and doesn’t claim to be xmpp compatible. So who cares what they do? I don’t use them.

plzupgrademe @plzupgrademe@fedi.txw.ca

@fastfinge it is. File Transfers are not so difficult on XMPP, they’re really just HTTPS.

Jingle is a big effort. Be prepared to learn about ICE, DTLS, STUN, TURN et al.

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

@plzupgrademe I think this library has everything I need for Jingle. The same way you did for mac, I'm doing for Windows. So that makes it simpler because I want to just be Windows native whenever possible. So no cross platform worries. github.com/sipsorcery-org/sipsorcery

plzupgrademe @plzupgrademe@fedi.txw.ca

@fastfinge sadly I wanted to make it a truly modern macOS first class citizen, so the app is using 100% Swift. So not a lot to leverage.