(See this post about NIST's PQC standardization process...)

Where do the encryption algorithms come in to play? In flight or at rest? What threat vectors are you hardening against?

I'm not too sure if "it uses a different encryption algorithm" is enough to differentiate from the competition. And to be perfectly honest, from one developer to another, I'm always extremely skeptical when a developer says "I plan to develop X" before I see something concrete like a codebase or some kind of alpha 😛

Have you thought of expanding on what Librephotos to make what you want?

So, something like Pixelfed, but with PQC encryption in the file system and enabled for HTTPS?

A few notes as I've been doing some PQ research for my own projects:

• NIST PQ encryption algorithms are typically for encrypting small amounts of data due to poor performance (like an AES symmetric key)
• NIST PQ encryption algorithms use public key cryptography to securely exchange keys between two parties (usually to establish a AES symmetric key... aka Key Encapsulation Mechanism, or KEM, with a Key Derivation Function, or KDF, which frequently uses Hash-based Message Authentication Code, or HMAC)
• Hybrid-PQ, as you mentioned, should be used since there are not years of testing on the new PQ algorithms
• AES256 is PQ with good performance, but lacks a way to securely exchange the shared key, so typically public key cryptography is used to bootstrap

With that said, I'd want to know where and how the encryption is going to be applied.

An ideal solution for me:

• Data is stored using AES on device and remote
• I have soul access to the AES key (can be derived, see last note)
• App generates and index of meta searchable fields and thumbnails also AES encrypted, but is decrypted when opening the app to make it usable.
• I can choose my backup (checkout rclone)
• All over the top features like OSM are done client side (or self-hosted backend)
• PQ would really only come into play to seal the AES key on my device. Instead of unlocking my photos with my AES key directly, its sealed behind a passphrase, pin code, hardware token, or other type of key. Pretty much what LUKs and Bitwarden do. Option for multiple keys would be great. A new device might take a passphrase and hardware key, but then might be sealed by a pincode.

I suppose you could use a PQ TLS, but if the payload is already AES encrypted, I see little value. You could use PQ to sign each object I suppose in case your AES key is broken, but that would mostly detect tampering of the data.