jdev - 2023-08-09

Do you guys knows some XMPP clients that have multi-user video-conferencing but with a "media-server" in the middle to handle the network heavy load ? Beside Jitsi.

edhelas, gst-meet also.

It uses the exact same extensions as Jitsi Meet though.

Correct atm.

To me Dino is only doing Muji, so no server in the middle beside the MUC to do the signalisation ✏

edhelas: Spark can do that with the Meet plugin. It simply embeds a browser with jitsi meet

Cause i'm planning applying for a grant to add Muji to Movim soon

But I was wondering if I could also add a step to have this "media--server" integration

@edhelas possibly https://github.com/tigase/tigase-meet / https://xeps.tigase.net/docs/meet-group-videocall/ ?

Wojtek, Guus, that’s all just embedding Jitsi Meet right?

> edhelas: Spark can do that with the Meet plugin. It simply embeds a browser with jitsi meet I'd like to avoid any kind of Jitsi integration like this indeed ↺

Link Mauve: yes

Ah no, Wojtek’s solution seems completely different.

Wojtek, why did you go for a totally new specification rather than reusing Jitsi’s solution? Do you have a list of pros and cons?

@Link Mauve no, tigase-meet is not related to Jitsy at all

tigase-meet looks interesting

> Wojtek, why did you go for a totally new specification rather than reusing Jitsi’s solution? Do you have a list of pros and cons? Jitsy? Or Jingle-ish?

I'd be interested to see if we could standardize this media-server thing as well, then you could easily use your updated Prosody/ejabberd server to handle the video-audio streams broadcast

AFAIR Jitsy has some customisations and they rather prefer to use their APIs (not necesarily extending XMPP)

So maybe I'll just start with doing what Dino did first, Muji and a few other things and see later how we can push a common standard regarding server-broadcasted video-conferencing

It seems that between Tigase, Jitsi and the others there's not yet some common specification

Galene, Janus are some other video server things

Selective forwarding unit, SFU mighy be the keywords

> Selective forwarding unit, SFU mighy be the keywords Thanks ! ↺

@Zash tigase-meet is SFU backed by Janus

I have a private non-standard XEP for using SFUs with XMPP and an implementation with Openfire with Galene https://igniterealtime.github.io/openfire-galene-plugin/xep/xep-xxx-sfu_01-01.xml

edhelas: the jsxc developers wrote a small article about group calls, both peer-to-peer and using a media server https://www.jsxc.org/blog/2021/08/31/A-group-call-proposal.html

I was doing s;me work on this but got distracted. Jingle is already in pretty good shape to communicate with an SFU with almost no protocol changes, but we might need a way to specify ice-lite since almost every SFU uses that. Different SFU also have rules about eg using two peerconnection one for subscribing and one for publishing, which would need two jingle calls to do I guess

> edhelas: the jsxc developers wrote a small article about group calls, both peer-to-peer and using a media server > https://www.jsxc.org/blog/2021/08/31/A-group-call-proposal.html Interesting ! But it seems that it was not finalized and released ↺

IIRC the JSXC SFU did all SFU signaling over HTTP and only advertised this HTTP API over XMPP. So it works but a bit cheating ;)

Ah ! :D

What would be the best is to have a (or several) server components that can do the SFU part.

Yes. If/when I work on it again I was working on a gateway between jingle and live it. But definitely supporting multiple SFU is important IMO, they're all a bit different but a bit similar

Hey was reading through the Snikket progress post that was shared. I saw the future of circles for grouping chats. Is there some specific xep i should look at that is used for that? I want to use circles in a way that when somebody sends a contact request to me i can see if any of my contacts has them in their circles and what circle. That includes server connections too possibly.

Reading through the docs it doesnt say of any specific xep. Which is understandable because its not tech documentation i assume

I meant phis specifically: https://snikket.org/service/help/features/circles/

https://xmpp.org/rfcs/rfc6121.html#roster-syntax-items-group ?

Ah its in the rfc 🤔 But the roster get and the snikket link suggest its only from client to server and in the same server. So I am still missing the part of another user querying the roster of a user not on the same server for a jid. ✏

Snikket manages rosters and MUC bookmarks based on circle membership

So the wire protocol is just XMPP-IM + XEP-0402 currently

The post was talking about presentation changes in Conversations 3 AFAIK

Right. Well at least the group support is there. So that part doesnt need to be done ^^

MSavoritias (fae,ve): hmm. I wouldn't necessarily want anyone to be able to see whether I have someone in my contacts, let alone what group I have them in, right? How do you envision that working?

There could be a world where contact sharing is a thing, with consent and all

Friends of friends networks and all that. Like the whole pet names thing

You could *maybe* do a "hey friend, here's a sha256 hash of a jid, do you have them in your contact list?" That'd be more privacy preserving than sending a jid to everyone (same if they have it, but if they don't it's better)