💾 Archived View for rawtext.club › ~sloum › geminilist › 001260.gmi captured on 2020-09-24 at 02:00:11. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Tue Jun 2 21:33:03 BST 2020
- - - - - - - - - - - - - - - - - - -
On Tue, Jun 02, 2020 at 09:57:27PM +0200, Petite Abeille wrote:
As of yesterday, the freeze is over! The spec is now "liquid" once again.
Cool. Can we remove things? :)
Yes, but not willy nilly. :)
❶ drop ;charset= from text/gemini content-type response. Everything is UTF-8. Gemini doesn't support legacy encodings.
Rational: Clients shouldn't burden themselves with legacy charset conversions, which is finicky. Servers are better placed to normalize encoding if they must. Gemini is about the future, not the past (EBCDIC 273 anyone?).
Being "about the future" shouldn't mean "losing the ability to view thepast".
Clients are very explicitly permitted not to burden themselves withlegacy charset conversions. From section 3.3:
Compliant clients MUST support UTF-8-encoded text/* responses.
Clients MAY optionally support other encodings. Clients receiving a
response in a charset they cannot decode SHOULD gracefully inform
the user what happened instead of displaying garbage.
If the majority of clients don't support anything other than UTF-8(which is likely, because adding support for other things is not fun,and many Gemini clients will be written for fun as smallsingle-developer or small-team projects), this will exert a strongpressure for people to only author in UTF-8 (which is also verystrongly encouraged in the Best Practices document that nobody reads),as well as motivate the inclusion of automatic transcoding in servers.
❷ drop everything from text/gemini but text and link lines.
Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...). text/gemini will not move the state of the art. Keep it simple. Less is more. My biggest objection to this is the heading lines, which I actually don'tsee as fundamentally about formatting at all (although obviously clients*can* use it as a hint for formatting and many do), but rather aboutimparting genuine semantic structure to a text/gemini document. Gemfeeduses these headers to "just know" how to title entries in a feed and howto title feeds themselves. Lightweight CMS software could use them togenerate a directory listing of documents using their titles instead oftheir filenames, relieving authors of the need to duplicate the title inboth post.gmi *and* index.gmi. Clients can use it to let users skipthrough long documents by section or subsection, or to display a tableof contents. Those headers don't just look pretty in some clients, theycan and should do real actual work which genuinely enhances theexperience of consuming textual content. I honestly think that gettingrid of those would be a case of "less is less".
❸ mandate
= TLS 1.3. Drop legacy support.
Rational: no point dragging the burden of the past into the future. Gemini innovative take on TLS deserves a modern foundation.
Funny you should mention this. Just today (or yesterday?) a new LibreSSLversion was released which now enables TLS 1.3 support in both clientsand servers by default. The only reason I didn't spec 1.3 in the firstplace was because I didn't want to discourage the use of LibreSSL whichis a project I support a lot (and which the first ever Gemini serverhappened to be built with!). I used to think that as soon as TLS 1.3came to LibreSSL, I would make exactly this change.
...
Since then I have also learned about BearSSL, which is *another*implementation I really don't want to discourage use of due to itsextremely small footprint which I feel aligns nicely with Gemini'sphilosophy.
That said, the odds of 1.3 support appearing in BearSSL any time soonseem slim, so waiting for this as well could doom us to never ditching1.2.
So, I will consider this. Feedback from implementers welcome.Statistics on how many known servers support 1.3 especially welcome!
Just for the record, that never-read Best Practices document alsoencourages people implementing TLS 1.2 to limit the ciphersuite tosomething 1.3-esque.
In protocol design, perfection has been reached not when thereis nothing left to add, but when there is nothing left to take away.
This would make Saint-Exupéry proud.
This quote has always been dear to my heart. :)
Cheers,Solderpunk