💾 Archived View for gemi.dev › gemini-mailing-list › 000773.gmi captured on 2023-11-04 at 13:06:04. Gemini links have been rewritten to link to archived content

View Raw

More Information

➡️ Next capture (2023-12-28)

-=-=-=-=-=-=-

[spec] avoiding the transport layer security trap

Petite Abeille <petite.abeille (a) gmail.com>

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?

Link to individual message.

---

Previous Thread: Gemini Server - new - gemini.mingmengtou.org

Next Thread: [spec] gemini capabilities