Livara’s public channels are for publishing content and, according to the product security page, do not have end-to-end encryption. Before posting, treat the content as something suitable for channel audiences to see and for the service to process—not as a confidential private message.
This difference is a product boundary. It does not mean that encrypting channels is technically impossible or that every service must implement public channels this way.
What exactly does “not encrypted” mean?
Two different protections should not be confused:
- Transport encryption, such as TLS: protects communication between the device and server in transit, but the server may be the decryption endpoint.
- End-to-end encryption: aims to make protected content decryptable only by authorized endpoints, not by the intermediary server.
Lacking E2EE does not necessarily mean sending plaintext over the network. Conversely, HTTPS or a browser padlock does not prove that the provider cannot access channel content. The EFF encryption guide explains this basic distinction.
Practical differences between a channel and a protected conversation
| Topic | Public channel | Private chat or group with E2EE protection |
|---|---|---|
| Intended audience | Publication to channel audiences | Authorized conversation participants and devices |
| Confidentiality from the server | Should not be assumed | Depends on protection being enabled and the protocol being implemented correctly |
| Copying by the audience | Possible | Still possible |
| Content management | Public content may be accessible to the service | Membership control and reports are not the same issue as content encryption |
| Risk from accompanying information | Activity and access may be observable | E2EE alone does not hide all metadata |
In Livara, the public security document describes LVR1 for private messages and LGS1 for protected groups. The same document says an incompatible legacy group must visibly remain outside E2EE. The label “group” therefore cannot replace checking the actual protection status.
Content moderation does not guarantee safety
The ability to review or remove public content can help operate a service, but its existence does not prove that every published link, file, or claim is safe. Users still need to evaluate news sources, the publisher’s identity, and link destinations.
Nor should privacy and safety be framed as an absolute either-or choice. Access control, user reports, tackling abuse, and content confidentiality are related but distinct issues. Each tool’s type and limitations should be clear, rather than treating encryption in general as a sign of criminal behavior.
What should you avoid posting in a public channel?
- Recovery phrases, passwords, private keys, or personal login links;
- Other people’s contact details and images without permission or a clear reason;
- Work documents not authorized for public release;
- Personal details whose disclosure risks would remain even after deleting the post.
Deleting or editing a post does not recall copies saved by the audience, screenshots, or reposts outside the service. The same limitation applies to the recipient of a private message: E2EE does not control the recipient’s behavior.
Check the destination before sending
A channel can be a suitable choice for a public announcement. For confidential content, first check the audience, encryption status, and devices involved. If the subject is sensitive, the app’s name or the “private” label alone is not enough.
Livara’s threat model explains limitations such as a compromised device, physical access, and disclosure by the recipient. Making the right choice starts with understanding these boundaries: public posting, content confidentiality, and service management are three separate goals.
