mechanism for a homeserver to suggest a default jitsi server to use for clients

[richvdh]

As a homeserver admin, I might like to suggest a default jitsi server other than jitsi.riot.im to people who connect with riot to my server.

[richvdh]

It's unclear how this would interact with the jitsi.preferredDomain riot config option.

It's also somewhat unclear whether this belongs in the matrix protocol at all, given jitsi integration is a riot-specific extension (so perhaps what we need is a way for servers to expose client-specific configuration parameters in a generic way?).

[turt2live]

Jitsi is in the spec under the widgets banner, but indeed there's no definition for how clients acquire their defaults.

[uhoreg]

Could possibly use matrix-org/matrix-spec-proposals#2301 or matrix-org/matrix-spec-proposals#2063

[olmari]

As end user perspective: The unique thing with Jitsi within Matrix (or Riot/client) is that instead of "just" a widget, there exist dedicated call button for it, making it in some sense part of at least Riot, if not Matrix.

As developer'ish perspective: Most proper 'author' to define what Jitsi ought to be used would be room admins, which would bring us back into integration manager(s) and such. Does current way of using IM also apply to riot call button method? This method would ofcourse need the IM alltogether and generally focus to make custom one ever so easier to deploy.

Next best thing would be the client well-known, that would at least point HS users towards "HS-trusted" Jitsi, while that method loses control over room specific one.

Maybe even user-overridable setting, while I don't know feasibility of that..

And ofcourse all of these could be supported at once, within well thought priorities.

And just as I was about to finish, indeed somthing like @uhoreg just linked could also work... Thing is that most privacy-minded persons will have something to say no matter what is done, at the same time this shouldn't be too hard, especially in end-user perspective.. While the issue there remains that "who should control what Jitsi-instance is used".

[turt2live]

So far the proposal is for clients to just do it through .well-known, as they're allowed to: matrix-org/matrix-react-sdk#4348

[olmari]

I like the idea of user default Jitsi offer in .well-known, if room wants to offer somwthing else, I guess they still can(?) So this becomes an question of exactly default Jitsi-instance for user :)

[neumantm]

For anyone else stumbling across this issue:
According to the documentation added in element-hq/element-web#13047
Element already supports using the client .well-known for the default jitsi server

[t3chguy]

Indeed it does.

See second half of /~https://github.com/vector-im/element-web/blob/develop/docs/jitsi.md#configuring-element-to-use-your-self-hosted-jitsi-server

[olmari]

Yep, it came more or less after this ticket, so I guess closing as implemented should be done :)

[t3chguy]

Would probably be good for it to documented in the spec rather than a client's doc

[assodefis]

I think I did add the good line on nginx
return 200 '{"m.homeserver": {"base_url": "https://matrix.defis.info/"},"im.vector.riot.jitsi": {"preferredDomain": "ourjitsi.defis.info"}}';
but when I want to add a jitsi widget, it keep offering me a jitsi.riot.im room

instead of a ourjitsi.defis.info

Should I write "preferredDomain": "https://ourjitsi.defis.info/" instead of "preferredDomain": "ourjitsi.defis.info" ?

[t3chguy]

That config only affects the call button. When using an integrations manager like your screenshot shows it always uses the one it has configured internally.

[assodefis]

OK, got it. Thank you for pointing this out.
Still, it's not working.
If I click on video call button in a conference, It creates a jitsi conference to https://app.element.io/jitsi.html#xxxxxxyyyyyy and not to ourjitsi.defis.info
So I probably write something wrong but what?

[t3chguy]

That jitsi.html is just a wrapper. After clicking join conference see where the iframe inside is pointing.

[assodefis]

I see. Well it sadly sends to https://jitsi.riot.im/JitsiMsrfdhjwrugogrlgvaloyubg
Never mind...

[alexander-potemkin]

Is it (jitsi server in use) something I can change if I make my custom build of Element client (for all platforms)?

[aaronraimist]

@alexander-potemkin a custom build of Element is not required. Element already has a feature that lets you or a homeserver pick a specific Jitsi server, see /~https://github.com/vector-im/element-web/blob/develop/docs/jitsi.md#configuring-element-to-use-your-self-hosted-jitsi-server.

(This issue is about making that part of Matrix so all clients can use it)

[alexander-potemkin]

@aaronraimist , thanks very much, got it now.

I'm a newbie in Element/Matrix and I'm trying to make my head around the voice calls - would it be right to say, that Matrix itself doesn't care how the calls are implemented?

So Element decided to use Jitsi for that matter, wrapping signaling things, that Jitsi is missing?
And other clients are free to implement whatever they want?

For example, FluffyChat (which seems to be the only one viable Element alternative) seems to use just plain WebRTC for that and that's also fine?

And what's the place (and high-level technical architecture) of call.element.io in all that? It feels like a drop-in meet.jit.si replacement, but what's the use/business case for that?

[aaronraimist]

would it be right to say, that Matrix itself doesn't care how the calls are implemented?

@alexander-potemkin Yes that is my understanding.

So Element decided to use Jitsi for that matter, wrapping signaling things, that Jitsi is missing?

Element uses Jitsi for group calls and plain WebRTC for 1:1 calls.

And other clients are free to implement whatever they want?

For example, FluffyChat (which seems to be the only one viable Element alternative) seems to use just plain WebRTC for that and that's also fine?

Yes.

And what's the place (and high-level technical architecture) of call.element.io in all that? It feels like a drop-in meet.jit.si replacement, but what's the use/business case for that?

My understanding is they plan to replace Jitsi (and maybe plain WebRTC for 1:1 calls) with Element Call. It gives them much more control and flexibility. For example Element Call finally allows for screensharing in the Element Desktop app which they found difficult to accomplish with Jitsi.

[alexander-potemkin]

Thank you, @aaronraimist !
That starts making some sense.

If Element call replaces Jitsi and/or WebRTC, how could Element then be self-hosted / isolated from the outside world?

[t3chguy]

Element call is also self-hostable. Heck even peer-to-peer right now with an SFU-mesh coming later

[alexander-potemkin]

@t3chguy , thanks I missed that the source code is available as well.

Don't you aware, by any chance, why Jitsi wasn't a match?

[t3chguy]

Jitsi has no roadmap project for an SFU-mesh approach - forking it would bring with it a much heavier project lots of which Element doesn't need, like XMPP, prosody auth, SIP bridging

[olmari]

Also this ticket is older than the "Element Call" project, which should kind of replace Jitsi at some point in the context. Jitsi isn't likely magically going away or disappear all of the sudden, but that is whole another thing in itself then :)

[alexander-potemkin]

Thank you, @t3chguy , @olmari !
So the idea is to have calls component/system implementing SFU and done the way Element team sees fit, at some point in future?