Architecting a Blind Relay: E2EE Clipboard Sync with Rust and Tauri

Jephter — Wed, 29 Apr 2026 12:19:09 +0000

A blind relay in Rust for encrypted clipboard sync: the client owns the key, and the server only moves ciphertext.

The Problem & Why Clipboard Sync Needs a Blind Relay

Most clipboard sync tools have a quiet design flaw: the server can read everything—and most people never notice.

Echo is my cross-device clipboard sync project. Copy text on one device, paste it on another. The hard part is not moving the text. The hard part is moving it without teaching the server how to read it. Echo is end-to-end encrypted clipboard sync built on a blind relay: Tauri sits at the native edge, the Rust/Axum backend handles auth and delivery, and the backend can move data without becoming part of the trust model.

In plain terms, a blind relay is a courier. It can check who you are, carry the package, and deliver it to the right place. It cannot open the package. In Echo, the package is ciphertext, and only the devices hold the key.

I built Echo this way because I did not want the usual trade. Not “encrypted in transit” with plaintext sitting in the middle. Not “encrypted at rest” with a backend that can still inspect what it relays. In Echo, “blind relay” means the server can authenticate the user, enforce rate limits, store ciphertext, send it to the right devices, and wake sleeping clients when needed. It does not get a decryption path.

That sounds abstract until you look at what actually ends up on a clipboard. SSH commands with temporary credentials. Customer data copied out of an internal tool. Admin URLs with tokens embedded in query params. One-time codes. Half-finished production queries. The clipboard is full of data that is sensitive precisely because it is short-lived and easy to treat casually.

The first time I felt this sharply was not during some security review. It was while moving a short-lived command between machines and realizing the fastest path was still a chat window. That is the normal failure mode. Not a dramatic breach. Just a convenient tool inheriting data it should never have seen.

What I built is simple to describe and strict in practice. Echo watches the clipboard on one device, encrypts the payload on the client with XChaCha20-Poly1305, sends ciphertext and a nonce through an Axum WebSocket relay, then decrypts only on the receiving device. The important choices are the typed WebSocket protocol, a one-owner WebSocket sink, bounded queues, and client-side encryption.

The result is a ciphertext relay, not a server-side encryption story. That distinction is the article.

Once I decided the server would be blind, the architecture got much simpler. The client owns the key. The client encrypts before the network. The backend handles delivery, ordering, and backpressure. Rust ended up being the right language because the hard parts were ownership, protocol design, concurrency, and removing bad states before they spread.

Rust, Tauri, and the Blind Relay Architecture

Echo has two distinct halves and one hard boundary between them.

The backend is an Axum service on Tokio with SQLx behind it. It owns authentication, the typed WebSocket protocol, live fan-out, bounded history, and push-token persistence. The client is a Tauri shell with a React app inside it. Tauri handles the native clipboard boundary and local persistence. The React layer handles keys, pairing, reconnect behavior, encryption, and UI state.

I do not think of Echo as a generic Tauri clipboard sync app. The Rust Tauri architecture matters because the trust boundary is split cleanly: native clipboard work at the edge, ciphertext coordination in the backend.

At the container level, the system is just a left-to-right relay with two side channels: durable ciphertext history and push wake-ups for sleeping devices.

AppState is intentionally thin. It coordinates three smaller subsystems instead of accumulating behavior until nobody trusts it:

SyncState owns live sessions, broadcast channels, and the in-memory history cache.
RateLimiter owns admission control.
PushManager owns push-token state and delivery limits.

I kept the hot path in memory on purpose. Sync services always have hot state. Hiding that behind the database does not make the system simpler. It just makes latency worse and makes it harder to know which copy of the state is in charge.

Key Design Decisions

I started with the trust boundary, not the stack.

Every real clipboard payload is encrypted on the client before it crosses the network:

export function encrypt(
  plaintext: string,
  key: Uint8Array
): { ciphertext: string; nonce: string } {
  const nonce = randomBytes(NONCE_BYTES);
  const cipher = xchacha20poly1305(key, nonce);
  return {
    ciphertext: toBase64(cipher.encrypt(new TextEncoder().encode(plaintext))),
    nonce: toBase64(nonce),
  };
}

I used XChaCha20-Poly1305 because I wanted a large nonce space and a boring API. That is the right kind of boring. The key stays on the device. Pairing moves it directly between devices through a QR or deep-link flow. The backend never gets a decryption path because I did not want one to exist.

If you are newer to this language: plaintext is the readable clipboard text, ciphertext is the encrypted output, and the nonce is a unique value used with the key for one encryption operation. The server stores and relays the ciphertext and nonce. It never gets the key.

The second design decision was to stop pretending the protocol was “basically one message type.” The early version leaned too hard on strings and I knew it was wrong while writing it. A sync system already has enough moving parts. It does not need control flow and data flow squeezed into the same shape because it feels convenient in the first commit.

A typed WebSocket protocol means different kinds of messages have different shapes. A handshake is not a clipboard payload. A presence event is not an error. That sounds obvious, but making it explicit removes a lot of guessing from the code.

The third decision was about ownership. I rejected Arc<Mutex<_>> around the WebSocket sink almost immediately. In async Rust that pattern usually turns into hidden coordination cost. The sink has one owner. Every other outbound path goes through a bounded channel. The lifecycle becomes obvious. Backpressure becomes explicit. Shutdown stops depending on unwritten rules.

The one-owner sink rule is simple: only one task writes to the socket. Everyone else sends messages to that task. That keeps the async write path boring, which is exactly what I want.

The fourth decision was to keep Tauri narrow. I wanted it exactly where it belongs: at the native edge, where clipboard behavior, local secret storage, and mobile bridge behavior are platform concerns. Everything above that line stays in app code.

One thing I would add next is protocol versioning. The current wire model is finally strict enough that version negotiation would be straightforward. Today the client and server still move in lockstep. I can live with that at this stage. I would not call it finished.

Deep Dives

The protocol only got sane once I modeled it as an ADT

Rust gives you tagged enums for a reason. If a protocol has multiple states with different meanings, model them that way.

An ADT here is just a Rust enum used to model the possible message types. Instead of carrying one loose object around and asking “what kind of thing is this?”, the compiler can force the code to handle each variant directly.

Echo now uses tagged enums on the wire:

#[derive(Debug, Clone, Serialize, Deserialize, PartialEq, Eq)]
#[serde(tag = "type", rename_all = "snake_case")]
pub(crate) enum ClientMessage {
    Handshake(HandshakeMessage),
    Clipboard(ClipboardMessage),
}

#[derive(Debug, Clone, Serialize, Deserialize, PartialEq, Eq)]
#[serde(tag = "type", rename_all = "snake_case")]
pub(crate) enum ServerMessage {
    Clipboard(ClipboardFrame),
    Presence(PresenceMessage),
    Error(ProtocolError),
}

That one decision removed a surprising amount of defensive code. The sync loop no longer has to guess meaning from special strings or overloaded fields. If a frame parses as ClientMessage::Clipboard, the code already knows it is the encrypted payload path. If it parses as Handshake, it is control flow. That is exactly the kind of separation I want the compiler enforcing.

The frontend mirrors the same model in desktop/src/protocol.ts, which matters more than people think. Client and server bugs get much rarer when both sides are forced to agree on the shape of the conversation instead of keeping two sets of assumptions in sync by luck.

Owning the WebSocket Sink in Async Rust

This is the part of the backend I would defend hardest in review:

let (sink, mut stream) = socket.split();

let (write_tx, write_rx) = mpsc::channel::<Message>(WRITER_CHANNEL_CAPACITY);
let mut writer_task = tokio::spawn(run_writer(sink, write_rx));

I gave the sink to one task and never looked back.

That tokio::spawn call also hides a Rust rule that is doing real architectural work for me: spawned futures must be Send + 'static. In practice, that means the task owns what it needs, can move across worker threads safely, and does not borrow some stack frame that will disappear under it. That is exactly what I want for connection handling.

That matters even if you are not deep into async Rust yet. A connection task should not depend on borrowed local state from a handler that may already be gone. Owning the data makes shutdown and cancellation much easier to reason about.

Once the sink belongs to run_writer, nobody else gets to send directly. History replay goes through the channel. Presence fan-out goes through the channel. Error frames go through the channel. Ping frames go through the channel. The write path is now one thing.

The teardown path gets simpler too:

tokio::select! {
    _ = &mut send_task => {},
    _ = &mut recv_task => {},
    _ = &mut ping_task => {},
    _ = &mut writer_task => {},
}

send_task.abort();
recv_task.abort();
ping_task.abort();
writer_task.abort();

That code is blunt on purpose. Sync systems do not usually fail in interesting ways. They fail in reconnect logic, stale tasks, and half-closed connections. I wanted the lifecycle to be clear enough that you could trace it in your head without inventing missing rules.

I also make the server authoritative for device identity after the handshake:

clipboard_msg.device_id = device_id.as_str().to_owned();
clipboard_msg.device_name = Some(device_name.as_str().to_owned());

That line closes a subtle but ugly class of bugs. A client does not get to authenticate once and then improvise a different identity mid-session. The server binds identity to the connection and stamps every clipboard frame with the validated values.

Tauri is where I stop clipboard echo loops at the edge

Cross-device clipboard sync has a boring failure mode: a remote write lands in the local clipboard, the local watcher sees it as a fresh local update, and the system starts rebroadcasting its own output.

I kill that loop in native code:

app.listen("clipboard-remote-write", move |event| {
    if let Ok(text) = serde_json::from_str::<String>(event.payload()) {
        let hash = calculate_hash(&text);
        if let Ok(mut guard) = ignored_hash_clone.lock() {
            *guard = Some(hash);
        }
    }
});

Then the polling loop ignores that exact value once:

if let Ok(mut guard) = ignored_hash.lock() {
    if let Some(ignored) = *guard {
        if ignored == current_hash {
            *guard = None;
            last_text = current;
            continue;
        }
    }
}

This is one of the few places where Arc<Mutex<_>> is not just acceptable, it is the right tool. The listener is synchronous. The critical section is tiny. There is no .await near the lock. I do not need an async primitive. I need one shared piece of state and a fixed rule.

I prefer this to debounce-style heuristics because timing lies. Clipboard APIs are noisy. Focus changes are noisy. “Probably the same event” is not an invariant. “Ignore the next clipboard value with this exact hash” is.

What the Type System Enforces

The best thing Rust bought me here was not speed. It was removing states I never wanted the system to represent.

DeviceId, DeviceName, and PushToken are validated newtypes. That pushes string validation to the edge. Once a handler or state method takes &DeviceId, I already know the value is non-empty and within bounds. That check is not scattered through the core logic.

AuthUser pushes authentication into the handler signature. If a route accepts AuthUser, Axum has already validated the bearer token and parsed sub into a Uuid. The unauthenticated state is not something the handler can forget to deal with because it never reaches that point.

The rate limiter uses an enum instead of a boolean:

pub(crate) enum IntervalPolicy {
    Enforce,
    Ignore,
}

This is a small example, but I like it because it is honest. true and false say nothing. Enforce and Ignore make the call say what it means.

The protocol is another example. Presence, handshake, clipboard, and error frames are separate types because they are separate concepts. The compiler keeps those paths apart at zero runtime cost. That is exactly the kind of leverage I want in a system that spends its life moving state between machines.

Performance, Backpressure, and Bounded State

Echo is built around limits because unbounded behavior is where small systems quietly become unreliable.

History in memory is capped at 50 messages per user. Durable history is trimmed to the newest 100 rows. The writer channel is capped at 64 messages. The client-side offline queue is capped at 200. Broadcast capacity scales by device count and clamps between 50 and 500.

Those are not random constants I sprinkled in at the end. They are the system deciding where backpressure should show up instead of pretending it can absorb infinite demand.

The rate limiter is also laid out to avoid extra contention:

#[derive(Clone, Default)]
#[repr(align(64))] // prevent false sharing between DashMap shard entries
struct RateLimitState {
    last_message: Option<Instant>,
    message_count: u32,
    window_start: Option<Instant>,
}

That #[repr(align(64))] is there because this state is hot and concurrent. I am not interested in cargo-cult micro-optimizations, but this one is cheap and justified.

I also accepted owned String payloads and real clones on fan-out because clipboard messages are usually small and the simpler ownership model matters more than shaving that path too early. The bigger performance win is structural: the system appends to memory and fans out first, then writes to Postgres behind the hot path. Delivery does not wait for the database.

The repo includes Criterion benches for broadcast and rate limiting. I care about them, but the larger performance story is simpler than any benchmark graph: bounded queues, no lock-across-await paths, one-owner sinks, and CPU-heavy work kept off the async scheduler when it belongs somewhere else.

This is not a sketch. The repo has benches for the hot paths, the protocol is typed end to end, and the backend, frontend, and native builds all pass.

Conclusion

The most important decision in Echo was refusing to let the server join the trust model.

Once that was fixed, the rest of the design got much clearer. The client owns secrets. The server owns coordination. Rust enforces the protocol shape and the ownership model. Tauri handles the native edge where web code has no business bluffing.

That is the takeaway I would carry into any system like this. If your relay can read the data, it is not a relay anymore. It is the problem.

The code is public, including the typed protocol, WebSocket handler, Tauri clipboard edge, and architecture diagram: github.com/jephter-olamiposi/echo.

DEV Community: Jephter