Customize manifest

[kontrollanten]

Description

• Manifest name and description is fetched from PeerTube config.
• Manifest icons are generated from client-overrides/icons/icon-512x512.png or assets/icons/icon-512x512.png.
• Manifest route is removed from the server which makes the client and server less coupled.

The current draft will change the behavior since we're only using the icon-512x512.png to generate all the icons. In cases where there is actually different icons (and not only different sizes) this draft will change the behavior, but the questions is if that's common?

Notes:

• Since HtmlWebpackPlugin isn't used by ng cli anymore I had to inject the manifest link manually. With HtmlWebpackPlugin it's injected out of the box.
• When Asset Versioning jantimon/favicons-webpack-plugin#175 is solved the asset filenames will contain hashes, which lets us remove more code.

Related issues

• Customize appearance (logo, favicon, PWA manifest name and icons) #2752
• Missing system icon for iOS ‘add to home screen’ functionality #2939 should be easy to solve here as well.

Has this been tested?

• 👍 yes, light tests as follows are enough
• 💭 no, because this PR is a draft and still needs work

Verify that manifest file and it's assets exists after running

• npm run dev
• npm run build -- --light && node dist/server.js
• npm run build && node dist/server.js

[Chocobozzz]

Hello,

I'm sorry but I don't understand: admins are not expected to build the client themselves. And the manifest was already generated from the config, so why should we change the way it's done?

[kimsible]

I may be wrong, but I think there is a misunderstanding between the run-time and the build-time ?
PeerTube releases the builds for admins, so I think a better approach would be to add a hook / action just before this line where the manifest is overridden :

PeerTube/server/controllers/client.ts

Line 159 in 19b163d

res.json(manifest)

These hooks could open the path to a real plugin for the manifest.

For the PWA icons we might create a CLI script to generate them from a 512x512 PNG icon ?

[kontrollanten]

Oh, sorry. My bad. I thought the frontend was built on the server, but now I see that the installation process downloads the artifacts and the only thing that's done on the server is dependency installation. 🤦🏻

My idea of the process was like:

1. storage/client-overrides contains icons/icon-512x512png.
2. PeerTube code is cloned at a certain release tag.
3. npm run build generates a manifest based on the PT config and the icon in client-overrides.

But if PeerTube doesn't want to support ability that sysadmins/admins builds the artifacts this idea obviously breaks. But I think it worth considering since it's a common process and it has some upsides:

• Configuring a manifest file is something that usually is done once, therefore I think it should be connected to the installation process.
• Separation of concerns. In my humble opinion the backend shouldn't know much about frontend and thus is moving all the client-overrides handling to FE a good idea.
• Less complexity since the server isn't involved in what assets are served on the client. The only assets that exists are the assets in the client folder.
• Auto generated icons out of the box by webpack plugin.
• Easy to let the admin customize manifest colors by using PT config.

[kimsible]

@kontrollanten thanks for the details =).

I understand what you mean, the needs to make an installation customizable but in my opinions, admins shouldn't have to build / configure the Javascript client in such a level, it's a developer task. I think admins need to customize their instance easily with an interface (UI or CLI), building PeerTube is long process that we can't do everytime we need to update the PWA icons, the old way was very faster and without any Javascript acknowledgement, why not improving the client-overrides concept with a CLI or a plugin ?

[kontrollanten]

I'm not sure if we're defining the roles the same way. I see two relevant roles in this scenario: sysadmin and admin. The sysadmin is the one who sets up the server and installs PeerTube. The admin is just handling content, users, etc via the web UI.

I think that in most cases it should be enough with letting the sysadmin configure logo and icons during the install phase. I can see the scenarios you're describing where the images should be updated and where it would be great if an admin could do that, but I can't see scenarios where that happens more than some times per year? Anyway I don't think it's worth the price of bounding the server and client together, but also to not be able to brand the UI during installation.

In our case we're going to move a Youtube channel with 3,7 M views per quarter to PeerTube, so we've to handle a lot of traffic which means that we want to be able to scale up servers when needed. Thus we'd like to configure as much as possible during the install phase (even though I've understood that's not how it meant to be). In the long run we aim to build our own frontend, which I think will be common among growing instances, and therefore I see upsides with separating FE and BE as well.

I don't think that you have to know Javascript to be able to change icons with this PR's proposal, you just have to move one icon to client-overrides and run npm run build. But maybe that can be possible to do within a plugin for those edge cases when hurry and common icons/logo update are needed; a file upload and then trigger a rebuild on the server.

I think I've made my case now :) I guess the bottom question is how separated server and client should be and also how much that should be able to programmatically configure during installation. I await the decision and agrees to whatever it'll be.

[kimsible]

that happens more than some times per year?

Even 1 time a year you can't re-build a server in production only for a logo or manifest update, building PeerTube can take a very long time : several minutes to 1 hour depending on your CPU / RAM. For example, the instance where I am admin, we've updated 4 times the logo since the launched in the 2020 march, so 4-times in less than a year, and it wouldn't stop because we planed to update it for special events regularly. Plus the current behaviour allows you to not keep your customisations at each docker image pull (in case you use docker). The last thing which was very useful is the title and description synchronisation into the manifest with the general config made by admins.

I understand your case, but maybe you can propose a solution that does not break the old client-override behaviour for instances that use this way to update their PWA icons ? Allowing sysadmin or developer to customize their client bundle is a good idea, but breaking what « admins » can do easily to replace it with a sysadmin / developer task is not really likeable.

But thank you for your work and a very interesting point you've rised up. =)

I'll let @Chocobozzz or @rigelk complete though they know better this part and could bring you a better help than me to improve and find a compromise to not break the existent app behaviour.

[kimsible]

You may add a hook here to override the all manifest and build your own manifest in a plugin, it will be very lighter to build though you won't have to re-build all the PeerTube app.

It will also allow to not touch the current behaviour.

[Chocobozzz]

@kontrollanten I'm sorry but we don't have time to support another official way to install peertube (meaning building the client). We are satisfied with our current release process, that is quite effective and (sys)admins seems happy with it.
A plugin or a cli script to regenerate icons could be a way to achieve the same goal, without modifying the way we release peertube.