~ivilata/gwit-spec

1

Expected link navigation depending on the current version of the site

Details
Message ID
<d586b5639a01561c7edcecfd8a53abfe@zaclys.net>
Sender timestamp
1736962577
DKIM signature
pass
Download raw message
Hi, 

I have a question about the expected behavior of URIs in context of 
browsing a site on a past commit.

Let's say we are on site 0xaaaa..., with HEAD of branch gwit_0xaaaaaaaa 
being commit 00000. I browse to a doc on a previous commit, let's say 
gwit://11111@self/index.gmi. Here I meet these links :

=> gwit://0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi
=> gwit://self/article.gmi
=> ./article.gmi
=> /article.gmi

What happens when I click on one of these links ?

* should I go to 
gwit://11111@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi ?
* should I go to 
gwit://00000@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi ?

Here is how I see the answer, onsidering followinf sentence :

> When parsing such a URI, a gwit client MUST first replace self with the 
> site identifier as described above

1. These links are equivalent and lead to HEAD of branch 
gwit_0xaaaaaaaa, aka 
gwit://00000@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi :
=> gwit://0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi
=> gwit://self/article.gmi

2. relative paths always refer to the current commit, hence these links 
lead to 
gwit://11111@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi
=> ./article.gmi
=> /article.gmi

___

If my understanding is right, I think this sentence needs more examples 
(if I understand RFC3986 right) :

> Resolving references (i.e. links) relative to a given base gwit URI 
> works as specified in Section 5 of RFC3986

I suggest to append these examples :

```

# In context of page gwit://<VERSION>@<SITE>/
gwit://<VERSION>@<SITE>/foo/bar + baz (or ./baz) => 
gwit://<VERSION>@<SITE>/foo/baz
gwit://<VERSION>@<SITE>/foo/bar/ + baz (or ./baz) => 
gwit://<VERSION>@<SITE>/foo/bar/baz
```
___

If I am wrong, my question is : how to forge links indicating "navigate 
to this file at the _current_ state of the gwit site" (you don't have 
commit ID before commiting) , and links indicating "navigate to this 
file at the _most recent_ state of the gwit site"
Details
Message ID
<Z4krD8enpYKiwXM9@sax>
In-Reply-To
<d586b5639a01561c7edcecfd8a53abfe@zaclys.net> (view parent)
Sender timestamp
1737046303
DKIM signature
pass
Download raw message
Hi, thanks for your observations!  You're right in your interpretation of the
spec; see inline for more details.

tom.ngr@zaclys.net (2025-01-15 17:36:17 +0100) wrote:

> I have a question about the expected behavior of URIs in context of browsing
> a site on a past commit.
> 
> Let's say we are on site 0xaaaa..., with HEAD of branch gwit_0xaaaaaaaa
> being commit 00000. I browse to a doc on a previous commit, let's say
> gwit://11111@self/index.gmi. Here I meet these links :
> 
> => gwit://0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi
> => gwit://self/article.gmi
> => ./article.gmi
> => /article.gmi
> 
> What happens when I click on one of these links ?
> 
> * should I go to
> gwit://11111@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi ?
> * should I go to
> gwit://00000@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi ?
> 
> Here is how I see the answer, onsidering followinf sentence :
> 
> > When parsing such a URI, a gwit client MUST first replace self with the
> > site identifier as described above
> 
> 1. These links are equivalent and lead to HEAD of branch gwit_0xaaaaaaaa,
> aka gwit://00000@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi :
> => gwit://0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi
> => gwit://self/article.gmi
> 
> 2. relative paths always refer to the current commit, hence these links lead
> to gwit://11111@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi
> => ./article.gmi
> => /article.gmi

Yes, this matches the intent of the spec, as RFC3986 keeps the current
"authority" part of the URI (in our case, `[<VERSION>@]<SITE>`) when resolving
a relative link.  This means that browsing a site containing relative links
should keep you "stuck" at the version where you started from, which looks to
me like the natural behaviour for a system where site versioning is relevant.
The gwit client may then ease "jumping" to the latest version of a page.

Please note that the `alt` config value rewriting a link like
`https://foo.bar/page.html` to `/page.html` instead of `gwit://self/page.html`
is consistent with this behaviour.

> ___
> 
> If my understanding is right, I think this sentence needs more examples (if
> I understand RFC3986 right) :
> 
> > Resolving references (i.e. links) relative to a given base gwit URI
> > works as specified in Section 5 of RFC3986
> 
> I suggest to append these examples :
> 
> ```
> # In context of page gwit://<VERSION>@<SITE>/
> gwit://<VERSION>@<SITE>/foo/bar + baz (or ./baz) =>
> gwit://<VERSION>@<SITE>/foo/baz
> gwit://<VERSION>@<SITE>/foo/bar/ + baz (or ./baz) =>
> gwit://<VERSION>@<SITE>/foo/bar/baz
> ```

I see how a clarification in the spec helps here, so I added one in commit
1e935e43 (with a single example to avoid some repetition).  Thanks for the
suggestion!

> ___
> 
> If I am wrong, my question is : how to forge links indicating "navigate to
> this file at the _current_ state of the gwit site" (you don't have commit ID
> before commiting) , and links indicating "navigate to this file at the _most
> recent_ state of the gwit site"

Your interpretation was right, but I'll include example links for both
behaviours, for the sake of completeness:

- Navigate to same state specified in URI being viewed: relative link (without
  authority part): `sub/page.gmi` or `/top/sub/page.gmi`.

- Navigate to most recent state: absolute link (with authority part):
  `gwit://0x.../top/sub/page.gmi`, `gwit://self/top/sub/page.gmi`,
  `//self/top/sub/page.gmi`.  No way to use a generic relative link here,
  though the client may help.

Cheers!

-- 
Ivan Vilata i Balaguer -- https://elvil.net/
Reply to thread Export thread (mbox)