Modern XMPP project discussion - 2024-06-17

Is there any means to distinguish between a direct message from an anonymized JID from a MUC, and a direct message from a real user? The reason I'm asking is: I'd like to group individual conversations based on the bare JID (sans-resource) of the sender, but I figure that model breaks down completely, when you're dealing with direct messages from an anonymized JID identified from a MUC (e.g. chatroom@conference.someserver.example/wendy); or is there anything I might be misunderstanding with the addressing of messages?

arcanicanis, those messages (should) have a payload element <x xmlns='http://jabber.org/protocol/muc#user' />

oh, alright, thank you, that helps.

This was added to the spec in 2017, it's possible that you will encounter some old servers in the wild that don't add it, but it should be rare enough that you needn't care (and the solution is generally to get those servers updated)

They aren't "modern" :)

anything in the ballpark of ~8 years ago or so, is usually a fair threshold to support back to, as I usually hold the same sentiment for web design/dev and such also

Also, curiously, are there any test suites for Jingle video/voice calling?

Hmm, not that I'm aware of. The typical benchmark is "does it work with Conversations?" 😅

(or more specifically: whatever's possible from a WebRTC-based implementations?)

I suppose I could dork around with writing some testing tools later on, or while I work through it, at some point.

Yes, pay no attention to the specifications, just make it look good in ~internet explorer~ Conversations! WCGW?

Didn't the Dino devs have problems with this because they, unlike everyone else, didn't use libwebrtc?

We always need more interop testing events, arrange one today! :)

> Yes, pay no attention to the specifications, just make it look good in ~internet explorer~ Conversations! WCGW? Sounds like the situation the fediverse has with Mastodon: where one heavyweight vendor just steamrolls over everyone else's efforts to be more interoperable, conformant, etc, and instead be coerced into "copy what __ does" ↺

"Oh, there's already a well-established extension for quote-posts that everyone else implemented? Nah, it doesn't exist to us, let's virtue about how we're 'inventing' it for the first time, as our own [non-intercompatible] extension."

> Didn't the Dino devs have problems with this because they, unlike everyone else, didn't use libwebrtc? That's the only part I'm concerned about: is if there's any WebRTC-specific stuff that gets burdened onto other clients, in order for a web user to participate in a Jingle call, but I haven't dug deep enough yet, just briefly read through some of the specs so far. ↺

I guess in respect of Conversations: at least it's not the situation of +10 years ago, of having to play within the limitations of Google Talk, that had virtually no development for some years, until they dropped the desktop client entirely (as well as botching open federation, server-side)

Dino is the most prominent non-WebRTC client, so you can test with that too

non-libwebrtc*, i does use WebRTC when the recipient supports that. ✏

I have doubt this exists, but is there any mechanism for any sort of mediaproxy/oEmbed proxy service, such as a proxy for retrieving a shared HTTP upload, or for generating an oEmbed preview of a link, without it being fetched directly client-side (just as a privacy option)?

Or if I concoct my own mechanism: is there a way for an XMPP client to retrieve some attestation token from the server, that it could present to an external out-of-band service, to prove it's a valid user from that XMPP service (so a mediaproxy service could be made that only serves users of the same server, rather than being a totally open proxy to the entire internet)? ✏