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 (v
2.4.2) on macOS (v
I can find no I want to apply the
*config.js in any apparently relevant directory.
#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!