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
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
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:
gemini://gemi.dev/gemini-mailing-list/messages/003509.gmi
(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:
gemini://gemi.dev/gemini-mailing-list/messages/003506.gmi
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.
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: gemini://gemi.dev/gemini-mailing-list/messages/003506.gmi Seriously, who put Drew in charge? -spc
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
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
> > 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
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: gemini://gemi.dev/gemini-mailing-list/messages/000612.gmi gemini://gemi.dev/gemini-mailing-list/messages/001060.gmi
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
> 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?
> 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?
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: ? ```
> 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?
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: gemini://gemi.dev/gemini-mailing-list/messages/003160.gmi This was added to the spec shortly thereafter. I also made a statement regarding robots.txt: gemini://gemi.dev/gemini-mailing-list/messages/003506.gmi 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.
> 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?
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
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) ?
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.
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)
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210222/c7fa
69cf/attachment.htm>
> 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)
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
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
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.
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".)
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:
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.
> 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.
> 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.
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.
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) -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210224/54e0 5a0a/attachment.htm>
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).
---
Previous Thread: [SPEC] Users actions should only trigger an unique request