A server has a job. It has to know that an envelope exists, which device should receive it, and whether the sender was allowed to send it. Those are real requirements. They are also smaller than the list most chat systems quietly take.
If the server can read the message, then everyone who can administer the server can read the message, and so can anyone who later compromises that server. “We trust our administrators” is a policy. It is not a design. People leave. Laptops get malware. Backups get copied.
Sealed before it moves
In RavenFlo the message is encrypted on the sender’s device. The server stores a sealed envelope and hands it on. Your servers, and ours, are in the same position: they cannot open it. That is the point of running the software on your premises. You gain control of the machines. You do not gain a window into the text, and neither do we.
Search follows the same line. It runs on the device, across that person’s own history. The server is not building a dictionary of everyone’s words in order to be helpful.
The notification is a wake-up
Phones are often on networks you do not control. A push service can tell the device to wake. It does not need the message, and it should not be given the message. The device then fetches the sealed envelope from your server, over a connection you pinned.
If a phone is lost, revocation is a statement about keys, not a request to a vendor to forget a plaintext they were holding. The lost device stops being able to open what comes next.
Where this leaves a deployment
You still operate the machines. Headquarters, a recovery site, a branch, a small relay for the wake-up. Deployment is that map. The privacy claim does not remove the need to patch, to monitor, or to know which role a box is playing.
It does remove a common excuse: that the server must see the message or the product cannot function. It can function. The envelope is enough.
The diagram, with less prose, is on the security page. If you want it drawn against your own network, talk to an engineer.