Help — Deadman System
Deadman Release
A per-file check-in and timed release system. If you go dark, your designated recipient gets access. Deniability is preserved throughout.
What the deadman system does
Each file can have an independent deadman configuration. You set a check-in interval and a release recipient. As long as you check in regularly, nothing happens. If you miss check-ins and cross your threshold, an encrypted release packet is sent to your designated recipient. The recipient can then retrieve your file.
The release packet is encrypted. It proves nothing without your Shape Key. Even after a deadman fires, the existence of data on the drive remains unproven to anyone who doesn't hold the key. Deniability is preserved end to end.
State machine
A deadman moves through explicit states. Transitions are one-way except for check-ins returning from Warning to Armed.
Armed
→
Warning
→
Triggered
→
Released
From any state, a check-in returns to Armed. Disarmed is always available from the Navigator if you have your Shape Key.
Armed
Active and waiting for check-ins. This is the normal operating state. The deadman is watching your check-in schedule. Nothing will happen as long as you check in before each deadline.
Warning (50% and 75% thresholds)
You've missed check-ins but haven't reached the trigger threshold. The system sends warning messages via your configured channel. A check-in at this stage returns to Armed. Three-stage escalation: warning at 50%, second warning at 75%, trigger at 100% of your configured timeout.
Triggered
You've crossed the threshold. The release packet is prepared for delivery. This state is one-way — you cannot check in to reverse a trigger. Disarm requires your Shape Key and active Navigator access.
Released
The encrypted release packet has been delivered to your designated recipient. The deadman has done its job. The file is now accessible to whoever holds the release packet and your Shape Key.
Release modes
Option A — Re-encrypt for recipient
On trigger, the .meta packet is re-encrypted to your recipient's public key (PGP, age, or X25519) and delivered via your configured channel. The recipient uses their own private key to decrypt the meta, then retrieves the file using the Shape Key you've shared with them separately. Most secure release path.
Option B — Meta only
On trigger, the .meta packet itself is delivered to your configured channel. Anyone holding the Shape Key can use it to retrieve the file. Simpler setup — no recipient public key required. The release channel must be one you trust.
The release packet proves nothing without your Shape Key
Either release mode delivers an encrypted packet. To an observer who intercepts it, it's junk binary. No proof of content. No proof of what it's for. Deniability at the release layer is preserved.
Check-in methods
You can check in from the Navigator app using your Shape Key, or using a check-in token stored separately. Check-in tokens use a narrow per-deadman derived key — the bulb can verify your check-in but cannot derive any other Shape Key values from the token.
Navigator check-in
Open the Navigator, load your credentials, navigate to the file's deadman status, and confirm. Full access to disarm or reconfigure if needed. Requires your Shape Key or Drive A.
Token-based check-in
A pre-generated HMAC check-in token. Can be stored separately from your Shape Key. Useful for regular automated check-ins or for check-ins from devices where you don't want your full credentials present.
Delivery channels
Email
The release packet is delivered to an email address you configure at arm time. The packet is encrypted — the email provider sees a binary attachment, not content. Use an address that will be accessible to your recipient if you're not.
Signal (via webhook)
Delivered via a configured Signal webhook endpoint. Requires a Signal bot or integration your recipient controls. Most private delivery path.
HTTP webhook
POST to any URL you control. Useful for automated workflows — a webhook that deposits the packet into your recipient's secure storage, triggers a notification, or routes to another system.
CLI commands
Navigator CLI
fgsp deadman arm — configure and arm a deadman on a file
fgsp deadman status — check current state and time remaining
fgsp deadman checkin — submit a check-in and reset the clock
fgsp deadman disarm — disarm (requires Shape Key; stops the clock)
fgsp deadman simulate — run the state machine forward with a fake clock to verify your config before committing
Use simulate before arming in production. It lets you walk through your escalation waterfall with a fake clock to verify the timing and delivery behavior before it's live.