fix: add meaningful favicon

[kerbo7]

Problem

Arbitrary favicon

<link rel="icon" href="data:image/svg+xml,&lt;svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'&gt;&lt;text y='.9em' font-size='90'&gt;F&lt;/text&gt;&lt;/svg&gt;">

Solution

Use Freenet logo as favicon

<link rel="icon" href="https://freenet.org/freenet_logo.svg">

[sanity]

Issue Priority Assessment

Generated: 2026-02-18T22:09:32.035140653+00:00
Issue hash: 06a2e2ad

Value Assessment

The Hugo head partial at hugo-site/themes/freenet/layouts/partials/head.html:10 currently embeds a one-letter SVG favicon (<text y='.9em' font-size='90'>F</text>), which every page renders and hence every visitor sees as the site’s favicon. While this does not break functionality, the placeholder is visually arbitrary and fails to convey Freenet’s identity to returning users or people with multiple tabs open, so the perceived polish and brand signals that a meaningful favicon provides are absent for the entire audience.

Swapping that hard-coded “F” SVG for the official Freenet logo at https://freenet.org/freenet_logo.svg would align the site’s presentational layer with the project’s branding goals and give the static site the same visual currency as other marketing materials. The favicon is served from the shared head partial, so the change automatically propagates to every page served through Hugo without touching the Rust/WASM components; it’s a low-cost enhancement that keeps the web front end consistent with Freenet’s broader messaging efforts.

There’s no dependency chain that currently hinges on the favicon being the placeholder, so fixing it does not unblock other features or CI workflows. Nor is it time-sensitive in the sense of breaking functionality or addressing a security issue; however, it is a quick, UX-polish task that furthers the visible professionalism of the main marketing site and can be slotted into the next UI-finish sprint without risking regressions.

Cost Assessment

Scope is minimal: the only definition of the favicon resides in themes/freenet/layouts/partials/head.html (around line 10), so implementing the issue simply means replacing the inline SVG data URI there with the Freenet logo URL provided. No other modules, templates, or downstream assets directly reference that string, so no additional files need touch unless we decide we want to mirror the asset locally instead of pointing to https://freenet.org/freenet_logo.svg.

Technically it’s trivial—just swapping out the href value in the <link rel="icon"> tag. There are no build steps, data migrations, or new dependencies involved, and Hugo should pick up the change automatically when the site is rebuilt. There’s no tricky browser behavior hiding here because favicons are standardized; just ensure the external SVG is served with the proper headers if we rely on it remotely.

Risk is very low. The only potential issue is the dependency on the external freenet.org logo URL staying available, so if we wanted to eliminate that risk we could instead drop a copy of the SVG into hugo-site/static and point the <link> to the local path. That would add a tiny bit more work but still barely increases complexity. Otherwise, the change can’t break any runtime logic because it only affects what icon the browser shows.

Testing effort is essentially nil beyond rebuilding the site locally (cargo make build-site or hugo server -D) and visually confirming the new favicon appears in the browser tab or via the HTML output. There’s no automated test that would cover this, so a single manual verification after the change is sufficient.

---

Generated by issue-prioritizer