Proposal about content-size and hash

[khuxkm at tilde.team]

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

> On Tue, 3 Nov 2020 13:11:16 +0100
> Björn Wärmedal <bjorn.warmedal at gmail.com> wrote:
> 
>> I assume the majority of people who suggest a feature want "gemini +
>> X", but everyone has their own idea of what X is :) If everyone built
>> their own protocol instead, almost all of those would be doomed from
>> the get-go. To get traction a potential new protocol needs to be
>> appealing to as many as possible -- and the creator needs to *reach
>> out* to as many as possible at that!
> 
> I agree on the fact the if everyone rolled their own protocol it'll be
> a mess, however, the appeal of Gemini would fade away if it starts
> growing in terms of features, the way I see to grow the community is
> hosting more content in the gemspace and going forward with refining
> the spec to a final paper that is more precise and easier for newcomers
> to get a grasp on because the protocol has evolved along with the
> current spec paper and stuff has been added that wasn't intended to be
> there from the beginning.

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.

> It would be discouraging for people to have their implementations break
> so often because the protocol is never stable and features get
> added/removed with stuff changing all the time.

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.

> The way I see it, Gemini is complete, the only way going forward is
> tidying up the spec and growing the gemspace with more content, and in
> the meantime, Gemini implementations will mature and become more
> appealing for newcomers.

I'm willing to agree with you on this point; it seems like we don't *need* this breaking change, at least not yet.

>> Well, if all I want is gemini + X, then using protocol Y with its
>> bloat of features I *don't* need is less tempting than sending a
>> feature proposal to the gemini ML. And again, that's a good thing! It
>> means people are engaging and shaping the trajectory of their own
>> internet future. A rejected proposal is a hundred times better than
>> one that was never discussed for fear of ridicule or social
>> repercussions. The community is alive and vibrant :D
> 
> You wouldn't want to add revision control to Gemini, that's what Git is
> for, just like you wouldn't add remote shell to Gemini because that's
> what SSH is for, this should apply to everything, use the right tool
> for the right task.

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.

Just my two cents,
Robert "khuxkm" Miles