I am currently rereading the
boringproxy documentation for feasibility for updating selected deployments. Thank you first for providing this new space for in-depth considerations around small scale self-hosting and open protocols. It will greatly support an upcoming v1 release of the tool.
In reading so, I am finding that
-client-name could maybe mostly fall-back to the current
hostname, if not provided differently (e.g. per user, user@host, … , when started from a
systemd @ unit), then making it optional.
-user name is also not mandatory for Web Interface access¹, then why so during authentication (authn) of a client? Is it that this process could rather be considered authorization (authz) instead, for it is also most often a systemic daemon that provides for it, and is a service acting on behalf of a user, an agent so to say, but not an interactive session by them in itself.
Also, there could be a better visual distinction between the display of the server command, and the explanation of the parameter/argument below.
Also, the boringproxy installation page on boringproxy.io does not have a title that reveals more details than the base domain, does not yet offer the new
latest binary, and also neither schema.org metadata nor OpenGraph tags or Twitter Cards. It is therefore blinding this Discourse (and social media users linking to it):
These are basically notes to myself as a reminder to investigate interest in these usability simplifications, and to prepare a little PR with the suggested changes.
¹ Don’t know if this is still the case with the newer v0.8 branches, as still currently updating.