[SPEC] Backwards-compatible metadata in Gemini

[Stephane Bortzmeyer]

On Thu, Feb 25, 2021 at 10:16:52AM +0100,
 Omar Polo <op at omarpolo.com> wrote 
 a message of 161 lines which said:

>     As things stands, I know I can
> 
>     cat file1.gmi file2.gmi ... > result.gmi
> 
>    and obtain a valid text/gemini file.

One of the things missing in the current specification is a formal
grammar of gemtext, so there is currently no way to know if lines must
end with a end-of-line or is the end-of-file sufficient.

=> gemini://gemini.bortzmeyer.org/gemini/missing-eol.gmi Example

Amfora and Lagrange seem to accept the last line (the one without an
end-of-line). But your example with cat would break it, concatening
the last line of the first file with the first line of the second file.

> Also, the examples you gave in support of your proposals seems bogus
> too.  Serving a mailing list archive over Gemini?  Cool, but why convert
> the mails to text/gemini?  Wrapping them in ``` (with headers visible)
> or serving them "raw" is not enough?

Because humans (specially non-anglosaxon humans) have trouble with
"From", "Subject" and "Message-ID"?

> If we want to build a better GUS I don't think that adding metadata
> to text/gemini will solve anything, it will actually make things
> worst.  The point is, you can't trust 3rd-parties metadata. [...]
> people will abuse the metadata to "go up" in the search results, and
> the outcome of that is crystal-clear on the Web,

I'm not convinced by this "look at the SEO mess" argument. Gemini is
not the Web, there is no money at stake, marketing people and salesmen
frown upon Gemini ("what, no pictures? No tracking?") so I really
doubt that many people would resort to dirty tricks just to be higher
in GUS' results.