jdev - 2025-11-20

Out of curiosity, what's the shortest path (in prerequsites and XEPs) to just write an extremely minimal WebRTC video/voice conference webclient, using XMPP for signalling and call setup, mainly for the sake of argument of illustrating how simply such a thing could be written (in a weekend-ish)?

and bonus points if an SFU is part of it (versus needing full mesh between all clients)

You'd have to pick and SFU and learn it. Might be more than a weekend right there

was eyeing jitsi-videobridge ( https://jitsi.org/jitsi-videobridge/ ), which can talk XMPP directly, via XEP-0340 ( https://xmpp.org/extensions/xep-0340.html ) ✏

or at least from what it claims, as printed on the tin

Sure but at that point you're just installing jitsi mostly?

Just the as one standalone architectural component, versus the full sweep of everything else: https://jitsi.github.io/handbook/docs/architecture/#components

whereas in this case, it'd be just ejabberd (probably using internal STUN/TURN), jitsi-videobridge, and a silly little static HTML webpage with JavaScript embedded as a webclient

And then build your own UI I guess? I'd be curious how that goes. I think they haven't updated the xep in awhile but it's still somewhat similar maybe

I guess more the question is: which XEPs do I have consider, at least for the call setup/join, part of XMPP? Or does XEP-0340 mostly take place of prior XEPs with that? ✏

Xep0340 is basically just an outdated description of "what jitsi does" it's not something likely to be used on the federated network. Regular jingle is probably sufficient for most cases especially if you're going for simplicity and don't need lots of bells and whistles

But this is all theoretical no one has fully built anything. There are several in progress explorations

Effectively all that's needed in my experiment is: something where someone can start a call/conference, could be voice-only, could add a video stream later; people outside of the call would have telepresence info of who's joined in the call, and that's really the extent of it.

Has anyone else ever discussed anything of WebRTC WHIP/WHEP in context of Jingle?

arcanicanis: https://discourse.igniterealtime.org/t/webrtc-based-audio-and-video-in-openfire-2025/95683

Interesting, thank you

Seems that the very early draft XEP is more readable at (Firefox chokes on the &xmpp###; entities, in the XML version): https://igniterealtime.github.io/openfire-orinayo-plugin/xep/index.htm ✏

Seems that the very early draft XEP is more readable at (Firefox chokes on the &xep####; entities, in the XML version): https://igniterealtime.github.io/openfire-orinayo-plugin/xep/index.htm ✏

*XMPP Summit 28* Only six places left 😲 Consider to list yourself better now than later: https://wiki.xmpp.org/web/Conferences/Summit_28#Summit_Participants

im doing a robotics thing using xmpp as a transport layer (because i wanted to), and im thinking for like commands and input it makes the most sense to send it as an iq that the robot must respond to either with a complete, a relevant value, an error, etc, then if its not responding i know it didnt recieve it yet

is there any reason i shouldnt abuse iqs for this? i mean i could do the same thing with just normal messages and maybe delivery/read receipt, but i think its very important to ensure response

what do you do if it doesn't respond? that doesn't necessarily mean it hasn't or won't receive and respond

indicate to the user that it hasnt recieved a response yet

its a line of site wireless connection, so i think it would be sufficient to indicate how long its been since last response, and if a command is sent indicate it hasnt been reported as completed yet

basically just something to display in the ui

> is there any reason i shouldnt abuse iqs for this? i mean i could do the same thing with just normal messages and maybe delivery/read receipt, but i think its very important to ensure response That sounds like a use not an abuse ↺

> what do you do if it doesn't respond? that doesn't necessarily mean it hasn't or won't receive and respond to be clear this isn't something special about XMPP IQs the exact same problem exists in any communication system, including http ↺

Sort of. TCP HTTP there's always a "response" even if it's just "os timed out socket" or "socket closed". XMPP you need to do timeouts at the application layer

socket doesn't have to close you can keep it open waiting as long as you want

> *XMPP Summit 28* > > Only six places left 😲 Consider to list yourself better now than later: > https://wiki.xmpp.org/web/Conferences/Summit_28#Summit_Participants Dear all, The XSF is aware that the exposed list is full so far. We are working towards offering more space. In the mean time, don't feel rejected. Kindly, expose yourself waiting at the end of the list with a "W.". This helps organising best. Thanks for everyone interested so far! ↺