Jitsi URL parameters should instead be set in settings/preferences dialog

Product Requests and Ideas
#1

Initially raised here

Why are so many “client preference” settings (community.jitsi .org/t/how-to-how-to-customize-meeting-options/74665/17)(broken link because new users can’t post more than 2 links), about which meeting organizers may not care at all (and which will typically not reach the server, as they’re in the client-side fragment identifier space [#], rather than the server-side query argument space [?]), exiled to the connection URL which meeting organizers will tend to propagate in its simplest form – i.e., only with any settings they do care about, which is likely to be zero?

I’m using Jitsi Meet (v2.4.2) on macOS (v10.10.5 (14F2511)). I can find no *config.js in any apparently relevant directory. I want to apply the #config.channelLastN=3 (github .com/jitsi/jitsi-meet/issues/5464#issuecomment-605931633)(broken link because new users can’t post more than 2 links) and &disableAudioLevels=true (community.jitsi .org/t/host-a-meeting-with-500-people-ideas/34672/101413)(broken link because new users can’t post more than 2 links) to all future launches of Jitsi Meet.

I don’t want to have to remember to edit every URL supplied by meeting organizers to add these not-really-fragment-identifiers (following #) that are really query parameters (and so should follow ?). HTTP URIs do not support multiple fragment identifiers in a single URI (&), nor do they support setting=value as a fragment identifier!

[How to] How to customize meeting options
#2

You can set those in config.js.

#3

No, I can’t, because I’m running the CLIENT, Jitsi Meet, not the SERVER, Jitsi.

From the original thread –

Seriously now – why would a SERVER admin need to control such settings on all their CLIENTs?

I’m sure all readers of this post have used some other chat tool. IRC, AIM, ICQ, Jabber, etc. All have server-side settings for the server, which the client never touches and usually knows nothing about – and all have client-side settings for the client, which the server never touches and usually knows nothing about.

Similarly, all tools in the multimedia conference space (Zoom, WebEx, Skype, etc.) have server-side settings for the server, which the client never touches and usually knows nothing about – and all have client-side settings for the client, which the server never touches and usually knows nothing about.

Why is Jitsi different? And more to the point, why should it remain so?

#4

Because the Server Admin controls the total application environment. Why is this so confusing to you? The parameters you’ve mentioned are all server-side controls to manage the application environment, most of which are resource-based decisions. lastN for instance, is a property that’s set to control the meeting experience for all users. Jitsi works on the SFU model (not MCU), so serious attention has to be paid to the resource impact on the clients. Why would this kind of consideration be one made on the front end, by a client?

Your rant makes me think you don’t even understand the driving technology behind video-conferencing. The fact that you would compare Zoom (which uses an MCU-type topology) to Jitsi (SFU) makes me think you’re not nearly as versed on this topic as you’d like to believe you are.

Passing config parameters via URL is actually a fringe benefit, because it allows the end-user to access some back-end configuration controls. It’s a plus, not a necessity. It’s following the core Jitsi principle of making the application as flexible to the user as possible - both on the back-end as well as the front-end.

If you really want that level of control granularity, spin your own server. It’s honestly that simple! Otherwise, these rants are beginning to look like forum spam.

1 Like