[SPEC] Backwards-compatible metadata in Gemini
cowan at ccil.org
Thu Feb 25 19:05:55 GMT 2021
On Thu, Feb 25, 2021 at 4:17 AM Omar Polo <op at omarpolo.com> wrote:
- we have TLS because it's fundamental to guarantee confidentiality
> between servers and clients
I personally don't give a damn about this (after all, who's going to pass
confidential information over Gemini? See below.), but I accept that other
- we have status codes, because a page that says "an error occurred"
> or "certificate required" cannot be interpreted correctly otherwise
They aren't actually part of the required protocol engine, except for 1x
vs. 2x. The META for the others is just human-readable content, and could
be replaced by a 2x document, and some other mechanism could be found for
the marginal case of 1x. (Clients might exploit 6x to automatically retry
with a (different) cert, but it's unclear that this is the Right Thing: the
protocol document is, as usual, ambiguous, as it says "should be retried"
but not who should retry it.)
> - 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?)
It's still hard to explain ``` within ```: you can talk about it but you
can't show an example.
Anyway, I don't care about any of these points, just that "necessary" is in
the eye of the beholder.
- the one adding the line-type =: (or whatever): you have to parse the
whole document to extract the metadata
True, but that's true for any approach except metadata-at-the-top. Note
that ^^^ within ``` does not mark metadata, so you have to parse at least
and it allows for possibly unreadable text/gemini files
է⫳∈®ϱ ⫯∫∩'♰ ∀ηӱ բ®οв₤ϱ≞ ∁ւ€∀♱ι∏₲ ⫲αւძ էο ®∃∀⫒ ԍϱ≞⫯∏ι ⫭ї₤ℇ∫.
_O_ver _there_/ _O_ver _there_ /_Send_ the _word, _Send_ the _word_ / _to_
[PRETEND THE NEXT PARAGRAPH IS IN ITALICS]
[READ THE WORDS IN ANY ORDER DESIRED]
ad pulcritudinem tria requiruntur, integritas, consonantia, claritas.
There's no problem creating Gemini text that's hard to read.
you probably will have trouble here
Workers at the Tower of Babel:
"Bitte geben Sie mir einen kleineren Schraubenschlüssel.'
'Non ho idea di quello che stai chiedendo.’
‘Давайте чашку чая и домой.’
‘Kei te korero koe i tito noa, ko ahau ngenge o te whare pourewa.'
There. A perfectly valid text/gemini or indeed text/plain document, and
yet quite unintelligible, and it would be trivial to make it far worse.
The question is, what is the _motive_ for writing and serving such rubbish?
Web pages lie to search engines because money. Web pages contain hidden
text because money. Web pages plant tracking pixels because money. The
love of money is the root of all Web evil. But where's the money in
Gemini? I mean, you could put textual ads in your pages and a link to a
website, but why not just use the website?
An user on a non-sophisticate client cannot (easily) understand
> that. It's just full of bloat.
Again, you'd have to be a fool to write something like your example or mine
except for hack value. Reasonable people would either put metadata at the
bottom of the document or the most important entries at the top and less
important ones at the bottom; it's the possibility of doing that, along
with allowing links-with-metadata, that make me want it to be able to go
anywhere. Gemini is like (anarchist) Anarres: everything is open to
everyone's . The Web has become like (capitalist) Urras: there is lots of
glitz on top, but the important stuff is hidden in the cellars, where
people are bleeding to death.
Repeating myself: metadata conventions should go in a metadata spec, *not*
in the text/gemini spec, since neither clients nor servers are required to
take any notice of them.
What I think is missing in all these discussions is a valid reason to
> outweight the cons.
Lars explained that much better than I could. Also, look up
cataloging-in-publication, which basically puts metadata on the copyright
page of every published book. That way it stays with the book.
However, I feel that denying and turning down feature requests for
> addition is not a good thing. I think we should reflect on what's the
> actual problem and solve it, because this smells like a XY problem to
"If you want PL/I, you know where to find it." --Dennis Ritchie
(PL/I was notoriously a bloated language by the standards of its time: by
today's standards, not so much.)
If we want to give people ways to manage their local data, maybe because
> they want to search across documents or do some kind of publications
> over Gemini, then centralising metadata in one place is an option.
Out-of-band markup is fine, except that it tends to get lost as content is
passed around, reduced reused recycled.
Sure, I can stick a
> description of "About the interpretation of the Will of power in
> Nietzsche" with tags "philosophy, nietzsche, will-to-power" and a
> category of "essay", but you cannot trust me to talk about those
> arguments in the page, maybe it only contains link to pics of cute
> kittens :)
Do that enough and people will simply ignore you. It's a funny-once joke.
> Why I think metadata will make things like GUS worst? While full-text
> search is not without its drawbacks, as Bortzmeyer reminded us, people
> will abuse the metadata to "go up" in the search results,
Why would a geminaut want to "go up"? We are already in orbit.
On Thu, Feb 25, 2021 at 6:41 AM Omar Polo <op at omarpolo.com> wrote:
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...
I agree: social pressure is probably enough here. But scripts make clients
*do* things, which is very different from passive metadata.
> ...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.
Again, clients have to implement this, and they probably won't because it's
a lot of trouble.
> 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.
I'm sorry, but I am unwilling to take this for granted. Why hide them?
(I'm already annoyed that Gmail hides signatures, and mine aren't always
the same, so I don't use the standard "-- " line to announce them any more.)
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
I actually think hiding the URL is bad UX. People should be able to know
*before* going to a page where it's coming from. Showing the domain is not
enough, because multi-hosting. (This is an option in Lagrange now.)
> 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?
"Know" is a very strong verb, especially for something that hasn't happened
yet. Metadata in HTML head elements was *required* to be hidden from day 1.
> 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.
That's what I want too. =: does not have to be a text/gemini line type,
just a convention explained elsewhere.
OT: I'm actually designing something like GeminiScript, but not for Gemini
clients. I think the idea of no-install instant-download software with
severe limitations on presentation and no access to the local system except
very limited keyboard/screen/mouse is in fact a good one, but unlike
Brendan Eich I have the luxury of more than two weeks to think about it. I
also want to make it as accessible to non-professionals as microcomputer
Basic was. It would run in its own native client, either CLI or TUI or GUI
(there are some issues around the fact that CLIs linearize access). Like
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
Your worships will perhaps be thinking that it is an easy thing
to blow up a dog? [Or] to write a book?
--Don Quixote, Introduction
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gemini