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
Comments
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 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. |
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 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.
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 comment has been minimized.
This comment has been minimized.
@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. |
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. |
An alternative suggestion: if the first level 1 title of the homepage starts with a unicode character, use that as a favicon? e.g.
This avoids an extra request. |
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.
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. 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 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. |
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.
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. |
Thank you.
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. |
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. |
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. |
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. |
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". 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)?
The point is not to find an alternative to favicon but whether the favicon as implemented in amfora should stay. 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.
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. |
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.
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. |
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.
Maybe I worded it badly, but the favicon presentation is a contenutistic issue, not a stylistic one.
As someone very eloquently wrote on the mailing list:
https://lists.orbitalfox.eu/archives/gemini/2021/005384.html It's not really your job to gatekeep now, is it? |
Yes, I am in charge of my own projects. News at 11. |
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. |
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.
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. |
…amics, tone: makew0rld/amfora#199" to "See Also"
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.
The text was updated successfully, but these errors were encountered: