Closed MilkManzJourDaddy closed 4 years ago
Most clients have configuration files these days, and there's .well-known discovery to transmit various forms of configuration. This also is a spec request and not an integration request handled by this repository.
No, you've completely missed that this is a UI/UX issue. Would you ask someone supporting their grandparents, (or young children on a PRIVATE non-federating family Homeserver) to tell those people to manually edit the config' file(s) or play around with .well-known? No, you would not, and the person doing the supporting may not be adept enough either.
But it is a UX/UI issue.
Perhaps you should define "other tooling" more precisely if you do not want an overlap; unless it is enjoyed, the typical closing of issues without understanding the issue, a common complaint actually.
The framework is in place, but it would be a useful UX/UI feature. Application Services should have their own spec', but bridges & 'bot issues are accepted in this repo'. ¯_(ツ)_/¯
But while you're quickly closing issues, have a look at the Kik™ bridging issue another person opened. I'm u.aware of the decision being reversed, and AFAIK it's still as I predicted elsewhere: Kik™ got shut down a while ago.
UI/UX issues also don't belong here, no matter how you twist them. The spec would need to define a common format for everyone to use.
VoIP clients i.e. Linphone have the ability to be configured via a remote configuration file by entering the URI, or scanning a QR Code. The use-case is for supporting a person without sufficient tech' aptitude or patience; and also as a time-saver when setting up a new device.
Often we support people where it's easier to set it up for them, possibly even setting their passwords! And often they do not have the patience to wait for us to go through all the settings on their device; which is a barrier for on-boarding.
However, if we can scan a URI to a file, or even encoded configuration that can be stored locally and possibly have a copy uploaded to the Homeserver, the interaction and on-boarding becomes much easier. Mimicking the VoIP example, such a file would already be on some (Home)server.
Also, in the inevitable event the end-user inadvertently toggles a setting which causes dismay, they could default to an earlier configuration file, stored locally, or on the Homeserver. In fact they hypothetically could select from a few.
This has also been seen on i.e. pfSense where a configuration file is typically kept safely on a USB drive along with installation media, in case of needing to start over.
https://docs.netgate.com/pfsense/en/latest/backup/automatically-restore-during-install.html#configuration-from-usb-during-install
On VoIP, e.g. LinPhone, they use XML for the actual provisioning, but show an example in old school Windows® *.ini file style:
https://wiki.linphone.org/xwiki/wiki/public/view/Lib/Features/Remote%20Provisioning/ .
As we know, Matrix uses JSON, not the XML as in the examples above, which are ONLY provided to illustrate the general concept which is an ESTABLISHED practice.