A practical architecture and security guide to visual tool chains, AES-GCM-encrypted IndexedDB projects, compressed URL recipes, and manual WebRTC DataChannel collaboration.
Nodes, wires, and execution are different concepts
A node identifies a tool, its expected input, and its last visible output; a wire describes where data should be passed next. This gives users one auditable view of a process, but a drawn connection is not permission to run a tool automatically or evidence that the data types are compatible.
Safe design separates planning from side effects. User-requested text handoff can be helpful, while file selection, password fields, code execution, network requests, and downloads must remain explicit. Each node should expose source, input preview, result, and error state.
- Persist stable tool identifiers.
- Explain incompatible data before handoff.
- Review output before propagation.
- Keep consequential action user-controlled.
IndexedDB persistence and on-device encryption
IndexedDB can store structured documents under project keys. A fresh AES-GCM initialization vector for every record, combined with the document identifier as authenticated additional data, helps detect tampering and prevents a ciphertext from being silently moved to a different record.
A non-extractable CryptoKey stored in the same origin's IndexedDB enables a serverless experience, but it is not the same threat model as a password vault. A compromised device, malicious extension, or hostile same-origin script can still ask the browser to use that key. Clearing site data removes the key and makes existing ciphertext unrecoverable, so users must manage privacy-safe backups for important work.
- Generate a fresh 96-bit IV per encryption.
- Validate schema and size before and after encryption.
- Explain quota failure; never promise unlimited storage.
- Expose project deletion and site-data controls.
URL recipes trade secrecy for portability
A compact JSON schema containing nodes, positions, and edges can be gzip-compressed and Base64url encoded into a database-free recipe. Base64url avoids `+`, `/`, and padding problems in query strings. A recipient must reject recipes that fail version, size, tool-slug, or edge-reference validation.
A URL is not a secret channel. Browser history, clipboard tools, chat systems, screenshots, and anyone who sees the link may copy its parameter. The secure default excludes both output and input. Including input must be a separate opt-in, and passwords or files must never be serialized. Marking the import route noindex is useful search hygiene, not access control.
- Always remove output.
- Exclude input by default.
- Validate size, version, slugs, and edge references.
- Never put sensitive data in a URL.
WebRTC can be serverless, but not signaling- or identity-free
RTCDataChannel can create a DTLS-protected browser-to-browser channel, yet peers still need to exchange SDP offers, answers, and ICE candidates. A design with no signaling service uses short-lived, single-use invitation and answer codes. Those codes may carry network candidates and belong in a separate trusted channel.
DTLS encrypts transport but does not prove who sent copied SDP in the real world. Both people should compare a short safety code derived from the room, peer identifiers, and both DTLS fingerprints by voice or through another trusted channel. A mismatch can reveal an active intermediary. A match is still not identity documentation, so live sharing also needs a separate explicit switch and should start paused.
Without STUN or TURN, firewalls, carrier NAT, symmetric NAT, and browser policy can block the path. Bounds on pending offers, concurrent transfers, chunks, complete documents, and DataChannel buffering reduce malformed-message and memory pressure.
- Keep iceServers empty and add no remote fallback.
- Make invitation and answer codes short-lived and single-use.
- Do not share documents before comparing the safety code.
- Never present a safety code as real-world identity verification.
Performance, accessibility, and verification checklist
The visual editor should not enter the home page's initial JavaScript path. Route-level dynamic loading, compression in a Web Worker, and bounded SVG wiring protect first paint and main-thread responsiveness. Touch users also need the full tool list, category filters, starter flows, auto-layout, undo, and standard form controls rather than a canvas-only interaction model.
A Local Agent plan should disclose confidence, steps, and selection reasons before it changes the canvas. Verification goes beyond TypeScript compilation: tests should cover recipe rejection, AES-GCM integrity, quotas, forged paths, expired SDP codes, symmetric safety codes, and static noindex/canonical output. Because WebRTC reachability depends on network topology, the interface must never promise a guaranteed connection.
- Load the heavy client only on workstation routes.
- Use a single-column mobile layout without overflow.
- Preview explainable AI plans before applying them.
- Keep browser and network limits visible.
Sources and verification
The following primary and official documentation was checked for this guide. Review each source's current version and change date as well.
Content is checked against visible ByteQuant product behavior and the listed primary sources where available. It is general information, not legal or security advice.