The problem
End-to-end encryption usually promises one thing: the server can't read your messages. It says nothing about whether the server can fake a message, quietly delete one, reorder a conversation, or swap in its own key for someone you're talking to, which is how encrypted chats are usually attacked in practice.
GhostChat starts from a stricter threat model: assume the server, or whoever controls it, is hostile. It may relay and store everything, but it must not be able to read, forge or silently alter anything, and each of those guarantees has to be visible and checkable by the people using it.
How it works
All encryption happens in the browser with libsodium; nothing is hand-rolled. The password is split before it leaves the device: one half signs in, the other unlocks a vault of private keys that the server stores but can never open. A 24-word recovery phrase can regenerate every key the account will ever use.
Every message is signed by its author and linked into a hash chain for its conversation. The server enforces the chain, and every client verifies it, so a forged, edited, reordered or dropped message shows up as a broken link. Keys are published in a transparency log, the same Merkle-tree design as Certificate Transparency, so the server can't show different people different keys without the proofs failing.
Files are encrypted in the browser in authenticated chunks, stored by the hash of their ciphertext, and checked against the hash the sender signed before they are decrypted.
“The server relays and stores data it can't read, can't forge and can't silently alter, and each of those guarantees is visible in the product.”