[tech] [spec] On extending gemini

Stephane Bortzmeyer stephane at sources.org
Tue Feb 23 07:48:12 GMT 2021


On Mon, Feb 22, 2021 at 12:44:05PM -0800,
 Nathan Galt <mailinglists at ngalt.com> wrote 
 a message of 32 lines which said:

> 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.

Simplicity and non-extensibility are core tenets of Gemini so I think
we all agree it is important to keep this target in sight. But I do
not think it means to reject everything without even considering
it. This would be a simple course of action, but it may deprive us of
useful things, and may hamper Gemini's adoption. I think we should
rather consider each proposal for its merits (and problems), keeping
in mind the criteria (which are sometimes non-explicit: for instance
the "only one network request" rule recently proposed by Solene was
not explicit in the specification).

Using as an example two recent discussions (favicons and metadata),
instead of dismissing them immediately, we could consider:

* do they add to the network budget (favicons do)?
* do they facilitate fingerprinting (favicons do, metadada don't)?
* is there a risk they add a pressure on non-willing clients to
  support them (CSS would do: a Web client without CSS is not very
  useful, while a Web client without favicon support is certainly not
  a problem for user adoption)?
* what level of complexity do they add (none in non-willing clients,
  for favicons and metadata, very little for those who adopt it)?
* do they degrade gracefully for non-willing clients (both proposals
  do)?

Therefore, discussions on this list about new proposals are
reasonable, IMHO.





More information about the Gemini mailing list