💾 Archived View for rawtext.club › ~sloum › geminilist › 005511.gmi captured on 2024-03-21 at 16:40:40. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Nathan Galt mailinglists at ngalt.com
Tue Feb 23 09:59:48 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Feb 22, 2021, at 11:48 PM, Stephane Bortzmeyer <stephane at sources.org> wrote:
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.
You’re only looking at the current metadata proposals, though, and not extrapolating out what sort of extensibility metadata brings. Once some capsules start using metadata that’s only usable in some clients, those capsules will have an implicit Best Viewed In Gemini Client X label stuck to them. The Best Viewed In Browser X era of the Web is _not_ something I want replicated in Gemini.
Because I’m already strongly in favor of making it easy to make a good Gemini client, I’m against proposals that could, down the line, increase the amount of work that it’d take to make a good, full-featured Gemini client. Arbitrary-metadata proposals are a fully general can of worms that, say, double-digit status codes aren’t.