@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 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.
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.
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.
@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 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
@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...
@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.
@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 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!);
