Lately, I find myself using Gopher more and more, as part of my research about the small web. I'm trying to build a low-resolution timeline of major events in gopherspace, geminispace and other communities (like Yesterweb), so I can propose the idea that these networks are the fruits of one cultural phenomenon: disenchantment with the web, desire to slow down or something else (still haven't fully analyzed my data).
I also see mentions of Spartan here and there, but I still don't think Spartan is useful for me, both as a user (a FOSS developer who enjoys small online communities, small software or privacy-by-design) and as a researcher (because Spartan is still heavily tied to Gemini, and won't add another story to my research).
However, I still decided to implement both protocols in a branch of gplaces, my Gemini client. I had to do some refactoring to allow code reuse, so gplaces.c grew from 1074 LOC to 1149 LOC (until commit d679d1f). Thanks to this refactoring, spartan.c is only 59 LOC and gopher.c is only 69 LOC. The code is in good shape, but I'm still fixing small issues when I find them during my day-to-day use of gplaces.
https://github.com/dimkr/gplaces/compare/gemini...dimkr:gopher?expand=1
On the one hand, support for these protocols doesn't make gplaces much bigger, and it's still tiny and lightweight. On the other hand, I can imagine how missing Gopher support affects user experience for users who do use Gopher and prefer to use one "small web" browser for multiple protocols. Users who use gplaces only as a Gemini client won't be affected by the addition of Gopher and Spartan support, so there's nothing to lose here really.
In addition, I don't like the idea of unencrypted traffic, so I decided to display gopher:// and spartan:// URLs in red, as a warning for the user. Is that a good idea or just an annoyance for users?
What should I do? I lean towards merging support for these two protocols, with some warning, but feedback is welcome and appreciated.