Unify Settings on all selected instances in current/all containers

[vendillah]

Unifying for current & all

I have my invidious instances split up in 2 containers (for now, as long as Beatbump hasn't solved cloudflare / proxy yet); in one of them I have "listen by default" enabled and the other I don't. Discovering Libredirect and a whole bunch of new instances, I wanted to enable these specific settings for each instance per container. This process could be speed up, if Libredirect would allow you to unify the settings across the current container. This is the feature I need, and may also solve some confusion (like in #141), but I'll go over some other ideas to keep in mind:

I myself don't particularly need an option to enable it for all containers, but it may help other use cases to also support that, as it doesn't seem like much extra work when "current" functionality would be implemented. I myself can think of enabling "proxy" with "all" functionality, but then, it would be just fine for me setting it manually in each, along with the container specific settings. (After all, the instances tend to change, but the containers are, to me, less dynamic, so going through each container is probably not much of a hassle, when a unifying option per container is available.)

It can be useful though for people logged in with multiple accounts in multiple containers, that just want the same settings for all accounts in one click; or people (like me) who use Temporary Containers as well and have no containers specific settings (unlike me, having "listen by default" enabled in one and disabled in the other).

So depending on whether the user has containers enabled in Firefox, the extension could tweak the current "unify settings across all selected instances" to "unify settings across all selected instances for Default|Music|Temp1|...|every container" functionality (& explanation, so that users better know what to expect).

Standardizing external preference modification

This goes out of topic, but I found it useful to write these ideas down here, rather than with every application, since you know more about these privacy front-ends than I do and are the developers dealing with the preference elicitation, so you have a better idea of what's feasible to get preferences synchronized.

Finding a solution for the 'temp/new container' problem without relying on "all" functionality is not trivial, and it should be noticed it's only a for the narrow group of people who are using Firefox + using containers + using privacy front-end applications + creating new containers (frequently) + having different settings per containerized application. (Which includes me :D) It could be solved by requesting the settings from the most up-to-date instance, for some application, then dynamically display them in the extension per container and then allow applications to just use other container's settings or even copy them over. So to not have to specify the "duplicate from container" for every temp/new container, that setting should default to the globally configured default container. A whole lot of work!

I think however first there should be a more unified approach among the applications to change settings without relying on an instance preferences page, which is of course outside of the control of Libredirect. It would be great if Invidious.io for example also kept an "available preferences page" up-to-date next to their available instances, so that extensions can

• fetch the full html (or the json of the settings, possibly containing some hints for html like value-name: ..., input-type: checkbox|slider|combo-box|..., input-element-specific-information: [ { stepsize: 2, min: 1, ... }, ... ], ...);
• load it in their extension menu (if not with custom styled html components & layout, but that would make it harder to keep it dynamic maybe and require more work);
• allow the user to set their preferences (perhaps per container :) ) locally in the extension; and
• the extension could set the cookies with these local preferences.

I hope this is a good idea and application developers will find it useful enough to implement it, although I have to admit the external solution "unify settings" is already a very good solution that finally will enable people to use multiple instances (as users are usually lazy/busy, don't want to set preferences every time and thus stick with one instance). Since I won't be working with a "preference-API" directly (analogue to the instances-API), I'm going to leave it up to developers actually using them to think them through and propose them.

For example, if json were be used rather than copying the preferences page's html, components used to get input in an application may be complicated html (think of MUI-sliders with 3 handles); perhaps a shared API is needed, not an application specific one, so that application developers are forced to transform their specific components to (possibly multiple) simple input elements and the extension developers using the API can more easily dynamically generate usable html for input. Even better: have the shared API generate the input-html with the json.

Alright, I'm going to end it here.