~adnano/gemini

17 12

[tech] [spec] On extending gemini

Details
Message ID
<CAFTy05bJcAAS_CFt=52cEk_cCPUrKM2HNQqfx8Nq2qiJeXdUQw@mail.gmail.com>
DKIM signature
missing
Download raw message
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
*can* be those things if we want to be.

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
Details
Message ID
<ce50f2ba-d732-945b-112f-ff35cc7ca9fd@protonmail.com>
In-Reply-To
<CAFTy05bJcAAS_CFt=52cEk_cCPUrKM2HNQqfx8Nq2qiJeXdUQw@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message
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
Sean Conner <sean@conman.org>
Details
Message ID
<20210221064948.GD9315@brevard.conman.org>
In-Reply-To
<CAFTy05bJcAAS_CFt=52cEk_cCPUrKM2HNQqfx8Nq2qiJeXdUQw@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message
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.
Sean Conner <sean@conman.org>
Details
Message ID
<20210221070442.GE9315@brevard.conman.org>
In-Reply-To
<ce50f2ba-d732-945b-112f-ff35cc7ca9fd@protonmail.com> (view parent)
DKIM signature
missing
Download raw message
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
Details
Message ID
<20210221105940.23x5olavgcvvurde@blueberry>
In-Reply-To
<CAFTy05bJcAAS_CFt=52cEk_cCPUrKM2HNQqfx8Nq2qiJeXdUQw@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message
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
Details
Message ID
<3ae295f3-26a9-2ea3-47fd-cab4cc01174f@NorthTech.US>
In-Reply-To
<20210221070442.GE9315@brevard.conman.org> (view parent)
DKIM signature
missing
Download raw message
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
Miguel de Luis Espinosa <enteka@fastmail.com>
Details
Message ID
<b70302ca-fdd0-44f2-9e5a-2924f869ec8e@www.fastmail.com>
In-Reply-To
<3ae295f3-26a9-2ea3-47fd-cab4cc01174f@NorthTech.US> (view parent)
DKIM signature
missing
Download raw message
> 
> 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
Details
Message ID
<20210221165722.GA6374@host>
In-Reply-To
<CAFTy05bJcAAS_CFt=52cEk_cCPUrKM2HNQqfx8Nq2qiJeXdUQw@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message
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
Details
Message ID
<20210222113041.ccmvtyzqyimwgen3@softwarelibre.nl>
In-Reply-To
<CAFTy05bJcAAS_CFt=52cEk_cCPUrKM2HNQqfx8Nq2qiJeXdUQw@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message
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
Details
Message ID
<6599D540-F199-4A59-A908-1955D7D50051@gmail.com>
In-Reply-To
<CAFTy05bJcAAS_CFt=52cEk_cCPUrKM2HNQqfx8Nq2qiJeXdUQw@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message

> 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?
Details
Message ID
<995AC189-7222-4983-A0BA-0ECDB5BA48E7@gmail.com>
In-Reply-To
<CAFTy05bJcAAS_CFt=52cEk_cCPUrKM2HNQqfx8Nq2qiJeXdUQw@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message

> 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?
Details
Message ID
<CAFkF85ZCK6yEWyxW14c-QYhni5MAqsZS0HLAhJK6xRB2CQhu6w@mail.gmail.com>
In-Reply-To
<6599D540-F199-4A59-A908-1955D7D50051@gmail.com> (view parent)
DKIM signature
missing
Download raw message
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: ?
```
Details
Message ID
<F6AD36B7-841E-40F0-9FFE-A45D84ECA343@gmail.com>
In-Reply-To
<CAFkF85ZCK6yEWyxW14c-QYhni5MAqsZS0HLAhJK6xRB2CQhu6w@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message

> 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?
Details
Message ID
<7BC32EC0-EE33-4A76-8737-58908E06886A@ngalt.com>
In-Reply-To
<CAFTy05bJcAAS_CFt=52cEk_cCPUrKM2HNQqfx8Nq2qiJeXdUQw@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message
> 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)
Stephane Bortzmeyer <stephane@sources.org>
Details
Message ID
<20210223074812.GD1341@sources.org>
In-Reply-To
<7BC32EC0-EE33-4A76-8737-58908E06886A@ngalt.com> (view parent)
DKIM signature
missing
Download raw message
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.
Details
Message ID
<8AB4747B-8159-42B9-BFCA-C9802C8D2A79@ngalt.com>
In-Reply-To
<20210223074812.GD1341@sources.org> (view parent)
DKIM signature
missing
Download raw message

> 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.
John Cowan <cowan@ccil.org>
Details
Message ID
<CAD2gp_RYt3KpECUzOhUqxUXZbN-cxQkEhtbvh947QxxpRfO9eg@mail.gmail.com>
In-Reply-To
<8AB4747B-8159-42B9-BFCA-C9802C8D2A79@ngalt.com> (view parent)
DKIM signature
missing
Download raw message
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)
Stephane Bortzmeyer <stephane@sources.org>
Details
Message ID
<20210226104145.GA5200@sources.org>
In-Reply-To
<CAD2gp_RYt3KpECUzOhUqxUXZbN-cxQkEhtbvh947QxxpRfO9eg@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message
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).
Reply to thread Export thread (mbox)