Thumbnails

[appgurueu]

In order to make the server list more visually appealing, server thumbnails might be a good addition. The implementation could fetch them from a provided URL.

[rubenwardy]

A better implementation would be for servers to include base64 encoded image data

One problem with this would be managing persistence/caching, to avoid the server sending the image multiple times and the client downloading multiple times. Using a hash would fix the client side of things,

A problem with any approach is moderation, we don't want nsfw or illegal images to appear

[appgurueu]

Not a fan of base64 encoded image data mushed in JSON. Been dealing with this for SkinDB support and it usually results in lots of unneeded retransmission as you have noted.

Using URLs for this is presumably much more comfortable: Server owners will only have to push an image to the right path on their website. Images would be cached by the serverlist and could be downloaded in parallel. To check whether a new image must be downloaded, HEAD could be used to get caching-related headers. This would allow particularly easy presentation on the website as simply an img tag.

A problem with any approach is moderation, we don't want nsfw or illegal images to appear

Of course. Perhaps this would require a report feature? Perhaps required approval for screenshots, CDB-style?

Another problem are security considerations (we should be using a simple image format like PNG and the server should be optimizing it, stripping potentially harmful chunks).

[rubenwardy]

I'm not sure how moderation should work. It makes sense to use the ContentDB login system, but it doesn't necessarily make sense for servers and clients to contact ContentDB for an image list / uploading directly.

Options:

1. The server could receive POSTs of the image, and then forward them to ContentDB to manage hosting and moderation.

2. Or servers could include a hash of the image when announcing to the serverlist, and then POST/PUT the image to ContentDB. If the image isn't approved yet, it could 404 on the client.

   This is inflexible as it means you can't go away from using CDB. But it keeps the serverlist fairly simple, it would just need to generate urls like "https://content.minetest.net/serverbanners/${hash}.png".

Using URLs for this is presumably much more comfortable: Server owners will only have to push an image to the right path on their website. Images would be cached by the serverlist and could be downloaded in parallel. To check whether a new image must be downloaded, HEAD could be used to get caching-related headers. This would allow particularly easy presentation on the website as simply an img tag.

Most servers don't have a website. To gain maximum adoption, this needs to be as easy possible

[appgurueu]

Most servers don't have a website. To gain maximum adoption, this needs to be as easy possible

Then they could simply use third-party (image) hosts.

[sfan5]

Honestly I would put this on the "infeasible, might reconsider later" pile.