WordPress WebSocket Relay in Rust with Yjs CRDT Provider for WP 7.0

Name: WordPress WebSocket Relay in Rust with Yjs CRDT Provider for WP 7.0
Availability: InStock
Author: jaredrethman

by jaredrethman·May 8, 2026·3 points·1 comment

Visit Project View on HN

AI Analysis

●●●BangerSolve My ProblemBig Brain

AES-256-GCM encryption at the PHP layer before the relay sees anything is brilliant.

Strengths

•Blind relay architecture means the server never decrypts user event payloads.
•Native Yjs sync provider drops into WP 7.0 without extra configuration.
•HMAC-SHA256 signed publishes prevent spoofed events from compromised plugins.

Weaknesses

•Relies on a hosted relay service; self-hosting docs are thin compared to SaaS pitch.
•WordPress audience may struggle with Rust server deployment and maintenance.

Post Description

WordPress 7.0 ships collaborative block editing via Yjs CRDT. The default transport is HTTP polling. The RTC layer exposes a `sync.providers` filter so you can swap in your own transport, so I built a WebSocket-based Yjs sync provider for it.

While building that I realized WebSockets unlock a lot more in WordPress than just RTC. Any `add_action` hook can now push a realtime `CustomEvent` to connected browsers without polling or a custom server.

The stack:

- Relay server: Rust (Axum/Tokio), WebSocket-first with SSE fallback

- Event payloads: AES-256-GCM encrypted before leaving WordPress, the relay only ever sees ciphertext

- Publish auth: HMAC-SHA256 signed requests

- Browser connections: short-lived scoped JWTs (5 min, auto-refresh)

- WordPress plugin: open source (GPL-2.0), hosted relay is WPSignal

GitHub - https://github.com/wpsignal/wordsocket/

A few use cases we've seen: live WooCommerce order updates, breaking news flags, realtime comment counts, and collaborative editing via WP 7.0 RTC. Curious what else people would build with a realtime event bus wired into WordPress action hooks?