02/SECURITY
Trust is a set of separate decisions.
Identity, authenticity, consent, and confidentiality each need their own answer. zendtru's architecture treats them that way.
01/THE TRUST MODEL
Who is the customer?
zendtru intends to verify customers through the Australian Government's myID and Digital ID system. The platform is designed to store a one-way identity hash in place of a customer's legal name.
Who can send?
Organisations would undergo manual approval. Their signing credentials would establish the origin of each message.
Who is connected?
In the intended model, both the organisation and customer approve a relationship before messages can be exchanged. Unconnected senders would have no route into the inbox.
Who can read it?
Message bodies are encrypted for the customer's device before reaching zendtru's routing and storage systems.
02/DESIGNED TO MINIMISE ACCESS
A delivery service should not need to read the message it delivers.
zendtru's design keeps organisation private keys outside its central service and customer private keys on customer devices. It cannot read encrypted message bodies.
The current trial uses established X25519 and AES-GCM encryption. We plan to implement the Signal Protocol and support secure delivery to more than one customer device as the product develops.
03/CURRENT STATUS
A careful foundation, still in development.
zendtru is at an early stage. Its local trial uses a mock Digital ID flow, hashed customer identities, and device-based encryption. myID integration, formal organisation review, mutual connection approval, Signal Protocol integration, multi-device delivery, recovery, and key transparency work remain ahead.
Connection controls are designed to prevent unsolicited senders. They cannot guarantee that every message from an approved organisation is safe, or that an approved account can never be compromised.