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