"Wide load" status code(s)?

[solderpunk]

On Fri, Jun 12, 2020 at 09:25:55AM -0400, Natalie Pendragon wrote:
> 
> Okay, here are some statistics for the most prevalent content types.
> Please do share any feedback you have, and I'll likely add this or
> something similar to the statistics page soon so it's continually
> available and up-to-date.
> 
> The number in parentheses after content_type is the number pages
> in Geminispace with that content_type, and I hope everything else is
> self-explanatory!
> 
> # text/gemini (10378)
> Mean   :    2.1 K
> Median :    1.2 K
> Max    :  753.3 K
> 
> # text/plain (1390)
> Mean   :    4.2 K
> Median :    1.4 K
> Max    :  333.8 K

Thanks for sharing these!  This is actually really useful information to
have, for thinking about the role of TLS overhead in Gemini.  It
actually seems like most text/gemini content is in fact about as big as
the server's TLS certificate or smaller, which kind of blows the idea of
Gemini being a good match for constrained networks out of the water -
even if we did have those 2x status codes, you'd still need to download
the server's cert, plus the (comparatively small) handshake traffic,
before you could make the decision to terminate early.

This overhead also scuttles lots of simple ideas to work around Gemini's
lack of a HEAD request equivalent.  Defining a well-known endpoint where
clients can fetch, e.g. a small file with the timestamps of the N most
recently updated files the server hosts makes no sense whatsoever if the
TLS overhead of fetching *that* list is, in fact, just as big as the
possibly out-of-date file the client actually wants in the first place.

It doesn't need to make it into the spec, but over time we should
develop and publicise best practices for minimising this overhead.  This
may include choosing signature schemes which are secure with smaller
key sizes, like ed25519.  Self-signed certificates also have a strong
advantage here by virtue of not needing to include a long chain of certs
leading to a trusted root.

These measures will bump heads with Petite Abeille's point about TLS
fingerprinting and how it's good, from an anti-censorship point of view,
to blend in with the crowd by not using "unusual" certificates.

Cheers,
Solderpunk