[SPEC] Backwards-compatible metadata in Gemini
Julien Blanchard julien at typed-hole.org
Tue Feb 23 19:23:25 GMT 2021
> Le 23 f?vr. 2021 ? 20:09, nothien at uber.space a ?crit :
>
> ?I'm just going to quickly address everything about the metadata ideas /
> proposals:
>
> They're not necessary.
>
> I'm going to split it into two groups: metadata affecting presentation,
> and metadata about the document.
>
> # Metadata for Presentation
>
> Gemini is (in specification and in spirit) against any specification of
> presentation. Stuff like favicons or colors as a part of the document
> are problematic because you're going above and beyond the /one/ thing
> that Gemini is trying to do: provide content without presentation.
> Instead of trying to introduce these, please work within the limits that
> Gemini has already presented to you.
>
> # 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.
>
> # "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, 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. Please
> /stop/ thinking about Gemini like it's the Web, or a replacement, or
> anything of the sort! Come to Gemini with an open mind to what it's
> trying to do. Read the spec, read the FAQ, read the companion
> documents, read the mailing list, and /understand/ the spirit of Gemini.
>
> # 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.
>
> # Compatibility
>
> Another issue with conventions is the fact that we have over 200
> individual pieces of software which use Gemini in its current state.
> This makes Gemini /very/ resistant to change, because we don't have the
> manpower to update all of that software. This is why the spec is now in
> a near-freeze state - all we want to do now is make clarifications to
> the existing spec and to not add new things.
>
> # Conclusion
>
> Please stop.
>
> Thanks.
>
> ~aravk | ~nothien
I wholeheartedly agree, please stop proposing unnecessary complexity that benefits nobody (just for the sake of normalizing everything) or adds client display fancyness.
We should always consider underpowered devices, screen readers, people with a slow internet connection. I know TLS is already a burden for some of these cases so let?s not add more data to transfer.
?
julienxx
Archive home | About this archive