Screenshot portability

[tomcardoso]

Build in a way to save unencrypted versions of screenshots so they can be fed to something like Obsidian for analysis.

[tomcardoso]

@claude, the idea here is that right now screenshots are locked into a given Sourcerer instance and can't be read by anything other than Sourcerer. It would be interesting to be able to offer unencrypted versions of the files in a specified folder so that tools like Obsidian or AI services can be connected to that folder, ingest the screenshot contents and analyze them. Can you stub out a more detailed version of this issue here?

[claude]

Claude finished @tomcardoso's task in 1m 57s —— View job

---

Detailed issue stub

Here's a fleshed-out version of this feature request based on how screenshots are currently stored:

---

Background / current state

Screenshots are captured via the browser extension and stored as AES-256-GCM encrypted .enc files inside the Sourcerer data directory (e.g. ~/Library/Application Support/Sourcerer/screenshots/ on macOS, or the user's custom vault path if one is set). The encryption key is derived from the user's password via Argon2id, and the IV is stored in the SQLite database alongside screenshot metadata. This means:

• No tool other than Sourcerer can read these files
• Viewing a screenshot requires the app to be running and unlocked
• There's no way to feed screenshots into Obsidian, AI services, or any other workflow without manually downloading them one at a time via the existing "Save screenshot" dialog

---

Proposed feature: unencrypted mirror folder

Add a configurable screenshot export folder — a user-designated directory that Sourcerer keeps in sync with decrypted, readable versions of all screenshots. External tools (Obsidian vaults, local AI pipelines, etc.) can point at this folder and consume the files directly.

---

Proposed behaviour

Settings

• New option in the settings panel: "Screenshot export folder" (disabled by default)
• Folder picker to choose any directory (with a warning that files here are not encrypted)
• The folder should be outside the vault — Sourcerer should warn if the user tries to pick a path inside their vault directory
• Option for the format of companion metadata files (see below)

Sync lifecycle

• When a screenshot is assigned to a contact → decrypted copy is written to the export folder immediately
• When a screenshot is deleted in Sourcerer → corresponding file in the export folder is also deleted
• When the feature is first enabled → a one-time bulk export of all existing screenshots is offered (with a progress indicator)
• When the feature is disabled → optionally delete the folder contents or leave them in place (user's choice)

File naming and folder structure

Two options worth considering:

Option A — flat, with contact name in filename:

{export-folder}/
  jane-doe_2026-05-22_143012.png
  jane-doe_2026-05-22_150431.png
  john-smith_2026-05-23_091204.png

Option B — per-contact subdirectory (better for Obsidian):

{export-folder}/
  jane-doe/
    2026-05-22_143012.png
    2026-05-22_150431.png
  john-smith/
    2026-05-23_091204.png

Option B is probably better for Obsidian use since the folder maps to a "note" or "person" concept naturally.

Companion metadata files (optional)

For Obsidian compatibility and AI ingestion, each screenshot could have a companion .md file with YAML frontmatter:

---
contact: Jane Doe
url: https://example.com/article
captured_at: 2026-05-22T14:30:12Z
sourcerer_id: abc123
---

This would let Obsidian link screenshots back to source URLs and make the metadata searchable. Could be toggled separately from the main export.

---

Implementation notes (for whoever picks this up)

The main work lives in src/main/ipc/screenshots.ts. The key functions to look at are:

• loadScreenshot() — already decrypts a screenshot to a buffer; the export path just needs to call this and write the result to disk instead of (or in addition to) returning it to the renderer
• screenshots:assign handler — the right place to hook in "write decrypted copy after saving"
• screenshots:delete handler — needs to also remove the export-folder copy
• src/main/utils.ts — the getPaths() function is where the export folder path config should live

A new IPC handler (screenshots:sync-export-folder or similar) would handle the initial bulk export. The export folder path should be stored in a settings table (there's likely already one) or in vault.json.

Security / UX considerations

• The export folder warning should be prominent and persistent — this is the most important UX concern. Users need to understand that anyone with access to that folder can see the screenshots without a password
• If the vault is on cloud storage (Dropbox, iCloud, etc.), the export folder should probably not be inside it by default — but the user might want it in their Obsidian vault which could itself be on cloud storage. The app shouldn't block this, just warn clearly
• Renaming a contact in Sourcerer: if using per-contact subdirectories, the folder should be renamed to match (or at minimum the old folder left in place and a new one created)

---

Out of scope (for this issue)

• Encrypting the export folder with a separate password
• Live filesystem watching / two-way sync
• Exporting contact metadata (name, notes, etc.) alongside screenshots — that's a separate export feature

---

• Gather context: explore how screenshots are stored in the codebase
• Understand the request: stub out a detailed issue for screenshot portability
• Draft and post detailed issue expansion

[tomcardoso]

@craigsilverman does ☝️ look right?