What should be done with non-http/https homepages or changelog links in nixpkgs?
If a package’s homepage uses gopher or gemini instead of http/https:
should it be used as is? Users that have clients can visit it and users that don’t would have to use a proxy service
proxy it uses floodgap’s proxy or vulpes proxy? what about the page creator’s wishes to not provide a http/https page, and users who do have clients
Should it generally be proxied but have an exception for packages specifically related to that proxy such as a gopher/gemini browser or a gopher/gemini server?
First of all I think it’s obvious that, if available, https should be preferred over http which should be preferred over anything else. Additionally ftp seems slightly better than other protocols.
Then I think it’s important to note that this is virtually no problem (at least according to me grepping nixpkgs): We have below maybe a dozen packages which use ftp for homepage or downloadPage. We have a singular package which has a gopher homepage.
So I think we don’t have to do anything about this situation:
homepage and downloadPage hold URLs, so we can put any URL in there
Using Proxies is not a good idea in my opinion: They can log user activity, alter content and (probably most realisticly) go out of service while not being connected to us or the upstream project at all. Broken links are already an issue without even adding completely unrelated services to the equation.
Proxies take away choice from the user who is more or less forced to use $Service we choose for them although it isn’t necessary for the intended purpose (accessing the homepage).
The format in downloadPage does not matter because no one ever wants to visit that. homepage is linked on search.nixos.org and if you want to know more about something that is only accessible over gemini or gopher you can’t which is a pretty bad user experience.
Also ftp is pretty old and insecure and I would always prefer https links over them.