https://pct.monster
I’ve been working on a personal side project called MistClient for a while now. It’s a communication client built around temporary identities and end-to-end encrypted sessions.
The core idea is simple:
The client generates keys and handles all encryption/decryption locally. The server only deals with temporary identities, session signaling, encrypted message queues, and file relay. It never sees the plaintext.
Here’s a summary of what’s currently implemented.
Identity & Encryption
A fresh X25519 key pair is generated every time the client starts
Session keys are derived via X25519 and used with AES-256-GCM
All text messages, session events, and file chunks travel in encrypted envelopes
Envelopes include authentication and associated data (AAD) — tampering, wrong keys, or incorrect chunk indexes are rejected
TOTP binding is supported (compatible with Ente Auth, Google Authenticator, etc.)
QR code + Base32 manual key
Standard 6-digit, 30-second codes
The TOTP secret never leaves the client (DPAPI on Windows, 0600 file on Linux)
The client shows a rotating MIST Live ID
Each installation also stores a random device credential for stateful API calls
Sessions
Connect using the other person’s current Live ID
Or generate a one-time key and exchange it offline
Incoming connection requests can be accepted or declined
Supports both one-shot sessions and persistent encrypted sessions
Sessions can have time limits and message count limits
Emergency stop is available (notifies the server to invalidate the current identity and related sessions)
Messaging
End-to-end encrypted text messages
Read receipts
Burn-after-reading messages (with configurable disappear timer)
Normal messages stay until the user clears them or the session ends
Encrypted File Transfer
Sender creates a file offer inside an active session
Receiver sees the filename and size before deciding whether to accept
Files are split into 256 KiB chunks
Each chunk is encrypted with AES-256-GCM and bound to the transfer ID + chunk index
Downloads go to a temporary .part file and are only renamed after a full SHA-256 check
Prefers direct P2P (LAN/VPN IPv4 and usable IPv6), falls back to encrypted server relay if needed
Routing Modes (Qt client)
P2P (default) — tries direct connection first, falls back to relay
Relay — everything goes through the encrypted server relay
Tor — routes through a local SOCKS5 Tor proxy (default 127.0.0.1:9050)
Custom relay servers are also supported. You can point the client at your own relay instance, test the connection, and save the setting.
Current Platform Status
Windows: Qt GUI + native Win32 GUI + CLI
Linux/Ubuntu: Qt GUI + GTK3 GUI + CLI
Android: Qt client (Full and Lite flavors)
macOS / iOS: Build support exists, formal signing and public release are not finished yet
Honest Limitations
No full ICE/STUN/TURN yet — current P2P only works with reachable addresses
Tor requires you to run a SOCKS5 proxy yourself
macOS notarization and iOS distribution are still incomplete
Some of the newer features (custom relay UI, full routing options, update flow) are mainly in the Qt client
This is still a personal, non-commercial project that I’m iterating on in my free time.
If you’re interested in temporary identities, end-to-end encrypted messaging, or the current implementation, you can check it out here:
https://pct.monster
Feedback, bug reports, and suggestions are very welcome.
This project was originally designed for regulated regions such as China (PRC) btw.
Top comments (0)