gemini - kennedy.gemi.dev

I think some sites have a /favicon.txt if you go looking, but I'm not sure which clients support checking it (maybe none?). It would be pretty simple to add a feature to manually fetch the favicon if the user wants to, but it doesn't seem like a super valuable feature to implement.

@skyjake You're right. I forgot about that feature. I added the option to the poll and will keep it up to see, how people think about these kind of topics.

👤 AnoikisNomads

@skyjake: a few do, yes. there definitely is no value in it, only individuality. both amfora and deedum don't recognize them. one of the aggregators did though, forgot which one

(The poll thread seems to generate a torrent of notifications. I've already fixed many of these duplicate notifications for the next version of Bubble.)

@AnoikisNomads @skyjake Two years ago, there was a pretty tense argument about removing favicon support from Amfora (https://github.com/makew0rld/amfora/issues/199).

On top of the "soft violation" of the spec, some people don't like to see a torrent of `51 Not found` in their logs, if they don't use favicons.txt.

🌝 ttocsneb

This may be better as a new thread, but I wonder if it would work to have a favicon, but stored in DNS in say a TXT record.

Thinking a bit more, it seems like it wouldn't work for those who don't have access to DNS.

I just think favicons are nice and people should use them. Grumpy Drew, so committed to upholding the Spirit of Gemini by any means necessary, has left gemini.

Whether involves another request or it is simply an emoji in the title heading, we should pick something. Something that doesn't cause ugliness when clients don't support it, something that is absolutely optional for all parties involved.

— kennedy.gemi.dev/observatory/known-hosts

@ttocsneb It's still a second request. You could also add the favicon URL to the reply for a page:

20 "text/gemini;lang=en-US;favicon=🚀"

☕️ mozz

Kennedy will fetch favicons and display them next to the site's domain name. To give you an idea of how common they are, here's the full list:

@michaelnordmeyer That's a cool idea but has its own downsides, it really feel like including favicons in the response as a key/value pair is an extension of the spec that clients and server devs would have to both know about, and that's not going to happen.

Other options are more informal things that can be implemented on the fly.

(edited)

@satch Given that the Gemini spec thrives to leave out anything unnecessary, a favicon won't make it into the spec, AFAICT. I just wanted to show a simple means, were you could also have favicons for different subareas for your capsule.

Implementation-wise, I think most clients would ignore an unknown key in that key/value list. But again, this is probabaly considered as feature creep.

I think you misunderstood me; I know that favicons won't make it into the spec and frankly agree with that.

That's why I think the favicon in the key/value list is probably not going to be implemented anywhere. /favicon.txt or a emoji in the text header is different because it can be done causually and people can bookmark your page using your recommended icon if they want.

I think that the most spec-compliant option is just to include a favicon as the first character in the first top-level heading on a page. That way it does its job whether or not the client has favicon support, and there's no pressure.

👻 sirwilburthefirst

My opinion:

- I think preserving 1 request per page is a good idea. It keeps things simple. It feels like a slippery slope if we start making exceptions to this rule.

- Messing with the mime type seems brittle to me. A lot of software uses mime types as a key. Extending that might break things.

- I like some of the ideas like using the emoji at the start of the title. That feels like in the spirit of Gemini to me.

- Do whatever you want, Lagrange is your browser :)

🐵 cquenelle

How about this: If the top level page on the site has a title at the start of the page, and the title starts with a single non-alpha-numeric character then use that character for the site icon. The browser would only know what it was if the user chose to go to the top level page. No fair loading it automatically. But if it was known it would apply to all the pages. I do notice that Geminispace.org seems to have two leading symbols. Which looks like both layers (site style and browser) are both trying to add the same style feature.

2023-05-23 · 2 months ago

@cquenelle i like this

☕️ Morgan

For what it's worth; lack of favicon support is my only, very minor, complaint about the gemini protocol.

clanmorgan.org does serve favicon.txt, I like how it looks if you use that for the site icon, and it's mildly frustrating that others mostly won't see it like that.

But! I'm not sure it's nearly important enough to be worth "fixing". Maybe it's even helpful to keep a minor feature that people want unimplemented, as a "line in the sand".

I voted "only if I can have one hardcoded too", though. What can I say, it would look cool.

2023-05-24 · 2 months ago

@Morgan People love their favicons dearly. Me too. But it also goes against the-client-styles-the-content-not-the-server. After asking for a personal favicon, people will ask for a certain color for their site to be applied by Lagrange. ¯\(ツ)/¯

@Morgan:

I like how it looks if you use that for the site icon, and it's mildly frustrating that others mostly won't see it like that.

The thing about Gemini is that clients have free reign on how content is presented (within the confines of the spec), so one should try to accept that it's futile to control and/or influence the visual appearance of one's capsule as seen by others.

I think it's great that everyone gets to choose these things privately for themselves. Tastes and preferences vary, after all.

@michaelnordmeyer

a certain color for their site to be applied by Lagrange

You can already switch color themes via Lagrange's site-specific settings, privately for yourself, of course. 🙂

(Page Information > Settings)

☕️ Morgan

Thanks @skyjake!

I totally agree with that point of view while finding it not particularly satisfying, mostly because it seems unlikely that people actually will pick and assign site icons. In Langrange for example I think they are very likely to stick with the pseudo-random default.

I don't really have a better suggestion.

I can imagine UI where you hover over the site icon and get choices: "randomize", "customize", "check for favicon.txt". But I don't think it would get much use, either.

I think what we have today works fine.