Should Gemini clients alert users upon redirect?

[Sandra Snan]

Luke wrote:
> It may seem like there is a "natural" difference between these two URL
> forms, but as far as I understand it the semantics of any URL path
> segment is opaque and determined by the server. The path is an opaque
> string whose semantics is not intrinsically discernable.
>
> There may be no files or directories involved whatsoever. It happens
> that there is a simple sort of implementation to serve a folder of files
> in this way, but that is by no means a universal URL path semantics that
> we can make inferences about.
>
> gemini://server/foo may or may not serve the same content as
> gemini://server/foo/ or it can redirect there. Either way it is up to
> the server to determine the semantics of the resource.

I don't wanna disagree with someone who is in my own corner on this?,
but?

It's tree semantics, which is evidenced in practice by the way relative
links work. (Especially since .. and co exist).

A link to bar/baz from gemini://server/foo leads to
gemini://server/bar/baz while a link to bar/baz from
gemini://server/foo/ leads to gemini://server/foo/bar/baz.

I've now implemented 31s and 301s from the slashed to unslashed so now I
can start using relative links again. Except they'll have to be written
to reflect the reality that /foo is a leaf node and not a directory
node, i.e. the leaf node is no longer a file named "" (the empty
string).

It's also something that might be good to reflect in culture and
convention.

I could see if, for example "gemini://medusae.space/index.gmi?20",
instead had the url been gemini://medusae.space/home/cooking/index.gmi,
how that would make sense in some way.

I've kept my own web page & capsule having all flat URLs in one huge
name space for a while. It's a tradeoff?

Sandra