> The encryption can be broken in the future if the rival states become allies, or otherwise become willing to share data with each other.

Witty, sure, but I would not trust it with sensitive data at all if it is relying on political relations ("politics") only.

> Many [vulnerabilities] in Whatsapp/Telegram/Signal

Please provide citations for currently known vulnerabilities of each of these, then.

Telegram does not even support "secret chat" (E2EE) on their desktop and web version of the software[1]. No need for vulnerabilities here.

[1] https://tsf.telegram.org/manuals/e2ee-simple

Horcruxes are just a layer of security. If you want to further encrypt (or do more steganography) on the messages then it is not hard to add that too depending on your threat model and paranoia level.

Horcruxes provide a unique solution to the problem of dragnets and increase costs of hacking your device even for governments.

Horcruxes are just a layer of security.

Sure, but the problem it solves is not the problem that needs addressing. Ciphertext and key delivery can already be done safely with E2EE apps like Signal. Metadata can be eliminated with e.g. Tor Onion Services.

Your apps relies on QR-codes to exchange data, the same channel can be used to authenticate Signal endpoints and/or exchange PSKs, no need for SSS. Goal for information theoretic security is fine but considering nobody is doing CT-only attacks against modern algorithms anyway, the easiest attack vector will be MITM attack or remote key exfiltration. E.g. Snowden has been very vocal in the past about NSAs of the world hacking endpoints, but has quieted a bit down wrt the matter, perhaps he realized that was too high bar for average users who still benefit from incremental security from Signal etc.

Pleas read through the whole doc. In many places it describes how it increases the cost of device hacking using 0-days significantly. There are limited other solutions for this, whereas Horcruxes are cheap and easy to implement.

The thing is, for the Horcrux to have any effect at all you need at least three devices per endpoint. And at that point using split TCB architecture is much better as under some assumptions it's provably secure against remote key exfiltration. See my work on TFC here: https://github.com/maqp/tfc