LXMF tells you a message's state. LXMessage.DELIVERED is set by a callback, lives in memory, and is gone after a restart and __mark_propagated sets the state to SENT, quietly conflating "a propagation node took it" with "I sent it".
Dethron adds an artifact instead:
the relay signs a custody attestation naming the message, the recipient, and the size and digest of the bytes it actually stored;
the recipient signs a receipt over the exact reconstructed bytes;
both travel back through ordinary propagation, and either can be re-checked later by anyone holding the public keys without trusting the relay that carried them.
A relay that attests and then discards is named by the absence of the recipient's receipt. That is the point: no intermediary is trusted.
pip install dethron
dethron relay ./relay --port 45810
dethron send ./alice report.pdf --to <contact> --relay <host:port/prop> --relay-contact <contact>
dethron fetch ./bob --source <contact> --relay <host:port/prop> --receipt-to <contact>
dethron receipts ./alice --relay <host:port/prop>
dethron verify ./alice
verify reads the files on disk and recomputes, trusting nothing an earlier command printed:
{"verdict": "pass", "checks": [
{"check": "custody 10019ad5 is signed by the relay that was asked", "proves": "entry", "passed": true},
{"check": "receipt 02377a24 is signed by the recipient sent to", "proves": "exit", "passed": true}]}
Alice and Bob are never online at the same time.
What it does not do. One message, one relay, one recipient no scale numbers at all. No key exchange and no discovery; you swap contacts out of band. The hostile relay is simulated by a laboratory command, not met in the wild. No threat model and no security audit: please don't put anyone at risk with this yet. It is 0.1.0.
Every milestone carries a document stating the controls that had to fail and the limits of what it establishes, with the artifacts published so the numbers can be recomputed rather than believed including the one where the redundancy hypothesis came back as a trade-off rather than a win, and the two-machine run that failed its own distinctness check.
One thing I would find useful. If you run a propagation node: ask it for custody of a message you sent through it, and tell me whether the size and digest it attests match what is actually in your store. That is the check I cannot run from here.
Code and evidence: https://github.com/elSilveira/dethron · the bench that produced it: https://github.com/elSilveira/dethron-research
The ZeroDivisionError I posted about earlier turned up while building this.
