Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove favicon support #199

Closed
ddevault opened this issue Feb 20, 2021 · 18 comments
Closed

Remove favicon support #199

ddevault opened this issue Feb 20, 2021 · 18 comments
Labels
roadmap A user-facing feature on the roadmap.
Milestone

Comments

@ddevault
Copy link

ddevault commented Feb 20, 2021

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.

@makew0rld
Copy link
Owner

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
Copy link
Author

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.

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.

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.

@makew0rld

This comment has been minimized.

@makew0rld makew0rld changed the title favicons: NACK Remove favicon support Feb 20, 2021
@makew0rld makew0rld modified the milestone: v1.9.0 Feb 20, 2021
@makew0rld
Copy link
Owner

makew0rld commented Feb 21, 2021

@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
Copy link

takaoni commented Feb 21, 2021

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
Copy link

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
Copy link

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
Copy link
Author

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.

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.

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.

@makew0rld
Copy link
Owner

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
Copy link
Author

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
Copy link

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
Copy link
Contributor

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
Copy link

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.

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.

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
Copy link
Author

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
Copy link

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.

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
Copy link
Author

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

@makew0rld
Copy link
Owner

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.

@makew0rld
Copy link
Owner

makew0rld commented Feb 22, 2021

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.

@makew0rld makew0rld added the roadmap A user-facing feature on the roadmap. label Feb 22, 2021
@makew0rld makew0rld added this to the v1.9.0 milestone Feb 22, 2021
lovetocode999 added a commit to lovetocode999/amfora-favicons that referenced this issue Feb 24, 2021
lovetocode999 added a commit to lovetocode999/amfora-favicons that referenced this issue Mar 6, 2021
aaronpk pushed a commit to indieweb/wiki that referenced this issue Sep 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
roadmap A user-facing feature on the roadmap.
Projects
None yet
Development

No branches or pull requests

6 participants