Modern XMPP project discussion - 2025-11-17

Is there an advantage to that over a component that hosts voice rooms over rtp?

> We should have a bot that goes like "I'd just like to interject for a moment. What you're refering to as MUC, is in fact a channel" 😂 ↺

> https://www.mit.edu/~jcb/tact.html ❤️ ↺

joning existing Mumble servers obviously

but yeah, as some point XMPP will hopefully offer similar functionality. Movim is apparently planning to have always on video chat channels (where you can obviously turn off the video to have audio only)

but Mumble still have that nice easy jumping between channels for gaming purposes that will be hard to replicate in a more general purpose chat app

SFU calls would be nice, especially for a "voice channel" For normal vidcalls, maybe integrating with Jitsi could be a better move (they also use XMPP for incall chats afaik) ✏

I might be wrong, but I think an SFU really only helps with video

Audio as well ✏

more than a TURN server for example?

it can *selectively forward* different A/V streams to different peers

should be better than TURN I think as it reduces p2p load ✏

The issue for now is persistance, there is no way to declare a stable voice/video "room" inside a MUC

Using Spaces is one way to go

I guess you guys can just throw it into the mix for gc3? some kind of room properties like pseudonymousness or voice-moderation

> it can *selectively forward* different A/V streams to different peers what is there to selectively forward in audio though? In video it selects different resolutions, but in audio? ✏ ↺

Mixing all the streams and muting everyone except the one talking

>> it can *selectively forward* different A/V streams to different peers > what is there to selectively forward in audio though? In video it selects different resolutions, but in audio? i guess there might be difference in codecs and whatnot ↺

I guess that would be additional features not strictly spealing part of a SFU?

but possibly included in an server that also does SFU?

Wouldn't that be a Selective Transcoding Forwarding Unit, but the acronym doesn't look too nice 😉

>> Private group chats on XMPP absolutely support OMEMO > I'm not familiar with the terminology, I'm very new to XMPP. > But I find it crazy that e.g. the default seems to be that on channels the conversations are logged (and then indexed). Even WhatsApp isn't that bad. > > What does "public" entail? That you don't need to be invited? That should be orthogonal to encryption. The default for any channel should be that it can't be read to anyone but the participants. If I remember correctly, a MUC (groupchat) on XMPP is "public" when the MUC is configured as members-only / registration-required. ✏ ↺

>> Private group chats on XMPP absolutely support OMEMO > I'm not familiar with the terminology, I'm very new to XMPP. > But I find it crazy that e.g. the default seems to be that on channels the conversations are logged (and then indexed). Even WhatsApp isn't that bad. > > What does "public" entail? That you don't need to be invited? That should be orthogonal to encryption. The default for any channel should be that it can't be read to anyone but the participants. If I remember correctly, a MUC (groupchat) on XMPP is "public" when the MUC is not configured as members-only / registration-required. ✏ ↺