Gemini sounds neat. Not sure I'll continue playing with it, but from the spec I have a couple of suggestions you are free to implement or ignore.

# Denial of Service

Permitting zero or more whitespace characters in a request a introduces a denial of service because the request is no longer bounded. Just keep sending whitespace to keep the connection open. Mandating a single character closes this particular hole.

It's possibly a minor DoS considering other attack vectors, but why leave any low-hanging fruit?

# Caching, ETags and Tracking

Caching is great, and I'm sure Gemini devs wouldn't object to caching if it could be handled without introducing user-facing privacy issues. Here's a sketch for an ad network protocol that I think would work with Gemini:

1. Client requests URL X.

2. Server replies with a redirect to "X?tracking-id", where tracking-id is associated with a set of IP addresses.

3. All links in the document append the tracking-id to preserve it.

Anytime a client accesses a document in the ad network, the tracking-id quickly returns. People often have multiple IPs for their laptop, desktop, phone, tablet, etc. but there would be enough overlap in these sorts of requests to correctly tie a set of IPs to a unique client.

What cookies, etags, etc. permit on the WWW is doing this without requiring sharing the client IP database.

So maybe what we can do is still enjoy the benefits of caching while at least detecting when some shenanigans are at play. The ad network outline above is observable behaviour from which we might be able to infer shenanigans.

To reintroduce caching without amplifying the tracking powers, and add the ability for the client to verify the server's ETag is legit, rather than treating it as an opaque identifier. If an etag for content specified the hash function used, then the client can verify the integrity of the document. So take the HTTP ETag header to a syntax like "ETag(sha256): ..."

Like the ad network outlined above, malicious servers could craft slightly different versions of a document for each IP and so generate unique ETags that may permit some sort of tracking in a similar way. However, the gemini document has no notion of hidden data (like comments and hidden fields in HTML), so any such shenanigans will always be visible in some way in the document itself, eg. embedding a unique hash code at the end, for instance.

So in the end, adding caching in this way should improve efficiency without appreciably amplifying tracking.

# Transclusion

A language with a construct becomes more expressive if it also includes its dual. Gemini has document-level references, where a document points to another document, but it lacks transclusion which is a dereferencing operation, such that you can embed another document into the current document.

So links in Gemini are:

=> gemini://some/url

Transclusion would be its inverse:

<= gemini://some/url

This is pretty handy actually. Kinda like iframes without the headaches. However, unlike iframes, I don't think the client should load the URL itself, but rather all communication should go via the server for the top-level document. This is again to avoid amplifying the tracking powers, since a top-level document server could append tracking-id to transcluded URLs and then they act just like tracking cookies.