Mercury

[solderpunk]

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 these
points.  I appreciate beautifully minimal things like FORTH, I value
ease of teaching and of learning, and I tinker with AVR micros and even
more constrained platforms myself.  I get it.  These are important things
to consider.  But at the end of the day no one protocol can optimise
simultaneously for all these things.  Often times the different
requirements fight each other.  Even aesthetic minimalism and
explainability can conflict, as really beautifully minimal systems with
great generality/flexibility/power often require the user to first adapt
to some unfamiliar, abstract mode of thinking that is not easy to grasp
quickly.

Ultimately, Gemini is supposed to be a practical protocol to solve a
concrete, real-world problem: the web has become a disaster on many
fronts simultaneously, and lots of people really want out, at least some
of the time and for some things, but the only "off the shelf" thing they
can flee to for roughly the same experience is Gopher, but many of them
can'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 a
beautiful object of appreciation for hackers that most people have no
use for (there's no shortage of these!), I want it to be a viable
lifeboat for evacuees from the web.  The first-class application is
computer literate non-developers using "normal computers" and software
other people wrote to read meaningful textual content with a reasonable
expectation of privacy.  I am happy to make it simpler, more beautiful,
more hackable, more general purpose, friendlier to low power computers
and slow networks, to whatever extent is possible without interfering
with its seaworthiness as a lifeboat.  I realise that it's worthwhile
to do so to incentivise developers (who are inevitably the early
adopters, and who will get excited by these properties) to write
clients 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 by
somebody who just learned what a socket is yesterday is ultimately
self-defeating from the lifeboat perspective.  If part of the reason
people want to flee from the web is because of privacy concerns,
offering them a plaintext alternative makes no sense at all, and they
just won't make the jump.  The mandatory encryption in Gemini is an
important, functional, deliberate part of the lifeboat design.  It would
be a bad lifeboat without out.

When we *do* chase improvements in these other regards without
compromising our role as a lifeboat, we also need to keep a sense of
perspective, make our criteria clear, make measurements and not trust
our guts, etc.  I'm all for a lower power, greener internet.  But if you
really want to push in that direction hard, you need to make radical
departures from the basic paradigms that the web and Gemini are both
built around.  I'm talking about systems where content is automatically
and user-invisibly replicated across hosts and naturally ends up
"migrating" to hosts which are closest, from a network perspective, to
the places where demand for access to that content is highest.  A really
radical 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 that
kind of a world.  It's built around old-fashioned ideas, on purpose, in
order to be "radically familiar" to both users and developers from the
web, because a lifeboat protocol *needs* to be radically familiar.  If
you throw in P2P and content-based addressing and blockchains and all
the stuff you need to use to address the deep problems with the
internet, a majority of both users and developers immediately have no
idea what is going on and they won't get in your lifeboat because they
can't.  So, by virtue of its deliberate old fashionedness, Gemini is
never going to be the absolute best choice for low power consumption,
for low bandwidth, etc.  That's not so say we shouldn't give those
things any thought, but we needn't bend over backward for 1% or 2%
savings because it just doesn't make sense.  We should concern ourselves
with the "low hanging fruit" of these problems.

If people who are interested in solving problems other than the "web
evacuee lifeboat" problem, or who are interested in building "jewels for
hackers" want to start separate projects of their own to do so, I wish
them, sincerely, all the luck in the world.  I straight up do not have
the time and energy spare after Gemini to have even slight active
involvement in such projects, but that doesn't mean I don't wish them
well.  If these other projects want to make use of the text/gemini
markup format, I am more than happy about that - it's a popular part of
Gemini and one which is completely orthogonal to the network protocol.
Please feel free to distribute it over IPFS, DAT, SSB, Gopher (maybe
people can write Gopher clients which interpret item type 0 documents
differently based on file extension?  It forces you into ugly URLs
forever, but so be it), and stuff that doesn't even exist yet.  You have
my blessing.

Be wary, please, of spreading a small and young community (not the
Gemini community, but the "neo small internet" community) too thin with
multiple simultaneous projects with only minor differences between each
other.  Be wary of burdening client authors with an expectation that a
good "small internet browser" needs to simultaneously support a large
number of protocols to be useful, because that's a pain and you should
be nice to client authors.  Be wary that clients which speak encrypted
protocols and unencrypted ones and which flip between them automatically
and invisibly are fundamentally risky propositions.

Be aware that "Mercury", as I sketched it, was a "conceptual
navigational aid" for me to try to grapple with the question of whether
or not Gemini was becoming "too complex" (and one that most people - not
all, but most - had a very negative reaction to).  As such it is was
designed (very quickly!) from the perspective of starting with Gemini
and ripping stuff out.  If other projects seek to explicitly optimise
some criteria which they feel Gemini is lacking in (energy consumption,
network overhead or latency, fits-in-head-ability, need for external
libraries), they should be aware that the Mercury sketch is not
necessarily a sensible starting point, because its design took for
granted certain concepts already depply established in the design of
Gemini, and those concepts were not established with these other
criteria in mind.  You might do a lot better by starting from scratch
and making all decisions with your ultimate goal firmly in mind.

I think that's all I have to say on this matter.

Cheers,
Solderpunk