Hi !

I have needed to share the link of a post on my gwit site.

The spec defines how to compose/follow a link in the context of a qwit 
site (through well-known site), but not outside a gwit site (ex. sharing 
by email, http, ect.).

I suggest a syntax similar to GET requests parameters, using the 
character ? as a separator.

The link MAY contain the address of a remote for the site, in the form 
of an http-encoded string, provided after the ? character..

This would give :

gwit://[<VERSION>@]<SITE><PATH>[#<FRAGMENT>][?<URL_ENCODED_REMOTE_ADDRESS>]

This would give, in my case :

gwit://16C8A566BB88303C2513CF6328996D46E0440E85/blog/2024/offlirsoch.gmi?remote=https%3A%2F%2Fframagit.org%2Fmatograine%2Fgwitsite.git

Hi matograine, thanks for proposal and sorry for the delay.  More below.

matograine (2024-10-01 20:37:51 +0200) wrote:

> […] I have needed to share the link of a post on my gwit site.
> 
> The spec defines how to compose/follow a link in the context of a qwit site
> (through well-known site), but not outside a gwit site (ex. sharing by
> email, http, ect.).
> 

Actually the Well-Known URI is rather intended for discovering whether a site
that you're already accessing by other means (HTTP) is also available via
gwit.  The most similar thing currently supported for sharing the link as you
mentioned would be for the email containing the gwit link to attach or inline
a site introduction.

But yes, that's cumbersome and I therefore see the value or your proposal.  If
I get it correctly, the gwit client receiving the "extended" gwit URI should
be able to split the remote URI out of it and use it to setup an initial
retrieval of the site if it didn't know about it in advance, right?

> I suggest a syntax similar to GET requests parameters, using the character ?
> as a separator.
> 
> The link MAY contain the address of a remote for the site, in the form of an
> http-encoded string, provided after the ? character..
> 
> This would give :
> 
> gwit://[<VERSION>@]<SITE><PATH>[#<FRAGMENT>][?<URL_ENCODED_REMOTE_ADDRESS>]
> 
> This would give, in my case :
> 
> gwit://16C8A566BB88303C2513CF6328996D46E0440E85/blog/2024/offlirsoch.gmi?remote=https%3A%2F%2Fframagit.org%2Fmatograine%2Fgwitsite.git

The proposal reminds me of how Magnet URIs include tracker or source info, or
how some PyPI URLS included an `#md5=…` fragment for client-side hash
verification.

We should be careful not to break RFC 3986 (URI Generic Syntax) here: query
strings come between path and fragment, otherwise the query is part of the
fragment (i.e. it comes after the `#`).  gwit URIs don't support query strings
and that's a whole can of worms not worth opening here in my opinion.

But using the fragment may make sense, as its info doesn't alter the identity
of the resource being retrieved (RFC section 3.4), and it's supposed to
somehow be removed by the client from the request (not that there are requests
as such in gwit, though).  So an option would be to allow a query-like tail
that would be removed by the client, e.g. (note the `#`):

    gwit://16C8A566BB88303C2513CF6328996D46E0440E85/blog/2024/offlirsoch.gmi#?remote=https%3A%2F%2Fframagit.org%2Fmatograine%2Fgwitsite.git
    becomes
    gwit://16C8A566BB88303C2513CF6328996D46E0440E85/blog/2024/offlirsoch.gmi

Or:

    gwit://16C8A566BB88303C2513CF6328996D46E0440E85/blog/2024/offlirsoch.gmi#…?<existing stuff>&remote=https%3A%2F%2Fframagit.org%2Fmatograine%2Fgwitsite.git
    becomes
    gwit://16C8A566BB88303C2513CF6328996D46E0440E85/blog/2024/offlirsoch.gmi#…?<existing stuff>

One could argue that that may interfere with some use of fragments for certain
document type (though none comes to my mind).  Of course the alternative
brings us back to query strings:

    gwit://16C8A566BB88303C2513CF6328996D46E0440E85/blog/2024/offlirsoch.gmi?remote=https%3A%2F%2Fframagit.org%2Fmatograine%2Fgwitsite.git#…?<existing stuff>

Note how the existing fragment had to be moved to the end, which may not be
evident when creating the URI, besides breaking the RFC's statement that the
query applies to the resource and not the whole URI…  However, using the
fragment also abuses the RFC's stated purpose (section 3.5) of identifying
something within the resource.  But gwit already makes a "creative" use of the
user information part of the URI for specifying site versions anyway, so it
wouldn't be a first… 😁

So I lean towards the fragment approach, though it may deserve some more
thinking…

Cheers,

-- 
Ivan Vilata i Balaguer -- https://elvil.net/