💾 Archived View for gemi.dev › gemini-mailing-list › 001056.gmi captured on 2024-06-16 at 15:33:07. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hello all, and welcome back Solderpunk! I have a few things to say about the recent events in the community. But first, let's take the following axioms: 1. Gemini has been in use by a large number of people for years now, without a major change to the specification. 2. The mailing list represents a minority of the users and implementers of Gemini. 3. For the vast majority of users and implementers, the specification hosted on gemini.circumlunar.space (from now: Spec0) remains the authoritative description of the protocol. With that in mind, I will get straight to the point: I believe that the specification should be frozen, with Spec0 remaining authoritative indefinitely. I am not claiming that Spec0 is flawless, however fixing any of its issues would likely cause more trouble than not doing so. In this case, I believe stable behavior to be more important than perfection. As Solderpunk has pointed out, any proposal for change has been met primarily with criticism. If so, why do we want to force change through? It has been proven in practice that Gemini functions well, and that no additional features were strictly necessary. I believe, that in order to avoid more controversy, incompatibility between implementations, and power struggles, we should freeze the specification permanently. Side note regarding Sp.'s return: With all due respect, I do not believe that you can realistically call yourself the dictator of the project. At most you can claim to rule this mailing list, which per axiom №2 is only a minority of the actual community. While I respect your role in the creation of the protocol (i.e., the whole of the original design), Gemini has grown larger than what a single BDFL can control. Especially after disappearing for months, I do not think we should consider your opinion worth any more than that of any other user of this mailing list. I do not mean to be harsh or hostile, simply expressing my opinion. Regarding the axioms' truthness: the first two can be verified by simple common sense. The third one, however, is a bit more complicated. While it is not possible to prove, from my personal reading of this mailing list, and from the fact that gemini.circumlunar.space acts as the “front page” of Geminispace, I believe with a reasonable level of certainty that more people read that specification than the one on GitLab. -- almaember P.S. I'm not sure how and why I wrote this message in such a semi-formal tone, but it's like this now and I won't change it.
> Especially after disappearing for months, I do not think we should consider your opinion worth any more than that of any other user of this mailing list. I do not mean to be harsh or hostile, simply expressing my opinion. And how many days exactly do you consider is "ok to be absent"? What is this, even.
Being absent is okay, disappearing then returning claiming to be dictator is. That's like if the descendant of an old royal family returned to a country that has been a republic for a long time, and trying to get control again. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
> With all due respect, I do not believe that you can realistically call yourself the dictator of the project. At most you can claim to rule this mailing list, which per axiom №2 is only a minority of the actual community. While I respect your role in the creation of the protocol (i.e., the whole of the original design), Gemini has grown larger than what a single BDFL can control. This is solderpunk's project. Always has been. He's the one who appointed Sean to tackle fine-tuning the spec. He is the canonical voice in the protocol. This has in no way grown larger than what a single BDFL can do. There are plenty of much more massive projects run by a single BDFL, including ones where that leader has gone quiet for years. Put simply, until such time as solderpunk decides to hand control to another maintainer or maintainers, this is his. If you require more practical terms, he's never licensed it. It's his. Sean recently threw a CC0 on the working-draft on Gitlab, but that's not canonical to begin with. On a personal note, I'm really glad he's back. I'm hoping with the conclusion of these changes we can just shut down this mailing list completely. It's the least Gemini thing about Gemini.
I think it's fair to say the term "dictator" was probably somewhat tongue in cheek, especially given the informal tone and the joke in the second sentence. They took what was likely a mental health break, given their recent gemlog post. Solderpunk is by definition the owner of the Gemini project insofar as they control the canonical specification. I don't disagree with your "axioms" but let's keep things in perspective and be civil. Obviously two months is a long time to be gone but owning an open source project doesn't mean Solderpunk is obligated to always have a presence or be responsive. Their interaction with the community is 100% at-will. - Andrew
He merely owns the website/capsule it's hosted on. Taking and hosting it, or even rewording it to avoid copyright issues, is a relatively simple task. GitLab doesn't own the GitLab specification just because it's hosted there, and neither does the operator of this mailing list own this message. I called those things axioms, which in retrospect is a little odd choice of word, because it's just that, something that is taken as true and forming the basis of the argument and not the argument itself. I do not criticize him for taking a break, that's okay. My problem is with the way he returned, i.e., taking power he basically didn't have any rights to at that point. The only thing he's currently doing is hosting a website and capsule. And, lastly this is not an open source project per se. More like a set of conventions projects agree on. In other words, a standard. On October 26, 2021 12:09:45 AM GMT+02:00, Andrew Thorp <andrew.thorp.dev@gmail.com> wrote: >I think it's fair to say the term "dictator" was probably somewhat >tongue in cheek, especially given the informal tone and the joke in >the second sentence. >They took what was likely a mental health break, given their recent gemlog post. >Solderpunk is by definition the owner of the Gemini project insofar as >they control the canonical specification. >I don't disagree with your "axioms" but let's keep things in >perspective and be civil. >Obviously two months is a long time to be gone but owning an open >source project doesn't mean Solderpunk is obligated to always have a >presence or be responsive. >Their interaction with the community is 100% at-will. > >- Andrew -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 2021-10-26 12:20AM, almaember wrote: > He merely owns the website/capsule it's hosted on. Taking and hosting > it, or even rewording it to avoid copyright issues, is a relatively > simple task. If I take a copy of whitehouse.gov and replace all the text with "lol the government's dumb" does that make it the official whitehouse.gov site? Solderpunk hosts the canonical version (which you said yourself is the one everyone follows) which means they're the one that "owns" the Gemini specification. > GitLab doesn't own the GitLab specification just because it's hosted > there, and neither does the operator of this mailing list own this > message. And yet I both host and own nytpu.com. Yes hosting =/= ownership, however in most cases (on Gemini at least) hosting *is* equivalent to ownership. > And, lastly this is not an open source project per se. More like a set > of conventions projects agree on. In other words, a standard. I don't recall anyone anywhere ever claiming that the Gemini Protocol itself is a software project; it is an open standard. That doesn't mean it magically belongs to everyone and no one should have control of it. There are criticisms to be had about most standards organizations and yet I've never seen anyone (other than you, rather) claim that the standards body shouldn't have control over the standards they maintain and publish. Look at the LZMA Specification, it is entirely maintained an published by one guy (it hasn't been updated since 2015 either). By your logic, shouldn't he have no rights to it and instead it should never be modified ever. It's public domain so you could create and modify your own right now. Yet veryone would ignore your hypothetical version and still use his canonical version that he owns and hosts, and nobody other than you would dispute any future changes he made that diverged from your version. ~nytpu -- Alex // nytpu alex@nytpu.com gpg --locate-external-key alex@nytpu.com
I hoped to not have to say it like this, I wanted to hide behind formal language and politeness, but I don't care about his opinion at all. He owns a website and a capsule, that's all. He didn't write the implementations and the capsules. He can do whatever he wants with his website, but for the rest, let the community decide. And the community has pretty much settled on the original spec, so... The difference to other standards is that we have no versions. When the C standards committee (which, by the way, has representatives of the major implementations), they release a new revision, but don't retroactively change anything. That's not possible with Gemini. On October 26, 2021 12:00:27 AM GMT+02:00, James Tomasino <tomasino@lavabit.com> wrote: >> With all due respect, I do not believe that you can realistically call >yourself the dictator of the project. At most you can claim to rule this >mailing list, which per axiom №2 is only a minority of the actual >community. While I respect your role in the creation of the protocol >(i.e., the whole of the original design), Gemini has grown larger than >what a single BDFL can control. > >This is solderpunk's project. Always has been. He's the one who >appointed Sean to tackle fine-tuning the spec. He is the canonical voice >in the protocol. This has in no way grown larger than what a single BDFL >can do. There are plenty of much more massive projects run by a single >BDFL, including ones where that leader has gone quiet for years. > >Put simply, until such time as solderpunk decides to hand control to >another maintainer or maintainers, this is his. > >If you require more practical terms, he's never licensed it. It's his. >Sean recently threw a CC0 on the working-draft on Gitlab, but that's not >canonical to begin with. > >On a personal note, I'm really glad he's back. I'm hoping with the >conclusion of these changes we can just shut down this mailing list >completely. It's the least Gemini thing about Gemini. > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
I think you may be asking for a heavier process than is warranted. It is my personal hope that there will be no further versions of the spec once finalized, other than perhaps a change from TLS should it ever become extremely obsolete, decades from now. > The difference to other standards is that we have no versions. When the C standards committee > (which, by the way, has representatives of the major implementations), they release a new revision, > but don't retroactively change anything. That's not possible with Gemini.
On October 26, 2021 12:59:33 AM GMT+02:00, Alex // nytpu <alex@nytpu.com> wrote: >On 2021-10-26 12:20AM, almaember wrote: >> He merely owns the website/capsule it's hosted on. Taking and hosting >> it, or even rewording it to avoid copyright issues, is a relatively >> simple task. >If I take a copy of whitehouse.gov and replace all the text with "lol >the government's dumb" does that make it the official whitehouse.gov >site? Solderpunk hosts the canonical version (which you said yourself >is the one everyone follows) which means they're the one that "owns" >the Gemini specification. Except whitehouse.gov is run by an elected government. This will apply when we start holding elections for Gemini. >> GitLab doesn't own the GitLab specification just because it's hosted >> there, and neither does the operator of this mailing list own this >> message. >And yet I both host and own nytpu.com. > >Yes hosting =/= ownership, however in most cases (on Gemini at least) >hosting *is* equivalent to ownership. He hosts and owns the website, yes. Maybe even the spec. The protocol though? Hell, that's too abstract to be owned by anyone. >> And, lastly this is not an open source project per se. More like a set >> of conventions projects agree on. In other words, a standard. >I don't recall anyone anywhere ever claiming that the Gemini Protocol >itself is a software project; it is an open standard. That doesn't mean >it magically belongs to everyone and no one should have control of it. >There are criticisms to be had about most standards organizations and >yet I've never seen anyone (other than you, rather) claim that the >standards body shouldn't have control over the standards they maintain >and publish. > >Look at the LZMA Specification, it is entirely maintained an published >by one guy (it hasn't been updated since 2015 either). By your logic, >shouldn't he have no rights to it and instead it should never be >modified ever. And you would be correct. At least already released versions shouldn't be retroactively modified. Releasing further revisions is fine. >It's public domain so you could create and modify your >own right now. Yet veryone would ignore your hypothetical version and >still use his canonical version that he owns and hosts, and nobody other >than you would dispute any future changes he made that diverged from >your version. > >~nytpu > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
almaember <almaember@disroot.org> writes:
> I do not criticize him for taking a break, that's okay. My problem is
> with the way he returned, i.e., taking power he basically didn't have
> any rights to at that point. The only thing he's currently doing is
> hosting a website and capsule.
Hi. I'm your friendly neighborhood mailing list admin. Please consider
this message a yellow card; further harassing Solderpunk will get you a
red card and unsubscribed from the list. If what you want is to propose
a democratically-run standards body for Gemini, please do so, but please
don't imply that Solderpunk picking back up the reins he handed to Sean
last year to hold is some kind of unprecedented arrogation of power.
--
Jason McBrayer | “Strange is the night where black stars rise,
jmcbray@carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.”
| ― Robert W. Chambers,The King in Yellow
> No, that was just to explain why what can be applied to other standards can't to Gemini. My > proposal is fairly simple if you remove all the language bloat: > 1. Take the original spec > 2. Slap a public domain or whatever on it > 3. Done. Now don't do anything, forever. He can correct me if I'm wrong, but I assume that the final spec will be released under some sort of public domain license. Per the FAQ the goal appears to be to submit it to IETF and/or IANA. > This will apply when we start holding elections for Gemini. Perhaps controversial, but we should not do this. Elections in a small, niche online community are a quick path to capture by groups who don't have the community's best interest in mind. I've seen this happen many times.
On Tue, Oct 26, 2021 at 01:12:37AM +0200, almaember wrote: > I hoped to not have to say it like this, I wanted to hide behind formal language and politeness, but I don't care about his opinion at all. He owns a website and a capsule, that's all. He didn't write the implementations and the capsules. He can do whatever he wants with his website, but for the rest, let the community decide. And the community has pretty much settled on the original spec, so... > > The difference to other standards is that we have no versions. When the C standards committee (which, by the way, has representatives of the major implementations), they release a new revision, but don't retroactively change anything. That's not possible with Gemini. The C standard is an ISO standard. Gemini is not. So the comparison doesn't make sense, especially with the committee comment.
On Tue, 2021-10-26 at 01:12 +0200, almaember wrote: > I hoped to not have to say it like this, I wanted to hide behind > formal > language and politeness, but I don't care about his opinion at all. He > owns a website and a capsule, that's all. He didn't write the > implementations and the capsules. almeamber, I understand your reaction to freezing the spec, but please at least take the time to check your facts before trashing someone. Solderpunk has written at least AV-98 (client) and molly-brown (server). He's not just some guy with a site and capsule; he's the person who created the spec and who still has ultimate control over it. The canonical Gemini specification is at <gemini.circumlunar.space/docs/specification.gmi>, and Solderpunk is the only one with write-access to <gemini.circumlunar.space/docs/specification.gmi>. > He can do whatever he wants with his > website, but for the rest, let the community decide. And the community > has pretty much settled on the original spec, so... The community has pretty much settled on the original spec because the original spec has pretty much settled (due to Solderpunk's absence). Neither are fully settled, and the community can resettle upon a mostly- same, updated spec. > The difference to other standards is that we have no versions. When > the > C standards committee (which, by the way, has representatives of the > major implementations), they release a new revision, but don't > retroactively change anything. That's not possible with Gemini. The difference with other standards is that they are standards. Currently, Gemini has only been specified - it has not be standardized. Right now, Gemini is non-standard. We don't have to worry about retroactively changing things because nothing is formalized; the specification is not yet set in stone. We need to finish the spec before we can worry about changing things. -- DJ Chase They, Them, Theirs
It was thus said that the Great almaember once stated: > I hoped to not have to say it like this, I wanted to hide behind formal > language and politeness, but I don't care about his opinion at all. He > owns a website and a capsule, that's all. He didn't write the > implementations and the capsules. He wrote the original specification, and updated it with feedback from those that did write implementations (both servers and clients). And he also wrote a server (Molly-Brown) and a client (AV-98). To say he didn't write an implemetion is rewriting history. > He can do whatever he wants with his > website, but for the rest, let the community decide. And the community has > pretty much settled on the original spec, so... Let me assure you that the community has NOT settled on the original spec. It's why I got burned out (and Solderpunk before me). -spc
On Tue, 2021-10-26 at 01:34 +0200, almaember wrote: > > On October 26, 2021 12:59:33 AM GMT+02:00, Alex // nytpu <alex@nytpu.com> wrote: > > > > If I take a copy of whitehouse.gov and replace all the text with "lol > > the government's dumb" does that make it the official whitehouse.gov > > site? Solderpunk hosts the canonical version (which you said yourself > > is the one everyone follows) which means they're the one that "owns" > > the Gemini specification. > > Except whitehouse.gov is run by an elected government. This will apply when we start holding elections for Gemini. Okay, so say that it's coca-cola.com, disroot.org, tilde.team, or example.com. Which specific entity or type of entity it is is not the important part of the example. -- DJ Chase They, Them, Theirs
On Mon, 2021-10-25 at 20:21 -0400, Sean Conner wrote: > Let me assure you that the community has NOT settled on the original spec. > It's why I got burned out (and Solderpunk before me). This is also a good point. I didn't mention this in my reply, but I agree with Sean's take. -- DJ Chase They, Them, Theirs
On Mon, Oct 25, 2021 at 11:21:04PM +0000, mntn wrote: > I think you may be asking for a heavier process than is warranted. It is my personal hope that there will be no further versions of the spec once finalized, A TLDR: the ecosystem can evolve without changing/breaking the existing spec. Let's freeze the spec soon! Agreed that the Gemini spec seems feature-complete for now. There was a time when I would've liked to see features like compression and tables, but the spec doesn't prevent anyone from serving up an alternate mimetype like text/gemini+gzip or csv. Clients like Lagrange can load a CSV document from a link as an inline table just like they load inline images (following a user gesture, ofc). This is a good example of adding functionality to the ecosystem without adding functionality to the spec. > other than perhaps a change from TLS should it ever become extremely obsolete, decades from now. Also agreed that it might be necessary to deprecate some TLS versions as time goes by, but that should be quite straightforward: deprecate one version of TLS, have capsules stop supporting it while clients support old and new versions, and then remove support from clients. Some people from the netsec crowd have bristled at Gemini's TOFU model, but I don't think fixing that should require changes in the spec either. Adding e.g. a DHT of some sort doesn't have to change how the Gemini protocol works; it can simply be a thing users use to verify certs "out of band" the first time they visit a capsule. Stuff like Tor hidden services are also a good fit for Gemini (I think the part of the Gemini Space accessible over Tor is called "Deep Space") and can mitigate the issues inherent to TOFU without changing the spec. Adding features is typically misguided: it's better to *complement* Gemini with other protocols suited for other purposes than to *extend* it. One such protocol is the spartan:// client-to-server protocol. Gemini can concentrate on supporting server-to-many-client situations while Spartan can concentrate on client-to-server communication. (This is not necessarily an endorsement of Spartan; I do have some issues with it, but that's off-topic). The ecosystem can evolve, but the spec seems about done. Welcome back, Solderpunk. -- /Seirdy
A TLDR: the ecosystem can evolve without changing/breaking the existing spec. Let's freeze the spec soon! On Mon, Oct 25, 2021 at 11:21:04PM +0000, mntn wrote: > I think you may be asking for a heavier process than is warranted. It is my personal hope that there will be no further versions of the spec once finalized, Agreed that the Gemini spec seems feature-complete for now. There was a time when I would've liked to see features like compression and tables, but the spec doesn't prevent anyone from serving up an alternate mimetype like text/gemini+gzip or csv. Clients like Lagrange can load a CSV document from a link as an inline table just like they load inline images (following a user gesture, ofc). This is a good example of adding functionality to the ecosystem without adding functionality to the spec. > other than perhaps a change from TLS should it ever become extremely obsolete, decades from now. Also agreed that it might be necessary to deprecate some TLS versions as time goes by, but that should be quite straightforward: deprecate one version of TLS, have capsules stop supporting it while clients support old and new versions, and then remove support from clients. Speaking of TLS: ome people from the netsec crowd have bristled at Gemini's TOFU model, but I don't think fixing that should require changes in the spec either. Adding e.g. a DHT of some sort doesn't have to change how the Gemini protocol works; it can simply be a thing users use to verify certs "out of band" the first time they visit a capsule. Stuff like Tor hidden services are also a good fit for Gemini (I think the part of the Gemini Space accessible over Tor is called "Deep Space") and can mitigate the issues inherent to TOFU without changing the spec. Adding features is typically misguided: it's better to *complement* Gemini with other protocols suited for other purposes than to *extend* it. One such protocol is the spartan:// client-to-server protocol. Gemini can concentrate on supporting server-to-many-client situations while Spartan can concentrate on client-to-server communication. (This is not necessarily an endorsement of Spartan; I do have some issues with it, but that's off-topic). The ecosystem can evolve, but the spec seems about done. Welcome back, Solderpunk. -- /Seirdy
> Gemini can concentrate on supporting server-to-many-client situations while Spartan can concentrate on client-to-server communication. I am not sure what you mean by this. Would you mind clarifying what "client-to-server" means in this context? If I had to guess, I'd guess you're referring to something analogous to an HTTP "POST" request (presumably in contrast to Gemini acting more like a "GET" in most cases)? Thanks, panda-roux On October 26, 2021 1:48:32 AM UTC, Rohan Kumar <seirdy@seirdy.one> wrote: >A TLDR: the ecosystem can evolve without changing/breaking the existing >spec. Let's freeze the spec soon! > >On Mon, Oct 25, 2021 at 11:21:04PM +0000, mntn wrote: >>I think you may be asking for a heavier process than is warranted. It >>is my personal hope that there will be no further versions of the spec >>once finalized, > >Agreed that the Gemini spec seems feature-complete for now. There was a >time when I would've liked to see features like compression and tables, >but the spec doesn't prevent anyone from serving up an alternate >mimetype like text/gemini+gzip or csv. Clients like Lagrange can load a >CSV document from a link as an inline table just like they load inline >images (following a user gesture, ofc). This is a good example of adding >functionality to the ecosystem without adding functionality to the spec. > >>other than perhaps a change from TLS should it ever become extremely >>obsolete, decades from now. > >Also agreed that it might be necessary to deprecate some TLS versions as >time goes by, but that should be quite straightforward: deprecate one >version of TLS, have capsules stop supporting it while clients support >old and new versions, and then remove support from clients. > >Speaking of TLS: ome people from the netsec crowd have bristled at >Gemini's TOFU model, but I don't think fixing that should require >changes in the spec either. Adding e.g. a DHT of some sort doesn't have >to change how the Gemini protocol works; it can simply be a thing users >use to verify certs "out of band" the first time they visit a capsule. >Stuff like Tor hidden services are also a good fit for Gemini (I think >the part of the Gemini Space accessible over Tor is called "Deep Space") >and can mitigate the issues inherent to TOFU without changing the spec. > >Adding features is typically misguided: it's better to *complement* >Gemini with other protocols suited for other purposes than to *extend* >it. One such protocol is the spartan:// client-to-server protocol. >Gemini can concentrate on supporting server-to-many-client situations >while Spartan can concentrate on client-to-server communication. > >(This is not necessarily an endorsement of Spartan; I do have some >issues with it, but that's off-topic). > >The ecosystem can evolve, but the spec seems about done. > >Welcome back, Solderpunk. >
October 25, 2021 9:48 PM, "Rohan Kumar" <seirdy@seirdy.one> wrote: > A TLDR: the ecosystem can evolve without changing/breaking the existing > spec. Let's freeze the spec soon! That is indeed what Solderpunk aims to do (AFAICT), just fixing up the last few corner cases before declaring the spec done and finished. > Speaking of TLS: ome [sic] people from the netsec crowd have bristled at > Gemini's TOFU model, but I don't think fixing that should require > changes in the spec either. Adding e.g. a DHT of some sort doesn't have > to change how the Gemini protocol works; it can simply be a thing users > use to verify certs "out of band" the first time they visit a capsule. > Stuff like Tor hidden services are also a good fit for Gemini (I think > the part of the Gemini Space accessible over Tor is called "Deep Space") > and can mitigate the issues inherent to TOFU without changing the spec. 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. > Adding features is typically misguided: it's better to *complement* > Gemini with other protocols suited for other purposes than to *extend* > it. One such protocol is the spartan:// client-to-server protocol. > Gemini can concentrate on supporting server-to-many-client situations > while Spartan can concentrate on client-to-server communication. > > (This is not necessarily an endorsement of Spartan; I do have some > issues with it, but that's off-topic). 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? Just my two cents, Robert "khuxkm" Miles
25 Oct 2021 23:20:51 almaember <almaember@disroot.org>: > My problem is with the way he returned, i.e., taking power he basically didn't have any rights to at that point. "dictators" don't have "rights", they just rule by fiat.
Hi Almaember, I suffer from wicked IBS (IBS can be like drowning in a desert - my longterm partner still doesnt get how helpless the condition can make you) and through systematic and institutional bullying burnout which cast a very long shadow. As a consequence I know that its possible to be offline/inactive for hours/days/weeks/months/years and then *BOOM* you are back on again and back to yourself. Infact, Ive been in what could be a 'wilderness years' that was pretty much masked through raising x2 children. At a personal level, the considerate aspects of Gemini encouraged me out of my own hole (anybody trying to build up a fingerprint of me prior to ~April 2021 will have a very hard time) - Gemini even secured me a research grant through NLNet. So personally I will be cutting Solderpunk a lot of slack and I will be eternally greatful for SP's impactfulness. ==================== Jonathan McHugh indieterminacy@libre.brussels (mailto:indieterminacy@libre.brussels) October 25, 2021 11:39 PM, "almaember" <almaember@disroot.org (mailto:almaember@disroot.org?to=%22almaember%22%20<almaember@disroot.org>)> wrote: Being absent is okay, disappearing then returning claiming to be dictator is. That's like if the descendant of an old royal family returned to a country that has been a republic for a long time, and trying to get control again. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
It was thus said that the Great Robert khuxkm Miles once stated: > October 25, 2021 9:48 PM, "Rohan Kumar" <seirdy@seirdy.one> wrote: > > > Adding features is typically misguided: it's better to *complement* > > Gemini with other protocols suited for other purposes than to *extend* > > it. One such protocol is the spartan:// client-to-server protocol. > > Gemini can concentrate on supporting server-to-many-client situations > > while Spartan can concentrate on client-to-server communication. > > > > (This is not necessarily an endorsement of Spartan; I do have some > > issues with it, but that's off-topic). > > 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? I have nothing to do with Spartan. Titan, yes---I came up with the initial idea, and it's Alex Schroeder who implemented and expanded on the idea. But I have looked a bit into Spartan---it was developed by Michael Lazar, and indeed, it seems to be "gemini - tls + uploads" (and he might have been inspired by titan, inimeg or discursi. Titan is more "an upload protocol". There was also inimeg: (the same as titan:) and yet another scheme (discursi?) that I can't find right now. -spc
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
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
October 26, 2021 4:34 AM, "Sean Conner" <sean@conman.org> wrote: > I have nothing to do with Spartan. Ah, yes, I got my Gemini visionaries mixed up. My apologies. > Titan, yes---I came up with the initial idea, and it's Alex Schroeder who implemented and expanded on the idea. Ooh, I actually hadn't known that. Just my two cents, Robert "khuxkm" Miles
On 25.10.2021 23:27, almaember wrote: > 1. Gemini has been in use by a large number of people for years now, > without a major change to the specification. > > 2. The mailing list represents a minority of the users and > implementers of Gemini. > > 3. For the vast majority of users and implementers, the specification > hosted on gemini.circumlunar.space (from now: Spec0) remains the > authoritative description of the protocol. I completely agree on all three points. > It has been proven in practice that Gemini functions well, and that no > additional features were strictly necessary. I don't currently plan to add any new features. > I believe, that in order to avoid more controversy, incompatibility > between implementations, and power struggles, we should freeze the > specification permanently. Consider it "feature frozen". There's still some stuff which I think ought to be done. But I do not anticipate making any changes which could not be fairly classed as "tidying up technical loose ends". I can't promise nobody will have to change a single line of code in their clients/servers, but I'm not going to do anything which is going to cause widespread substantial breakage. Ordinary end users probably won't notice anything changing. > Side note regarding Sp.'s return: With all due respect, I do not > believe that you can realistically call yourself the dictator of the > project. At most you can claim to rule this mailing list, which per > axiom №2 is only a minority of the actual community. While I respect > your role in the creation of the protocol (i.e., the whole of the > original design), Gemini has grown larger than what a single BDFL can > control. Especially after disappearing for months, I do not think we > should consider your opinion worth any more than that of any other > user of this mailing list. I realise you've retracted this review in another post. I'm going to briefly address it otherwise because I suspect there may be other people who still feel this way. Look, to some extent, I get where you are coming from. The folk notion of BDFL can only be pushed so far. If I had disappeared for ten years and the project had flourished under alternate leadership and then I sprang back from the void and claimed that since I never formally relinquished BDFL-status I still had the divine right to undo the previous decade of change willy-nilly, nobody would think that was fine. And I get that I haven't been a very responsible leader this year. I'm sorry. People are entitled to be somewhat disgruntled. Anybody who knows me knows I'm much more of an idealist than a pragmatist, but at this point, to people questioning the legitimacy of my return to leadership, I really have to ask whether you honestly think, as a purely practical matter, that there's an alternative which is going to lead to a better result? 10 years of bikeshedding and slippery slope expansion under "design by committee" seems like the *best* we could hope for. At worst, we could end up with warring factions and multiple threads of incompatible parallel development of dubious legitimacy. I actually think the tremendous diversity of implementations we already have would act as an effective countermeasure to drastic change happening under that second scenario - and that is exactly by design - but I don't care to put that theory to the test. Me coming back, kicking ass and chewing bubblegum seems likely to be both the
On Tue, 2021-10-26 at 17:17 +0000, Solderpunk wrote: > On 25.10.2021 23:27, almaember wrote: > > > > I believe, that in order to avoid more controversy, incompatibility > > between implementations, and power struggles, we should freeze the > > specification permanently. > > Consider it "feature frozen". There's still some stuff which I think > ought to be done. But I do not anticipate making any changes which > could not be fairly classed as "tidying up technical loose ends". I > can't promise nobody will have to change a single line of code in their > clients/servers, but I'm not going to do anything which is going to > cause widespread substantial breakage. Ordinary end users probably > won't notice anything changing. Great. > PS: Don't worry, I've got plenty of gum. What flavor? /j -- DJ Chase They, Them, Theirs
Jason McBrayer <jmcbray@carcosa.net> writes:
> Hi. I'm your friendly neighborhood mailing list admin. Please consider
> this message a yellow card; further harassing Solderpunk will get you a
> red card and unsubscribed from the list.
Please disregard; I see you apologized already. I had a bunch of mail
queued for sending from offline, and it didn't get sent until today,
when much of it was out of date.
--
Jason McBrayer | “Strange is the night where black stars rise,
jmcbray@carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.”
| ― Robert W. Chambers,The King in Yellow
Jason McBrayer <jmcbray@carcosa.net> writes:
> Hi. I'm your friendly neighborhood mailing list admin. Please consider
> this message a yellow card; further harassing Solderpunk will get you a
> red card and unsubscribed from the list.
Please disregard; this was part of a batch of mail that got queued for
several days, and delivered after it was no longer relevant.
--
Jason McBrayer | “Strange is the night where black stars rise,
jmcbray@carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.”
| ― Robert W. Chambers,The King in Yellow
Uh. I managed to cause some chaos, but at least hopefully it had cleared some things up, both for me and for others. I agree now that this method is the one that will cause the least amount of trouble. I hope I didn't leave any lasting impressions. Btw, if I'm already writing this email: how much do you expect to clean up? Like, is a complete restructuring of the spec necessary or is it just a few rough edges? -- Unless you're replying to me on the Gemini mailing list, reply to almaember@almaember.com instead. Website: https://almaember.com/ Gemini capsule: gemini://almaember.com/
On 2021-10-27 20:49, Almaember wrote: > I hope I didn't leave any lasting impressions. It's nothing compared to real drama (like favicon.txt). > Btw, if I'm already writing this email: how much do you expect to clean > up? Like, is a complete restructuring of the spec necessary or is it > just a few rough edges? It can't be submitted to standard bodies like IETF in its current state. The spec is far from looking like an actual RFC.
It was thus said that the Great Almaember once stated:
>
> Btw, if I'm already writing this email: how much do you expect to clean
> up? Like, is a complete restructuring of the spec necessary or is it
> just a few rough edges?
You can check out the issues for the protocol itself:
https://gitlab.com/gemini-specification/protocol/-/issues
and the issues for the gemtext format:
https://gitlab.com/gemini-specification/gemini-text/-/issues
-spc (According to those, lots of rough edges)
---