(proposal) on metadata in documents

[smlckz at tilde.pink]

On Mon, 16 Nov 2020, Philip Linde wrote:

> On Sun, 15 Nov 2020 19:41:47 +0000 (UTC)
> smlckz at tilde.pink wrote:
>
>> We don't want or need anything like that. That is a breaking change to the spec so breaks all existing clients.
>
> How so? My client will never interpret such meta-data, and I see the
> lack of provisions for it in text/gemini as a feature, but I don't see
> how adding it would break my client. To my client, it's regular text
> lines in the document body.
What I thought was that if header metadata were to be introduced, they need to
be hidden (at least) as they degrade user experience. You as a visitor do not want
to see the document is X bytes in size or the md5sum or sha512sum of the
document before actual content.

And if they need to be hidden, the spec needs to be changed and that
would break existing clients. Hopefully you can see what I meant.

For this reason, I had to be ''Kill joy'' and amend my proposal so that
the metadata must be placed at the end of the document.

> The main advantage of this proposal is that the spec really doesn't need
> to be concerned with it. It's still text/gemini and there are no
> changes to the protocol. That makes it a great honeypot. Hopefully,
> most future suggestions for changes to the protocol can instead be
> added to an evergrowing list of in-document header fields that no one
> will implement.

Not only text/gemini, but also any other text/* format. I have clearly
stated that this is just metadata. As each field is optional, 
unrecognised fields would be ignored.

> -- 
> Philip
>

~smlckz