[tech] [spec] On extending gemini

Michael Lazar <lazar.michael22 (a) gmail.com>

I feel like I should say something as the author of the controversial
gemini favicon RFC [0].

This comment was posted earlier today by ddevault on the Amfora issue
tracker [1].

> Every gemini page shall complete in a single gemini request. Please
> do not send extra requests to my server, opt-in or not. Gemini is
> not the web and adding flashy features and new standards is
> decidedly un-gemini.
>
> I might update my server software to automatically blackhole any IP
> address which tries to request a favicon file.

And continuing in the following comment (after makeworld expressed
some reservations).

> This is the only means we have of self regulation. I'll ask nicely
> first but ultimately I'll do what I have to in order to preserve
> Gemini's simplicity and utility as a small internet protocol.
> Do not. Extend. Gemini.
> Period.

This is disgraceful, shameless intimidation.

Note the deliberate timing of when this issue was raised.
gemini://srht.site was announced just a few hours earlier and the
obvious expectation is that ddevault will soon host a significant
portion of gemini capsules in the wild. He now has the power he
needs to make demands of other gemini developers.

The threat isn?t to blackhole all requests to /favicon.txt, which
might have been considered reasonable. No, the thread is to blackhole
the IP address of every amfora user, cutting them off from a large
swath of gemini and thereby crippling the client. Destroying the
hundreds of hours that makeworld has no doubt spent building up his
software and community. Unless he submits, unwavering, to ddevault?s
ultimatum to "fix" his software.

And it worked.

Think carefully about the consequences of using gemini://srht.site.

Now, switching gears to rant about gemini more broadly. For context,
I was one of the earliest adopters of gemini, although I don?t have
any ties to its inception and the group of people who brainstormed
ideas for the initial spec. I was a spectator who stumbled upon it
while I was browsing through bongusta! one day [2].

Solderpunk and the FAQ [3] are wrong about gemini. Gemini?s success
is not because the protocol was designed to be restrictive, or secure,
or accessible, or any other post-hoc rationalization that one might
come up with to explain why gemini is better than the web.

Gemini is nothing more than a set of common-sense solutions to
problems that were expressed by the gopher community around the time.
By ?gopher community? I don?t mean the UMN gopher/gopher+ of the 90?s
which is long since dead. I mean the modern gopher revival of the
post 2000?s, which is *completely* different in both form and
function. Gopher has not survived the past 30 years because the
protocol was simple and restrictive. On the contrary, gopher has
evolved profoundly.

So then what?s so special about gemini? Why not stick to gopher? Put
simply, it was time for gopher to evolve again. The gopher community
wanted more. But we had reached the limit of what was capable without
breaking gopher in backwards incompatible ways. Thus gemini was
conceived to fill that gap. This is such an important distinction to
make. Gemini was *not* born to add restrictions to an increasingly
bloated web. Gemini was born to release the shackles of a legacy
gopher protocol.

The secret to gemini is not what it restricts; but what it enables.
Constraint breeds creativity. This is the reason that gopher and
gemini have been successful. A bunch of tinkerers, hackers, artists,
poets, and makers found a new medium to express themselves. Or
rather, a bunch of normal folks like you and me discovered that we


It?s the magic of the smolnet. It?s fleeting; you can?t capture it in
a bottle and you can?t freeze it in time by locking down the spec.
Enjoy it while it lasts. I came up with the favicon emoji RFC because
I thought it was a fun idea. I ported botany to gemini because I
thought it was a fun idea. Don?t stifle your own ideas out of fear of
what will happen to gemini://. Gemini will evolve whether you want it to
or not.

- Michael (mozz)

[0] gemini://mozz.us/files/rfc_gemini_favicon.gmi
[1] https://github.com/makeworld-the-better-one/amfora/issues/199
[2] gopher://i-logout.cz:70/1/bongusta
[3] https://portal.mozz.us/gemini/gemini.circumlunar.space/docs/faq.gmi

Link to individual message.

colecmac@protonmail.com <colecmac (a) protonmail.com>

Thank you for chiming in mozz, I appreciate it.

 > Unless he submits, unwavering, to ddevault?s ultimatum to "fix" his software.
 >
 > And it worked.

Not just yet! I take back my initial quick decision to remove them. I hate
having to go back and forth on this, but I think it's important.

As the developer of Amfora, I'm genuinely unsure what to do here. I feel
uncomfortable at being at the centre of this, but also intrigued at what this
means for Gemini and its future.

I'd like to make a small correction to your email:

 > No, the threat is to blackhole the IP address of every amfora user, cutting
 > them off from a large swath of gemini and thereby crippling the client.

Drew's idea would only blackhole Amfora users who had enabled the the favicon
feature, which is off by default, to respect Gemini's one request philosophy.

However this is still a tactic I strongly disagree with, and although Drew said
(on IRC) he considered "banhammering" a last resort, I don't think it should be
on the table at all for clients that are not causing any server problems.

To be honest, I am leaning to keeping the feature, because it's what I want, and
it's my client, goddamnit! If Drew still says he will go ahead with the
blackhole then I will add a manual exception for his domains. This is obviously
an ugly thing to do, reminiscent of WebKit Quirks[1], but I don't see another
option.

1: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/Quirks.cpp


Feel free to subscribe or watch #199 for Amfora-specific updates on this.

https://github.com/makeworld-the-better-one/amfora/issues/199


makeworld

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Michael Lazar once stated:
> I feel like I should say something as the author of the controversial
> gemini favicon RFC [0].

  I've been pondering a response to this all day, and I wasn't sure even if
I should respond.  Thanks for breaking the ground here.

> This comment was posted earlier today by ddevault on the Amfora issue
> tracker [1].
> 
> > Every gemini page shall complete in a single gemini request. Please
> > do not send extra requests to my server, opt-in or not. Gemini is
> > not the web and adding flashy features and new standards is
> > decidedly un-gemini.
> >
> > I might update my server software to automatically blackhole any IP
> > address which tries to request a favicon file.
> 
> And continuing in the following comment (after makeworld expressed
> some reservations).
> 
> > This is the only means we have of self regulation. I'll ask nicely
> > first but ultimately I'll do what I have to in order to preserve
> > Gemini's simplicity and utility as a small internet protocol.
> > Do not. Extend. Gemini.
> > Period.
> 
> This is disgraceful, shameless intimidation.

  But it fits with his character.  When I asked for the IP address of his
web proxy to block it (because of his refusal to support robots.txt), he 
resorted to name calling:
  
        https://lists.orbitalfox.eu/archives/gemini/2020/003509.html

(Note for non-US readers:  The term "dick" is a slang term for "penis" and
is used as a slur against other males.  It is *also* true that "Dick" is a
legitimate name (a short form for "Richard"), but as I'm not named
"Richard", nor is Drew, it was obviously a slur against me.)

  It does come across as Drew saying "blocking is for me, not for thee.")

> Note the deliberate timing of when this issue was raised.
> gemini://srht.site was announced just a few hours earlier and the
> obvious expectation is that ddevault will soon host a significant
> portion of gemini capsules in the wild. He now has the power he
> needs to make demands of other gemini developers.
> 
> The threat isn?t to blackhole all requests to /favicon.txt, which
> might have been considered reasonable. No, the thread is to blackhole
> the IP address of every amfora user, cutting them off from a large
> swath of gemini and thereby crippling the client. Destroying the
> hundreds of hours that makeworld has no doubt spent building up his
> software and community. Unless he submits, unwavering, to ddevault?s
> ultimatum to "fix" his software.
>   
> And it worked.
> 
> Think carefully about the consequences of using gemini://srht.site.
> 
> Now, switching gears to rant about gemini more broadly. For context,
> I was one of the earliest adopters of gemini, although I don?t have
> any ties to its inception and the group of people who brainstormed
> ideas for the initial spec. I was a spectator who stumbled upon it
> while I was browsing through bongusta! one day [2].

  I am not fond of Drew (and it's for more than his just calling me a bad
name), but I'm trying square his actions against mine from 2019.  For
context, I was *the* first adopter of Gemini, writing my own server even
before Solderpunk could write one (for the record: he wrote the second
Gemini server).  I *broke* the spec with my implementation, not at all
agreeing with Solderpunk about some pretty fundamental issues with the
protocol, because at *that* time, the protocol:

	used single digit resonse codes
	no support for client certificates
	a link line of [text|url]
	no virtual hosting
	a request format ala gopher (including TABs!)
	no rediection
	no indication of pages are actually gone vs not found
	no MIME parameters

  I like to think I wasn't quite the dictator that Drew comes across as (in
both his Amfora ticket, or this message to the list:

	https://lists.orbitalfox.eu/archives/gemini/2020/003506.html

Who put *him* in charge of Gemini?)  I had (well, still have) strong
opinions on Gemini, but I did present my arguments for certain features, and
against others.  And it wasn't uncommon in the early days of sweeping
changes and mass updates to clients *and* servers.

  As a consequence, I find this seeming charge of "don't change the spec
EVER!" troublesome.  That once Solderpunk (where *IS* he, by the way?) makes
the few changes that are requested, that's it.  It's done.  No more
experimentation.  Ever.  It feels as if Gemini is ossifying even before it's
set in stone.  It's a weird feeling.

> It?s the magic of the smolnet. It?s fleeting; you can?t capture it in
> a bottle and you can?t freeze it in time by locking down the spec.
> Enjoy it while it lasts. I came up with the favicon emoji RFC because
> I thought it was a fun idea. I ported botany to gemini because I
> thought it was a fun idea. Don?t stifle your own ideas out of fear of
> what will happen to gemini://. Gemini will evolve whether you want it to
> or not.

  I thought the favicon emoji was a fun idea.  I still do.  I even support
it on my server.  Astrobotany is a *wonderful* use of client certificates
(and something I was hoping would happen when I was pushing for their use). 
And I agree, Gemini will evolve over time.  Inline images?  Okay, data: URLs
[3]!  Or wait, I know!  A MIME type of multiple/related!

  -spc (Muahahahahahahahahahaha!)

> [0] gemini://mozz.us/files/rfc_gemini_favicon.gmi
> [1] https://github.com/makeworld-the-better-one/amfora/issues/199
> [2] gopher://i-logout.cz:70/1/bongusta

[3]	I'm the joker responsible for that.  Gemini Client Torture Test #21.

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great colecmac at protonmail.com once stated:
> To be honest, I am leaning to keeping the feature, because it's what I want, and
> it's my client, goddamnit! If Drew still says he will go ahead with the
> blackhole then I will add a manual exception for his domains. This is obviously
> an ugly thing to do, reminiscent of WebKit Quirks[1], but I don't see another
> option.
> 
> 1: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/Quirks.cpp

  Keep the feature but don't add a "quirks" mode.  It will hurt Drew in the
long term.  I use Amfora and enable favicon.txt support.  I go to Drew's
site and get banned.  Oh, Amfora isn't working for his site, let me try
another client.  Oh, I'm *still* banned?  WTF?  Okay, I'll just skip this
snowflake site then.  Or maybe I (and other former Amfora users who got
banned and switched clients) send email to Drew asking to be reinstated.

  Also, this message from Drew:

	https://lists.orbitalfox.eu/archives/gemini/2020/003506.html

  Seriously, who put Drew in charge?

  -spc

Link to individual message.

mieum <mieum (a) namu.blue>

Hey folks,

I hope chiming in tangentially like this isn't a faux pas.

I just wanted to say that I am grateful for all of you skilled and wise
(and opinionated) people here on this list and Gemini at large. I
consider myself among the most plebian of laymen, and have learned A LOT
keeping an ear to the pavement about all things Gemini here. I am
grateful that there are so many passionate and knowledgeable people
caring about Gemini. 

In regard to the issue of this thread, I see many people whom I admire
and respect expressing valid concerns about an important issue. I hope
that all concerned parties here can hear each other, and that with this
issue and others, we can proceed with an underatanding that agreement
is not a condition of community. There are many passionate people
residing in Geminispace, and I hope that we can appreciate that even
those with whom we disagree are in fact not only our neighbors, but 
also our closest allies.

This is my ignorant and biased two cents. I do not mean to mininize
anyone's opinion here, of course. Just wanted to remind all of you that
there are a lot of people out here who appreciate that all of you care
so much. Now I'm off to dick around (isn't English fun?) on one of my 
many obscure capsules :)

Good night Gemini,
~mieum

Link to individual message.

Bradley D. Thornton <Bradley (a) NorthTech.US>

What we have here, is a little cancel culture fun goin' on ;)

Let's play paint the asshats into a corner, shall we? You decide which
folks get loaded on the train to oblivion okay?

What I'm really upset about here, is the fact that the last bambi I
murdered for food got incinerated coz I couldn't get it down off the
mountaiin when my part of the mountain was engulfed by the fires. I
barely made it out myself, and were it not for a grower who knew I was
probably still on the mountain and completely unaware of the evacuation
orders, I would have been cooked myself.

So I come back, to what, this? Hey I took couple of glances at the list
and how the Gemini space has grown, along with the explosive adoption of
this experimental protocol and though to myself, "Man, it's still in the
spirit of the old NSFnet AUP - that's awesome.

Now I learn that someone is disrespecting me. This will not stand.

For the better part of two decades, my friends and colleagues on the
Gopher list have chided me for my refusal to accept proxies which permit
people to use HTTP protocol to access my gopherholes. Yet in that time,
I have NEVER come accross an administrator who outright refused to
accept my personal **choice** to disallow such proxies to invade my
network space.

It may be not in alignment with what others have wanted, in order to
repopularize the Gopher protocol, but I am, and always have been, a firm
believer that if you want to surf any protocol space, then you should
use the tools specifically designed for those purposes. I lamented the
removal of Gopher protocol from the **browsers*, and subesquently,
cogitated over why one would even bother having an http:// in the
address bar if that's ultimately going to be the only supported method
of browsing, all of this while Geocities went lights out and Angelfire
stopped showing up in SERPs... and people became the dopamine enslaved
property of private enterprise that butcherd and packaged and wrapped us
in celophane with a price tag as they placed us into inventory.

So here comes this new thang using TCP 1965 and I'm like, "Okay, kewl!
That's how we extend Gopher to a new beginning without damaging it or
crippling the backward compatibility of it, and we can leave port 70
alone, without losing what is so great about the protocol!"

>From the lessons learned in hindsight with respect to functionality and
utility, Gemini introduced a novel methodology that is, or at least was
until a couple of days ago, adventerous, experimental, with that
sensible utility and above all, not afraid to examine ideas and kick
them around a bit.

I was so excited when the first time Gemini space delivered to me an
almost discernable ANSI graphics file. I know most of you weren't even
born when that was a thing, long before most everyone here was privy to
ARPANET access. But it was a big deal for me.

And now, instead of simply discussing the virtues that include the pros
and cons, with demonstrated test cases, some latecomers are showing up,
drawing lines in the sand with their divisive sticks, and making threats
against the people who have put in the hard work and actually built
Gemini in the first place? How dare you?

To see the creators and original pioneers, so to speak, of the Gemini
protocol threatened and bullied like this? Especially the gentlemen
whose servers most everyone in Gemini space actually run themselves?

I dunno what Faceplant taught y'all, but if it was kneejerk reactions
are something you think is a noble thing then maybe you learned well,
and maybe you should just keep on Faceplanting and cutting off a few
more pounds of flesh for Google, and those who would refuse to respect
the wishes of server admins that don't want their services bastardized
by proxies delivering their content to people in HTTP space.

Now, threatening people like the authors of Amfora, and Jetforce, and
GLV-1.12556 (the first ever Gemini server)? Man that's not just bad
form, it's borderline ad homonym - a bannable offense in most treatises
of netiquette. The people I've just mentioned are the people who made
possible your very enjoyment of this novel service answering on TCP
1965, and you have the audacity to dangle deplatforming at them? Do you
wish to incite a Hatfield and McCoy like volley?

I don't think so. Chill, have a crumpet, watch an old episode of Lost in
Space, or listen to a a good death metal band live in concert, or a
string quartet performing Bach - whatever floats your boat and takes you
to that happy place of yours. If you don't, everyone will end up with
urine on their pant legs and that's stinky, to say the least.

Now, I've personally just discovered Lagrange, and I must say I'm
enamored of it. It fricken' rocks and at this time is my goto GUI client
for Gemini (and  Gopher). My fav is however,  still Elpher, and no, I'm
still a Vim guy, but that's okay. I've seen people rave about how kewl
other clients are, some I like, some I feel are lacking with respect to
my needs, and ALL of that is okay. I even prefer using some really
rickety old and unmaintained CLI based clients.

So let's talk not talk about ultimatums, but instead, about choices.
About user choices and about server admin choices and the rules they
adopt as their acceptable use policies. If a server admin says, "You
can't put up content on my servers with favicons - then fricken' don't
do that!

but don't be an asshat and say you'll ban the IPs of people using
clients that support a feature you can otherwise prohibit your
respective userbase as part of your terms of service, or threaten to
lobby for the deplatforming of well meaning, enthusiastic developers -
that's childish, that's juvenile, that's moronic.

That's as stupid as the crippleware that Tusky became when it violated
the philosophy of FOSS and user empowerment by hardcoding philosophy
into the client. You take away the empowerment of the user and you're no
better than Dorsey or Ellison or Zuckerberg or ABC... Don't be evil my
ass, that's exactly what ABC has become.

If a user says, I don't want favicons coz I'll get tracked (ridiculous
reasoning, but as valid as any other preference), then either use a
client that doesn't support that or find the dev of your fav client and
ask them if they'll integrate such configurability into their client
that allows you to hold the pickles and lettuce. Special orders really
don't upset them, and if you do it in the form of a patch or pull
request, even better!

You need to realize that you're speaking to creators - people who like
to build things, and more often than not, it actually makes their day
when they know someone likes their product enough to ask for a feature
to be added. That's actually flattery man!, Flatter them. Thank them.
Let them know, as a consumer of their products that you have things you
think would be beneficial.

That's how you affect change.

Or you can threaten. And cancel yourself.

The truth about tracking, is that you can't do anything about stopping a
provider from attempting to do so. You're in their syslogs, their
firewall logs, and they can fingerprint you from other remote resources.
No one, that I'm aware of here, is interested in tracking anyone in
Gemini space. That will not always be the case, and already there are
those who are in earnest betrayal of the trust of this community, and as
is typical, those people are the individuals that are clamoring the
loudest for control, slinging threats, and engaging in ad homonym.

I'm seeing all kinds of new ideas and proposals and questions put into
experimentation for feasibility and that's part of what Project Gemini
is about (for example:
gemini://gemini.circumlunar.space/~ew/2020/20201217-towards-a-proper-flightlog-4.gmi
), some fly, some don't. Some are adopted even though the use cases are
narrow while others are popular and detested by many - for those latter
cases, we have three choices, that of user configurability, that of
server administrative policy, and official canonization into the spec.
That third item of remediation is, of course, the weakest of all
remedies when a popular functionality is the topic. Anyone can fork an
existing project and launch a death star. Don't kid yourselves, and it
will happen. It already has actually, there's a Richard Cranium out
there in Gemini space disrespecting robots.txt - and that's a very real,
clear, and imminent threat to privacy.


I hope that helps :)

-- 
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268

Link to individual message.

Miguel de Luis Espinosa <enteka (a) fastmail.com>

> 
> I hope that helps :)
> 
> -- 
> Bradley D. Thornton
> Manager Network Services
> http://NorthTech.US
> TEL: +1.310.421.8268
>

I love amfora and I'm not using that favicons thing because I cannot see 
the point of that on amfora. I works nicely without it. 

However,

I will still support and use amfora no matter what the developer _chooses_ 
to do on this issue.

And specially,

I will still support and use amfora no matter what anybody elses chooses 
to do. In other words, whoever chooses to blcok amfora chooses to block 
me, as well, fwiw, for I will _not_ be using anything else to access such sites. 

My usual reaction to matter as these is to ask everyone to cool off a bit, 
and maybe re-formulate their concerns in a more positive way. It would be 
still a valid point. However, I do think I owe, we owe, a bit of respect 
to every contributor to Gemini. And certainly that's the case for Amfora.

Miguel de Luis Espinosa

Link to individual message.

nervuri <nervuri (a) disroot.org>

On Sun, Feb 21, 2021, Michael Lazar wrote:
>> I might update my server software to automatically blackhole any IP
>> address which tries to request a favicon file.

>This is disgraceful, shameless intimidation.

It's also bad on a technical level.  It would only take one bad actor to
get all Tor exits blocked.  This also applies to other shared IPs like
VPN exits and other proxies.

It's a pity that Drew chose this off-putting type of approach.  It tends
to have the reverse effect.

A good argument against automated favicon requests is that they
contribute to fingerprinting.  Not by much, but little things like this
can add up.  The alternative approaches suggested by Drew don't have
this problem:

> There are alternatives, such as generating a colored icon or image
> based on the hash of the domain, or allowing users to set a custom
> favicon themselves.

Here's what Solderpunk had to say on the topic:

https://lists.orbitalfox.eu/archives/gemini/2020/000612.html
https://lists.orbitalfox.eu/archives/gemini/2020/001060.html

Link to individual message.

avr@geminet.org <avr (a) geminet.org>

On Sun, Feb 21, 2021 at 12:23:15AM -0500, Michael Lazar wrote:
> This is disgraceful, shameless intimidation.

At the moment there's nothing preventing a gemini client from running
an interpreter for a gemtext embedded scripting language other than
good habits and intent. The only thing anyone in the gemini-verse
can do to prevent such things is to not play along. Self-regulation
is all we have.

Maybe it's unfortunate that this truth has been stated with, let's call it
DeVaultian flair, but that doesn't make it wrong or even "intimidation". 

> The threat isn?t to blackhole all requests to /favicon.txt, which
> might have been considered reasonable. No, the thread is to blackhole
> the IP address of every amfora user, cutting them off from a large
> swath of gemini and thereby crippling the client. Destroying the
> hundreds of hours that makeworld has no doubt spent building up his
> software and community. Unless he submits, unwavering, to ddevault?s
> ultimatum to "fix" his software.

I think a returning a 58 error code ("Client is broken and smells bad") on 
requesting favicons would be a more appropriate respons but I can see where 
he's coming from. It's a form of "not playing along" with something he might 
think is very detrimental to the health of the gemini-universe. Drew being
prolific and/or provides resources in the public interest should not be used 
against him.
 
> Think carefully about the consequences of using gemini://srht.site.

It's a bit early for such warning. Gemini is commercially worthless. There
are no big consequences to simply moving a capsule. And if one thinks
gemini will become big and commercially succesful, now is the time to pay 
special interest as to what might turn out to be a slippery slope.

The web didn't get to be in the abysmal state it is in today by a few
bad actors with lots of influence who ruined it for the rest. It's mostly
been well intentioned people thinking "This is probably okay. It's not really
worse than what other-site is already doing". Then copy/paste repeat that
for a couple of decades and you'll arrive at the Jenga tower of crud that
is the current web. The web is a poster child of the slippery slope argument in
action and something the gemini community should be wary of and keep a
keen eye on.

> Gemini is nothing more than a set of common-sense solutions to

> The secret to gemini is not what it restricts; but what it enables.
> Constraint breeds creativity. 
 
> I came up with the favicon emoji RFC because
> I thought it was a fun idea. 

And it is a fun idea, but..

Another fun idea from the web is javascript. In essence it can be a really
convenient way to cross t's and dot i's in the content, and add some fun
creative flourishes. In practice it's turned the web into a network for 
distributing (proprietary) software and burying actual content for 
nefarious purposes.

It's not about what nice conscientious people will do with a fun extention;
it's about how greed and corruption ultimately can co-opt it for their
own purpose.

The best way to prevent going down a slippery slope is to *not step onto the slope*.

I think that for every fun extension it is wise to ask oneself the
question, "Is this creative, or am I re-inventing the web?"

"Favicon" sounds particularly web-ish, especially in light of the two solutions
already brought up ("if the first level 1 title of the homepage starts with a 
unicode character, use that as a favicon" and "generating a colored icon or image
based on the hash of the domain"), which do feel more in line with gemini.

Feel free to disagree with Drew's delivery, but I think it would be best to keep 
any arguments related to current and future gemini.

	cheers,
	Andreas

Link to individual message.

Petite Abeille <petite.abeille (a) gmail.com>



> On Feb 21, 2021, at 06:23, Michael Lazar <lazar.michael22 at gmail.com> wrote:
> 
> I feel like I should say something as the author of the controversial
> gemini favicon RFC [0].

Bah.

But yes ?while fun? the present Gemini favicon.txt spec "sucks balls" (technical term).

A small tagged data link would achieve just the same, minus overhead:

=> data:text/plain;charset=utf-8,%F0%9F%90%B0 favicon

?0?

Link to individual message.

Petite Abeille <petite.abeille (a) gmail.com>



> On Feb 21, 2021, at 06:23, Michael Lazar <lazar.michael22 at gmail.com> wrote:
> 
> This is disgraceful, shameless intimidation.

Gemini vigilantism. Grand. You reap what you sow. 

?0?

Link to individual message.

Oliver Simmons <oliversimmo (a) gmail.com>

On Mon, 22 Feb 2021 at 11:49, Petite Abeille <petite.abeille at gmail.com> wrote:
>
> > On Feb 21, 2021, at 06:23, Michael Lazar <lazar.michael22 at gmail.com> wrote:
> >
> > I feel like I should say something as the author of the controversial
> > gemini favicon RFC [0].
>
> Bah.
>
> But yes ?while fun? the present Gemini favicon.txt spec "sucks balls" (technical term).
>
> A small tagged data link would achieve just the same, minus overhead:
>
> => data:text/plain;charset=utf-8,%F0%9F%90%B0 favicon
>

Or, if it becomes a thing, a metadata line:
 ```
^^^
favicon: ?
 ```

Link to individual message.

Petite Abeille <petite.abeille (a) gmail.com>



> On Feb 22, 2021, at 12:54, Oliver Simmons <oliversimmo at gmail.com> wrote:
> 
> metadata line

Why not. 

But really. 

Continuously overloading preformatted text lines with exotic semantic 
is... a design smell. 

?0?

Link to individual message.

Drew DeVault <sir (a) cmpwn.com>

I really don't like this mailing list, because Gemini is lightning in a
bottle and this list is constantly trying to open the bottle. But alas,
here we are again.

I'm sorry for putting the stick on the table upfront; in hindsight it
was rude. I always prefer friendly negotiation first. However: Gemini is
constantly at a dire risk of being extended upon, a pattern which will
ultimately drive it to suffer the fate of the very problems of the web
which motivated its creation in the first place. I like Gemini, and if
we want Gemini to continue being likable, then it cannot grow in this
fashion.

This is not the first time we've dealt with this problem. This mailing
list is a constant stream of pleas for spec additions. Inline styles,
inline images, tables, forms and POST equivalents, the list goes on and
on and on. This mailing list is obsessed with reinventing the web, and
that's NOT what Gemini is for. Solderpunk has been quite clear on this.

The only means we have of regulating this behavior is by making a
statement with our client and server implementations. This is not the
first such statement I've made. First I stated that I would require SNI:

https://lists.orbitalfox.eu/archives/gemini/2020/003160.html

This was added to the spec shortly thereafter.

I also made a statement regarding robots.txt:

https://lists.orbitalfox.eu/archives/gemini/2020/003506.html

In this case: surprise, portals are just user agents, and blocking them
is blocking users. Dick move.

Most recently, favicons. Contrary to Sean's nasty comments, I am only
making statements on behalf of *my* software, not Gemini as a whole, and
I have every right to. You have every right to make statements on behalf
of your software, too. Clients like Amfora have already done so by
implementing favicons. Mine is a statement of opposition, and we will
ultimately have to come to some kind of consensus. This is how protocol
ecosystems work.

Mozz, your extensions are irresponsible. You view this medium as a
changing, evolving platform, and accept the consequences as it is
fleeting and ultimately doomed to ruin.

Fuck that.

We have a good thing here, and deliberately and recklessly fattening it
is going to screw it up for everyone. Take some responsibility for your
role in making this platform thrive for as long as it can. This
historical revisionism about how Gemini is a platform for Gophers to
feed their creativity into expanding upon Gopher's limitations is
ridiculous.  The purpose of Gemini has always been crystal clear. The
spec has received only minor clarifications and has always come with the
following promises:

- Any changes will not require drastic changes in implementations
- It will be frozen once time has proven it correct

Solderpunk reaffirmed this on the new year.

What you're advocating for is not what Gemini is supposed to be. If you
want that, then fine, go make it in another protocol. Stop trying to
open our lightining bottle. Please.

Finally, to clarify the role of srht.site: I did not intend to issue an
unstated threat of leveraging srht.site's influence to strong-arm Amfora
in this respect. There is not a case of "deliberate timing" here. My
statement regarding the possibility of black holeing was only with
respect to gmnisrv, which is a minority player in the field of Gemini
servers. I don't intend to shove this view onto all users of srht.site -
that's well beyond the scope of appropriate influence. I understand why
this was not clear, and I'm sorry for the confusion.

Link to individual message.

Petite Abeille <petite.abeille (a) gmail.com>



> On Feb 22, 2021, at 16:42, Drew DeVault <sir at cmpwn.com> wrote:
> 
> Fuck that.

?Gemini is like violence ? if it doesn't solve your problems, you are not 
using enough of it.?

?0?

Link to individual message.

Jason McBrayer <jmcbray (a) carcosa.net>

Drew DeVault writes:

> I'm sorry for putting the stick on the table upfront; in hindsight it
> was rude. I always prefer friendly negotiation first.

This was my opinion of the favicons situation ? that you (Drew) were
correct in substance, but wrong in form. It would have been much better
to raise the issue on the mailing list, with your arguments against the
favicon convention up-front.

> You have every right to make statements on behalf of your software,
> too. Clients like Amfora have already done so by implementing
> favicons. Mine is a statement of opposition, and we will ultimately
> have to come to some kind of consensus. This is how protocol
> ecosystems work.

I agree, but I feel it would be better to work towards that consensus in
a more collegial manner.

> Mozz, your extensions are irresponsible. You view this medium as a
> changing, evolving platform, and accept the consequences as it is
> fleeting and ultimately doomed to ruin.

I'm going to speak in Mozz's defense here, even though I think that at
this point the favicons convention experiment should be abandoned by
clients. Two things: first, the favicons convention is wrong, but it's
not *obviously* wrong, because it doesn't affect the protocol, the
gemtext format, or otherwise cause any backward compatibility issues.
Secondly, when Mozz introduced the favicon convention, Gemini was in a
much greater state of flux, and the community more experimental than it
is today. Mozz wrote it up as a concrete proposal on the mailing list,
implemented it on portal.mozz.us, and went from there. I suggest that
they did nothing wrong in that context, and proceeded exactly as they
should have.

With hindsight, the "one resource, one request" principle looks more
important with regard to privacy than it did at that time, and that's
why I'd recommend dropping support for favicons. But implementing
favicons at that time wasn't a mistake ? it was an experiment.

> - Any changes will not require drastic changes in implementations
> - It will be frozen once time has proven it correct
>
> Solderpunk reaffirmed this on the new year.

I understand that Solderpunk is extremely busy, but I do think that the
mailing list is suffering in his relative absence; a limitation of the
BDFN (benevolent dictator for now) structure we currently have.

> Finally, to clarify the role of srht.site: I did not intend to issue
> an unstated threat of leveraging srht.site's influence to strong-arm
> Amfora in this respect. There is not a case of "deliberate timing"
> here. My statement regarding the possibility of black holeing was only
> with respect to gmnisrv, which is a minority player in the field of
> Gemini servers. I don't intend to shove this view onto all users of
> srht.site - that's well beyond the scope of appropriate influence. I
> understand why this was not clear, and I'm sorry for the confusion.

Thank you for this; this does a tremendous amount to de-escalate the
situation. 

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

Link to individual message.

Pierre-Jean Baraud <pierre-jean (a) baraud.fr>

Hello everyone,

Drew DeVault wrote:
> The only means we have of regulating this behavior is by making a
> statement with our client and server implementations.

> Most recently, favicons. Contrary to Sean's nasty comments, I am only
> making statements on behalf of *my* software, not Gemini as a whole, and
> I have every right to. You have every right to make statements on behalf
> of your software, too. Clients like Amfora have already done so by
> implementing favicons. Mine is a statement of opposition, and we will
> ultimately have to come to some kind of consensus. This is how protocol
> ecosystems work.

I am very new to the game (this is my first mail in this mailing list) and
I never really participated in any "protocol ecosystems" in making.
Nevertheless, is there not a risk in that game that's
the most popular implementation defines the rule and hence, the game
is not being right, but being popular?

> Finally, to clarify the role of srht.site: I did not intend to issue an
> unstated threat of leveraging srht.site's influence to strong-arm Amfora
> in this respect. There is not a case of "deliberate timing" here. My
> statement regarding the possibility of black holeing was only with
> respect to gmnisrv, which is a minority player in the field of Gemini
> servers. I don't intend to shove this view onto all users of srht.site -
> that's well beyond the scope of appropriate influence. I understand why
> this was not clear, and I'm sorry for the confusion.

That is very nice to clarify that. But it still raises the concern of
such risk in
future by an actor of similar size: will the stick not overcome any
rational debate?

Also, unrelated, but I have learnt a lot from this mailing list through these
different debates and I think I start to have a better idea now of
Gemini's philosophy
thanks to you all (and I'm sure many of my first intuitions would have
first been
considered as anti-pattern / recreating the web)?
This learning has been very organic, almost chaotic and only thanks to
the people
posting "wrong" initiatives here as the answer they receive served for me as
guidelines as "Gemini philosophy".
Is there anywhere a more structured document, the equivalent of "unix
philosophy"
but for Gemini that would express the intention behind some of the
"limitation"/restrictions
of the platform that a newbie like me could refer to instead of
learning "by chance"
this through some response here and there (and sorry if it is an obvious link
that I am not aware about) ?

Link to individual message.

Drew DeVault <sir (a) cmpwn.com>

On Mon Feb 22, 2021 at 12:07 PM EST, Pierre-Jean Baraud wrote:
> I am very new to the game (this is my first mail in this mailing list)
> and I never really participated in any "protocol ecosystems" in
> making.  Nevertheless, is there not a risk in that game that's the
> most popular implementation defines the rule and hence, the game is
> not being right, but being popular?

Yes, that's a risk indeed. I think it's a well-managed risk in Gemini
right now, we have a huge selection of client and server softwares to
choose from and no single actor has a dominant role. And unlike web
browsers, new Gemini software can be written and useful in the span of a
weekend, providing an easy escape hatch - but this will change if we're
not strict in limiting the scope of the protocol.

> That is very nice to clarify that. But it still raises the concern of
> such risk in future by an actor of similar size: will the stick not
> overcome any rational debate?

I do realize that srht.site has the potential to become sizable enough
to carry substantial influence on the direction of Gemini. However, I
don't want it to do so: srht.site should only be a boon to the
community, not a risk or a political tool. I pledge to not use it as a
platform for pushing any opinionated decisions which are not already
representative of the community consensus.

I can't say this for the next service that comes along, but hopefully it
helps to set the tone.

> Also, unrelated, but I have learnt a lot from this mailing list
> through these different debates and I think I start to have a better
> idea now of Gemini's philosophy thanks to you all (and I'm sure many
> of my first intuitions would have first been considered as
> anti-pattern / recreating the web)? This learning has been very
> organic, almost chaotic and only thanks to the people posting "wrong"
> initiatives here as the answer they receive served for me as
> guidelines as "Gemini philosophy".  Is there anywhere a more
> structured document, the equivalent of "unix philosophy" but for
> Gemini that would express the intention behind some of the
> "limitation"/restrictions of the platform that a newbie like me could
> refer to instead of learning "by chance" this through some response
> here and there (and sorry if it is an obvious link that I am not aware
> about) ?

The FAQ helps a lot:

gemini://gemini.circumlunar.space/docs/faq.gmi

But I think a lot of people don't read it, or perhaps forget about it,
because many of the proposals oft floated are clearly not in the spirit
of Gemini as laid down by the upstream documentation.

Link to individual message.

Oliver Simmons <oliversimmo (a) gmail.com>

On Mon, 22 Feb 2021 at 17:08, Pierre-Jean Baraud <pierre-jean at baraud.fr> wrote:
>
> Nevertheless, is there not a risk in that game that's
> the most popular implementation defines the rule and hence, the game
> is not being right, but being popular?

This is kind of what happened to the HTTP/HTML web, with big
corporations such as Google taking over.
Mozilla/Firefox was created for the purpose of stopping Microsoft
taking over the web when they were a big player.

> Is there anywhere a more structured document, the equivalent of "unix
> philosophy"
> but for Gemini that would express the intention behind some of the
> "limitation"/restrictions
> of the platform that a newbie like me could refer to instead of
> learning "by chance"
> this through some response here and there (and sorry if it is an obvious link
> that I am not aware about) ?

Not exactly like that, but there's
https://gemini.circumlunar.space/docs/faq.gmi
(section 2)

Link to individual message.

John Cowan <cowan (a) ccil.org>

On Mon, Feb 22, 2021 at 11:33 AM Jason McBrayer <jmcbray at carcosa.net> wrote:


> > Solderpunk reaffirmed this on the new year.
>
> I understand that Solderpunk is extremely busy, but I do think that the
> mailing list is suffering in his relative absence; a limitation of the
> BDFN (benevolent dictator for now) structure we currently have.
>

In another project, I like to describe myself as Chief Cook and
Bottle-washer For Now.  Keeping that firmly in mind and telling people
about it helps to defuse anyone's fear (including mine) that I will aspire
to be the Absolute Dictator of the Known Universe.  ("But I could do so
much *good* that way."  "Riiight.  'For nothing is evil in the beginning.
Even Sauron was not so.'  And 'Power tends to corrupt, and absolute power
corrupts absolutely.  Great men are often bad men.'")


> >  I understand why this was not clear, and I'm sorry for the confusion.
>
> Thank you for this; this does a tremendous amount to de-escalate the
> situation.


Lesson to be learned, perhaps: when an actor in a position of power (real,
potential, or even just perceived) issues a moderate threat, other actors
may read it as an existential threat, and so eventually provoke the Second
Coming (of Jesus or the Valar or both, it's going to be a rough ride in any
case).  So the bigger you are, the meeker you should be; after all, the
meek will inherit the earth, bit by bit, pushing back against violence.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
So they play that [tune] on their fascist banjos, eh?
        --Great-Souled Sam

Link to individual message.

Nathan Galt <mailinglists (a) ngalt.com>


> On Feb 20, 2021, at 9:23 PM, Michael Lazar <lazar.michael22 at gmail.com> wrote:
> 
> The secret to gemini is not what it restricts; but what it enables.
> Constraint breeds creativity. This is the reason that gopher and
> gemini have been successful.

While this quote is far enough from the main thrust of Michael?s point to 
be considered a grossly misleading out-of-context quote, I want to agree 
with it in parts.

Restrictions on Gemini (the protocol and gemtext) make it easy to have 
lots of Gemini clients that are all capable of browsing _all_ of 
Geminispace and not just the simpler ones. This is in _stark_ contrast to 
HTTP-land, where if you want to browse all of the Web you need to use one 
of 2.5 browser engines. I think having lots of good clients for all the 
popular platforms (and many of the unpopular ones!) is a goal worth 
preserving, even though I have a bunch of good clients for all the 
platforms I?m ever likely to use (and I?m exceedingly unlikely to write one of my own).

Because Gemini complexity and browser diversity are fundamentally at odds 
with each other, and the Web already chose complexity at the cost of 
diversity, I?ve become much more against protocol/gemtext additions. I 
thought the favemoji thing was cool when I first heard about it, but since 
it?s something of a camel?s nose in the tent, I changed my Amfora settings 
back to not requesting them.


=> https://idioms.thefreedictionary.com/a+camel%27s+nose+(under+the+tent)

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Drew DeVault once stated:
> This
> historical revisionism about how Gemini is a platform for Gophers to
> feed their creativity into expanding upon Gopher's limitations is
> ridiculous.  

  Michael is correct---you are not.  Gemini *is* an expansion of gopher, not
a reimagining of the web.  Citing primary sources here (Solderpunk himself):

gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/pondering-whats-inb
etween-gopher-and-the-web.txt

	It's no secret, of course, that I love gopher.  Some of my reasons
	are outlined in previous writings[2].  And it's neither a secret
	that I hate the web, or at least it's modern incarnation.  Both of
	these things can be, and are, true while I still believe that Gopher
	is not perfect and has shortcomings, and there are things about the
	web experience to miss when one surfs on port 70.  So lately I've
	been thinking about "the space inbetween", about hypothetical dream
	protocols which are more than gopher but less than HTTP.

	...

	As a first contribution to this line of thinking, I have come up
	with a protocol which basically consists of three small changes to
	gopher which address what I *think* I currently believe are its
	three greatest shortcomings.

	The first change is that TLS encryption of all connections is
	mandatory.  No two port cleartext/cyphertext distinction like HTTP
	and HTTPS, no upgrade from cleartext using STARTTLS, just secure
	connections from the get go and that's it. ...

	The second change is that the standard non-directory item type is
	not a plaintext file, but a text file in some very lightweight,
	human-readable markup language which supports inline linking to
	other resources.  ...

	The third and final change is the introduction of an item-type which
	means "interpret this selector and interact with it in some way
	determined by its schema".  The 'h' item-type already plays this
	role for many more advanced clients, if you put a "URL:" in front of
	the selector, but this is IMHO an ugly hack which really spoils the
	clean semantics of the gopher protocol.  And item-type of 'h' is
	supposed to and *should* mean "this is a HTML file", and item-types
	shouldn't do double duty as it defeats the point of them.

gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/why-gopher-needs-crypto.txt

	I'm talking about the fact that my hypothetical new protocol
	operated strictly over TLS connections - plaintext straight up
	wasn't an option.  I am of the opinion that the widespread lack of
	encryption in gopherspace today is the protocol's biggest
	shortcoming, and I actually suspect that this point alone
	discourages some folks who would otherwise be on board from adopting
	it.  But others, including Bongusta overlord Logout, do not see the
	need, so here's my attempt at a justification.

	...

	The web is surely a dumpster fire, but let's not pretend gopher is
	perfect and cannot be improved.  Those of us fleeing the web have
	just fallen back here because it's about the only off-the-shelf
	vaguely web-like thing that there is to fall back to.  Some of us
	may be truly comfy here, and that's absolutely fine.  Increasingly I
	think I'd like to use gopher as a temporary base of operations to
	build something even better.

gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/more-on-gopher-and-crypto.txt

	My recent post[1] about "why gopher needs crypto" received a very
	well-considered response[2] over at The Boston Diaries.  The author
	(do I call you "the conman"?) rightly points out that the true
	challenge is not in actually conducting a gopher request/response
	transaction over a TLS connection, which in relatively trivial and
	has been done before.  Rather, the core difficulty lies in the
	absence of any way to represent in a type-1 response that a
	particular gopher resource is accessible via TLS.

	...

	The conman suggests that creating a new protocol is to risk that we
	"start falling into HTTP territory".  This is of course a very real
	risk, but I also very strongly believe that it is perfectly
	avoidable if we are sufficiently determined from day one to avoid
	it.  To this end, I hope to think and write (and read, if anybody
	wants to join in!) more in the future not just about the
	shortcomings of gopher but very explicitly about what is right and
	what is wrong about HTTP and HTML.  It's vitally important to
	identify precisely what features of the web stack facilitated the
	current state of affairs if we want to avoid the same thing
	happening again.

gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/the-soul-of-gopher.txt

	What is the "true spirit of gopher"?  Its "heart and soul", the
	deep, conceptual commitment which distinguishes it from other
	protocols, in particular from the web?

	...

	Now that we've uncovered the true spirit of gopher, the natural
	question, for those participating in the on-going discussions about
	new gopher-inspired protocols, is whether or not this idea is one
	that the gopher community really cherishes and which should be
	preserved in the Ultimate New Protocol of Truth and Glory.

	...

	... There's plenty of evidence out there that a lot of Gopher
	enthusiasts don't actually *want* a protocol that divides sharply
	between navigation and content.  They just want to be able to serve
	plain-text with hyperlinks anywhere they like, via a bare bones
	protocol that doesn't support tracking and other unpleasantries. 
	Something like "HTML with only the <a href> tag, over HTTP/0.1".  I
	think that's all *I* want.

gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/protocol-pondering-
intensifies-ii.txt

	In the previous post in this series[1] I compared request formats
	for gopher and HTTP and thought a bit about what a good anonymous
	document system actually needs.  I ended up deciding that the answer
	was nothing more than gopher already provides.  In this post I'll
	continue that discussion, focussing instead on the response format.

	...

	This protocol is not as simple as gopher, but I would argue its
	power to weight ratio is substantially greater.  ...

gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/protocol-pondering-
intensifies-iii.txt


	A standard gopher menu line looks like this:

	...

	An obvious update which could be made here is to take advantage of
	the fact that between now and gopher was first invented, URLs have
	been invented!  We don't need to specify the selector (path), host
	and port separately, we have a standard way to build that into one
	string, and every modern programming language has libraries for
	parsing/buiding them. ...

gopher://zaibatsu.circumlunar.space/0/~solderpunk/gemini/cold-blanketry.txt

	The Gemini project has attracted more attention in a short time
	frame than I expected, and on the whole the project is moving very
	fast!  It's quickly becoming apparent that not everybody is going to
	agree with everybody else about what the best path forward for the
	project is.  If things keep moving this fast, it's going to be very
	hard to keep building and maintaining consensus among the entire
	community.

	I understand that this seems kind of sad and kind of scary, but I
	think (and surely hope!) that it will be okay.

	The worst case scenario as I see it is that the Gemini project
	quickly descends into internal arguments, nobody can agree on
	anything and the whole thing fizzles out in a week.  If that
	happens, we've all still got gopher, which isn't going anywhere. ...

  If you have a rebuttle, fine, but "citation needed."

> The purpose of Gemini has always been crystal clear. 

  Yes, a new gopher.  Ahd simplicity of implementation for both client and
server.

> The
> spec has received only minor clarifications and has always come with the
> following promises:

  No.  The spec has received *major* changes and clarifications since it was
first written.  I've mentioned in other messages the differences from then
and now.  But saying it has only ever had "minor clarifications" is history
revisionism.

  -spc

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Sean Conner once stated:
> 
> > The purpose of Gemini has always been crystal clear. 
> 
>   Yes, a new gopher.  

  Upon reflection, I misspoke here.  Not a new gopher, but a new protocol
with a gopher feel.  It's not meant to replace gopher (nor the web).

> Ahd simplicity of implementation for both client and
> server.

  -spc

Link to individual message.

Drew DeVault <sir (a) cmpwn.com>

There's no doubt that Gemini draws inspiration from Gopher, but that's
not the matter at hand. I'm not going to rebuke your sources because
this question is not disputed.

The real question is whether not Gemini is or has ever been a playground
for Gophers to innovate on their hot new ideas in, and it most certainly
is not. Solderpunk has gone on record many, many times as disfavoring
extensibility. While the specification was under development, sure, it
changed quite a lot, but it has not undergone any major changes for some
time now. With his stance on non-extensibility, the lack of major
changes in well over a year, alongside statements like this in the
spec's introduction:

> Although not finalised yet, further changes to the specification are
> likely to be relatively small. You can write code to this
> pseudo-specification and be confident that it probably won't become
> totally non-functional due to massive changes next week, but you are
> still urged to keep an eye on ongoing development of the protocol and
> make changes as required.

It's pretty reasonable to assume that Gemini has entered its end-game
and it's not open to further innovations or experiments. Stating that it
is or has been is the historical revisionism to which I am referring.
Gemini has been quite obviously approaching its "done" stages for well
over a year.

If you don't agree, go ask Solderpunk yourself. He doesn't seem to enjoy
talking to this community anymore, though, for reasons quite apparent to
me.

Link to individual message.

Stephane Bortzmeyer <stephane (a) sources.org>

On Mon, Feb 22, 2021 at 07:16:26PM -0500,
 Sean Conner <sean at conman.org> wrote 
 a message of 178 lines which said:

> Gemini *is* an expansion of gopher, not
> a reimagining of the web.  Citing primary sources here (Solderpunk himself):
> 
> gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/pondering-whats-i
nbetween-gopher-and-the-web.txt
> 
> 	It's no secret, of course, that I love gopher.

While the historical debate is very interesting (I wasn't there, and I
love to learn about how things became what they are), it does not help
a lot with current discussions such as "should we extend Gemini with
this or that?" I guess (just a guess: no social scientist made a
serious survey of geminists yet) that most geminauts today never used
Gopher and even do not know about it. They want something better than
the Web for some usages and they do not refer to an old protocol.

Gemini faces a strategic issue: is it a system for a few Gopher
nostalgics or is it something that may be presented and promoted to a
wider audience? (No, I don't target "world domination".)

Link to individual message.

Stephane Bortzmeyer <stephane (a) sources.org>

On Mon, Feb 22, 2021 at 12:44:05PM -0800,
 Nathan Galt <mailinglists at ngalt.com> wrote 
 a message of 32 lines which said:

> Because Gemini complexity and browser diversity are fundamentally at
> odds with each other, and the Web already chose complexity at the
> cost of diversity, I?ve become much more against protocol/gemtext
> additions.

Simplicity and non-extensibility are core tenets of Gemini so I think
we all agree it is important to keep this target in sight. But I do
not think it means to reject everything without even considering
it. This would be a simple course of action, but it may deprive us of
useful things, and may hamper Gemini's adoption. I think we should
rather consider each proposal for its merits (and problems), keeping
in mind the criteria (which are sometimes non-explicit: for instance
the "only one network request" rule recently proposed by Solene was
not explicit in the specification).

Using as an example two recent discussions (favicons and metadata),
instead of dismissing them immediately, we could consider:


  support them (CSS would do: a Web client without CSS is not very
  useful, while a Web client without favicon support is certainly not
  a problem for user adoption)?

  for favicons and metadata, very little for those who adopt it)?

  do)?

Therefore, discussions on this list about new proposals are
reasonable, IMHO.

Link to individual message.

Stephane Bortzmeyer <stephane (a) sources.org>

On Mon, Feb 22, 2021 at 08:41:05PM -0500,
 Drew DeVault <sir at cmpwn.com> wrote 
 a message of 29 lines which said:

> If you don't agree, go ask Solderpunk yourself. He doesn't seem to
> enjoy talking to this community anymore, though, for reasons quite
> apparent to me.

I will not comment on personal issues (like most of us, I don't know
why he is now silent) but this is a problem for Gemini. The Benevolent
Dictator model has a lot of strengths (fast decision, consistency, no
bureaucracy and processes, ability to keep focused on a tough goal,
etc) but it requires the BD to act. If the BD is absent or silent,
this model turns into the Nobody In Charge, which is really bad,
because it does not allow to decide on touchy issues.

Link to individual message.

Nathan Galt <mailinglists (a) ngalt.com>



> On Feb 22, 2021, at 11:38 PM, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> On Mon, Feb 22, 2021 at 07:16:26PM -0500,
> Sean Conner <sean at conman.org> wrote 
> a message of 178 lines which said:
> 
>> Gemini *is* an expansion of gopher, not
>> a reimagining of the web.  Citing primary sources here (Solderpunk himself):
>> 
>> gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/pondering-whats-
inbetween-gopher-and-the-web.txt
>> 
>> 	It's no secret, of course, that I love gopher.
> 
> While the historical debate is very interesting (I wasn't there, and I
> love to learn about how things became what they are), it does not help
> a lot with current discussions such as "should we extend Gemini with
> this or that?" I guess (just a guess: no social scientist made a
> serious survey of geminists yet) that most geminauts today never used
> Gopher and even do not know about it. They want something better than
> the Web for some usages and they do not refer to an old protocol.
> 
> Gemini faces a strategic issue: is it a system for a few Gopher
> nostalgics or is it something that may be presented and promoted to a
> wider audience? (No, I don't target "world domination".)
> 

This assumes, of course, that Gemini isn?t fine the way it is.

I only used Gopher a tiny bit back when it was a contender, but every time 
I?ve looked at running a Gopher anything I?ve run away in disgust and fear 
from the hard-wrapped 80-column lines with the leftmost column taken up by 
line-type directives. I wouldn?t even know _how_ to write pages like that 
without going bonkers. Gemini, meanwhile, is _very_ familiar to someone 
who?s written HTML and Markdown: Write text files, upload via scp.

Sneering at Gopher fans isn?t particularly helpful here.

Link to individual message.

Nathan Galt <mailinglists (a) ngalt.com>



> On Feb 22, 2021, at 11:48 PM, Stephane Bortzmeyer <stephane at sources.org> wrote:
> 
> On Mon, Feb 22, 2021 at 12:44:05PM -0800,
> Nathan Galt <mailinglists at ngalt.com> wrote 
> a message of 32 lines which said:
> 
>> Because Gemini complexity and browser diversity are fundamentally at
>> odds with each other, and the Web already chose complexity at the
>> cost of diversity, I?ve become much more against protocol/gemtext
>> additions.
> 
> Simplicity and non-extensibility are core tenets of Gemini so I think
> we all agree it is important to keep this target in sight. But I do
> not think it means to reject everything without even considering
> it. This would be a simple course of action, but it may deprive us of
> useful things, and may hamper Gemini's adoption. I think we should
> rather consider each proposal for its merits (and problems), keeping
> in mind the criteria (which are sometimes non-explicit: for instance
> the "only one network request" rule recently proposed by Solene was
> not explicit in the specification).
> 
> Using as an example two recent discussions (favicons and metadata),
> instead of dismissing them immediately, we could consider:
> 
> * do they add to the network budget (favicons do)?
> * do they facilitate fingerprinting (favicons do, metadada don't)?
> * is there a risk they add a pressure on non-willing clients to
>  support them (CSS would do: a Web client without CSS is not very
>  useful, while a Web client without favicon support is certainly not
>  a problem for user adoption)?
> * what level of complexity do they add (none in non-willing clients,
>  for favicons and metadata, very little for those who adopt it)?
> * do they degrade gracefully for non-willing clients (both proposals
>  do)?
> 
> Therefore, discussions on this list about new proposals are
> reasonable, IMHO.
> 

You?re only looking at the current metadata proposals, though, and not 
extrapolating out what sort of extensibility metadata brings. Once some 
capsules start using metadata that?s only usable in some clients, those 
capsules will have an implicit Best Viewed In Gemini Client X label stuck 
to them. The Best Viewed In Browser X era of the Web is _not_ something I 
want replicated in Gemini.

Because I?m already strongly in favor of making it easy to make a good 
Gemini client, I?m against proposals that could, down the line, increase 
the amount of work that it?d take to make a good, full-featured Gemini 
client. Arbitrary-metadata proposals are a fully general can of worms 
that, say, double-digit status codes aren?t.

Link to individual message.

avr@geminet.org <avr (a) geminet.org>

On Tue, Feb 23, 2021 at 08:53:30AM +0100, Stephane Bortzmeyer wrote:
> On Mon, Feb 22, 2021 at 08:41:05PM -0500,
>  Drew DeVault <sir at cmpwn.com> wrote 
>  a message of 29 lines which said:
> 
> > If you don't agree, go ask Solderpunk yourself. He doesn't seem to
> > enjoy talking to this community anymore, though, for reasons quite
> > apparent to me.
> 
> I will not comment on personal issues (like most of us, I don't know
> why he is now silent) but this is a problem for Gemini. The Benevolent
> Dictator model has a lot of strengths (fast decision, consistency, no
> bureaucracy and processes, ability to keep focused on a tough goal,
> etc) but it requires the BD to act. If the BD is absent or silent,
> this model turns into the Nobody In Charge, which is really bad,
> because it does not allow to decide on touchy issues.

I don't think BDFL is a single role and it depends on the nature of the 
project. If you compare a spec's BD to a BD for a large project with lots 
of churn (Linus) or a programming language (Guido), it might seem slow, but
I'm unsure if such different projects can be directly compared.

How Gemini's BD tends to chime in after pondering and waiting for moods to 
settle, and then  explain his process of thought in a clear, calm way that makes 
any camps in a disagreement feel like they've been heard is quite exceptional.

I think "Let's rebuild the web, but better!" is a common last refrain
of parties that involve alcohol and have hackers present. Gemini
is an outlier here in that it actually seems to be happening.

In short, I don't think absence or silence is really a negative 
in these situations, and should be seen more as a sign of deliberation 
than negligence.

Link to individual message.

John Cowan <cowan (a) ccil.org>

On Tue, Feb 23, 2021 at 4:59 AM Nathan Galt <mailinglists at ngalt.com> wrote:


> Once some capsules start using metadata that?s only usable in some
> clients, those capsules will have an implicit Best Viewed In Gemini Client
> X label stuck to them. The Best Viewed In Browser X era of the Web is _not_
> something I want replicated in Gemini.
>

We are already there.

For example, a capsule that contains text/plain files can be rendered in
some clients but not all, or at least a conformant Gemini client can be
written that can't cope with text/plain.  The same applies to all other
media types, because media types are extensible.

What is more, a capsule that links to Gopher menus or documents is most
easily read using a client that supports either Gopher protocol natively or
an outboard Gopher proxy.  That's because of the extensibility of the
Internet protocol suite.

The issue that arose with "works best in browser X" was presentational:
some web pages looked good (for particular values of "good") in browser X
but not so good in browser Y.  That changed when browsers started to
include a JavaScript engine, and it became also a matter of what pages
would even *work* in browser Y at all.  But we are far from that precipice
now.

Fortunately, we have general agreement that there will be no *standardized*
presentational markup in text/gemini.  But it's still possible to write a
client that interprets a line beginning with "***" by rendering it in
italics, and we can't stop that, nor can we stop it from spreading to other
clients, or authors starting to use it.  That's because of the
extensibility of the interpretation of plain-ish text.

The only way to avoid all this is a WHATWG-ish standard in which everything
a client can do is spelled out in excruciating detail, and whatever is not
permitted is forbidden.  I think it is 100% unlikely that we will ever go
there.

Because I?m already strongly in favor of making it easy to make a good
> Gemini client, I?m against proposals that could, down the line, increase
> the amount of work that it?d take to make a good, full-featured Gemini
> client. Arbitrary-metadata proposals are a fully general can of worms that,
> say, double-digit status codes aren?t.


You can abuse metadata, but as I have demonstrated above, you can also
abuse existing content, and one is no worse than the other.  A metadata FAQ
would say that clients can convert the values of metadata lines from
machine-readable to human-readable (from "Jefferson, Thomas" to "Thomas
Jefferson", for example, or even from "Waldo, Edward Hamilton" to "Theodore
Sturgeon") but a metadata line should otherwise be treated like a text line.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
The present impossibility of giving a scientific explanation is no proof
that there is no scientific explanation. The unexplained is not to be
identified with the unexplainable, and the strange and extraordinary
nature of a fact is not a justification for attributing it to powers
above nature.  --The Catholic Encyclopedia, s.v. "telepathy" (1913)

Link to individual message.

Stephane Bortzmeyer <stephane (a) sources.org>

On Wed, Feb 24, 2021 at 08:20:14PM -0500,
 John Cowan <cowan at ccil.org> wrote 
 a message of 161 lines which said:

> But it's still possible to write a client that interprets a line
> beginning with "***" by rendering it in italics, and we can't stop
> that, nor can we stop it from spreading to other clients, or authors
> starting to use it.  That's because of the extensibility of the
> interpretation of plain-ish text.

> The only way to avoid all this is a WHATWG-ish standard in which
> everything a client can do is spelled out in excruciating detail,
> and whatever is not permitted is forbidden.  I think it is 100%
> unlikely that we will ever go there.

There is another way, which is not 100%-foolprof (but, then, nothing
is), it's to show users that we care about extensions requests and do
not dismiss them automatically. If we clearly say why this extension
is a bad idea, it will be easier to exercice social pressure against
those who use it. If, on the other hand, we are closed to every
discussion, people will, as you notice, do it anyway, and badly.

It is also a matter of outreach: clearly documenting the "Gemini way"
and making it wildly accessible (the FAQ already does a good job).

Link to individual message.

---

Previous Thread: [SPEC] Users actions should only trigger an unique request

Next Thread: [ANN] Hello from filter.id.au