Glossary

Glossary

Project-wide terminology — roles, architecture, and security concepts used across the README, the CYD Console Guide, and the codebase. For console-specific quick-lookup terms (address types, epoch, preset states), see the CYD Console Reference.

Roles & architecture

• Decoy — a board that emits the fake crowd. Either a Ward or a Shade (below); has no screen of its own.
• Ward — the ESP32-C5 decoy role: dual-band Wi-Fi 6, meant as a fixed or vehicle-mounted node putting out a dense, dual-band crowd.
• Shade — the ESP32-C6 decoy role: lean, 2.4 GHz only, meant for everyday carry — a low-profile mobile decoy.
• Vigil — the controller/librarian role, running on an ESP32 "Cheap Yellow Display" (CYD) board. The one node with a screen: radar/status display, touch control, encrypted SD card library, and custody of the fleet's signing key. See the CYD Console Guide for everything it can show and do.
• Fleet — the whole set of nodes (one or more Wards/Shades plus a Vigil) working together over an encrypted ESP-NOW link.
• Churn — the engine that continuously ages out old fake identities and generates new ones, so the decoy population turns over like a real crowd instead of sitting as a fixed set of devices.
• Persona (cross-protocol) — a single synthetic "device" whose BLE and Wi-Fi identities are bound together, appearing and disappearing as a pair. This exists specifically so a correlator watching both radios can't isolate a real dual-radio phone by filtering out decoys that only ever show up on one radio.
• Population-match — the crowd-sizing logic: the number of live fake devices is driven by how many real nearby devices are actually observed (split across however many fleet nodes are live), so an empty room doesn't get flooded with fake traffic and a busy one doesn't look sparse.

Presets & operating modes

• Preset — one of six fleet-wide behavior settings pushed from the Vigil console's CONTROL page: PAUSE, STEALTH, NORMAL, DENSE, MAX, TURBO. See the CYD Console Guide → CONTROL for exactly what each one does.
• TURBO — the one preset that isn't a realism setting. Every board independently maxes its own BLE and Wi-Fi transmission — no crowd-size matching, no persona coupling — trading realism for raw volume. It's a manual, field-use flood mode (two-tap confirm required to send it), not something that runs by default. See the README's Legal & responsible use section for what it is and isn't.
• Baked regime — the simpler build/deploy mode (what the browser web-flasher installs): every board shares one built-in, publicly-known key. No enrollment step exists in this regime. Good for trying Simulacra out; not a private deployment.
• Provisioned regime (-DSIMULACRA_FLEET_PROVISION=1) — the full-security build mode: the Vigil mints a random fleet key at first boot, and decoys join through an on-air enrollment handshake rather than sharing a compiled-in key. This is what unlocks the FLEET ROSTER and enroll/revoke controls on the console.

Detection & learning

• Self-learning — decoys passively observe the shape (vendor, format, advertising structure) of real nearby devices and turn that shape into new decoy archetypes — never the device's actual identity. A learned template means "a device of this kind," never "this specific device."
• Law-3 — the hard safety rule enforced everywhere a template or signature could be learned or emitted: certain identity-carrying formats (e.g. Apple Continuity / Fast Pair pairing beacons) are always refused, so Simulacra can never accidentally trigger a real pairing prompt or emit something a phone would treat as an actual known accessory.
• Signature / tracker fingerprint — a known-device pattern (AirTag, SmartTag, Tile, Flock, Axon, etc.) the console can match against real-world adverts to flag a tracker or piece of surveillance hardware, as opposed to a device merely flagged for behaving suspiciously (reappearing near you repeatedly without matching a known signature).
• Escalation — how a detected follower's confidence grows over repeated sightings: NEW → RECURRING → PERSISTENT. See the Console Reference for the exact thresholds.
• Protection posture — the console's single honest one-word summary of your current state (CLOAKED / EXPOSED / DARK / HUNTED). See the Console Reference.

Security & keys

Two separate keys exist and protect different things — mixing them up is a common point of confusion:

• Fleet transport key — the shared symmetric key that encrypts status/threat/learn-sync traffic between every node on the mesh. All enrolled decoys hold the same copy of this key; it's what lets nodes talk to each other and the Vigil at all. It is not encrypted at rest — a physically recovered decoy's key is recoverable from flash. Revoking a lost/captured decoy (fleet roster → REVOKE) rotates the whole fleet onto a new key immediately.
• CONTROL signing key (-DSIMULACRA_CONFIG_CTRL=1) — a separate Ed25519 keypair. The Vigil holds the private half and signs every preset/CLEAR THREATS command; decoys hold only the public half and can verify a command but never forge one. Whoever holds the private key controls the fleet's behavior — the committed placeholder key in the repo is public, so it must be regenerated (tools/gen_ctrl_key.py) before deploying anything you actually care about.
• Enrollment — the on-air handshake by which a decoy in the provisioned regime proves itself and receives the fleet transport key from the Vigil, without ever sharing a pre-baked secret. Uses a trust-on-first-use (TOFU) model: you visually confirm a short fingerprint on the console against what the decoy prints over its own serial console before accepting it.

Everything else

For Bluetooth address types (RPA / NRPA / static), epoch, and the LIVE-vs-PENDING preset distinction, see the CYD Console Reference glossary — those are used specifically in the context of what the console displays.

---

Back to Home.