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.
You might take a look into #UWPX, a once promising, but later abandoned #Jabber/#XMPP client by #FabianSauter a.k.a. #COM8 (not on #fediverse?):
https://github.com/UWPX/UWPX-Client
Maybe you can even take over his work instead of starting from scratch?
IIRC, it does have #OMEMO, but no A/V calls, no message reactions, maybe #MAM, not sure.
@fastfinge another instance of "there's no good #xmpp client, let's do another one that probably will never be good either"?
Gajim and Dino can run on Windows and macOS. Sure, they don't work great and don't feel native, but fixing those issues is probably easier than starting from scratch. Just saying.
I'm not sure, how good #accessibility is with #GTK on Windows, which is most relevant here. Do you happen to know?
But, yes, a cross-platform client would be good, as new features and bug fixes from one platform make it to the other.
@debacle @pixelschubsi As with all things Linux related, gtk accessibility is really bad. Completely unusable on windows last I checked.
@debacle @fastfinge GTK uses AccessKit, a cross-platform accessibility API. There might be issues with it, but fixing those would also bring immediately more benefit to a lot of apps, not only XMPP clients or GTK apps.
@fastfinge@interfree.ca
Maybe checkout #ox (#OpenPGP for #XMPP). It's not as complicated as #OMEMO. it's currently supported by #profanity, #gajim and #GoSendxmpp. #Conversations is currently working on support.
Maybe checkout #ox (#OpenPGP for #XMPP). It's not as complicated as #OMEMO. it's currently supported by #profanity, #gajim and #GoSendxmpp. #Conversations is currently working on support.
@martin @fastfinge
BTW, profanity and dino are not using libsignal, for omemo. Both are using libomemo-c.
https://tracker.debian.org/pkg/libomemo-c
BTW, profanity and dino are not using libsignal, for omemo. Both are using libomemo-c.
https://tracker.debian.org/pkg/libomemo-c
- replies
- 0
- announces
- 0
- likes
- 1
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
@fastfinge there's always Delta Chat which solved almost all of these problems already :)
@fastfinge it was an eye opener for me to realize there is an omemo:legacy, and omemo:2 and an omemo:1. I look forward to trying your app.
@plzupgrademe Personally, I'm using Snikket for end to end testing. If the Snikket server doesn't support it, or the Snikket client (just rebranded Monal) can't deal with it, it's not high on my list of priorities. Yes, I know that's a terrible way to implement an open standard. But Snikket is the server I use, and Monal is the client I and everyone I know uses on IOS. So a desktop app needs to work with them to be useful to me. And features they don't support are features I'll never be able to use.
@fastfinge @plzupgrademe snikket IOS isn't a rebranded Monal, but a rebranded siskin. You can tell from the notification problems as documented over here: https://eversten.net/en/blog/notification/
@fastfinge Ive been playing with The Dotnet ecosystem recently, and I have to say I'm impressed. As long as you.re willing to write a common core and per-platform UIs, it's the framework to go with. It's the only way I know of to get native UIs on every platform without cross-language pain.
@miki Yup. Though in this particular case I can't be cross platform, because I need to use windows encryption primitives to safely store OMEMO keys and usernames and passwords and things.
@fastfinge You could expose these behind an abstraction and use Keychain on Mac, for example.
@miki I could. But then I'm trusting myself to write a secure abstraction layer. And I do not.
@fastfinge @miki perhaps instead of an abstraction layer, just a side-by-side (sxs) platform-specific optimization.
I’m using Keychain, but when with using trusted primitives, it’s always possible to use an effective lock in an ineffective way.
@plzupgrademe @miki Maybe someday. But there are good clients on Mac and Linux already. So Windows is my priority number 1.
@fastfinge @miki @plzupgrademe short question: why not participate in gajim development and help improving it rather than reinviting the wheel once again?
That approach would help the ecosystem way more than starting yet another client and abandoning it half way through. Just my two cents.
@martin I had heard that this was discouraged by the XMPP foundation for...unclear reasons?
@fastfinge@interfree.ca
What makes you think so? The xeps are experimental/deferred but it's not discouraged.
What makes you think so? The xeps are experimental/deferred but it's not discouraged.
@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.
@fastfinge you're completely wrong we have third party clients and more coming all the time
https://github.com/trufae/parla
https://lambadalambda.github.io/estuary/
Unreleased tui client by @jae
https://github.com/trufae/parla
https://lambadalambda.github.io/estuary/
Unreleased tui client by @jae
@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
Name a feature that you think is some secret proprietary thing
@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".
@fastfinge @jae if you want a change, write an RFC. That's why Autocrypt v2 is an RFC.
Emoji reactions? Its an RFC.
Emoji reactions? Its an RFC.
@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.
@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
> 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
@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?
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?
@fastfinge @jae the main website says "built on internet standards" and links here:
https://github.com/chatmail/core/blob/main/standards.md
https://github.com/chatmail/core/blob/main/standards.md
@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 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.
@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.
https://datatracker.ietf.org/doc/rfc9788/
> 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.
https://datatracker.ietf.org/doc/rfc9788/
@fastfinge @jae
the peer to peer apps are WebXDC, also a standard: https://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
the peer to peer apps are WebXDC, also a standard: https://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
@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.
@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.
@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.
@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.
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.
@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.
@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.
@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
nobody is forcing you to use any servers operated by DeltaChat or running the Chatmail configuration
@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.
@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.
> 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.
@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.
@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
> 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
@fastfinge @jae I think you misunderstand: what purpose would this header possibly be used for in a chat client situation?
@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.
@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
> 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
@fastfinge @jae you would use in-reply-to and on-behalf-of for that ? For a message thread?
@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?
@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
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
@fastfinge @jae but what if they didn't implement XEP-0030
@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.
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.
@fastfinge @jae so there are non-optional XEPs that shouldn't be XEPs?
@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?
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?
@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.
@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
@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
@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.
@fastfinge @jae why should I conform to the one that's OBSOLETE though, this is just stupid
@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.
@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.
@fastfinge @jae just want to be sure: have you ever seen this ? It was linked from the standards list
https://github.com/chatmail/core/blob/main/spec.md#chat-mail-specification
https://github.com/chatmail/core/blob/main/spec.md#chat-mail-specification
@martin@social.mdosch.de
Maybe your mixing it up with legacy PGP xep-0027 which you shall really not use anymore.
@fastfinge@interfree.ca @fastfinge@interfree.ca
Maybe your mixing it up with legacy PGP xep-0027 which you shall really not use anymore.
@fastfinge@interfree.ca @fastfinge@interfree.ca
@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
@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.
@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 🙏
@arcanechat @feld @jae Deltachat is just as much of a poison to openness as Bluesky and threads. All marketing and vibes to capture users.
@fastfinge not at all, but you are free to have your own wrong opinions, have a nice day
@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
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
@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.
@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
@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.
@fastfinge @arcanechat @jae which XMPP client are you using that has good accessibility, is open source, and you don't have to worry about rotting in the app store and eventually just getting removed?
@fastfinge @arcanechat @jae I've been fortunate enough to convince them to change many times, so I guess they really really love me
IRC to GTalk to XMPP (bc gtalk shutdown) to Whatsapp (because XMPP was miserable) to Telegram to DeltaChat
IRC to GTalk to XMPP (bc gtalk shutdown) to Whatsapp (because XMPP was miserable) to Telegram to DeltaChat
@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
@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
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
@feld @arcanechat @jae Or you have techy friends. But even if they’d agree, I’m not teaching my elderly relatives deltachat just to have to teach them something else when, not if it breaks accessibility.
@fastfinge @arcanechat @jae kinda ironic tbh as elderly users are one of the biggest success stories of Delta Chat especially as they never have to think about the concept of a username or password
@feld @fastfinge @arcanechat @wafflesies @jae xmpp shines when its anything but decentralized
cc @anemone
cc @anemone
@mischievoustomato @anemone @feld @wafflesies @arcanechat @jae This is not at all correct. WhatsApp uses the Signal Protocol. No relation to XMPP. en.wikipedia.org/wiki/Signal_Protocol
@fastfinge @anemone @mischievoustomato @wafflesies @arcanechat @jae Signal/Noise protocol is for E2EE, not what's inside. What's inside is a custom binary implementation of XMPP essentially
Here's a repo of someone reverse engineering this protocol:
https://github.com/raphaelvserafim/whatsapp-binary/
There's XMPP in there still, but they ripped out all the parts they didn't want or didn't scale
Here's a repo of someone reverse engineering this protocol:
https://github.com/raphaelvserafim/whatsapp-binary/
There's XMPP in there still, but they ripped out all the parts they didn't want or didn't scale
@feld @anemone @mischievoustomato @wafflesies @arcanechat @jae Interesting. Maybe the EU gateway provider thing will force them to federate again. Though I doubt it.
@fastfinge @anemone @mischievoustomato @wafflesies @arcanechat @jae they'll do what everyone else is doing: spin up a company with a couple employees, build a proof of concept messenger that "federates" but restrict who can actually use it, then tell the EU gov that you satisfied their requirements because another company can interoperate with their network
@feld @arcanechat @jae You can do passwordless XMPP. Nobody does, but you can. And there's a standard for it. So when one or more people eventually do, it'll work in both apps that decide to do it, in the same way.
@feld @arcanechat @jae And "Just use our client and our library and our invite links, because that's what openness means," can be the tagline of deltachat.
@fastfinge @arcanechat @jae the invite links situation is well under its way to being solved precisely because of censorship and single point of failure sorts of things
but anyway -- if someone already has Delta Chat app installed, they never actually access https://i.delta.chat as the app intercepts the URL
but anyway -- if someone already has Delta Chat app installed, they never actually access https://i.delta.chat as the app intercepts the URL
@feld @arcanechat @jae That's good. Now once there's a viable implementation not using deltachat's libraries or controlled by deltachat, and a way for the two clients to negotiate capabilities so they aren't forced to just be identical, I can happily use and promote it. Deltachat has good ideas. It's just not safe for me, or anyone else with a disability, to risk becoming dependant on. Because "small open-source underfunded organization stops caring about accessibility" is a far more likely threat to my use-case than "government blocks my instant messenger". It's also a threat that has happened repeatedly, and will continue to happen.
@fastfinge @arcanechat @jae
> and a way for the two clients to negotiate capabilities so they aren't forced to just be identical
Why is everyone SO obsessed with trying to build a messenger ecosystem with asymmetric features/capabilities?! What a total shit show that is for everyone -- developers and users
> and a way for the two clients to negotiate capabilities so they aren't forced to just be identical
Why is everyone SO obsessed with trying to build a messenger ecosystem with asymmetric features/capabilities?! What a total shit show that is for everyone -- developers and users
@feld @arcanechat @jae Because in the real world, everyone has different needs. My friends E-ink display can't show moving videos. My ESP32 controller doesn't run JavaScript, so can't participate in Deltachat Apps. My headless Linux box has no audio or video support, so can't do voice or video calls. I can't see images at all, so would prefer that servers not waste my mobile data by sending me avatars and pictures. The only way this can work if the protocol can communicate everyone's different needs and abilities, so devices don't get things they can't handle, users don't get things they don't want, and people don't get confused about what works and what doesn't.
@fastfinge @arcanechat @jae
> My ESP32 controller doesn't run JavaScript, so can't participate in Deltachat Apps.
then all it has to do is ignore the messages related to it, they won't harm it
"be liberal in what you accept..."
I have custom bots/bot accounts. They ignore all the WebXDC messages without issue. I can even try to call them. They'll never answer, but it is completely harmless.
I literally don't get the issue here.
Let's say you have the same account accessible over Bitlbee, your phone, and some ESP32. Do you want it to expose the capabilities of the currently active device even though it's the same account? So what, someone might not have the phone button appear if you're not active on the right client?
That is a HUGE metadata leak. You absolutely should not expose that information. (Signal does right now, you can spy on people and see when they're using their phone vs their desktop)
> My ESP32 controller doesn't run JavaScript, so can't participate in Deltachat Apps.
then all it has to do is ignore the messages related to it, they won't harm it
"be liberal in what you accept..."
I have custom bots/bot accounts. They ignore all the WebXDC messages without issue. I can even try to call them. They'll never answer, but it is completely harmless.
I literally don't get the issue here.
Let's say you have the same account accessible over Bitlbee, your phone, and some ESP32. Do you want it to expose the capabilities of the currently active device even though it's the same account? So what, someone might not have the phone button appear if you're not active on the right client?
That is a HUGE metadata leak. You absolutely should not expose that information. (Signal does right now, you can spy on people and see when they're using their phone vs their desktop)
@feld @arcanechat @jae What I want is for my grandmother not to think she did something wrong when she sends me an app, and the connection never establishes. Or spend five hours troubleshooting her internet when she tries to call me and it doesn't work. Or for my app not to waste all of my mobile data because my cousin sent 54 photos to the family group. Without protocol negotiation, you can never be user friendly in these ways.
@fastfinge @arcanechat @jae
Grandma will just be calling when she gets "There was an error decrypting an OMEMO message addressed to this device." errors instead I guess?
> Or for my app not to waste all of my mobile data because my cousin sent 54 photos to the family group.
Already possible to disable automatic attachment downloads in the Delta Chat app
Grandma will just be calling when she gets "There was an error decrypting an OMEMO message addressed to this device." errors instead I guess?
> Or for my app not to waste all of my mobile data because my cousin sent 54 photos to the family group.
Already possible to disable automatic attachment downloads in the Delta Chat app
@feld @arcanechat @jae I mean sure. That's an actual problem that I can solve for her. Though these days it never really happens. The only protocol with that problem still is Matrix.
@fastfinge @arcanechat @jae I haven't used XMPP in probably 5 or 6 years, but I did just have a friend mention the OMEMO error yesterday
@fastfinge @arcanechat @jae you know, XMPP could probably be good if someone produced a project implementing the XMPP core protocol and the important XEPs in one package with a clean JSON-RPC API so anyone could write a UI around it easily and then everyone has the same implementation so there are no compatibility issues and then people can focus on building highly polished UIs to their taste instead of toiling for years on protocol internals
if someone did that I bet XMPP would explode in popularity
if someone did that I bet XMPP would explode in popularity
@feld @arcanechat @jae There are multiple libraries that do what you want. And they all work with one another. Pick your favourite and go. QXmpp if you like QT, slixmpp if you like Python, Martin for Swift...
@fastfinge @arcanechat @jae why are they tied to a specific programming language instead? they don't offer an RPC API
@feld @arcanechat @jae Because an RPC API means dealing with a ton of fun new issues around security, and writing wrappers in each language anyway. So why bother? Better to have native libraries. Also faster.
@fastfinge @arcanechat @jae nice to see that Martin didn't even validate certificates until 5 months ago
https://tigase.dev/tigase/_libraries/Martin/~commits/bcebdb654d8b3a34f625f6f8b853a8403d13eeec
https://tigase.dev/tigase/_libraries/Martin/~commits/bcebdb654d8b3a34f625f6f8b853a8403d13eeec
@fastfinge @arcanechat @jae RPC API: zero issues around security actually, because it doesn't work over TCP/IP. Delta's only works over stdio on purpose to avoid security issues
@feld @arcanechat @jae Yup, because most people use self-signed certificates. Depending on the centralized SSL issuers is bad for centralization. And allows easier sensorship. And it did compare fingerprints.
@fastfinge @arcanechat @jae wait, so only the messages are OMEMO encrypted right? None of the other XMPP related chatter? So all of that metadata can be scooped up by anyone who MITMs these self-signed certs?
@fastfinge @arcanechat @jae injection *where*? Your own program spawns the deltachat-rpc-core process and is the only process that can access the stdio
of course if your own XMPP program gets pwned... then you're pwned
of course if your own XMPP program gets pwned... then you're pwned
@feld @arcanechat @jae But the rpc process is sending me data it got from the internet. So now I'm responsible for checking for shell injection issues along with everything else. If only I just had a library that integrated directly with the tools I already use, instead of doing a clumsy RPC dance.
@fastfinge @arcanechat @jae so which JSON library is terrible at its job and is vulnerable to shellcode injection? You make it sound like you're using shell/sed/awk to process this RPC response
@feld @arcanechat @jae If someone MITMs a cert, the cert fingerprint still changes, and you get warned. Just like how SSH works.
@fastfinge @arcanechat @jae I just pulled the source to check and it's a SHA1 fingerprint... which we can produce collisions for...
@fastfinge @feld @arcanechat @jae
>QXmpp if you like QT
Isn't that the meme KDE XMPP library that Kaidan uses and supports none of the OMEMO versions everyone else actually uses?
>QXmpp if you like QT
Isn't that the meme KDE XMPP library that Kaidan uses and supports none of the OMEMO versions everyone else actually uses?
@phnt @feld @arcanechat @jae I have no idea what Kaidan does. But from a brief glance as someone who doesn't use it, it looks fine.
@fastfinge @feld @arcanechat @jae There is an issue with Kaidan users where almost nobody can read their OMEMO encrypted messages, because Kaidan implements only some new-ish version of OMEMO and not the older ones used by other clients. So if you use Kaidan, you effectively can only talk to other Kaidan users when using OMEMO.
From a quick look a cmake files in Kaidan, it seems that it uses QXmpp. So unless they disabled some support, QXmpp isn't really usable in the real world. I don't think it is even compatible with Conversations. (Conversations holding back the whole ecosystem is another can of worms I'm not going into.)
From a quick look a cmake files in Kaidan, it seems that it uses QXmpp. So unless they disabled some support, QXmpp isn't really usable in the real world. I don't think it is even compatible with Conversations. (Conversations holding back the whole ecosystem is another can of worms I'm not going into.)
@phnt @fastfinge @arcanechat @jae correct it only implements OMEMO2 and they refuse to implement OMEMO1
also they had a cool bug recently where it told you that the OMEMO was successful when it only worked for one side
https://invent.kde.org/libraries/qxmpp/-/merge_requests/794
also they had a cool bug recently where it told you that the OMEMO was successful when it only worked for one side
https://invent.kde.org/libraries/qxmpp/-/merge_requests/794
@fastfinge @arcanechat @jae you're conflating things. They're taking the certificate itself and hashing it with sha1 to determine what its fingerprint is.
From their code:
let fingerprint = SslCertificateInfo.calculateSha1Fingerprint(certificate: cert!);
which is in:
Sources/Martin/util/SslCertificateInfo.swift
From their code:
let fingerprint = SslCertificateInfo.calculateSha1Fingerprint(certificate: cert!);
which is in:
Sources/Martin/util/SslCertificateInfo.swift
@feld @phnt @arcanechat @jae Most things only implement OMEMO2. 1 was deprecated years ago. Time to update your client.
@fastfinge @feld @arcanechat @jae Conversations doesn't support it, so it doesn't matter that other clients support it, if nobody on mobile can read your messages. Gajim doesn't support it either I think...
https://codeberg.org/iNPUTmice/Conversations/issues/55
https://codeberg.org/iNPUTmice/Conversations/issues/55
@phnt @feld @arcanechat @jae I've never even heard of conversations. Nobody I know uses it; we're all Monal or Siskin. They should really get on updating, though.
@fastfinge @feld @arcanechat @jae
>What does OMEMO file attachments that the existing file transfer over HTTPS doesn't give you?
The server having no idea what the contents of the file is. What's the point of an encrypted chat when you can leak valuable metadata by accidentally uploading an unencrypted attachment over an encrypted HTTP connection.
>I've never even heard of conversations. Nobody I know uses it; we're all Monal or Siskin.
It's the only usable XMPP client on Android. Almost every other XMPP client on Android is forked from it.
>What does OMEMO file attachments that the existing file transfer over HTTPS doesn't give you?
The server having no idea what the contents of the file is. What's the point of an encrypted chat when you can leak valuable metadata by accidentally uploading an unencrypted attachment over an encrypted HTTP connection.
>I've never even heard of conversations. Nobody I know uses it; we're all Monal or Siskin.
It's the only usable XMPP client on Android. Almost every other XMPP client on Android is forked from it.
@feld @arcanechat @jae Who knows. If I had a library written in the language I'm using I wouldn't even have to think about it.
@fastfinge @arcanechat @jae but what if this mysterious "data from the internet" was designed to attack your programming language you selected? It's all the same problem, untrusted input is untrusted input.
But thankfully random people / bad actors can't message you on Delta Chat so you can't fall victim to drive-by malicious messages. Unless your grandma ups her hacking game I guess :)
But thankfully random people / bad actors can't message you on Delta Chat so you can't fall victim to drive-by malicious messages. Unless your grandma ups her hacking game I guess :)
@phnt @fastfinge @arcanechat @jae I think it's really funny that there are multiple XMPP projects right now flirting with implementing PGP instead of OMEMO
@fastfinge @arcanechat @jae @phnt alt-text in case your client isn't seeing it from the edit for whatever reason:
Hi Given the fact that this project made a huge progress the last years with great features, we tried to port Shmoose away from Swiften and also use qxmpp. During this, we discovered that the current omemo implementation in qxmpp is 'v2 only' which in turn has the side effect that it is currently not compatible with all the other major xmpp clients. Do you have a plan how to handle this? There are e.g. omemo pyhton implementations available which handles both, v1 and v2 of the omemo protocol transparent to the using product. Best regards Geobra
Hi Given the fact that this project made a huge progress the last years with great features, we tried to port Shmoose away from Swiften and also use qxmpp. During this, we discovered that the current omemo implementation in qxmpp is 'v2 only' which in turn has the side effect that it is currently not compatible with all the other major xmpp clients. Do you have a plan how to handle this? There are e.g. omemo pyhton implementations available which handles both, v1 and v2 of the omemo protocol transparent to the using product. Best regards Geobra
@phnt @fastfinge @arcanechat @jae see, this is extra fascinating to me because my experience with XMPP clients in iOS/MacOS was that they are universally terrible (maybe Monal is better now, but it was SO UGLY for years and years)
Everyone just said "lol, get an Android XMPP is great here we have Conversations it's so good"
and they're right, it *is* a good client. Very high quality.
But that client is dead in the water these days and still only supports OMEMO v1
so... the XMPP ecosystem continues to be irreparably fractured.
Everyone just said "lol, get an Android XMPP is great here we have Conversations it's so good"
and they're right, it *is* a good client. Very high quality.
But that client is dead in the water these days and still only supports OMEMO v1
so... the XMPP ecosystem continues to be irreparably fractured.
@feld @phnt @arcanechat @jae I suspect PGP is the future. OMEMO is just kind of a crappy design. The issues with it were mostly solved, but they're just not worth it. As Matrix is also discovering. Though I don't know enough about cryptography to comment on the security trade offs, just the UX ones. There's some guy who runs a furry blog with opinions who's name I honestly can't remember. I'll leave that to him.
@fastfinge @phnt @arcanechat @jae I know who you refer to and they shall not be named for fear of invoking their ... wrath?
They hate PGP because of the legacy baggage that has historically caused all sorts of bugs and security problems, but if you do it like DeltaChat and you only support the absolute minimum of the spec that you need and you're done. That's what the XMPP community should do too because it works very well.
I'm just not convinced that E2EE is possible on the fediverse because you have the issue of "where do the keys get stored" -- in your browser session? On all your clients/apps? How do you synchronize them? yuck yuck yuck
They hate PGP because of the legacy baggage that has historically caused all sorts of bugs and security problems, but if you do it like DeltaChat and you only support the absolute minimum of the spec that you need and you're done. That's what the XMPP community should do too because it works very well.
I'm just not convinced that E2EE is possible on the fediverse because you have the issue of "where do the keys get stored" -- in your browser session? On all your clients/apps? How do you synchronize them? yuck yuck yuck
@phnt @feld @arcanechat @jae I mean in an ideal world, everyone just runs their own server they trust. But yes, in the actual world, OMEMO encrypted file uploads should be supported.
@feld @phnt @arcanechat @jae What this thread has ultimately proved is that what we need is E2E for Activity Pub. Then we can all just IM over the fediverse. Equally unblockable because it's just HTTP to random places. And with none of my concerns around centralized control, and none of the XMPP baggage, and not trying to synchronize an entire dag the way Matrix does.
@fastfinge @feld @arcanechat @jae There's already a draft spec for that. Issue is that nobody thought about key distribution yet, which is the hardest part of it (as proven by both XMPP and Matrix).
Spoiler alert: Barely anybody will be implementing it anyway.
https://github.com/swicg/activitypub-e2ee
Spoiler alert: Barely anybody will be implementing it anyway.
https://github.com/swicg/activitypub-e2ee
@phnt @fastfinge @arcanechat @jae they can just use autocrypt v2 which was designed to solve this exact problem for all protocols interested in secure key distribution/exchanges, ratcheting, etc without any centralized servers involved
hopefully that's what happens, it would be good for the users
edit: oh! I thought this was about XMPP not fediverse haha... yeah big doubt about this
hopefully that's what happens, it would be good for the users
edit: oh! I thought this was about XMPP not fediverse haha... yeah big doubt about this
@phnt @feld @arcanechat @jae I mean, nobody is going to implement it without key distribution sorted out. But once it is, I see no reason why a bunch of people wouldn't. I'd be happy to get it into iceshrimp and the clients I use. And the loops/pixelfed guy has already talked about it previously. And Sharky/firefish/whatever it's calling itself today will implement it because they implement everything. Pleroma and gnusocial will say they're going to implement it, but never will, eventually leaving it up to Akoma. GoToSocial will implement it five years later. Mastodon will implement something shaped like it, but use entirely different encryption and key formats. But eventually, everyone will have some form of it, and will all be able to exchange encrypted IMs with each other.
@fastfinge @phnt @arcanechat @jae
> Pleroma and gnusocial will say they're going to implement it, but never will, eventually leaving it up to Akoma.
hey, get it right: Pleroma will never implement it because we experimented with it years ago and decided it's wrong and unfit for the fediverse :)
https://blog.soykaf.com/post/encryption/
> Pleroma and gnusocial will say they're going to implement it, but never will, eventually leaving it up to Akoma.
hey, get it right: Pleroma will never implement it because we experimented with it years ago and decided it's wrong and unfit for the fediverse :)
https://blog.soykaf.com/post/encryption/
@feld @phnt @arcanechat @jae Use the FIDO stuff and have everyone store it on their YubiKey or as a passkey. The advantage is that everyone is forced into having a hardware 2fa device. I'm...mostly half joking.
@feld @phnt @arcanechat @jae OMG this article is infuriating! Why did this guy use real HTML headings, and yet also keep the markdown formatting? What is this weird combination of both HTML and markdown at the same time it's making me cry.
@fastfinge @phnt @arcanechat @jae I think it's generated with Hugo, can't comment further. Sorry 😭
there's not much you're missing from the not-really-alt-texted images except they're from his visit to North Korea lol
there's not much you're missing from the not-really-alt-texted images except they're from his visit to North Korea lol
@fastfinge @phnt @arcanechat @jae I only do ssh with my yubikeys so I'm already on board with this idea but yeah...... kind of an intractable problem
@fastfinge @feld @arcanechat @jae
>Pleroma and gnusocial will say they're going to implement it, but never will, eventually leaving it up to Akoma.
There are Pleroma Chats, so that could be used as some baseline, but chats and that spec aren't really compatible last time I looked. And my view is that they are already better ways for E2EE chats than the fediverse. You get identity isolation as a "bonus" and there's no X protocols + 1 competing over the same thing.
That said, if they do it properly, the server part should be rather simple as it should be the client doing all the work and the server should just send the messages to their destinations. However if the server will also hold the keys, or there will be only one key per user, than there's no shot I'm implementing this. Multi-device support is my requirement for even bothering with it.
>Mastodon will implement something shaped like it, but use entirely different encryption and key formats.
Mastodon actually got a grant approved to implement that unfinished spec, so the ActivityPub thing will probably be happening again. Where Mastodon is actually what defines the spec.
>Pleroma and gnusocial will say they're going to implement it, but never will, eventually leaving it up to Akoma.
There are Pleroma Chats, so that could be used as some baseline, but chats and that spec aren't really compatible last time I looked. And my view is that they are already better ways for E2EE chats than the fediverse. You get identity isolation as a "bonus" and there's no X protocols + 1 competing over the same thing.
That said, if they do it properly, the server part should be rather simple as it should be the client doing all the work and the server should just send the messages to their destinations. However if the server will also hold the keys, or there will be only one key per user, than there's no shot I'm implementing this. Multi-device support is my requirement for even bothering with it.
>Mastodon will implement something shaped like it, but use entirely different encryption and key formats.
Mastodon actually got a grant approved to implement that unfinished spec, so the ActivityPub thing will probably be happening again. Where Mastodon is actually what defines the spec.
@phnt @fastfinge @arcanechat @jae
> so the ActivityPub thing will probably be happening again. Where Mastodon is actually what defines the spec.
yeah remember when the AP WG recognized Pleroma was a major contributor to the fediverse and invited us to be stakeholders and asked us for input on important far-reaching issues and proposed changes to the entire fediverse? Ahh wait that never happened they just ignore us and it's not worth any of our time to try to force our way in and argue just to be told "well Mastodon is doing it this way anyway, so that's the spec now"
> so the ActivityPub thing will probably be happening again. Where Mastodon is actually what defines the spec.
yeah remember when the AP WG recognized Pleroma was a major contributor to the fediverse and invited us to be stakeholders and asked us for input on important far-reaching issues and proposed changes to the entire fediverse? Ahh wait that never happened they just ignore us and it's not worth any of our time to try to force our way in and argue just to be told "well Mastodon is doing it this way anyway, so that's the spec now"
@feld @phnt @arcanechat @jae Good lord. Did this guy move on to become a Lemmy dev? Because he seems like someone who has opinions about China.
@fastfinge @phnt @arcanechat @jae nah he's a good friend of mine and has no fear. I think in another life he'd be one to go into war zones just to get some cool rare photos.
@phnt @fastfinge @arcanechat @jae ANOTHER LIFE. We're not sending him in to get blown to bits in *this* life. :)
@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
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
@Monal @miki @plzupgrademe If you want to be both cross platform and accessible, WX is literally your only practical option. QT5 has come a long way, but there are still lots and lots of issues you’d have to work around. GTK is right out.
@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.
@feld @fastfinge @arcanechat @wafflesies @jae
Yes, in my company we're using XMPP for IoT. And as a team chat. Both work well.
@fastfinge @feld @arcanechat @jae
AFAIK, there are multiple ways to login without password in #XMPP. E.g. #Conversations_im does support login via client-side TLS certificate with "XEP-0178: Best Practices for Use of SASL EXTERNAL" which works with both #ejabberd and #prosody. #Gajim used to support it, but the removed it because of lack of testing resources or sth.