A way for admins to change the favicon in admin settings

[Cassolotl]

Because it's nice to have a bit of icon individuality on the bookmark bar, and because a lot of admins are using a hosting service now so they need to be able to customise their instance from the admin settings.

---

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[nclm]

Yes! I came to open the same issue, looked it up beforehand, and found this :) Now that there is a custom CSS field, the favicon is one of the big missing customisation option.

[carbonpenguin]

Was just looking for this in the admin interface. +1 to the request... :)

[koyuawsmbrtn]

It's pretty easy, could @Gargron please put it on the roadmap for 3.0? It should be just a small and simple patch. Sadly I'm not really experienced with Ruby on Rails so I can't help here.

[albjeremias]

how do people change this?

[koyuawsmbrtn]

how do people change this?

they just replace the favicon file inside the public folder

[m-a-x-s-e-e-l-i-g]

This, as well as the apple-touch-icon.png (and other similar icons).

[ErnestCodes]

I guess changing the favicon in the file is how to go about this

[edmael]

+1 to this, it's a simple but welcome change.

[johnsonm]

Like others, I got here because I was expecting this to be part of the configuration; an expectation developed from setting up Discourse, which has fairly substantial "Branding" support. Worth seeing what they do, including image conversion, to make this simple.

[Gargron]

There is a significant difference... Discourse is not a decentralized social network, every forum is a different, completely separate website, and that is expected. Different Discourse servers neither compete nor cooperate with each other, they just serve whatever specific purpose a forum usually serves. For Mastodon, it is vital that an onlooker can recognize that it's not simply a random website, but a Mastodon server, and therefore part of the decentralized network where they will be able to interact with content from other servers. The server operator benefits from the trust established through brand recognition (visitors know what Mastodon is and what to expect from it, so they are more willing to sign up) and there is no confusion whether "I am signed up on Foo" and "I am signed up on Bar" are completely separate social networks or not. There are brand customization options in Mastodon - the title, the description, the hero image - but the favicon and header and footer logos are intentionally left unchangeable in this line of thinking.

[johnsonm]

What you say makes complete sense for a Mastodon server with open registration.

As you know, the first part of Mastodon setup is the choice whether to make the server for just a single user, and there's nuanced support in the platform for closed registration. There are a lot of Mastodon servers with closed registration; not just those that are in single user mode, but those that serve a particular community. At least, I've run into what I would call "many" while I was trying to decide whether to start running a Mastodon server!

I'm setting up a Mastodon server as part of a community. Registrations will be available within that community, in order to give them a Mastodon server on which the Local and Federated views are likely to be relatively more interesting to them than some "random" Mastodon server with open signup that they find. I am trying to help bootstrap participation in decentralized social networking within that community. Here, the community brand is important, and is a way to promote Mastodon within that community.

Ultimately, it's not hard to set up nginx rules that point to branded favicon etc. I've already done that.

But I think you are perhaps unnecessarily discounting the value to Mastodon and the fediverse of incorporating favicon in site branding, where it can enhance opportunities to enable and encourage existing communities to expand out into the fediverse by use of Mastodon. I don't mean to argue, and won't prolong a conversation here; I just wanted to present a view that wasn't clearly encompassed in your reasoning. It doesn't ultimately matter to me now whether Mastodon makes this change; the nginx route is trivial. I only want to help. ☺

[jsailo]

+1 to this. I guess this is never going to be implemented?

@johnsonm I read that you have managed to do this using nginx rules. Could you please help/provide us non-techie people on the steps of how to do this?

/non-techie = Can run a bunch of CLI commands and tinker with existing code. That's it.

EDIT: Is it this one? https://serverfault.com/questions/308299/how-to-set-a-favicon-ico-for-a-specific-virtual-host-on-nginx

[svoeth]

@Gargron would you mind telling me which of these is my own server, which is my private account, which is a totally different server and which ones are just joinmaston.org landing page?

I don't mind having this setting hidden somewhere, but changing the favicon will happen, but currently it is a pain in the a**

Thank you :)

[johnsonm]

@jsailo My hack didn't trivially work with the upgrade to Mastodon 4, and I polled my community and they like the new elephant, so I'm just going to remove the the branding suggestions I had added to my writeup because I won't be in a position to maintain that documentation going forward.

The easiest thing is to do it like any other customization to Mastodon, which is to make the changes in the source, commit them to a local branch, and either serve Mastodon from a source build, or build a docker container from the build (docker build -f Dockerfile --tag whateveryoucallit .) That's not a particularly non-techie solution, but it's the best I have.

I would make a different choice here and make the branding customizable, but also it's not my choice to make.

[QGuLL]

It is dirty, but I've fixed my nginx conf and favicon is back with 4.0 (adapt "path to"):

+        location /packs/media/icons/favicon-16x16-c58fdef40ced38d582d5b8eed9d15c5a.png {
+            return 301 https://path.to/favicon.ico;
+        }
+
+        location /packs/media/icons/apple-touch-icon-1024x1024-db6849588b44f525363c37b65ef0ac66.png {
+            return 301 https://path.to/favicon.ico;
+        }

I don't know about those path, maybe they can change for you, I've got them from the F12 console of my browser.

It might not work in the future, but upgrades of mastodon are less frequent as before, so it can be a temporary long solution.

Edit : more generic way :

       location ~ "/packs/media/icons/" {
                return 301 https://path-to/favicon.ico;
         }

The bad part is that it's always the same size, wether the app ask for 32x32 or 16x16 or 1024x1024 (lol apple).

[rixx]

For Mastodon, it is vital that an onlooker can recognize that it's not simply a random website, but a Mastodon server, and therefore part of the decentralized network where they will be able to interact with content from other servers. The server operator benefits from the trust established through brand recognition

I think this approach is fundamentally misguided, and I very much hope that you reconsider. I feel very iffy about having brand recognition being higher up in your priorities than instance ownership.

At this point, instance owners already change their favicons, and all the other things you mentiond (footers, for example) that you think have to be immutable and make every instance look like mastodon.social. We hack our nginx configs, we hack our custom.css files, and, in the case of the favicon, we have to patch in files of our own.

All this kind of restriction achieves is that it's more annoying to have a favicon that makes it easier to distinguish instances, and that people on hosted instances can't do it.

[rickosborne]

For posterity, the Apache2 equivalent of @QGuLL 's nginx config is:

RewriteEngine on
RedirectMatch 301 "^/packs/media/icons/.*[.](png|ico)" "https://example.com/favicon.$1"

(Confirmed as of 4.0.2.)

[unayok]

If you are serving the icon files statically (via nginx, for example)... This gist is a sample script for determining and generating various sizes of icon files based on the current <html><head><link> references and /manifest and a good quality primary image.

It works okay for me. It queries the main page and the manifest, and (naively) finds the various icon links and desired sizes. It uses Pillow to resize the base image, and drops them into the destination (presumably your /mastodon/public folder). In my setup, nginx has its root set to a writable /mastodon/public directory that contains the system directory mounted into the docker.

Hope this is helpful for some.

[hansenandrew]

I would love my favicon to show up on the browser. Is there a way to get it back?

[rstockm]

For Mastodon, it is vital that an onlooker can recognize that it's not simply a random website, but a Mastodon server

I see what you're getting at, but maybe there is some common ground here.
Lets's take a look at the custom favicon of chaos.social:

a) it has the official shape
b) the official color (well not for the 4 but lets ignore this for the sake of argument)
c) a server-logo (rocket) in the right color (white).

It's perfectly clear that this is a mastodon server, bit it gives me orientation at first glance to distinguish this server from the other 3 I have accounts on.

So what about this:

• admins have a way to upload a svg
• this will be rendered in white color in the official logo
• fitting the space the official "m" does.

For my openbiblio.social server - which adresses libraray people - this would be - well - a book:

Actually, this looks ginda creepy, but you get the idea.
This might sound a bit like over-engineering, but it would suit both needs?

[Freeplayg]

For Mastodon, it is vital that an onlooker can recognize that it's not simply a random website, but a Mastodon server

Also now in 4.0, don't you already have these to already tell that it's a Mastodon server?

[Openmedianetwork]

A thread on social tec of this https://socialhub.activitypub.rocks/t/branding-on-the-fediverse/2534

[2-www]

i suspect that there were many cases of people seeing the default Mastodon icon after visiting a link to an instance, and thinking it's impersonating the mastodon.social (possibly to spread malware!).

perhaps [no longer relevant]

[2-www]

For Mastodon, it is vital that an onlooker can recognize that it's not simply a random website, but a Mastodon server

Also now in 4.0, don't you already have these to already tell that it's a Mastodon server?

that is currently visible only on some screen sizes

[cadadr]

For Mastodon, it is vital that an onlooker can recognize that it's not simply a random website, but a Mastodon server, and therefore part of the decentralized network where they will be able to interact with content from other servers.

It's a fediverse server, in that context, not a mastodon server.

[psydwannabe]

For Mastodon, it is vital that an onlooker can recognize that it's not simply a random website, but a Mastodon server, and therefore part of the decentralized network where they will be able to interact with content from other servers.

@Gargron - At what point do you intend to implement mandatory Mastodon themes on the other Mastodon forks, as well as the other Fediverse clients, in keeping with your unified dream of sameness?

Or were you planning to force us all in a future update to defederate from non-vanilla Mastodon servers so we get the perfect Apple walled-garden experience?

Just trying to understand your thinking here.

[egypturnash]

yeah eugen can you please let us hang up some curtains and make the spaces we run feel like home to us and to our users, we are all nodes on the People's Glorious Social Network and I am perfectly fine with that, delighted to be a part of it even, but we are also specific nodes with specific values and identities and feelings; we are communities that are talking to ourselves in the Local timeline as well as talking to the whole world in the other timelines.

I have put off upgrading to 4.x because you broke all my customizations the last two times I upgraded and I still haven't fixed them since the last one and I intend to be switching over to the Glitch fork and wrapping my head around its weird two-tier style system solely so I can decorate the heck out of my instance and expect it to keep looking the same when I update the underlying software.

[Gargron]

Configurable favicon and app icon are on the roadmap.

[cambraca]

Until then, it's .. a bit of work :) Maybe this will be useful as reference: cambraca@b61b61d

[gessel]

@cambraca - thanks, very helpful.

If anyone wants a bash script that should (still) generate all the standard favicon variants at least up to the at the time of writing 512x512: https://www.blackrosetech.com/gessel/2020/12/21/favicon-generation-script. I'm sure there are much fancier ones online, but this did what I needed at the time.

It assumes you're starting with an .svg.

[Chewie9999]

@cambraca - thanks, very helpful.

If anyone wants a bash script that should (still) generate all the standard favicon variants at least up to the at the time of writing 512x512: https://www.blackrosetech.com/gessel/2020/12/21/favicon-generation-script. I'm sure there are much fancier ones online, but this did what I needed at the time.

It assumes you're starting with an .svg.

Thank you!
Note a recent version of InkScape is required, mine from 2020 did not include the -o option, but v1.3 does.
Also the "size" line needs some slightly different resolutions for Mastodon. I'm using the following:

size=(16 32 36 48 57 60 72 76 96 114 120 144 152 167 180 192 256 310 384 512 1024)

[gessel]

Thanks, that's great, I added a note for Mastodon users on my script page and credited you. If I modded the line to be the union of both requirements it would get a bit pretty big.
size=(16 32 36 48 57 60 70 72 76 96 114 120 128 144 150 152 167 180 192 256 310 384 512 1024)

[Chewie9999]

Thanks, that's great, I added a note for Mastodon users on my script page and credited you. If I modded the line to be the union of both requirements it would get a bit pretty big. size=(16 32 36 48 57 60 70 72 76 96 114 120 128 144 150 152 167 180 192 256 310 384 512 1024)

Fair enough.
I included sizes that would replace files that start "android-chrome-", but I don't think they're actually used - I never see them in the source when requesting a page, even though I see the apple ones and I'm not on an apple device.

[gessel]

Oh, good work! I didn't even think to check my actual logs, duh, just followed specifications without checking if they're actually requested, an always moving target, these days.

[almereyda]

We have added these lines to an Nginx configuration to adapt favicon.ico, and also the /packs/media/icons route:

    location = /favicon.ico {
             return 301 https://example.com/favicon.ico;
    }
    location ~ "/packs/media/icons/" {
             return 301 https://example.com/images/icon-128.png;
    }

[3-w-c]

@almereyda thanks for the tip! I think the first block might set up an infinite redirect? And the second one didn't work for us, we needed to do this (with the caret ^ before the tilde ~):

  location ^~ "/packs/media/icons/" {
    return 301 https://example.com/favicon.ico;
  }

(PS it might have been mentioned elsewhere in thread but we also had to replace public/favicon.ico in our copy of the code)

[renchap]

Fixed by #30040