Proposal about content-size and hash

[Arav K.]

> The list has been full of little proposals to add just one
> more protocol element to make things look a bit more like http
> or one more tag to make things look a bit more like html.
>
> In a way this is understandable - the features of http+html
> are well known, and part of ones mental problem solving kit, and
> everybody uses gemini a bit differently, so when encountering
> a limitation, suggesting bits of http+html is easy...
>
> But (and I don't speak for solderpunk) I view gemini as a
> reaction against http/html - the thesis is that there might
> have technical aspects of that stack which has made surveillance
> capitalism easier. So I don't see gemini as http+html lite - I
> see it as its antithesis.
> 
> If people want to see gemini evolve, don't have it converge
> on http+html, have it work towards a better world.

This is an orthogonal point.  Yes, I agree that there are elements of
HTTP+HTML that allow for surveillance, and yes, we don't want them, but
a content-size header is not wandering in that direction at all.  It is
an optional extension that allows clients to show progress bars and
potentially give ETAs for downloads.  Period.  Please tell me about what
aspects of surveillance capitalism content-size allows for.

> For instance: In this thread people worry about partially
> downloaded data - we don't know if a gemini document has
> been transferred completely. We also have the problem that
> people are writing gemini to web gateways but other people
> would like to keep their content in gemini-space only.
> And then Emery Hemingway astutely points out that the modern
> web has forgotten about caching and replication.
>
> So: If (and it is a big if) there extension proposals to be
> made, how about an (optional) footer in the document markup
> (not the transfer protocol) which improves on the mean:
>
> "(c) Joe Soap, all rights reserved"
>
> to something which states under what conditions that document
> might be distributed, if it is a cachable static page or one which
> updates and who should be credited as author. There are many
> parts of the small web which contain a snippet of valuable
> information, and often it is unclear how to rescue those
> if the original site disappears. A line like
>
> -- CC-SA: Joe Soap
>
> for creative commons, share alike or
>
> -- GMI,DYN,NOC: Joe Soap
>
> for gemini space only, dynamic content not to be cached, or just
>
> --
>
> for end of document. So this mechanism then solves multiple
> problems (I think /robots.txt is an ugly afterthought) and
> opens the way for people to cache/curate/remix/reuse each others
> ideas. The -- could be a different tag, but -- is in common
> use to denote a signature, so a footer, already.

It doesn't solve the original problem I was trying to address, as I've
pointed out above (i.e. it doesn't allow for progress bars or ETAs).
What you're suggesting is an orthogonal idea that can be implemented in
conjunction with my proposal.  And it's not a bad idea you've got here!
But it is in no way an argument against my proposal.  Even if you didn't
mean it in that way, I want to make this clear.

~aravk | ~nothien