<-- back to the mailing list

[tech] [spec] On extending gemini

Nathan Galt mailinglists at ngalt.com

Mon Feb 22 20:44:05 GMT 2021

- - - - - - - - - - - - - - - - - - - 
On Feb 20, 2021, at 9:23 PM, Michael Lazar <lazar.michael22 at gmail.com> wrote:
The secret to gemini is not what it restricts; but what it enables.
Constraint breeds creativity. This is the reason that gopher and
gemini have been successful.

While this quote is far enough from the main thrust of Michael’s point to be considered a grossly misleading out-of-context quote, I want to agree with it in parts.

Restrictions on Gemini (the protocol and gemtext) make it easy to have lots of Gemini clients that are all capable of browsing _all_ of Geminispace and not just the simpler ones. This is in _stark_ contrast to HTTP-land, where if you want to browse all of the Web you need to use one of 2.5 browser engines. I think having lots of good clients for all the popular platforms (and many of the unpopular ones!) is a goal worth preserving, even though I have a bunch of good clients for all the platforms I’m ever likely to use (and I’m exceedingly unlikely to write one of my own).

Because Gemini complexity and browser diversity are fundamentally at odds with each other, and the Web already chose complexity at the cost of diversity, I’ve become much more against protocol/gemtext additions. I thought the favemoji thing was cool when I first heard about it, but since it’s something of a camel’s nose in the tent, I changed my Amfora settings back to not requesting them.

=

https://idioms.thefreedictionary.com/a+camel%27s+nose+(under+the+tent)