Conversations: Launch Jitsi Meet app if the server supports video MUC

[SamWhited]

Jitsi Meet is a group video solution that acts as a component which can be run on any XMPP server. It uses XMPP MUCs and Jingle for signaling. They have a new Android app and the next vesion of it will support an intent for launching it from other apps.

It would be nice if, when in a MUC, Conversations would query the MUC to see if the the Jitsi Meet component is installed, check if the app is installed, and if both are available, show a "Go to video" option in the MUC's context menu. Since the protocols used are all open sourced (some are published by the XSF), other services could also implement this intent, so the feature would not be entirely dependent on the Jitsi Meet app.

This specific feature would solve long standing issues like #1234, but would be relatively simple to implement.

• App manifest with intents list: https://github.com/jitsi/jitsi-meet/blob/master/android/app/src/main/AndroidManifest.xml

[Natureshadow]

Absolutely +1 for that!

[griffindoors]

Is this the role of PEP?

[SamWhited]

Is this the role of PEP?

No, for the XMPP side of things I think the flow here would go something like this:

Query the server for disco#items, query each item for disco#info (conversations may already have done up to this point for you), in the info list look for an identity where the category is component and the name is JitsiVideobridge, eg. <identity type='conference' name='JitsiVideobridge' category='component'/>.

If we support MUC, and we support Jitsi Videobridge, and any app that provides the appropriate intent is installed (see the Android Manifest linked in the issue) show the "start a video chat" menu item when we're in MUC rooms. I'm not sure how the intent actually works; I assume you have to send it the Meet instance's URL in the data parameter (I'm also not sure how to get this URL, so a bit of research may be required).

EDIT: This appears to be the commit that added support, so you may be able to tease out what data to send from here: jitsi/jitsi-meet@fdc96044ad659c31c5eb0422a5af0f8fce789444

[knoy]

This is really cool, my only concern would be that for users this is a significant downgrade in communication security and it wouldn't seem very obvious that's what's happening.

According to https://github.com/jitsi/jitsi-meet/issues/409 the video content is decrypted on the server. I'm a little unfamiliar with jitsi meet and webrtc, but perhaps there is some way we could use an OMEMO=signed value to authenticate video calls? Just a thought

[stevenroose]

Is any work done on this? It doesn't seem like a big technical difficulty. To overcome the security concern, it could be possible to show a message like "When making video calls, the server at [jitsi-videobridge-domain] might have access to the call's content.". I guess users will only use video bridges that are hosted by a trusted party like their company or themselves.

[iNPUTmice]

Proper a/v calling is on the todo list for this year. So we don’t need to open jitsi meet anymore.