I’m building LANCAST, a privacy-first, peer-to-peer communication system designed around a fundamentally different networking model: no cloud, no servers, no accounts, and no unnecessary persistence. ↗
LANCAST enables devices on the same local network to discover each other and communicate directly through encrypted peer-to-peer sessions, while keeping the communication lifecycle intentionally ephemeral.
The core idea is simple:
If sensitive data never needs to leave the local network and does not need to become a permanent record, the amount of infrastructure that needs to be trusted, secured, and maintained can be dramatically reduced.
LANCAST is currently being developed as a native desktop application using React 18, Tauri 2, and Rust.
The frontend handles the application interface and user interaction, while the Rust backend owns the security-sensitive networking, cryptographic operations, native integrations, and communication layer.
The architecture is intentionally separated into clear boundaries:
React → Tauri IPC → Rust Core → Local Network
The repository contains the implementation as well as a dedicated architecture document describing the system in greater depth. ↗
There is no conventional HTTP messaging backend sitting between communicating peers.
There is no cloud relay required for the core LAN communication model.
The Tauri IPC boundary provides the integration surface between the application interface and the native Rust layer, keeping security-critical functionality outside the frontend execution environment.
LANCAST is being designed around three core principles.
No cloud dependency.
The communication model is designed to operate directly over the local network rather than requiring a remote messaging infrastructure.
No mandatory account system.
Peers can communicate locally without requiring the conventional cloud identity and authentication workflow used by centralized messaging platforms.
Ephemeral application state.
Operational messages, sessions, keys, groups, and related state are maintained in memory rather than being built around a conventional persistent messaging database.
The philosophy is straightforward:
Minimize the existence of sensitive data instead of building an enormous permanent archive and attempting to protect it afterward.
When the application terminates, its in-memory application state is reclaimed with the process rather than becoming a permanent cloud conversation history.
This is not simply a privacy feature added at the interface level.
It is part of the architecture.
LANCAST does not require users to manually exchange IP addresses before communicating.
Peers can discover each other through UDP multicast on the local network.
A LANCAST-specific protocol marker is used to identify relevant discovery frames, allowing participating instances to recognize one another.
The conceptual flow is:
Local Network → Multicast Discovery → Peer Detection → Session Establishment
The network itself becomes the discovery layer.
There is no central peer directory that every device needs to contact before discovering another local participant.
Once two peers discover each other, LANCAST establishes a cryptographic session using Curve25519 ECDH.
The resulting shared secret is expanded into session-specific cryptographic material through HKDF-SHA256.
Application traffic is then protected using AES-256-GCM authenticated encryption.
The communication protocol also incorporates message authentication and sequence-based replay protection.
Conceptually, the security pipeline is:
Peer Discovery → Key Exchange → Key Derivation → Encryption → Transport → Authentication → Replay Validation → Decryption
The important architectural property is that the communication session is established directly between peers rather than being delegated to a centralized messaging service.
After discovery and session establishment, communication moves directly between participating peers.
LANCAST currently uses TCP for its full-duplex messaging and transfer channel, with application-level framing and encrypted payloads.
The communication path can be represented as:
Application Data
↓
Session Cryptography
↓
Encrypted Frame
↓
TCP Transport
↓
Remote Peer
↓
Authentication
↓
Decryption
This removes the conventional application-level intermediary from the communication path.
The peers communicate with each other instead of sending the conversation through a centralized messaging server.
One of the defining architectural decisions in LANCAST is its ephemeral state model.
The frontend uses Zustand for application state, while the backend maintains operational state through in-memory Rust structures. ↗
There is no conventional message-history database sitting behind the communication layer.
There is no server-side conversation archive that needs to be synchronized back to the client.
The intended lifecycle is:
Create → Use → Terminate → Disappear
This changes the security and privacy model significantly compared with systems designed around permanent communication histories.
The objective is not to create a more secure permanent archive.
The objective is to avoid creating an archive where one is not necessary.
LANCAST also approaches privacy beyond network encryption.
For protected application views, the desktop layer can use native operating-system mechanisms to restrict supported screen-capture paths.
On Windows, LANCAST uses SetWindowDisplayAffinity with WDA_EXCLUDEFROMCAPTURE.
On macOS, native NSWindow sharing configuration is used for the corresponding protection mechanism.
Linux support is handled on a best-effort basis because screenshot behavior varies significantly depending on the compositor and display environment.
The important distinction is that this protection is implemented at the native desktop layer rather than being treated as a frontend-only visual feature.
LANCAST includes an explicit Broadcast Mode for controlling when a peer announces its presence on the local network.
Rather than assuming that a UI action automatically means a network operation succeeded, the system can wait for actual peer acknowledgement before treating the broadcast state as active.
This creates a distinction between:
Application Intent
and
Confirmed Network State
That distinction becomes increasingly important as LANCAST evolves toward more complex peer-to-peer communication.
LANCAST is not limited to one-to-one messaging.
The system includes a group communication model supporting public and private groups, membership management, invitations, and real-time group events.
Public groups can participate in local discovery.
Private groups follow a more controlled membership model, where invitation and membership state determine participation.
This extends the peer-to-peer architecture from individual sessions into controlled local communication spaces.
LANCAST also supports direct file transfer through the encrypted peer connection.
Files are divided into chunks and transmitted through the established communication channel before being reconstructed by the receiving peer.
The current implementation supports transfers up to 100 MB per transfer, with multiple files supported within the documented transfer model.
The conceptual pipeline is:
File → Chunking → Encryption → Encrypted Transport → Reassembly → User-Controlled Download
The receiving application does not need to immediately turn the transferred data into permanent application storage.
The user controls when the received file is downloaded.
This preserves the broader ephemeral-data philosophy of the system.
The current technology stack is intentionally focused on combining modern UI development with native systems programming.
Frontend: React 18, JSX
Styling: Tailwind CSS
State Management: Zustand
Animation: Framer Motion
Native Runtime: Tauri 2
Backend: Rust
Networking: UDP Multicast + TCP
Key Exchange: Curve25519 ECDH
Key Derivation: HKDF-SHA256
Encryption: AES-256-GCM
Integrity / Authentication: HMAC-SHA512
Build Tooling: Vite
Distribution: Windows, macOS, and Linux
The project is being developed as a native application rather than as a browser-only communication interface. ↗
The choice of Rust + Tauri is fundamentally architectural.
A modern React frontend provides a productive environment for building the interface and application experience.
Rust provides the native systems layer required for security-sensitive functionality such as:
Network communication
Cryptographic operations
Session management
File streaming
Native operating-system integration
Window-level privacy controls
Resource management
Tauri provides the bridge between these two worlds while keeping the native application layer lightweight.
The result is a stack where the interface can remain highly productive while the lower-level communication and security logic remains under native control.
LANCAST is now expanding beyond its original desktop implementation.
The repository contains a dedicated LanCastMobile project initialized around React Native, marking the beginning of the mobile direction. ↗
However, mobile support is not simply a matter of recreating the desktop interface.
Mobile operating systems introduce additional constraints around:
Local-network permissions
Background execution
Process lifecycle
Battery consumption
Network discovery
Sandboxing
Platform-specific networking behavior
The real challenge is preserving LANCAST's communication model across different execution environments while respecting the constraints imposed by each operating system.
The most interesting part of LANCAST is not the chat interface.
It is the underlying communication architecture.
The project combines:
Local Peer Discovery
Ephemeral Cryptographic Sessions
Authenticated Encrypted Transport
RAM-Only State
Native OS Security Controls
Direct Peer-to-Peer Networking
Cross-Platform Native Execution
into a single communication system.
At that point, LANCAST starts becoming more than a messaging application.
It becomes an exploration of what a local-first communication protocol can look like when privacy is treated as an architectural constraint from the beginning.
There are several significant systems problems still ahead.
Mobile Networking
Maintaining reliable peer discovery and communication under mobile operating-system restrictions.
Mesh Networking
Allowing communication to extend beyond directly reachable peers through multi-hop local routing.
Ephemeral Voice
Introducing real-time voice communication while preserving the LAN-only communication model.
Protocol Evolution
Designing versioned protocol frames so that future LANCAST releases can evolve without unnecessarily breaking existing deployments.
Security Hardening
Continuously reviewing the cryptographic protocol, IPC boundaries, memory lifecycle, authentication flow, and native integrations.
Cross-Platform Consistency
Maintaining comparable privacy characteristics across Windows, macOS, Linux, and mobile platforms despite fundamentally different OS capabilities.
These are not simply UI features.
They are systems-engineering problems.
The next stages of LANCAST include:
• Ephemeral voice channels over local networks
• Disappearing message timers
• Multi-hop mesh routing
• CLI companion tooling for headless environments
• Plugin APIs for custom message renderers
• Continued mobile development
The long-term objective is not to recreate another cloud-based social platform.
It is to build a reusable communication layer that can operate locally without requiring permanent centralized infrastructure.
Modern communication has normalized a very specific architecture:
Device → Internet → Cloud → Internet → Device
LANCAST asks a different question:
What if the devices could simply communicate directly?
For many local environments, the participants are already physically close and connected to the same network.
A classroom may not need a remote messaging server to exchange information.
A laboratory may not want sensitive communication routed through an external service.
A private office may prefer communication that remains inside its network.
A temporary event may need communication without requiring every participant to create an account.
A development environment may benefit from an isolated local communication channel.
In all of these cases, the local network already exists.
LANCAST explores whether that network can become the communication infrastructure itself.
The long-term vision is larger than messaging.
The system is being designed toward a communication layer capable of supporting:
Desktop ↔ Desktop
Desktop ↔ Mobile
Mobile ↔ Mobile
and eventually:
Peer ↔ Peer ↔ Peer
through local and mesh-based networking.
Messaging is the starting point because it provides a clear demonstration of the architecture.
The underlying concept is much broader.
LANCAST is currently a Work in Progress and is being actively developed.
The public repository contains the desktop implementation, native Rust/Tauri layer, mobile project foundation, architecture documentation, build configuration, and ongoing project history. ↗
The project is open source under the MIT License. ↗
The current milestone is not about declaring the system finished.
It is about getting the foundations right first:
Networking.
Cryptography.
Protocol Design.
State Lifecycle.
Native Security.
Cross-Platform Architecture.
Everything else can be built on top of those foundations.
LANCAST is being built around one principle:
Communication should not require permanent infrastructure.
No unnecessary intermediary.
No mandatory cloud.
No permanent communication archive by default.
Just peers, a local network, and an encrypted communication layer.
Broadcast on LAN. Encrypted. Instant. Traceless. ↗