[SPEC] Backwards-compatible metadata in Gemini

[Sean Conner]

It was thus said that the Great nothien at uber.space once stated:
>   
> I'm going to split it into two groups: metadata affecting presentation,
> and metadata about the document.

  There is another group:  metadata affecting navigation.

  Years ago, there was an extention for Firefox (back when I think it was
just known as Mozilla) that would use metadata in the <HEAD> section of a
web page to construct a navigation bar for the site.  The metadata included:

	next		next "page" in the collection
	previous	previous page in the collection
	first		first page in the collection
	last		last "page" in the collection
	up		up one level of the collection tree
	top		top level in the collection
	home		the entry page (might not be the same as top)
	about		about the collection
	archive		page listing each page in the collection
	search		search the collection
	glossary	list of terms used in the collection
	copyright	copyright status of page
	canonical	canonical link to page

  Yes, these can all be just links on a page.  But the idea was not to
clutter the page with these links, but construct a UI element with the
navigation items.  This could include a navigation bar (what I experienced),
but it could also be a menu item, a popup menu, or keyboard shortcuts for
each each one, depending upon the client.

  The Gemini portal at <https://portal.mozz.us> only gives us two of these:
up and top.

> # Metadata for the Document
> 
> What's the /point/ of standardizing a format for providing metadata
> about a document?  Seriously, I don't understand.  What's the benefit of
> letting a client know who the author is?  If you, an author, want users
> to know that you wrote something, just write "I wrote this".  These
> kinds of proposals are unnecessary.  If you want it to be read properly
> by a screen reader, just write in full sentences ('this was written on
> the 23rd of February').  Keep it open, prevent it from turning into a
> matter of convention, and think about how to solve problems /without/
> extending the specification in any way.  Even if it's
> "backward-compatible", you're creating a rift in Gemini - see "Problems
> with Conventions" below.

  Such metadata could include a summary of the page, keywords, copyright
status, location data (location here being the location the page is about,
not the location of the author or reader), time (when the page in question
was written, when it's about, etc.) in addition to the author, in a format
that is easy for a machine to recognize.  A good example is a search engine
could use this information instead of having to attempt to identify it from
the text alone.

> # "It's Just A Suggestion/Idea"
> 
> The problem with 'just' posting ideas and suggestions and proposals like
> these is that they waste everyone's time (including yours).  Instead of
> trying to add new, unnecessary, and unwanted features to Gemini, 

  Unwanted by you, others might want it.  I think there are better arguments
against this than just "don't do it."  That does nothing to convince those
that want it to stop working on it.  They might just go ahead and do it
anyway.

> start
> creating content within it!  We (and I'm speaking for a lot of people
> here) are tired of dealing with new ideas from eager new Geminiauts who
> keep trying (consciously or unconsciously) to reinvent the Web.  

  Yes.  And for the first year about the *only* topic being discussed was
the format for text/gemini.  It is *still* being talked about, only not
quite so much.

> # The Problem with Conventions
> 
> Conventions are naturally difficult because you're politely asking
> people to do something.  This separates the Gemini userbase into people
> who have done that thing and people who haven't.  If you want to create
> a new convention, /please/ think about the effect this can have,
> particularly with conventions involving presentation.  As others have
> pointed out, every new convention threatens to make a split in the user
> base, and if anyone (user or site) can for any reason prefer one side
> over the other, you've begun the process of separation.  Don't do that,
> because we're just going to have to shoot your shit down.

  Having been on this list from the beginning, I can say that the majority
(I would say nearly all) of the proposals have not gone anywhere.  Why? 
Because it's easy to make a proposal, it's apparently impossible to get
anyone to actually *implenent* the damn things, even as a
"proof-of-concept".  That people are lazy is an incredible filter.

  There were two people who came into the mailing list (at different times),
incredulous that TLS was used.  "It's horrible!" they said.  "You should use
something better!" they said.  A simple task of taking them at face value
and saying, "Okay.  Show us!  Implement a server and client so we can see
how much easier and better your ideas are," worked wonders.  One simply
disappeared.  The other actually did the work, and withdrew the idea
(because implementing crypto is not easy).

  Now we have a much strong case for "Why TLS?"  Just "shooting your shit
down" only serves to piss people off.

> # Conclusion
> 
> Please stop.

  It won't.  In six months we'll have a new crop of people asking.

  -spc