Afterlight: the ghost you leave in the machine, sealed on your own laptop
This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine
What I Built
When someone dies, their family inherits a ghost: accounts nobody can find, subscriptions that keep billing, a laptop no one can unlock, thousands of photos on a drive no one knew existed. Almost nobody leaves a map.
Afterlight is that map. It is a local-first digital estate planner. A language model running on your own laptop interviews you, one plain question at a time, and turns your answers into a letter of instruction for the people you love: where things are, who to call, what to cancel, what you want. The letter is encrypted, and the key is split into five printable cards. Any three unlock it. Nothing ever touches a server.
I took "ghost in the machine" literally, and kindly. Día de los Muertos is about keeping the dead present through memory and care. Afterlight is the practical side of that: the last thing you do so that your family's grief is not also a scavenger hunt. It is not a chatbot that impersonates the dead. It never pretends to be anyone.
What it does:
- Interviews you. A local model asks natural follow-ups, but a state machine decides which topics are covered, so a small model stays on track.
- Refuses secrets. If you paste a password, card number, or seed phrase, a guard blocks it before it reaches the model or the disk. The letter says where things are ("password manager, emergency kit in the blue folder"), never what they are.
- Writes the letter from facts. Every fact comes from a validated record, not from model free text. The model only helps with personal messages, and you approve everything before sealing.
- Seals with open standards. age encryption, with the key split by SLIP-39 into 5 cards, any 3 of which unlock it.
- Recovers without me. The result opens with the stock age tool, so the family does not need Afterlight at all. I confirmed this: recovery opens with the stock age binary, no Afterlight code involved.
Demo
{% embed youtu.be %}
Code
{% embed hendrahend/afterlight %}
How I Built It
The central design choice is a hard split between what the model does and what plain code does.
!Afterlight create flow
!Afterlight recover flow
Purple boxes are where the open-weight model works. Everything else is plain, testable code.
The model: gemma3:4b (2.5 GB), served through Ollama on a Windows laptop with no GPU. The backend speaks an OpenAI-compatible API, and the model name lives in a config file, not in the code. I compared one model — gemma3:4b produced valid JSON on 5 of 5 answers at about 18 tokens/s, which was enough to move forward without a GPU.
The interview: a state machine owns the checklist (accounts, money, devices, people, wishes). The model rephrases each question naturally and extracts answers into a JSON schema using constrained output. Pydantic validates the result. If the model fails, static fallback questions keep the interview going. A small model plus a strict scaffold turned out to be more reliable than a big model improvising.
The guard: regex and entropy checks (Luhn for card numbers, seed-phrase patterns, high-entropy tokens) run on every answer before it goes anywhere.
The seal: a random 128-bit secret becomes the age passphrase, and the same secret is split with SLIP-39 (shamir-mnemonic, Trezor's reference implementation) into 3-of-5 word shares with checksums, printed as cards with a QR code. A RECOVERY.txt in the package explains, in plain language, how to open everything with only age and any SLIP-39 tool.
<!-- TODO: afterlight-recover-flow.png — upload and paste the URL -->
_Recover flow diagram coming once I capture the screenshots._
Recovery needs no model at all, only open tools.
Tests: 163 tests. Seal and recover round-trip for every 3-of-5 combination, fail correctly with only 2 shares, catch a single checksum typo in a share word, reject guard samples (API keys, card numbers, seed phrases), and a test fails on any non-loopback network connection.
I wrote the spec first in AGENTS.md and built the code with opencode following it. I decided the architecture and the hard rules up front (local-first, no plaintext on disk, guard every answer, no non-loopback network); the agent implemented to that plan rather than inventing its own.
Why Does Open Innovation Matter?
Privacy is the precondition, not a feature. This is the most sensitive data a person owns: accounts, money, family, wishes. With a closed API, every answer in the interview would travel to someone else's server. With an open-weight model on my own laptop, nothing leaves. You do not have to take my word for it: the demo runs with Wi-Fi off, and the test suite fails if the code opens a non-local connection.
This must outlive me. A digital legacy tool that depends on a company is a promise that expires when the company does. Afterlight's output uses open standards with independent implementations, age and SLIP-39. In thirty years, your family needs a copy of age and the instructions in RECOVERY.txt. They do not need this project, and they do not need me.
The model is swappable. Changing the model is one line of config. That is what lets the same tool run on a modest laptop today and on whatever small model is best next year.
It costs nothing to run, which matters for something people should do once and not pay a subscription to keep safe.
The honest tradeoff: a small local model is not as capable as a frontier model, so it cannot be trusted to improvise. That pushed me to give it a narrow job inside a deterministic structure, and I think the tool is safer for it.
The Spirit of It
The first time I ran the interview on my own life, the questions were simple but the answers were not. "Where are your accounts?" — I could answer that. "Who should get the photo drive no one else knows about?" — I had to decide, and deciding meant admitting there was something to decide. The guard is the moment I respect most: I pasted a real-looking API key into the test on purpose, and it refused to seal. It would rather be a pain in the moment than a secret leaked in a letter. And when three cards opened the letter and two did not, the 3-of-5 math stopped being a theorem and became a promise I could actually keep for my family.
Are your passwords in Git in plain text? SOPS encrypts them
SOPS (Secrets OPerationS) is an open-source command-line tool for encrypting secrets in config files: it encrypts the values in YAML, JSON, ENV and INI files (and whole binary files) with age, PGP, AWS KMS, GCP KMS, Azure Key Vault, HuaweiCloud KMS or HashiCorp Vault and OpenBao, so the secrets can sit in Git next to your config.
The names stay readable and only the values are encrypted, so diffs stay useful. It's MPL 2.0 licensed and a CNCF Sandbox project.
In this video:
- What SOPS is and how it works (one data key per file, locked for each key you choose; sops edit decrypts into your editor and encrypts again when you exit)
- 3 real uses: commit encrypted secrets to Git, one .sops.yaml rules file for dev and prod keys, and passing secrets to an app with exec-env
- The catch: you manage the keys, losing every key means losing the data, names stay readable, and what to do if a key leaks
- Who it's for, an alternative, and how to try it
Three real uses:
1. Commit secrets to Git: each value is encrypted with AES-256-GCM (AES256_GCM), so a diff points to the value that changed (the sops: block's date and checksum change too). With a .gitattributes entry and git config diff.sopsdiffer.textconv "sops decrypt", git diff can show decrypted diffs to anyone who holds a key.
2. One rules file: a .sops.yaml at the repo root holds creation_rules, where path_regex picks the keys for each file, for example one age key for development files and another for production. The first matching rule wins.
3. Pass secrets to an app: sops exec-env puts the decrypted values in one child process's environment, never written to disk; sops exec-file hands the app a FIFO or a temporary file instead.
Also in the docs: --encrypted-regex to encrypt only the data and stringData values of a Kubernetes secrets file, key groups with Shamir's Secret Sharing (for example, keys from 2 of 3 groups needed to decrypt), sops updatekeys and sops rotate, and an optional audit log to PostgreSQL.
The catch: SOPS doesn't create or store your master keys. You bring age or PGP keys, a cloud key service (AWS KMS, Google Cloud KMS, Azure Key Vault and HuaweiCloud KMS are paid services of those cloud providers) or HashiCorp Vault or OpenBao. A file can be decrypted as long as one of its keys still works, so if you lose every one, the data can't be recovered: keep a backup key (the docs describe a spare PGP key kept securely for emergency decryption). Only values are encrypted: names and the file's structure stay readable, and the docs advise keeping encrypted files reasonably private. If a key leaks, remove it from .sops.yaml, run sops updatekeys, then sops rotate for a new data key, and only then change the passwords themselves. YAML anchors and top-level arrays aren't supported, and the key service connection has no authentication or encryption of its own (the docs suggest an SSH tunnel). There's no web interface or central secrets server: it's a command-line tool.
Try it (with dummy values):
Download a binary for your platform from github.com/getsops/sops/releases
age-keygen -o key.txt (age-keygen comes with age, its own tool)
sops encrypt --age "$(age-keygen -y key.txt)" --output test.enc.yaml test.yaml
export SOPS_AGE_KEY_FILE=key.txt
sops decrypt test.enc.yaml
Back up key.txt: it's your private key.
Links:
Repo: getsops/sops
Docs: getsops.io
Installation: getsops.io
age keys: getsops.io
.sops.yaml rules: getsops.io
Key management and rotation: getsops.io
exec-env and exec-file: getsops.io
Security and threat model: getsops.io
Licence (MPL 2.0): github.com/getsops/sops/blob/main/LICENSE
age: FiloSottile/age
Alternative: Infisical, Infisical/infisical
Facts checked 2026-10-20 (SOPS v3.13.3, released 2026-07-23; 23,455 GitHub stars). Started at Mozilla in 2015, a CNCF Sandbox project since 2023. An open-source option to consider, not an endorsement. Not affiliated with the SOPS project, the CNCF, Mozilla or Infisical.
Narration: AI voice.
#SOPS #SecretsManagement #DevOps
Chapters
0:00 Intro
0:14 The fix
0:27 How it works
0:42 Three real uses
1:01 The catch
1:25 Who it's for
1:35 Try it
11 views
Mentions
Afterlight: the ghost you leave in the machine, sealed on your own laptop This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine What I Built When someone dies, their family inherits a ghost: accounts nobody can find, subscriptions that keep billing, a laptop no one can unlock, thousands of photos on a drive no one knew existed. Almost nobody leaves a map. Afterlight is that map. It is a local-first digital estate planner. A language model running on your own laptop interviews you, one plain question at a time, and turns your answers into a letter of instruction for the people you love: where things are, who to call, what to cancel, what you want. The letter is encrypted, and the key is split into five printable cards. Any three unlock it. Nothing ever touches a server. I took "ghost in the machine" literally, and kindly. Día de los Muertos is about keeping the dead present through memory and care. Afterlight is the practical side of that: the last thing you do so that your family's grief is not also a scavenger hunt. It is not a chatbot that impersonates the dead. It never pretends to be anyone. What it does: - Interviews you. A local model asks natural follow-ups, but a state machine decides which topics are covered, so a small model stays on track. - Refuses secrets. If you paste a password, card number, or seed phrase, a guard blocks it before it reaches the model or the disk. The letter says where things are ("password manager, emergency kit in the blue folder"), never what they are. - Writes the letter from facts. Every fact comes from a validated record, not from model free text. The model only helps with personal messages, and you approve everything before sealing. - Seals with open standards. age encryption, with the key split by SLIP-39 into 5 cards, any 3 of which unlock it. - Recovers without me. The result opens with the stock age tool, so the family does not need Afterlight at all. I confirmed this: recovery opens with the stock age binary, no Afterlight code involved. Demo {% embed youtu.be %} Code {% embed hendrahend/afterlight %} How I Built It The central design choice is a hard split between what the model does and what plain code does. !Afterlight create flow !Afterlight recover flow Purple boxes are where the open-weight model works. Everything else is plain, testable code. The model: gemma3:4b (2.5 GB), served through Ollama on a Windows laptop with no GPU. The backend speaks an OpenAI-compatible API, and the model name lives in a config file, not in the code. I compared one model — gemma3:4b produced valid JSON on 5 of 5 answers at about 18 tokens/s, which was enough to move forward without a GPU. The interview: a state machine owns the checklist (accounts, money, devices, people, wishes). The model rephrases each question naturally and extracts answers into a JSON schema using constrained output. Pydantic validates the result. If the model fails, static fallback questions keep the interview going. A small model plus a strict scaffold turned out to be more reliable than a big model improvising. The guard: regex and entropy checks (Luhn for card numbers, seed-phrase patterns, high-entropy tokens) run on every answer before it goes anywhere. The seal: a random 128-bit secret becomes the age passphrase, and the same secret is split with SLIP-39 (shamir-mnemonic, Trezor's reference implementation) into 3-of-5 word shares with checksums, printed as cards with a QR code. A RECOVERY.txt in the package explains, in plain language, how to open everything with only age and any SLIP-39 tool. <!-- TODO: afterlight-recover-flow.png — upload and paste the URL --> _Recover flow diagram coming once I capture the screenshots._ Recovery needs no model at all, only open tools. Tests: 163 tests. Seal and recover round-trip for every 3-of-5 combination, fail correctly with only 2 shares, catch a single checksum typo in a share word, reject guard samples (API keys, card numbers, seed phrases), and a test fails on any non-loopback network connection. I wrote the spec first in AGENTS.md and built the code with opencode following it. I decided the architecture and the hard rules up front (local-first, no plaintext on disk, guard every answer, no non-loopback network); the agent implemented to that plan rather than inventing its own. Why Does Open Innovation Matter? Privacy is the precondition, not a feature. This is the most sensitive data a person owns: accounts, money, family, wishes. With a closed API, every answer in the interview would travel to someone else's server. With an open-weight model on my own laptop, nothing leaves. You do not have to take my word for it: the demo runs with Wi-Fi off, and the test suite fails if the code opens a non-local connection. This must outlive me. A digital legacy tool that depends on a company is a promise that expires when the company does. Afterlight's output uses open standards with independent implementations, age and SLIP-39. In thirty years, your family needs a copy of age and the instructions in RECOVERY.txt. They do not need this project, and they do not need me. The model is swappable. Changing the model is one line of config. That is what lets the same tool run on a modest laptop today and on whatever small model is best next year. It costs nothing to run, which matters for something people should do once and not pay a subscription to keep safe. The honest tradeoff: a small local model is not as capable as a frontier model, so it cannot be trusted to improvise. That pushed me to give it a narrow job inside a deterministic structure, and I think the tool is safer for it. The Spirit of It The first time I ran the interview on my own life, the questions were simple but the answers were not. "Where are your accounts?" — I could answer that. "Who should get the photo drive no one else knows about?" — I had to decide, and deciding meant admitting there was something to decide. The guard is the moment I respect most: I pasted a real-looking API key into the test on purpose, and it refused to seal. It would rather be a pain in the moment than a secret leaked in a letter. And when three cards opened the letter and two did not, the 3-of-5 math stopped being a theorem and became a promise I could actually keep for my family.
Are your passwords in Git in plain text? SOPS encrypts them SOPS (Secrets OPerationS) is an open-source command-line tool for encrypting secrets in config files: it encrypts the values in YAML, JSON, ENV and INI files (and whole binary files) with age, PGP, AWS KMS, GCP KMS, Azure Key Vault, HuaweiCloud KMS or HashiCorp Vault and OpenBao, so the secrets can sit in Git next to your config. The names stay readable and only the values are encrypted, so diffs stay useful. It's MPL 2.0 licensed and a CNCF Sandbox project. In this video: - What SOPS is and how it works (one data key per file, locked for each key you choose; sops edit decrypts into your editor and encrypts again when you exit) - 3 real uses: commit encrypted secrets to Git, one .sops.yaml rules file for dev and prod keys, and passing secrets to an app with exec-env - The catch: you manage the keys, losing every key means losing the data, names stay readable, and what to do if a key leaks - Who it's for, an alternative, and how to try it Three real uses: 1. Commit secrets to Git: each value is encrypted with AES-256-GCM (AES256_GCM), so a diff points to the value that changed (the sops: block's date and checksum change too). With a .gitattributes entry and git config diff.sopsdiffer.textconv "sops decrypt", git diff can show decrypted diffs to anyone who holds a key. 2. One rules file: a .sops.yaml at the repo root holds creation_rules, where path_regex picks the keys for each file, for example one age key for development files and another for production. The first matching rule wins. 3. Pass secrets to an app: sops exec-env puts the decrypted values in one child process's environment, never written to disk; sops exec-file hands the app a FIFO or a temporary file instead. Also in the docs: --encrypted-regex to encrypt only the data and stringData values of a Kubernetes secrets file, key groups with Shamir's Secret Sharing (for example, keys from 2 of 3 groups needed to decrypt), sops updatekeys and sops rotate, and an optional audit log to PostgreSQL. The catch: SOPS doesn't create or store your master keys. You bring age or PGP keys, a cloud key service (AWS KMS, Google Cloud KMS, Azure Key Vault and HuaweiCloud KMS are paid services of those cloud providers) or HashiCorp Vault or OpenBao. A file can be decrypted as long as one of its keys still works, so if you lose every one, the data can't be recovered: keep a backup key (the docs describe a spare PGP key kept securely for emergency decryption). Only values are encrypted: names and the file's structure stay readable, and the docs advise keeping encrypted files reasonably private. If a key leaks, remove it from .sops.yaml, run sops updatekeys, then sops rotate for a new data key, and only then change the passwords themselves. YAML anchors and top-level arrays aren't supported, and the key service connection has no authentication or encryption of its own (the docs suggest an SSH tunnel). There's no web interface or central secrets server: it's a command-line tool. Try it (with dummy values): Download a binary for your platform from github.com/getsops/sops/releases age-keygen -o key.txt (age-keygen comes with age, its own tool) sops encrypt --age "$(age-keygen -y key.txt)" --output test.enc.yaml test.yaml export SOPS_AGE_KEY_FILE=key.txt sops decrypt test.enc.yaml Back up key.txt: it's your private key. Links: Repo: getsops/sops Docs: getsops.io Installation: getsops.io age keys: getsops.io .sops.yaml rules: getsops.io Key management and rotation: getsops.io exec-env and exec-file: getsops.io Security and threat model: getsops.io Licence (MPL 2.0): github.com/getsops/sops/blob/main/LICENSE age: FiloSottile/age Alternative: Infisical, Infisical/infisical Facts checked 2026-10-20 (SOPS v3.13.3, released 2026-07-23; 23,455 GitHub stars). Started at Mozilla in 2015, a CNCF Sandbox project since 2023. An open-source option to consider, not an endorsement. Not affiliated with the SOPS project, the CNCF, Mozilla or Infisical. Narration: AI voice. #SOPS #SecretsManagement #DevOps Chapters 0:00 Intro 0:14 The fix 0:27 How it works 0:42 Three real uses 1:01 The catch 1:25 Who it's for 1:35 Try it
I do not like the idea of self-hosting VaultWarden because I generally do not like the idea of application software requiring so much random access memory for even the simplest tasks. So, my idea was to use something like pass[0] or passage[1] (pass[0] + age[2]) on a remote server, but the problem arises when Yubikeys come into play. I am in no way, shape, or form, endorsing this PonyApp thingy and cannot vouch for it as I haven't audited it. But judging by what it says on the tin, it does appear like a candidate to solve the specific problem I have. [0]: passwordstore.org [1]: FiloSottile/passage [2]: FiloSottile/age