I’m an independent developer in China, and I’ve been building PaperPhonePlus and PaperPhoneLite: two AGPL-3.0 messaging projects that share a self-hosted foundation but make very different product and threat-model choices.
I did not want Lite to be merely a cheaper or incomplete Plus. The two editions answer different questions:
- What if someone wants a complete private communication environment with native clients, social features, and meetings?
- What if hiding the server’s public network identity and minimizing exposed services matter more than having every feature?
PaperPhonePlus: the complete edition
PaperPhonePlus is designed for everyday personal, community, and team communication. It includes private and group messaging, social posts, a public timeline, native clients for iOS, Android, Windows, and macOS, and LiveKit-based audio/video meetings for up to 100 participants.
The client is built with React 19 and TypeScript, while the server uses Rust and Axum. Private chats are protected with end-to-end encryption. Encrypted group mode uses Sender Keys, and identity private keys remain on the local device. The messaging layer also includes a persistent outbox, idempotent message IDs, server sequence synchronization, and gap recovery after disconnection.
Plus is the edition for people who want one self-hosted environment to cover messaging, larger groups, calls, meetings, and social sharing.
PaperPhoneLite: privacy through deliberate reduction
PaperPhoneLite removes audio/video calls, public timelines, and social modules. This is intentional: fewer services and features mean a smaller exposed surface and a clearer privacy model.
In production, the native client embeds Tor, waits for Tor bootstrap to complete, and connects only to a Tor v3 onion service. There is no clearnet fallback if the onion connection fails. The server therefore does not need a public domain or publicly exposed application port.
Private chats use hybrid X25519 + ML-KEM-768 key agreement, followed by XSalsa20-Poly1305 message encryption. Encrypted groups use Sender Keys. Identity private keys and Sender Keys remain local, while the server stores and relays ciphertext.
Lite still keeps practical communication features: private chats, encrypted groups of up to 2,000 members, reliable synchronization, rich messages, contact labels, QR codes, two-factor authentication, blocking, and optional ntfy or Bark notifications.
An additional local text-privacy layer
One unusual PaperPhoneLite feature is designed for a different problem from network encryption: protecting locally visible conversations from casual exposure.
Users can enable an optional Message Privacy password. This adds local password-based protection before the normal end-to-end-encryption flow. The password is not uploaded to the server and is not automatically synchronized between devices. Lite can also lock chats manually or automatically when the application leaves the foreground.
Lite offers eight text-appearance modes that change how message text is rendered on that device. Their purpose is to make accidentally exposed on-screen text less immediately readable—for example, when someone briefly sees an unlocked screen.
This distinction matters: visual transformation is not cryptographic encryption and does not replace E2EE. The appearance modes are a local privacy and usability layer that works alongside the chat lock and Message Privacy password. The underlying communication still relies on the normal encryption system.
Self-hosting without unnecessary infrastructure
Both projects are intended to be deployed by their users rather than depending on a centralized PaperPhone data service.
PaperPhonePlus can be deployed with Docker Compose or Zeabur. LiveKit needs to be configured when audio/video meetings are required. Files remain on the server’s persistent volume.
PaperPhoneLite uses Docker Compose together with Tor. It does not require a public domain, Nginx, or an exposed application port, and the MySQL and Redis services remain unexposed. Uploaded files are stored on the selected server’s persistent volume rather than Cloudflare R2 or another mandatory object-storage provider.
The result is not “one edition is better.” Plus and Lite are answers to different constraints:
- Choose Plus for a complete self-hosted communication ecosystem.
- Choose Lite when Tor-only connectivity, concealed server network identity, and minimal exposed infrastructure are the priorities.
Security boundaries
Neither project has undergone an independent security audit. End-to-end encryption also cannot protect a compromised endpoint, screenshots, content deliberately saved or forwarded by a recipient, or all operational metadata required to deliver messages.
I prefer to state those limits clearly and invite technical review rather than ask users to accept security claims on trust. Feedback on the cryptographic design, Tor deployment model, local text-privacy feature, documentation, and installation experience would be especially valuable.
Links
- Project overview: https://619dev.github.io/
- PaperPhonePlus: https://github.com/619dev/Paperphone-plus
- PaperPhoneLite: https://github.com/619dev/PaperPhoneLite
If you try either edition, I would be glad to hear which threat model fits your use case and where the self-hosting process could be improved.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.