approachabe & frugal & composable

[colecmac at protonmail.com]

> At this point I am honestly considering speccing that => lines may
*only* use URLs whose scheme corresponds to an application protocol.
Permitting *any* RFC-compliant URL is just way, way too open-ended and
defeats the point of so much careful efforts elsewhere in the protocol.

I would be in favour of this, I don't want to start seeing pages that
have tags on them.


makeworld

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, June 2, 2020 4:00 PM, solderpunk <solderpunk at SDF.ORG> wrote:

> On Tue, Jun 02, 2020 at 09:09:47PM +0200, Petite Abeille wrote:
>
> > Either a client understands an URI scheme, say http/https, and knows what to do with it (e.g. turn it into an interactive hyperlink of sort, pretty print it somehow, etc), or it doesn't, in which case just display it 'as is'.
> > In short, only decorate scheme you know, leave the rest alone, and render it as static text.
> > Never hide anything.
> > Put another way, text/gemini is fundamentally text. Nothing more, nothing less. And that's good enough for a minimal client.
> > More advance clients could choose to render links to the best of their abilities, say gemini:// links are turned into navigational aids of sort.
> > And that is that.
>
> This sounds "short and sweet" and simple, but this basically makes
> Gemini infinitely extensible. Link lines stop having anything to do
> with the concept of "links", and become vehicles for anything that
> somebody wants to come up with a URI scheme for, which is a large and
> totally open category which will grow over time and may come to include
> very scary things (for the love of God, there was an IETF draft for a
> javascript: scheme! [1]). Giving clients the power to recognise any old
> scheme which comes along is guaranteed to induce a repeat of the
> evolution of the web. Basically we can now think of the line:
>
> => scheme:restofuri Human friendly label
>
> as equivalent to something like:
>
> <scheme arg1="restofuri" arg2="Human friendly label"/>
>
> text/gemini would be fully as extensible as HTML where client authors
> can just invent new tags like <blink> and <marquee>. It's exactly what
> nobody here wants.
>
> I am so angry that there isn't a construct in the internet
> architecture which is nothing more than a convenient way to concisely
> specify an application protocol, a hostname or IP address, a port, and
> a path. This is such an obviously useful thing to have. It's what
> almost everybody thinks a URL is, but it turns out that's wrong. Who
> would have thought that Gopher's clunky and archaic notation of:
>
> path<TAB>hostname<TAB>port<TAB>
>
> literally has not been improved on in ~30 years?
>
> At this point I am honestly considering speccing that => lines may
> only use URLs whose scheme corresponds to an application protocol.
> Permitting any RFC-compliant URL is just way, way too open-ended and
> defeats the point of so much careful efforts elsewhere in the protocol.
>
> Cheers,
> Solderpunk