End-to-end encryption means the service provider can’t see your data even if they wanted to

Not necessarily. All it means is that intermediaries can’t see the data in transit. You need to trust that the data is handled properly at either end, and most service providers also make the apps that you run at either end.

This is incorrect. End-to-End is defined as from “User to User” and not “User to Service provider”. That would be just transport encryption.

https://en.m.wikipedia.org/wiki/End-to-end_encryption

I switched to adguard, yes. But you can just give pi-hole a dnsmasq config file. The underlying dns server Pi-Hole uses does support those.

Just mount the file via a docker volume. I will have to look up the exact paths. Config would look like

address=/domain.tld/192.168.0.1

Based on you screenshot from the NPM Dashboard there seems to be something wrong. In the setup window you show that you forward the traffic with http and port 80, in the dashboard screenshot you forward the traffic with https and port 80.

Just skip http and self signed certificates all together. Modern Browsers make it a pain to use non https sites. A simple domain setup with dns acme challenge is a little bit of a hassle but worth the hour(s) of invested time. Especially with npm were it is a set and forget option.

Does pihole support wildcard dns entries yet? To my knowledge the gui only supports single entries so that you have to enter every subdomain manually in pihole that you want to have forwarded. Workaround would be to use a dnsmasq config file or use something else like addguard.

It usually is the directory where you execute the docker compose command.

And which one of those are actually vulnerabilities that are exploitable? First, yes ofc unauthenticated endpoints should be fixed, but with those there is no real damage to be done.

If you know the media path then you can request a playback, and if you get the user ids then you can get all users. That’s more or less it.

Good? No. But far from making it a poor choice exposing it.

Performance is not the goal, but cleaner code and more manageable code. But both will ultimately lead to better performance. As of now it was basically impossible to change something in the database structure since it was hard to estimate the impact of it.

Consider the 10.y.z simply to be 0.y.z and everything works out.

Jellyfin inherited a lot of shitty code and architecture from emby. They simply cannot guarantee anything across patches until it is sorted out.

imho much better then releasing major version after major version because the break stuff regularly.

just two pieces of data: the date the target Signal account was created, and the date that it last connected to the service.

And how does Usernames help here? Should be the same 2 data Points and not more?