💾 Archived View for rawtext.club › ~sloum › geminilist › 005504.gmi captured on 2023-11-14 at 10:03:17. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

[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 thinkwe all agree it is important to keep this target in sight. But I donot think it means to reject everything without even consideringit. This would be a simple course of action, but it may deprive us ofuseful things, and may hamper Gemini's adoption. I think we shouldrather consider each proposal for its merits (and problems), keepingin mind the criteria (which are sometimes non-explicit: for instancethe "only one network request" rule recently proposed by Solene wasnot 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 arereasonable, IMHO.