If qBittorrent is not complaining about file errors you are in fact still seeding the original file. Especially on Linux file systems a file keeps being referenced as long as at least one application is still accessing it, regardless if you delete, rename or alter it. Once you close qBittorrent the ‘old’ file will be dropped though.

And at that point it won’t be seeded anymore as it does not match the checksums that are stored in the .torrent file or were retrieved via a magnet link. If the client is not broken it should not be possible to seed corrupted or altered files.

After looking deeper into the docs they do not support and do not plan to support the Relying Party role. So it probably won’t fit for this use case.

Depending on what you are trying to do, Authelia does have OIDC in beta https://www.authelia.com/roadmap/active/openid-connect/

I use Authelia again since in beta it now supports multiple Pass/FIDO keys via the web interface, and it does work reasonably well.

Well, how about having a local API and have no calls at all to your cloud infrastructure? Probably too easy and you cannot lock people into your ecosystem.

Does it though? I had a similar setup in the past, but I did not feel good with it. If your first backup corrupts that corruption is then synced to your remote location. Since then I have two separate backup runs for local and remote. But restic as well with resticprofile. Remote is a SFTP server. For restic I am using the rclone backend for SFTP since I had some connection issues with the internal SFTP backend (on connection resets it would just abort and not try to reconnect, but I think it got improved since then)