💾 Archived View for oppen.digital › memex › 20210711 captured on 2022-01-08 at 14:04:10. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

On Sourcehut

People keep asking me why I moved off Sourcehut and why I don't recommend using the service, so I'm posting this here so I don't need to waste any more breathe (bytes, bandwidth) on the matter. I'll refrain from commenting on other incidents, or using any emotive language, I'm not interested in a witchhunt, so with that in mind here's some basic facts and quotes:

Another Gemini browser briefly implemented support for a Gemini proposal where capsules have favicons, Drew reacted to this by opening a ticket on Amfora's Git repository threatening to blackhole any ip address requesting a favicon:

Drew's ticket on Amfora's Git repository

Sourcehut has the ability to host Gemini capsules, what Drew was threatening here was to block access to his paying customers capsules if people tried to access them using a browser that had implemented the favicon proposal. His comments on the above ticket are worth paying close attention to.

Drew on Signal

Here's Drew a few months later discussing Signal, presented without comment:

Moxie’s insistence on centralized ownership, governance, and servers for Signal puts him in a position of power which is easily, and inevitably, abused.

Archive of the ticket

Remove favicon support #199

Closed

ddevault opened this issue on 20 Feb · 18 comments

Closed

Remove favicon support

199

ddevault opened this issue on 20 Feb · 18 comments

Comments

@ddevault

ddevault commented on 20 Feb •

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.

@makeworld-the-better-one

Owner

makeworld-the-better-one commented on 20 Feb

While in general I agree that Gemini should be one request, I simply like the favicon idea. I think it is fun and harmless.

I have tried to make the feature as unobtrusive as possible on the server end. It is off by default, and will only request the favicon once per session, excepting reloads. If your server doesn't have a favicon, it will remember that for the session and not ask for it again.

I might update my server software to automatically blackhole any IP address which tries to request a favicon file.

I feel like this would be quite an aggressive response and ultimately detrimental to the Gemini ecosystem as a whole. I'd appreciate if we discussed more before you made any decisions like that.

While I understand your ideological opposition to favicons, I fail to see how whether people use them or not would actually affect your hardware in a meaningful way. I don't think users should be punished for harmless behaviour.

@ddevault

Author

ddevault commented on 20 Feb

I think it is fun and harmless.

This is how we end up reinventing the web. Everyone else has a different feature that they think is "fun and harmless". Where you think marquee came from?

The golden rule of Gemini is: do not extend the spec.

Not good enough. If someone can turn it on, someone will ask for it in another client, and the feature will proliferate and settle into the ecosystem permanently. Rinse and repeat for the next "fun and harmless" feature for the next 20 years and someone will be inventing a new small internet protocol all over again.

I feel like this would be quite an aggressive response and ultimately detrimental to the Gemini ecosystem as a whole. I'd appreciate if we discussed more before you made any decisions like that.

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.

@makeworld-the-better-one

This comment has been hidden.

@makeworld-the-better-one makeworld-the-better-one changed the title favicons: NACK Remove favicon support on 20 Feb

@makeworld-the-better-one makeworld-the-better-one modified the milestone: v1.9.0 on 20 Feb

@makeworld-the-better-one

Owner

makeworld-the-better-one commented on 21 Feb •

@ddevault Whatever decision is made, I request that as a common courtesy you give me week's notice or more if you intend to begin blackholing IP addresses. It is unfair to users to not allow them to access all the pages of your capsules, forever, with no method of appealing or undoing the block.

I wish to serve myself and Gemini users at-large with Amfora. Giving me that week's notice will allow me to make decisions to continue serving them. Thank you.

@takaoni

takaoni commented on 21 Feb

I am deeply shocked to see such behavior. @ddevault Threats are not an acceptable way to gain acceptance of one's ideas and I hope that the consequences to come will make you understand that respect is part of the minimum requirement for interacting with other people.

Personally, I don't use this feature but if the protocol allows it then there is no reason to be against it IMHO, and if there is a grey zone in the specs, let's just work on it, as proposed by Solene on the mailing list.

Anyway, thank you @makeworld-the-better-one for your work on Amfora. I can't wait to see the next features to come.

@tobykurien

tobykurien commented on 21 Feb

An alternative suggestion: if the first level 1 title of the homepage starts with a unicode character, use that as a favicon? e.g.

🐈 I am a cat

Welcome to my capsule...

This avoids an extra request.

@mcorossigo

mcorossigo commented on 21 Feb

If I may express my opinion, without entering into the merit of the tone of discussion, I think the very premise of this issue is wrong.

Every gemini page shall complete in a single gemini request.

It does. The favicon is not part the gemini page, is has no involvement in the rendering process and does not change it's content. Unlike html pages, gemini pages cannot link or ask for specific favicons.

It's a "property" of the server like the robots.txt (gemini://gemini.circumlunar.space/docs/companion/robots.gmi).

Because of this the favicon request should not be accounted in the per-page request count, that remains one.

Favicon is an helpful navigational aid and visual clue when using tabs (in the amfora specific case), and I whould like the feature to stay.

What @tobykurien describe is completely different and, as far as I know, it's something that's pretty frowned upon in the mailing list, for good reasons too.

I might update my server software to automatically blackhole any IP address which tries to request a favicon file.

I mean, I hope this is some sort of misunderstanding because this enter quite a bit in the realm of childishness, and can be easily circumvented by any sort of blacklist-like config entry in amfora config.

I have not followed the mailing list nor the IRC channels in the last couple days, so if I've missed some developement about this, I'm sorry.

@ddevault

Author

ddevault commented on 21 Feb

Whatever decision is made, I request that as a common courtesy you give me week's notice or more if you intend to begin blackholing IP addresses. It is unfair to users to not allow them to access all the pages of your capsules, forever, with no method of appealing or undoing the block.

Of course. I'd even go longer, like 30 or 90 days. The intention isn't to pull the rug out from under users. It's to provide a pressure to correct bad behavior. But since you've agreed to remove it, there's no need to make an ultimatum at all, you can take your time with the next release and don't feel the need to rush it to ship this change.

It's the only form of regulation we've got, and I'm prepared to use it to preserve Gemini for what it is, and not for what web users think it should be. Get used to it.

Favicon is an helpful navigational aid and visual clue when using tabs (in the amfora specific case), and I whould like the feature to stay.

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.

@makeworld-the-better-one

Owner

makeworld-the-better-one commented on 21 Feb

Of course. I'd even go longer, like 30 or 90 days.

Thank you.

since you've agreed to remove it

I've taken this back. Sorry to be going back and forth, but as I mentioned on the mailing list, I'd like to make the decision that feels right to me, once and for all. And I'm more inclined to leave it in. I will mention any final decision here.

@ddevault

Author

ddevault commented on 21 Feb

Okay. Remember: what feels important to you doesn't feel important to someone else, and what feels important to them doesn't feel important to you. What matters is that we all resist the temptation to first embrace, then extend Gemini, lest we ultimately extinguish it as well.

@tobykurien

tobykurien commented on 22 Feb

Why would adding an emoji in a page title be frowned upon @mcorossigo ? As I see it, this isn't different to how gmisub/Lagrange can use links with dates in them as if they are RSS feed items. It is non-extensible, doesn't need to be an official spec, doesn't interfere with page rendering, is backwards compatible, doesn't add a new page request, and is a natural way of expressing your favicon anyway.

@sotpapathe

Contributor

sotpapathe commented on 22 Feb

I will keep using and contributing to amfora no matter what the decision about favicons is.

That being said, I tend to agree with @ddevault on this (though not on the way he phrased his concerns). I think extending gemini should only be done through changes to the spec after open discussion in order to not end up with incompatible clients and servers and a bloated protocol. The current simplicity of gemini and its one-request-per-page are important qualities in my opinion. I will keep favicons disabled and leave it up to @makeworld-the-better-one to make the decision on their removal.

I kinda like the color from the domain hash some of the GUI clients have implemented. As a middle ground between this and favicons, why not select the favicon emoji based on the hash of the domain name? No extra requests and I think it's closer to the gemini philosophy where presentation and style is left to the client.

I just hope such discussions are made with a cooler head in the future.

@mcorossigo

mcorossigo commented on 22 Feb

Why would adding an emoji in a page title be frowned upon @mcorossigo ?

I'm not sure really. Reading the mailing list I noticed a lot of zealotry against attributing any kind of special semantic to pretty much anything. Tha main argument being to protect from proliferation of features. I think it is a pretty weak argument, along the lines of "I prefer starving to death instead of eating because of the slight change I get fat".

Anyway, you can put whaterver you want in the title, having it being interpreted in a semantic comparable to the one of a favicon is the problem.

If I want to visit the favicon.txt file on all servers I find by manually typing the address, I can do it. Why the client, which is in all aspects acting on my behalf, should not do the same if I specifically ask it to (by switching on the config)?

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.

The point is not to find an alternative to favicon but whether the favicon as implemented in amfora should stay.

And I think yes, it should.

As a capsule owner, I don't like the hash-color solution at all, I like to choose what and how the user see the content I create in the way I indeded it to be seen, even the favicon.

I think extending gemini should only be done through changes to the spec after open discussion in order to not end up with incompatible clients and servers and a bloated protocol. The current simplicity of gemini and its one-request-per-page are important qualities in my opinion.

Bloated is once again a pretty inflated word. The way a client look for a specific file (favicon.txt) is not a protocol issue, because I can manually look for it if I want. It's an application convention. And the one-request-per-page thing is not part of the spec, so technically by enforcing it you are bloating the gemini specification. See, what is a bloat for a man is.. I don't know.. not bloat for another.

@ddevault

Author

ddevault commented on 22 Feb

Anyway, you can put whaterver you want in the title, having it being interpreted in a semantic comparable to the one of a favicon is the problem.

Another benefit of this is that it already just works with all clients without any changes. Any client which displays the first heading as the title of the page will naturally display any emoji which is included there. Thus it's already within the realm of the specified behaviors of Gemini without extending anything at all. If Amfora so wishes, it could detect this title format and hide the generated icon in this case.

As a capsule owner, I don't like the hash-color solution at all, I like to choose what and how the user see the content I create in the way I indeded it to be seen, even the favicon.

Then you don't understand Gemini. Gemini strictly separates the roles of content and presentation to the server and client respectively. It's not your place to specify how your content is presented in Gemini. Go use the web if you want that.

@mcorossigo

mcorossigo commented on 22 Feb

The favicon (in a similar fashion of robots.txt) is not a property of the page, but of the host, that's why it has to be look at the root. Having to add it in every single title or not at all, (or even worst only sometimes) nullify any value the favicon has.

Gemini strictly separates the roles of content and presentation to the server and client respectively

Maybe I worded it badly, but the favicon presentation is a contenutistic issue, not a stylistic one.

Go use the web if you want that.

As someone very eloquently wrote on the mailing list:

Seriously, who put Drew in charge?

https://lists.orbitalfox.eu/archives/gemini/2021/005384.html

It's not really your job to gatekeep now, is it?

@ddevault

Author

ddevault commented on 22 Feb

Yes, I am in charge of my own projects. News at 11.

@makeworld-the-better-one

Owner

makeworld-the-better-one commented on 22 Feb

Please keep this thread for Amfora-specific discussion. If you would like to discuss favicons in general, use the mailing list or email each other privately.

@makeworld-the-better-one

Owner

makeworld-the-better-one commented on 22 Feb •

I will be removing favicon support in Amfora.

I still think they are fun and mostly harmless. But I really understand the value in the one-request-per-page idea, and how automatic external requests go against the Gemini philosophy. And the idea that certain Amfora users could be singled out and identified by this also quite bothers me.

Also, while the favicon RFC is the most harmless additional feature to Gemini I can think of, I still believe that any additional feature should need strong motivations, once beyond the experimental phase. The RFC by mozz was published 264 days ago, so I would say the experimental period is over. The motivation section of that document is still empty. And there's nothing wrong with that! But it indicates to me that there isn't a strong reason to continue to support it.

Favicon is an helpful navigational aid and visual clue when using tabs (in the amfora specific case), and I whould like the feature to stay.

I agree. But I have been meaning to fix this anyway for a while, by adding things other than numbers to tabs - the domain, the page title, etc. Edit: See #202

I will not be auto generating emojis from domains or anything like that, as I think for the time being that could get confusing with the previous favicon support. Emojis also hold emotional meaning in a way that color schemes or randomized icons don't.

Finally, I still resent @ddevault opening this discussion with a threat. It created drama and complicated the discussion. It also made this choice more difficult, because I do not want this decision to be reduced as simply conceding to the threat. Please refrain from "putting the stick on the table upfront", as you say, in the future.

@makeworld-the-better-one makeworld-the-better-one added the roadmap label on 22 Feb

@makeworld-the-better-one makeworld-the-better-one added this to the v1.9.0 milestone on 22 Feb

@makeworld-the-better-one makeworld-the-better-one closed this in 180d108 on 22 Feb