lagrange
lagrange copied to clipboard
skyjake
Add favicon capability
It would be nice if lagrange loaded /favicon.txt and presented it in the page top and bookmarks tab.
There is a specification for it here:
gemini://mozz.us/files/rfc_gemini_favicon.gmi
I won't add an automatic favicon fetch because that goes against the design of Gemini IMO, but I suppose this could be a manual context menu item in the bookmarks list. It would then prevent the default behavior of a random icon being selected for that bookmark.
When adding a bookmark it could also provide a button for fetching the site favicon, if the user wants to check for one.
I understand, and I am myself a bit ambivalent about it. But as the icon is just one unicode character I think it suits gemini. Your suggested approach sounds good.
I won't add an automatic favicon fetch because that goes against the design of Gemini IMO
This is very true. It's simple but it's a second request that's not user initiated. I don't think we have the same level of threat from it as http does with the favicon supercookies, but it is clearly a bolt-on that attempts to expand the spec. It should be aggressively fought against as default behavior.
Let the user decide, no icon, random icon (default and only choice now in Lagrange), or capsule icon. And why not implement it in a way so no redirects is allowed, only accept capsule:/favicon.txt I find the random icon quite annoying, as it changes the capsules intended view. Maybe I don't want a random chair/heart/toilet/hat as my logo on my capsule.
A less automatic solution would be fine.
Maybe adding a button in bookmark edit dialog : [ Fetch favicon.txt ]. It will attempt to grab the /favicon.txt from capsule and replace old (or predefined) one.
Edit : realize it is exactly what you propose @skyjake :+1:
f79e6735864a16c20d0ed0cc9d79c8c20aeb4816 puts you in full control of the bookmark/site icons.
And by this I mean that you get to manually set the icon to whatever Unicode character you want to use.
In light of recent discussions on the Gemini mailing list, it remains to be seen whether I'll add any further features to fetch server-defined icons. However, for now you will be able to do it manually by opening the gemini://some.site/favicon.txt and copypasting the character from there to the bookmark edit dialog.
IMO it is better to allow the user to choose which icon they want to use for a site, based on what meanings and connotations they ascribe to a particular symbol.
A few more notes about supporting favicons.
- Lagrange doesn't have a cache of site-specific data. This would be required so favicons are not re-fetched on every visit. Adding such a cache is a considerable time investment, and it would need more than favicons to make that a sensible undertaking (e.g., adding user's site-specific theming choices).
- The top banner needs to display the icon, but what should be done before the favicon request completes? a) Delay displaying the page, or b) swap in the "real" icon once it has been fetched? Neither option is great.
This is a lot of complexity that is not really justified by the value added by server-provided favicons.
As there are objections overall to favicons, a context menu item in the bookmark list should be good enough, like "Fetch favicon". When it is clicked a redraw can be done. Cache seems overkill for gemini.
cache would still be needed as I understand it, as the favicon will be lost next time you reopen bookmarks sidebar or restart browser
cache would still be needed as I understand it, as the favicon will be lost next time you reopen bookmarks sidebar or restart browser
The favicon is stored in bookmarks.txt as a codepoint value.
To clarify my previous comment, it was about implementing favcions the "web" way, where they would appear seamlessly without the user bookmarking anything. One can argue this is what a capsule owner expects to happen when they put up a favicon.txt.
Treating them as a suggested/default bookmark icon is quite a bit simpler to implement because a) Lagrange already supports customized bookmark icons (no additional caching needed), and b) the fetching can be done when requested or when the bookmark is created.
So my first comment pretty much still applies.
@jazei-AR: The risk should be no more than the gmi-request in the first place, as the URI would be hardcoded from the client. The reasoning against it seems to be more about that the gemini protocol is more or less "set in stone", and no fundamental altering should be done, and I think I agree to that.
Hello,
I have a question about this: When I go to the page gemini://spartan.mozz.us/. Does the icon, which is in the favicon.txt, also appear with the page. What is the reason for this?
Edit: Found the answer in https://github.com/skyjake/lagrange/blob/dev/src/gmdocument.c#L1918
@marek22k Yes indeed, those are hardcoded icons for the sites that host a protocol specification. Lagrange does not check favicon.txt.
f79e673 puts you in full control of the bookmark/site icons.
This seems to apply to bookmarks but how do sites like skyjake.fi/lagrange/ or gemini://gemini.circumlunar.space/capcom/ select the icon displayed in the title bar?
The icon is chosen based on a hash of the domain name, so it is random but deterministic. Bookmark icons set by the user override the default icon. The official Gemini capsule has a hardcoded icon.
Cool. That makes sense.
I assume the color scheme is also chosen in a similar way?
That is correct. The various color schemes seed their random palette elements from the domain name (with a possible ~user path included), same as with the icon.
The icon is chosen based on a hash of the domain name, so it is random but deterministic. Bookmark icons set by the user override the default icon. The official Gemini capsule has a hardcoded icon.
That is correct. The various color schemes seed their random palette elements from the domain name (with a possible ~user path included), same as with the icon.
Can you please share how this icon hash and color pallete is generated?
@vg Well, you can find the code for doing that in gmdocument.c. The palette generation is not that straightforward because there are multiple theme variants. When it comes to the icon, the app computes a (slightly broken) CRC-32 of the domain name (possibly including a tilde username, like "domain.org/~username/") and picks the icon from a hardcoded set of Unicode characters. Various bits of the computed checksum are directly used when choosing theme colors.
My suggestion is, for one thing, allow an option to disable icons entirely, and allow the user to set icons (and colours) manually.
Many people (including myself) dislike the use of the /favicon.txt because it needs an extra request, which violates the principle of Gemini.
So, I have made up a way to use a X.509 certificate to define the favicon. Its working is: The ID of the extension is 2.25.327847519394146920218914781995694576662.3. The data type is a sequence. If the sequence contains a UTF-8 string then it is interpreted as specified in the specification of the favicon.txt. The implementation MUST allow the user to disable this feature, if it is implemented.
I personally don't like favicons and don't use it (and to me, I would be OK even if favicons are not implemented at all), but I made up such a specification only because of disliking the other method.
I think that #237 would also be acceptable (although only with the option that is disabled by default, as suggested by skyjake; or possibly with a button that will do so only if you explicitly select "download favicon"; or a combination of the two).
