💾 Archived View for rawtext.club › ~sloum › geminilist › 001927.gmi captured on 2020-09-24 at 01:33:06. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Fri Jun 26 12:04:24 BST 2020
- - - - - - - - - - - - - - - - - - -
On Thu, Jun 25, 2020 at 06:48:04PM +0000, Phil Leblanc wrote:
_minimalism_: as a personal taste and aesthetic principle, Yes. Also
a guiding principle, as frugality.
_simplicity_: Yes, by far the most important reason -- as in "less
moving parts", "no black box". Easily understanding all the core parts
to the ground Grasping it all at the same time without digging deep.
It relates to "_explainability_": explain sockets and basic network
to a beginner and they will grasp Gemini without pain - it could even
be a basic example of how to use sockets
...
_easier DIYability_: Yes. closely related to simplicity. A _very
refreshing_ aspect of Gemini is "it is so simple you can implement it
in a few hours. -- Ooops... and for TLS? -- it is very simple. Just
call this [big] shared library. -- Hmm ... if I call a big TLS library
where it becomes complex, I could as well _very easily_ build a
HTTP/HTML client by calling libcurl, right? And arguably, I can find
libcurl in as many platforms as libtls!
I think it relates also to hardware hobbyists. I don't mean the
Raspberry Pi sort of thing (actually more powerful than hardly old
PCs). I mean rather Arduino-like boards. I could imagine some smart
guys will or have already implemented a ultra minimal TCP stack, and
PPP to an internet gateway and could use Gemini -- ... probably not
with TLS.
Thanks for clarifying. For what it's worth, I acknowledge all thesepoints. I appreciate beautifully minimal things like FORTH, I valueease of teaching and of learning, and I tinker with AVR micros and evenmore constrained platforms myself. I get it. These are important thingsto consider. But at the end of the day no one protocol can optimisesimultaneously for all these things. Often times the differentrequirements fight each other. Even aesthetic minimalism andexplainability can conflict, as really beautifully minimal systems withgreat generality/flexibility/power often require the user to first adaptto some unfamiliar, abstract mode of thinking that is not easy to graspquickly.
Ultimately, Gemini is supposed to be a practical protocol to solve aconcrete, real-world problem: the web has become a disaster on manyfronts simultaneously, and lots of people really want out, at least someof the time and for some things, but the only "off the shelf" thing theycan flee to for roughly the same experience is Gopher, but many of themcan't/won't flee to Gopher due to various shortcomings, one of which,yes, really, is the lack of encryption. I don't want Gemini to be abeautiful object of appreciation for hackers that most people have nouse for (there's no shortage of these!), I want it to be a viablelifeboat for evacuees from the web. The first-class application iscomputer literate non-developers using "normal computers" and softwareother people wrote to read meaningful textual content with a reasonableexpectation of privacy. I am happy to make it simpler, more beautiful,more hackable, more general purpose, friendlier to low power computersand slow networks, to whatever extent is possible without interferingwith its seaworthiness as a lifeboat. I realise that it's worthwhileto do so to incentivise developers (who are inevitably the earlyadopters, and who will get excited by these properties) to writeclients and servers and other tools which can then be used by others.And it honestly makes *me* happier to push it in those directions.But throwing out TLS so that it can be more readily implemented bysomebody who just learned what a socket is yesterday is ultimatelyself-defeating from the lifeboat perspective. If part of the reasonpeople want to flee from the web is because of privacy concerns,offering them a plaintext alternative makes no sense at all, and theyjust won't make the jump. The mandatory encryption in Gemini is animportant, functional, deliberate part of the lifeboat design. It wouldbe a bad lifeboat without out.
When we *do* chase improvements in these other regards withoutcompromising our role as a lifeboat, we also need to keep a sense ofperspective, make our criteria clear, make measurements and not trustour guts, etc. I'm all for a lower power, greener internet. But if youreally want to push in that direction hard, you need to make radicaldepartures from the basic paradigms that the web and Gemini are bothbuilt around. I'm talking about systems where content is automaticallyand user-invisibly replicated across hosts and naturally ends up"migrating" to hosts which are closest, from a network perspective, tothe places where demand for access to that content is highest. A reallyradical solarpunk future internet has to be built around slow,intermittent, improvised/opportunistic connections, and "offline first"thinking has to dominate. Gemini is just dead in the water in thatkind of a world. It's built around old-fashioned ideas, on purpose, inorder to be "radically familiar" to both users and developers from theweb, because a lifeboat protocol *needs* to be radically familiar. Ifyou throw in P2P and content-based addressing and blockchains and allthe stuff you need to use to address the deep problems with theinternet, a majority of both users and developers immediately have noidea what is going on and they won't get in your lifeboat because theycan't. So, by virtue of its deliberate old fashionedness, Gemini isnever going to be the absolute best choice for low power consumption,for low bandwidth, etc. That's not so say we shouldn't give thosethings any thought, but we needn't bend over backward for 1% or 2%savings because it just doesn't make sense. We should concern ourselveswith the "low hanging fruit" of these problems.
If people who are interested in solving problems other than the "webevacuee lifeboat" problem, or who are interested in building "jewels forhackers" want to start separate projects of their own to do so, I wishthem, sincerely, all the luck in the world. I straight up do not havethe time and energy spare after Gemini to have even slight activeinvolvement in such projects, but that doesn't mean I don't wish themwell. If these other projects want to make use of the text/geminimarkup format, I am more than happy about that - it's a popular part ofGemini and one which is completely orthogonal to the network protocol.Please feel free to distribute it over IPFS, DAT, SSB, Gopher (maybepeople can write Gopher clients which interpret item type 0 documentsdifferently based on file extension? It forces you into ugly URLsforever, but so be it), and stuff that doesn't even exist yet. You havemy blessing.
Be wary, please, of spreading a small and young community (not theGemini community, but the "neo small internet" community) too thin withmultiple simultaneous projects with only minor differences between eachother. Be wary of burdening client authors with an expectation that agood "small internet browser" needs to simultaneously support a largenumber of protocols to be useful, because that's a pain and you shouldbe nice to client authors. Be wary that clients which speak encryptedprotocols and unencrypted ones and which flip between them automaticallyand invisibly are fundamentally risky propositions.
Be aware that "Mercury", as I sketched it, was a "conceptualnavigational aid" for me to try to grapple with the question of whetheror not Gemini was becoming "too complex" (and one that most people - notall, but most - had a very negative reaction to). As such it is wasdesigned (very quickly!) from the perspective of starting with Geminiand ripping stuff out. If other projects seek to explicitly optimisesome criteria which they feel Gemini is lacking in (energy consumption,network overhead or latency, fits-in-head-ability, need for externallibraries), they should be aware that the Mercury sketch is notnecessarily a sensible starting point, because its design took forgranted certain concepts already depply established in the design ofGemini, and those concepts were not established with these othercriteria in mind. You might do a lot better by starting from scratchand making all decisions with your ultimate goal firmly in mind.
I think that's all I have to say on this matter.
Cheers,Solderpunk