# [SPEC] Backwards-compatible metadata in Gemini

Omar Polo op at omarpolo.com
Thu Feb 25 11:40:47 GMT 2021

Oliver Simmons <oliversimmo at gmail.com> writes:

> On Thu, 25 Feb 2021 at 09:17, Omar Polo <op at omarpolo.com> wrote:
>>
>> I think this is a bogus point.  I never contributed to OSM, but from
>> what you're saying I suppose they use something like XML/SGML/...  Those
>> things are *meant* for extensions (the 'X' in XML stands for that),
>> whilst everything around Gemini is focused on non-extensibility and
>> simplicity, even at cost of missing features.
>>
>
> I'm not talking about XML/etc, that's an entirely separate topic.
> I'm talking about the key=value system.
>
>
>> have:
>>  - we have TLS because it's fundamental to guarantee confidentiality
>>    between servers and clients
>>  - we have status codes, because a page that says "an error occurred"
>>    or "certificate required" cannot be interpreted correctly otherwise
>>  - we have a media-type in the response, so users know what kind of
>>    document they're getting
>
> These are all about the protocol, not Gemtext.

While it's true that the protocol and gemtext are two different things
(I can serve HTML over gemini and text/gemini over HTTP), they are close
to each other, and it conveys the point that Gemini is made of
practically only needed stuff, nothing more.

(I read about the Mercury protocol, which I didn't knew, and it's really
interesting, but only if you don't consider TLS essential, which I do.)

>>  - we have links, so we can connect different pages, even across
>>    different capsules
>>  - we have titles, paragraphs, quotes and lists to express and organize
>>    our writings
>>  - we have pre-formatted blocks to allow certain types of
>>    explanations/presentations that otherwise would have been impossible
>>    (how do we teach how to write text/gemini in text/gemini?)
>>
>> From here you can notice how humanly-centric Gemini is.  We don't have
>> features for bots (more than what it's absolutely needed at least) and
>> even more importantly we only have basic and necessary stuff.  There's
>> no fluff in Gemini.
>
>
>
>> If you think about it, we only have features that we can't objectively
>> live without (no links? no paragraphs? no media-types? ...) while we're
>> lacking various things that would be "nice to have".
>
> Specification section 5.5 - Advanced line types:
>> The following advanced line types MAY be recognised by advanced clients.
>> Simple clients may treat them all as text lines as per 5.4.1 without any loss of essential function.
>
> I agree though, unnecessary features shouldn't be added.
>
>
>> We don't have headers, because with them comes extensibility and
>> complexities, and we're getting just fine without them.  We don't have
>> inline formatting because it's difficult to handle client-side and we're
>> doing really fine without, etc.
>
> Extensibility *is* an issue with metadata, but this applies to Gemtext
> as a whole due to its nature of being text-based, who's to stop
> someone from creating a new line type that their client understands?
> Standardising metadata now would make people less likely to add it in
> their own weird formats in the future, and laying down solid rules of
> what is and isn't allowed as metadata in Gemini documents helps in
> avoiding (it doesn't prevent entirely) people from adding styling or
> other weird things in the future.

It's attrition that will prevent things like this in the future, not
standardisation.  For example, I can create a Gemini client that
supports a script-type line, like

but then I would have to convince this list, people who write content
and people who write clients and tools to recognise the -~ line type and
cope with that.  I don't think it will gain traction, so...

> On the opposite side, adding metadata would make it easier for people
> to add new things like styling, if they ignore what it's intended for.
> Neither side of the argument really wins here in my eyes.

...not having metadata is slightly better then because people would have
to come up with a syntax, implement it in their clients and convince
others to do the same while looking weird in the eyes of others.  Having
a standardised syntax for it allows from day-one someone to say
background-image: kittens.png' and be fine with that, without looking
weird to other people browsing his/hers capsule.

It's similar to why we don't have headers in the protocol: because
someone, somewhere at some time will abuse them.  Having faith in the
community is a good thing, but ensuring that certain things aren't
possible is better.

One thing that I haven't though about when writing the mail, but only
later when discussing the matter with thfr@, is that we're trying to
hide stuff from users eyes.  Sure, if used correctly those two proposed
syntaxes (=: and ^^^) can be easy to read, but lets be honest: clients
won't show them as-is, in particular the more advanced ones.

As things stands now, there are only two things that Gemini clients
usually hide: the URL of a link-line and the alt-text of a pre-formatted
block.  There's a understandable UX reason for that, but do we really
need to add something else that we know will be hidden to end users?

(Yeah, clients also hide the #' and =>' usually too, but that's not
count as "hiding stuff" IMHO, and they usually provide ways to see the
URL or alt text, or even the raw text/gemini)

Another thing that I forgot to explicitly say in my previous message is
that we can use some sort of common notation, a convention, rather than
adding new things to the specification.  See for instance the
"Subscribing to Gemini pages" companion specification: a lightweight,
convention-based way to provide atom-like feeds.  I found it pretty
elegant, and has proven a) easy to implement b) easy for content writers
to use c) easy for end-users to consume and d) avoid adding extra line
types/file types/etc to the specification.

>[snip]
>
> Now, to get off-topic:
>
>> [0]: mine?  I would love to have a syntax for definition lists and
>>      3-levels of unordered lists.
>
> If you mean ordered lists with your first point they would be ~fairly
> hard for clients to parse compared to other line types, they don't
> start with a static first three characters. (See spec section 5.3 -
> "Line-orientation")
> 1. Hi
> 2. Foo
> 3. Bar
> Works fine anyways with plain text, it just doesn't have as nice
> line-wrapping as quotes and unordered lists.

No, I mean definition lists.  They're like dictionary entries, where you
provide a term and then its definition.  In LaTeX is

\begin{definition}
\item[foo] definition of foo
\end{definition}

in mandoc

.Bl -tag
.It foo
definition of foo
.El

in HTML <dl>/<dd>/<dt>.  I find them super-useful when explaining
things, even if they aren't as widespread as other types of lists.  I'm
emulating them with

* foo: description of foo

but this was just a kind of moot point to show that everyone here would
like to add something to the spec probably, but in the end we're doing
just fine as things are.

> Multiple levels of unordered lists actually wouldn't be very hard:
> * Hi
> ** And welcome
> *** to my list
> * Boop!
> ** Booyah!

there were a proposal for that some time ago, but it didn't gained
traction and died.  Amen :/

>> [1]: .gms is GeminiScript of course.  A minimal, non-estensibile and
>>      simple scripting language for your preferred client, hoping it
>>      doesn't lack support for it /s
>
> burn. it. with. fire.
>
>
> - Oliver Simmons (GoodClover)

`