[spec] avoiding the transport layer security trap

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¢



More information about the Gemini mailing list