💾 Archived View for rawtext.club › ~sloum › geminilist › 005847.gmi captured on 2023-11-14 at 09:49:11. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Petite Abeille petite.abeille at gmail.com
Tue Mar 2 09:46:11 GMT 2021
- - - - - - - - - - - - - - - - - - -
It has been made abundantly clear that Gemini has no appetite whatsoever to untangle the protocol itself from its chosen transport layer, namely TLS.
So be it.
This is very much in line with older protocol designs such as HTTP vs HTTPS.
Some design mistakes become to entrenched they become best practices :)
https://dilbert.com/strip/2008-09-03
IPFS —the modestly named InterPlanetary File System— shows another way: by abstracting the connection mechanism from the protocol itself.
Specifically, the 'how' of connecting to a service is abstracted by describing its details with multiaddr.
For example, accessing a Gemini service over a plain tcp connection could be specified as:
/dns4/host.xyz/tcp/1965
While accessing the same Gemini service over TLS+SNI could be specified as:
/dns/host.xyz/tcp/1965/tls/sni/host.xyz
Finally, something like DNS service discovery can bootstrap the entire process by advertising what specific multiaddr applies to a given Gemini host:
dig +short TXT _gemini._tcp.host.xyz.multiaddr=/dns/host.xyz/tcp/1965/tls/sni/host.xyz
That's all folks.
±0¢