Nexus SecOps -- Purple Team Arena POC (Y.js + WebRTC)

Read this before connecting

This is a proof-of-concept, not the full Purple Team Arena. It demonstrates the Y.js + WebRTC pattern that a future production arena would build on. It is not the arena itself, and it should not be treated as one. No authentication, no persistence, no moderation, no rate-limiting.

External CDN exception: Nexus SecOps is normally a zero-external-dependency static site. This tool is the documented exception. It loads yjs@13.6.18 and y-webrtc@10.3.0 from cdn.jsdelivr.net. The <script> tags use Subresource Integrity (SRI) hashes for tamper detection.

SRI hashes are PLACEHOLDERS in this POC The integrity="sha384-PLACEHOLDER_VERIFY_BEFORE_PUBLICATION" attributes below are placeholders. Before deploying this page publicly, regenerate real SHA-384 SRI hashes for the exact pinned version URLs at srihash.org (or via openssl dgst -sha384 -binary file.mjs | openssl base64 -A) and replace the placeholder strings. With placeholders, modern browsers will refuse to execute the modules and the tool will silently fail — that is the intended fail-closed behavior until verification.

Public WebRTC signaling servers: The y-webrtc default signaling endpoints are wss://signaling.yjs.dev, wss://y-webrtc-signaling-eu.herokuapp.com, and wss://y-webrtc-signaling-us.herokuapp.com. Your room name is sent to those servers in plaintext. Anyone who knows your room name can join. Do not transmit real attack details, real IOCs, real credentials, or anything sensitive over this channel. All defaults below are clearly synthetic.

What a real arena needs (and this POC does not provide): self-hosted signaling (e.g. Cloudflare Workers WebSocket or a dedicated y-websocket server), TURN servers for NAT traversal in restrictive networks, persistent storage (y-leveldb / y-indexeddb), authentication tied to identity, room-level access control, abuse moderation, and observability. See the "what this POC does NOT do" list at the bottom.

Educational use only. Use this to understand how CRDTs make peer-to-peer state sync feel real-time without a central server. Use it for tabletop demos with synthetic data. Do not use it to coordinate real incident response or to share live threat intelligence.

Connection

Room name (synthetic / demo)

Your display name

Disconnected

Shared Whiteboard

Click and drag to draw. Strokes sync to all peers via Y.Array. Each user gets an auto-assigned color from an 8-color palette.

Shared Threat Board

Synthetic data only. Use RFC 5737 IPs (192.0.2.x / 198.51.100.x / 203.0.113.x), example.com domains, and dummy hashes (e.g. aaaaaaaa...). Do not enter real IOCs.

Type

Value Notes (optional)

No entries yet. Connect and add a synthetic IOC.

Connected Users

Real-time peer list via Y.Map presence channel. Updates as users connect and disconnect.

Not connected.

How it works

Y.Doc -- single shared CRDT document for the room.
Y.Array -- whiteboard strokes + threat board entries (ordered, append-mostly).
Y.Map -- presence channel keyed by client ID.
WebrtcProvider -- peer discovery via signaling, then direct P2P data channels.
No server holds state. When the last peer leaves, the room is gone.

What this POC does NOT do

No persistenceState is ephemeral. When all peers disconnect, the room is gone. A page refresh loses your local view; reconnect re-syncs from any remaining peer. If you are the last peer and you refresh, all data is lost.
No authenticationAnyone who knows the room name joins. There is no identity verification. Display name is self-asserted and can be spoofed.
Public signalingThe y-webrtc defaults route discovery through public bridge servers. Your room name is sent there in plaintext. Use a private signaling server for anything non-demo.
No moderationNo rate limit, no content filter, no kick / ban. A malicious peer can spam strokes or threat entries until the document grows unbounded.
No NAT traversal beyond STUNy-webrtc uses public STUN servers but no TURN. Peers behind symmetric NATs or strict corporate firewalls will fail to connect.
Performance untested at scaleDesigned and tested with ~5 concurrent users on the same LAN. CRDT growth, sync convergence time, and bandwidth at 50+ users is unknown — Y.js can handle it, but this POC has not been profiled.
No SRI verification (placeholder hashes)The CDN integrity attributes are PLACEHOLDER strings. Browsers will refuse to load the modules until real SRI hashes are computed and pasted in. This is intentional fail-closed behavior.
No encryption beyond WebRTC defaultsWebRTC data channels use DTLS, but the application-layer payload is plaintext to anyone in the room. Treat this like a public chat channel.
For real productionAdd y-leveldb or y-indexeddb for persistence, y-websocket with a custom server (or Cloudflare Workers Durable Objects) for signaling and fallback transport, TURN credentials, OAuth-tied auth, room-level RBAC, audit logging, and abuse moderation.

Browser requirements

Chrome / Edge / Firefox / Safari recent versions. Requires:

WebRTC (RTCPeerConnection, RTCDataChannel) for peer-to-peer transport
WebSocket for signaling server connection
ES Modules (<script type="module">) for Y.js + y-webrtc imports
Subresource Integrity (SRI) — script will not execute without verified hashes
SVG for the whiteboard canvas