Proposal about content-size and hash

[khuxkm at tilde.team]

November 3, 2020 10:22 AM, "Ali Fardan" <raiz at stellarbound.space> wrote:

> On Tue, 03 Nov 2020 14:07:49 +0000
> khuxkm at tilde.team wrote:
> 
>> I don't really think this is a scenario where there are things that
>> weren't "intended"; what was intended was to create a protocol,
>> lighter than the Web and heavier than Gopher, for serving content
>> securely (at least, from where I sit and what I see). Obviously, the
>> protocol isn't perfect, so sometimes it needs things added that may
>> not have been there at the beginning, but fit the intent of the
>> protocol.
> 
> Let me reword... weren't considered from the beginning, here is an
> example: 5.4.2 from the spec goes into great detail even defining what
> whitespace is, while 5.5.2 and 5.5.3 aren't defined in the same style
> as 5.4.2 was defined, there's nothing wrong with that, the protocol
> evolved and these were added later, though they weren't considered at
> the very beginning, that's what I meant by weren't "intended".

I think this is an apples to oranges comparison; 5.5.2 has to do with the text/gemini media type, which, while it is a part of the spec, isn't protocol based (i.e; I could serve text/gemini on a web server if I really wanted to)

>> The spec was created around August of 2019 (at least, the list was
>> first posted to in mid-August). It's only a year old. If a breaking
>> change *needs* to be made, it's not too late yet.
> 
> If a crucial change were to be made, of course, I'm all for it, but in
> my opinion, it seems that there is no need for any more features to be
> added, and the way I see it is moving towards stabilizing the spec
> without any breaking changes, that's just my opinion.

I agreed with you on that point though; this isn't needed, at least not yet. But if the breaking change needed to be made, like you said, it should be made. This attitude of "oh, we don't need anything else" might convince some people who otherwise would have had good suggestions to back away; after all, if we aren't adding new features, why bother giving your suggestion?

>> That's not really a good comparison. Obviously you wouldn't add
>> revision control and/or a remote shell to Gemini; that has nothing to
>> do with serving content. But if the X in "gemini + X" has to do with
>> content (serving it, etc.), it's worth considering.
> 
> I may have went to the extreme with this, but take a look at web land,
> there's applications written to entirely run on the web, those include
> mail readers, video and music players (implemented in JS), document
> editors (Google docs and whatnot), and finally, control panels which
> serve the purpose of a remote shell, obviously, that's not SSH, but if
> more and more features get accepted to the protocol, how long until
> that becomes possible?

Just for the sake of it, I really want to try and make a remote shell in Gemini CGI, just to prove a point. You can do it already, with the protocol as-is; send the command as a query to a CGI endpoint

> Applications can be implemented in Gemini currently, using CGI, these
> applications don't have to do with serving content, you could implement
> a calculator, a banner generator, and a git repository viewer, all
> using what is currently available, I have no argument against
> implementing such applications using CGI which currently allows
> extending the protocol without requiring more features to be added.

Okay, but with all due respect, what does that have to do with content size? CGI isn't going to help the fact that the protocol currently has no way to indicate "this is how big the response will be" or "this is the hash of the file". Those questions, at least in my opinion, need to be answered at the protocol level, unless we're going to make a .well-known for Gemini.

Just my two cents,
Robert "khuxkm" Miles