A proposal to freeze the Gemini specification

[Jonathan McHugh]

Hi Rohan,

October 26, 2021 10:47 AM, "Rohan Kumar" <seirdy@seirdy.one> wrote:

> On Tue, Oct 26, 2021 at 06:44:23AM +0000, Robert "khuxkm" Miles wrote:
> 
>> I'm of the opinion that TOFU is perfectly fine in this scenario. The
>> only thing I think would be good as an addition to Gemini is a way to
>> deprecate a certificate. As it stands, if your capsule gets compromised
>> there is no way to stop clients from recognizing the compromised
>> certificate as valid. That being said, as you mentioned, that's more of
>> a thing that can be decided out-of-band and doesn't really require the
>> Gemini spec to change.
> 
> The initial request can also be MITM'd, which can be mitigated by
> verifying the key "out-of-band". This "out-of-band" thing shouldn't be
> Gemini itself but ideally something completely different and possibly
> generalizable to non-Gemini scenarios.
> 
>> I feel like that's a mischaracterization of Spartan. In the past, I've
>> described Spartan as "gemini - tls + uploads", because that's basically
>> what it is (barring some things like the =: line type for input links,
>> and the one-character status codes). It's more its own protocol that
>> happens to take design cues from Gemini (Sean, if I'm completely
>> missing the point here, please do tell me, but this is the impression
>> I've gotten so far). Perhaps you meant Titan?
> 
> Oh, I was thinking of Titan. Another project I'm liking better is
> Iapetus.
> 
> --
> /Seirdy

Iapetus does look nice judging by this:
=> https://codeberg.org/oppenlab/iapetus repo_homepage

Are there any working clients or servers floating around?

I assume it could then be feasible to setup an infrastructure which only demands GemText and then provides it in the Gemini protocol?



====================
Jonathan McHugh
indieterminacy@libre.brussels