💾 Archived View for rawtext.club › ~sloum › geminilist › 006041.gmi captured on 2023-09-08 at 17:07:37. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-11-30)

-=-=-=-=-=-=-

<-- back to the mailing list

Gemini privacy

Bradley D. Thornton Bradley at NorthTech.US

Wed Mar 10 09:51:39 GMT 2021

- - - - - - - - - - - - - - - - - - - 

On 3/9/2021 4:54 PM, Sean Conner wrote:

It was thus said that the Great Phil Leblanc once stated:
On Tue, Mar 9, 2021 at 6:36 PM <nothien at uber.space> wrote:
P.S: I've been thinking about all the issues we've come across with TLS,
and I've been collecting ideas for a new transport security protocol. I
know ~spc's stance on crypto ("get it approved by the crypto community,
make an implementation, then we'll talk"),

NaCl? ;) https://github.com/cipriancraciun/gemini-experiments

I think Sean Conner's statement is rhetoric or tongue-in-cheek :-)
Whether one likes it or not, Gemini IS built upon TLS. Period. That
ship has sailed. So I understand Sean (and others) want to limit
entropy in the mailing list
It's not completely rhetorical---it's to just shut up those what want
others to do the work. But I mean it---present a working proof-of-concept
that has passed the crypto community and by all means, it'll be worth
talking about then (mostly about hose easy it is to implement across a
variety of languages). Until then, it's TLS.
-spc (We've already had one "proof-of-concept" alternative crypto, but it
was rejected by the person who did it for further study ... )

Yes we have. A little over a year ago. Ciprian Craciun wanted to, andmost enthusiastically, proposed that we replace TLS with NaCl. He evenwrote a proof of concept to support and test it (above), which in thelong run wasn't really a viable solution, at least for Gemini protocol.

I've seen a lot of other folks come in proposing truly extensibleintegrations, but extensible is usually antithetical to Project Gemini'saims.

Now that Gemini is experiencing Logarithmic growth it seems that manywell meaning folks are dropping onto the list and proposing changes tothe specifications that have not only already been hashed out by bothconsensus, but also practical trial and error feasibility studies inactual practice.

NaCl didn't fly because it's a wonderful thing to build a better webconnection with, and if one actually considers those notions, ittranslates into a very narrow deployment capability - even TLS has notbeen without its issues in Gemini, Sean was fortunate due to his use ofthe particular libtls, and for some things, even using his ownlibraries, while Python presented some interesting problems that I'm notsure all have been resolved. Other languages... the same. Someimplementations fare better than others, but still, one can actuallywrite a client or a server that provides basic Gemini protocolcompliance in a weekend or two that includes TLS (at least in IPv4).

It's not a lot to ask that someone implement rather than postulate whatis possible, can the suggestion actually yield services that adhere tothe basic premise upon which Gemini is prefaced?

If Orange is the new black, then Gemini is the new *show me* state. It'sa very simple concept, 'Is this a realy proposal? Where's the beef? Showeveryone the money, and that can be introduced along with a discussionbacked by demonstrated feasibility.

But before even that, we're talking about a very young project. It'scertainly not too much to ask, and yes it should be prominently postedsomewhere, to please review the archives because much of what is beingbantered back and forth lately are very much reruns of what those whohave already implemented production services have wrestled with.

Ciprian kinda just up and disappeared last spring following his NaClproposal. He even advocated for a versioning system for Gemini protocolthat included current stable, past stable, and I guess tomorrow's latestand greatest extensible.... Wait! That would make Gemini like HTTP. Itwas a valid excercise in building a prototype for a better web, andthat's just not Gemini. Sadly, I get the feeling that there are a lot offolks that are chomping at the bit to contribute something in the realmof protocol design here, but we're not buildng a better web throughGemini - we never were.

Rohan was just mentioning to me the other day that he would still liketo see just two things canonized in Gemini. Accessibility support thattriggers what I have referred to as *noise* alerts -ASCII art (In fact,I've already begun implementing an interim solution), and compression.Me too. I want those things for users and clients, respectively.

The problem with compression however, is that it has been stated severaltimes that Gemini is intended (expected, rather) to deliver mostly smallfiles, but not so ubiquitously so in my case. i.e., I've been a SCOpartner for many many years and I'm one of the only places I know of onthe net where you can freely download ISOs of SCO 5 and 6, the kewlestpart about that, and one reason I don't want webproxies on my lawn, isbecause I make those archives available exlusively via Gemini (MaybeGopher too, I'll have to check lolz). Point being, Vger gets a couple offolks downloading old SCO .iso's every month, and it seems to go finewithout compression. Would compression be nice? - you betcha! but at1Gbps it's not really that big of a deal - at least for now.

At this juncture the spec is being finalized, the time for wonderfulideas as to how to handshake and secure connections has pretty muchpassed, and judging by the evidence (check GUS or LUPA, Geddit, Manisha,medusae.space, Sloam and gmisub just to name a few), Gemini is off to agreat start and Solderpunk has, as recently as a week ago, acknowldegedthat his child has now gone off to college as a young adult.

By the way, neither of those two things (Accessibility or gzipcompression) have anything to do with, nor have any place indiscussions, for spec changes.

One thing I would really suggest here for folks climbing on board theGemini train with new ideas - use Gemini first. We have a LOT ofresources, including several archives of this mailing list which you cansearch through. Much of what people suggest lately are more often thannot already hashed out in the archives, which are easily searchable fromwithin Gemini space.

Well, just my thoughts on the matter. If you build it (and it works)they will come, or you can talk about it, but that won't *make it so*Commander Data ;)

I hope that helps :)

Kindest regards,

-- Bradley D. ThorntonManager Network Serviceshttp://NorthTech.USTEL: +1.310.421.8268