From 4a471ee31a850ac14ae7b0cdf7c9f3f740f6cab1 Mon Sep 17 00:00:00 2001 From: "Aaron D. Lee" Date: Thu, 2 Apr 2026 16:49:13 -0400 Subject: [PATCH] Add narrative and packaging strategy docs why-fieldwitness.md: Plain-language narrative for non-technical audience (journalists, grant reviewers). Opens with local government scenario, explains the evidence gap, positions FieldWitness against existing tools, includes three usage scenarios and technical appendix. packaging-strategy.md: Four-tier packaging plan ordered by feasibility for a solo developer. Hosted demo first (8-12h effort), standalone binary second, mobile app with grant funding, browser extension last. Includes onboarding flow, pricing model, and strict sequencing. Co-Authored-By: Claude Opus 4.6 (1M context) --- docs/planning/packaging-strategy.md | 262 ++++++++++++++++++++++++++++ docs/planning/why-fieldwitness.md | 149 ++++++++++++++++ 2 files changed, 411 insertions(+) create mode 100644 docs/planning/packaging-strategy.md create mode 100644 docs/planning/why-fieldwitness.md diff --git a/docs/planning/packaging-strategy.md b/docs/planning/packaging-strategy.md new file mode 100644 index 0000000..4277bc6 --- /dev/null +++ b/docs/planning/packaging-strategy.md @@ -0,0 +1,262 @@ +# Packaging Strategy + +**Audience:** Internal planning (solo developer) +**Status:** Active planning document +**Last updated:** 2026-04-01 + +--- + +## The core problem + +FieldWitness is a Python CLI and Flask web application installed via `pip install fieldwitness`. This requires: + +- Python 3.11 or later installed on the system +- Comfort with a terminal +- Familiarity with pip, virtual environments, and dependency management +- Willingness to debug installation issues (missing system libraries, wheel build failures, PATH problems) + +This excludes an estimated 95%+ of the target audience. A journalist covering a school board meeting will not open a terminal. The feedback is consistent: journalists want, in order of preference, an iPhone app, a Mac drag-and-drop application, or a hosted web service. `pip install` is where they stop. + +The attestation capability -- prove this file is mine, unaltered, timestamped -- is the product journalists would pay for. Everything else (federation, steganography, killswitch) is invisible or incomprehensible to this audience until the core attestation experience is accessible without developer tooling. + +--- + +## Packaging tiers + +Ordered by impact and feasibility for a solo developer working 10-15 hours per week. + +### Tier 1: Hosted demo (lowest effort, highest reach) + +**What it is.** A public web instance where journalists can upload a file and see attestation in action. No install. Just a URL. + +**What it provides:** + +- Immediate "try it" experience for anyone evaluating the tool +- Eliminates every installation barrier simultaneously +- Provides the demo for grant applications, conference talks, and blog posts +- Gives the project a URL to share that is not a GitHub repository + +**What it is NOT:** + +- Not for production use with sensitive files. A public demo instance cannot make security guarantees about uploaded content. The demo page must state this clearly. +- Not a replacement for self-hosted or local deployment for real operational use. + +**Implementation:** + +- Deploy the existing Flask web UI on a VPS (DigitalOcean droplet, Hetzner, or similar) +- Restrict to attestation and verification only (disable fieldkit, stego, admin, drop box) +- Add a prominent banner: "This is a public demo. Do not upload sensitive files." +- Rate limit uploads (e.g., 10 per IP per hour, 50 MB max) +- Auto-purge uploaded files after 24 hours +- HTTPS via Let's Encrypt (not self-signed) +- Minimal hardening: firewall, fail2ban, unattended-upgrades +- Estimated hosting cost: $5-12/month + +**Feasibility:** High. This is a deployment task, not a development task. The Flask web UI already handles attestation and verification. The work is configuration, hardening, and adding the demo-mode restrictions. + +**Estimated effort:** 8-12 hours for initial deployment, then minimal ongoing maintenance. + +**Priority:** Do this first. Before anything else. Every other packaging tier benefits from having a live URL to point people to. + +### Tier 2: Standalone binary (medium effort) + +**What it is.** A downloadable application that runs without Python, pip, or any developer tooling. Double-click to start. + +**Options, in order of preference:** + +**Option A: PyInstaller / PyApp standalone.** + +- Bundle the Flask web UI into a single executable (Mac .app, Linux AppImage, Windows .exe) +- User downloads, double-clicks, browser opens to `localhost:5000` +- PyInstaller is mature and well-documented for Flask apps +- Produces a ~50-100 MB download (Python runtime + all dependencies bundled) +- Cross-platform builds require CI on each platform (GitHub Actions has Mac/Linux/Windows runners) +- Code signing is needed for Mac (Apple notarization) and Windows (Authenticode) to avoid security warnings that will terrify the target audience. Mac notarization requires a $99/year Apple Developer account. Windows Authenticode signing requires a code signing certificate ($200-500/year or free via SignPath for open source). +- Estimated effort: 20-30 hours including CI setup and platform testing + +**Option B: Homebrew tap (Mac only).** + +- `brew install fieldwitness` handles Python, dependencies, and PATH setup +- Lower effort than PyInstaller (no bundling, just a formula) +- But still requires users to have Homebrew installed, which requires a terminal +- Better suited as a secondary distribution channel for Mac users who are slightly technical +- Estimated effort: 4-6 hours + +**Option C: curl-pipe-bash installer.** + +- `curl -sSL https://fieldwitness.org/install.sh | bash` +- Script installs Python if needed, creates a virtual environment, installs FieldWitness +- Creates a desktop shortcut or menu entry +- Common in developer tools (rustup, Homebrew itself) but asks users to paste terminal commands from the internet, which security-conscious users rightly distrust +- Estimated effort: 8-12 hours + +**Recommendation:** Start with Option A (PyInstaller) for Mac and Linux. Skip Windows initially -- the target audience skews heavily Mac. Add the Homebrew tap as a bonus for Mac users who prefer it. + +### Tier 3: Mobile app (high effort, highest value) + +**What it is.** An iPhone (and eventually Android) camera app that attests photos at the moment of capture. + +**Why this matters:** + +- Smartphones are where journalists capture evidence +- Attestation at capture time is stronger than attestation after transfer to a laptop +- This is the ProofMode competitor +- This is the $10/month product -- the thing a journalist would put on an expense report +- "Take a photo, it's automatically attested" is the simplest possible user experience + +**What it would do:** + +- Custom camera interface (or hook into the system camera via share sheet) +- At capture: strip dangerous EXIF fields, preserve evidentiary fields, compute hashes, sign with on-device Ed25519 key, append to local chain +- Store attestation records locally +- When connected to Wi-Fi or organizational network: sync attestation records to Tier 2 org server +- Export evidence packages for individual photos +- Push notification reminders for dead man's switch check-in + +**Technical approach:** + +- **Swift (iOS) or Kotlin (Android)** for native apps, or **React Native / Flutter** for cross-platform +- The cryptographic core (Ed25519, SHA-256, hash chain) would need to be reimplemented or wrapped via a shared library +- The `cryptography` Python library that FieldWitness uses wraps OpenSSL, which is available on both platforms +- Alternatively: Rust core library compiled to iOS/Android via FFI, with native UI layer +- A pragmatic first step: use the phone's share sheet to send files to a local FieldWitness web UI running on the same network (Tier 2 server), avoiding native app development entirely + +**Feasibility:** High effort. Likely requires grant funding to cover 3-6 months of focused development. A React Native approach with a Rust crypto core would minimize platform-specific work but still represents a major project. + +**Estimated effort:** 200-400 hours for a minimum viable iOS app. Double for cross-platform. + +**Prerequisites:** The hosted demo (Tier 1) must exist first. The standalone binary (Tier 2) should exist first. Building a mobile app before the desktop/web experience is solid would be premature optimization. + +### Tier 4: Browser extension (speculative) + +**What it is.** A browser extension that attests web pages, screenshots, and downloaded documents. + +**Use case:** "Prove this web page existed in this form on this date." A Wayback Machine for individual journalists, creating locally-held proof rather than depending on the Internet Archive. + +**Why it is speculative:** + +- The Wayback Machine already exists and is widely trusted +- Browser extensions have a difficult security model (broad permissions, update mechanisms, store review) +- The overlap with the core FieldWitness audience is uncertain -- this is closer to OSINT tool than field evidence tool +- Significant effort for uncertain adoption + +**If pursued:** A minimal extension that captures the page HTML + screenshot, computes hashes, and sends to a local FieldWitness instance for attestation. Not a standalone attestation tool -- a bridge to the existing system. + +**Estimated effort:** 40-80 hours for a minimal Chrome extension. + +**Recommendation:** Do not build this until Tiers 1-3 are established and there is clear user demand. + +--- + +## Onboarding flow design + +The goal: a non-technical journalist goes from "what is this?" to "I just attested my first file" in under three minutes. + +### The hosted demo flow (Tier 1) + +1. Journalist arrives at `fieldwitness.org` (or wherever the demo is hosted) +2. Landing page: one paragraph explaining what FieldWitness does (use the language from [why-fieldwitness.md](why-fieldwitness.md)), plus a prominent "Try it now" button +3. Click "Try it now" -- goes directly to the attestation page +4. Upload any file (photo, document, PDF) +5. FieldWitness displays the attestation result: + - The file's cryptographic fingerprint (SHA-256 hash, displayed as a short ID) + - The timestamp + - A "Download verification receipt" button +6. The receipt is a small JSON file (or a one-page PDF) that includes everything needed to verify the attestation later +7. Below the result: "Now try verifying it" -- a link to the verification page where they upload the file and the receipt, and see confirmation that the file matches + +**The "aha moment"** is step 5-7: seeing the verification receipt for the first time and understanding that this receipt can prove the file's integrity to anyone, anywhere, without trusting FieldWitness or any third party. + +### The installed flow (Tier 2+) + +1. Download and open FieldWitness (double-click the .app on Mac) +2. Browser opens to the local web UI +3. First-run wizard: "FieldWitness needs to create a cryptographic identity. This is like a digital signature -- it proves attestations came from you." One button: "Create identity." +4. Identity created. User sees their fingerprint (a short hex string) and a recommendation to back it up. +5. "Attest your first file" -- same upload flow as the demo, but now signed with their identity +6. Download evidence package -- a ZIP containing the original file, the attestation record, and a `verify.py` script that anyone can run + +### What to avoid in onboarding + +- Do not explain hash chains, Merkle trees, or Ed25519 during onboarding. These are details for the security architecture docs, not the first-run experience. +- Do not require account creation, email verification, or any form of registration. +- Do not show a dashboard, settings page, or feature list before the user has attested their first file. Get them to the core action immediately. +- Do not use the word "cryptographic" in the UI. Use "digital fingerprint" and "digital signature" instead. + +--- + +## Pricing model + +All source code remains GPL-3.0. The open-source tool is and remains free. Revenue comes from hosted services, not software licenses. + +### Free tier (current) + +- CLI tool: `pip install fieldwitness` +- Self-hosted web UI: `fieldwitness serve` +- All features, no restrictions +- User is responsible for their own deployment, backups, and security + +### Hosted individual tier ($10/month) + +- Hosted attestation at `app.fieldwitness.org` (or similar) +- Persistent identity and attestation history +- Evidence package export and download +- Cloud backup of attestation records (not original files -- those stay local) +- External timestamp anchoring (RFC 3161) included +- C2PA export when available +- Target audience: freelance journalists, Substack writers, independent investigators + +### Hosted organization tier ($50/month) + +- Everything in the individual tier +- Multi-user with role-based access +- Federation server (sync attestations with partner organizations) +- Source drop box (token-gated anonymous upload) +- Organizational identity key (attestations signed by the org, not individual reporters) +- Admin dashboard for attestation management +- Target audience: newsrooms, NGOs, human rights organizations + +### What the pricing assumes + +- The $10/month price point is based on the journalist feedback: this is an amount a freelancer could expense or justify personally +- The $50/month org tier is intentionally low to encourage adoption by small NGOs +- Revenue is not the primary goal in the first year -- adoption and feedback are. Pricing exists in the plan to demonstrate sustainability to grant reviewers. +- Stripe or Paddle for payment processing. Do not build custom payment infrastructure. + +### Revenue is not the first priority + +The sequence is: users, then feedback, then audit, then trust, then revenue. Do not optimize for revenue before the free product has active users. The hosted demo (Tier 1) is free and should remain free indefinitely. + +--- + +## What NOT to build + +These constraints are load-bearing. Violating the sequence wastes limited development time on things that do not yet have an audience. + +**Do not build a mobile app before the hosted demo exists.** The demo is the proof-of-concept that validates whether journalists care about this capability at all. Building a mobile app for a product nobody has tried is a months-long gamble. + +**Do not build the standalone binary before the hosted demo exists.** Same reasoning. The demo validates demand. The binary is for users who have already tried the demo and want a local installation. + +**Do not build a browser extension before the mobile app.** The browser extension serves a niche use case. The mobile app serves the primary use case (attesting photos at capture). Niche features wait until the core experience is established. + +**Do not build paid features before the free product has users.** Stripe integration, subscription management, and payment UI are non-trivial and completely irrelevant if nobody is using the free tool. + +**Do not build a custom landing page before the demo exists.** The demo IS the landing page. A marketing site without a working demo is vaporware. + +**Do not build multi-platform simultaneously.** Start with Mac (the dominant platform for journalists in the US market). Add Linux for NGOs in resource-constrained environments. Add Windows only if there is demonstrated demand. + +--- + +## Sequencing summary + +| Phase | Deliverable | Effort | Prerequisite | +|-------|-------------|--------|-------------| +| 1 | Hosted demo instance | 8-12 hours | None | +| 2 | "Why FieldWitness" narrative + demo link | 4-6 hours | Phase 1 | +| 3 | PyInstaller Mac .app | 20-30 hours | Phase 1 | +| 4 | Homebrew tap | 4-6 hours | Phase 3 | +| 5 | Hosted individual tier (paid) | 20-40 hours | Phase 1 + users | +| 6 | iOS app (MVP) | 200-400 hours | Phases 1-3 + funding | +| 7 | Browser extension | 40-80 hours | Phases 1-6 + demand signal | + +Total to reach a usable demo that journalists can try: **12-18 hours** (Phase 1 + 2). That is one to two weekends of focused work. Everything after that is incremental. diff --git a/docs/planning/why-fieldwitness.md b/docs/planning/why-fieldwitness.md new file mode 100644 index 0000000..bbbc4cf --- /dev/null +++ b/docs/planning/why-fieldwitness.md @@ -0,0 +1,149 @@ +# Why FieldWitness Exists + +**Audience:** Non-technical first (journalists, editors, grant reviewers, advocates), with a technical appendix for developers and security reviewers. + +--- + +## The problem + +A journalist covering local government photographs a leaked budget document showing irregularities in public spending. She publishes the story. Six months later, the city's attorney writes a letter: "That photograph is fabricated. There is no evidence it existed before your article." + +The journalist has the photo on her laptop. The file has a date stamp, but anyone with basic computer skills can change a file's date. She has it in iCloud, but Apple's timestamps prove when the file was uploaded, not when it was taken, and certainly not that it hasn't been altered since. She emailed it to her editor -- but that only proves she sent *something* to her editor, and both parties are considered interested. The metadata inside the photo could establish when and where it was taken, but metadata is trivially editable and routinely stripped by every messaging app and social media platform. + +She has no proof. Not because she fabricated anything, but because none of the tools she uses were designed to prove she didn't. + +This is not a war-zone problem. It is an every-newsroom problem. It happens at school board meetings, city council sessions, county commissioner hearings, and state legislature corridors. It happens every time a public official decides the easiest defense is to attack the evidence rather than address the substance. + +--- + +## Why existing tools fail + +**Cloud storage (iCloud, Google Drive, Dropbox).** These services record when a file was uploaded and synced. They do not prove a file's contents haven't changed. The timestamps belong to the cloud provider, not the journalist, and can be subpoenaed, disputed, or simply unavailable if the journalist changes services. + +**Email.** Emailing yourself a file creates a record that something was sent at a certain time, but email headers are not cryptographically signed in a way courts consistently accept. And you're trusting Google, Microsoft, or whoever runs your mail server to testify on your behalf. + +**Signal, WhatsApp, encrypted messaging.** These tools protect the privacy of your communications. They do not create verifiable records of what was communicated. Signal's disappearing messages are the opposite of evidence preservation. These tools solve a different and equally important problem. + +**The Wayback Machine.** Useful for web pages, useless for photographs, documents, and files that were never published online. + +**ProofMode (Guardian Project).** The closest existing tool to what FieldWitness does. ProofMode is Android-only, designed for individual use, and does not handle multi-reporter workflows or cross-organization chain of custody. It is a good tool solving a narrower problem. + +**C2PA (Content Authenticity Initiative).** An emerging industry standard backed by Adobe, Microsoft, and the BBC. Primarily designed for camera manufacturers and publishing platforms -- not for field journalists working offline. FieldWitness is building a bridge to C2PA so that attestations can be exported in the industry-standard format (see the technical appendix). + +None of these tools answer the question a lawyer actually asks: "Can you prove, to a standard a court would accept, that this file existed in exactly this form at the time you claim, and that it has not been altered since?" + +--- + +## What FieldWitness does + +When you attest a file with FieldWitness, it creates a cryptographic fingerprint that proves the file existed in this exact state at this exact time, signed with your identity. That proof is chained to every other attestation you have ever made, so tampering with one means tampering with all of them. The proof can be independently verified by anyone using the free verification tool -- no FieldWitness account or installation needed. + +The key properties: + +- **Tamper-evident.** If a single byte of the file changes, the fingerprint breaks and verification fails. +- **Time-anchored.** Each attestation is chained to all previous attestations in sequence. External timestamps (from independent timestamping authorities) can anchor the chain to a provable point in time. +- **Identity-bound.** Each attestation is signed with the journalist's cryptographic identity. The signature proves who attested the file without exposing their device, location, or personal information. +- **Independently verifiable.** FieldWitness produces self-contained evidence packages -- ZIP files with the original file, the attestation record, and a standalone verification script. A court, a lawyer, or a colleague can verify the evidence with nothing but Python installed. No FieldWitness account. No internet connection. No trust in any third party. +- **Works offline.** Every core function works without internet access. FieldWitness was built for environments where connectivity is unreliable, monitored, or dangerous. + +--- + +## Three scenarios + +### 1. Solo journalist protecting their evidence + +Maria covers local government for a Substack newsletter. She attests every photo, document, and recording she collects. Her attestation chain grows over time, creating a continuous, tamper-evident record of her work. When a source's leaked memo is challenged, she exports an evidence package and hands it to her lawyer. The lawyer runs the verification script and confirms: this file was attested on this date, signed by Maria's identity, and its fingerprint is intact. + +Maria does not need to understand cryptography. She opens FieldWitness in her browser, uploads a file, and clicks "Attest." The hard part is already done. + +### 2. Newsroom with multiple reporters + +A regional newspaper has five reporters covering a corruption investigation. Each reporter attests their own evidence. The newsroom runs an organizational FieldWitness server that collects and indexes all attestations. When the newspaper needs to produce evidence for a legal proceeding, it can export a complete, verifiable chain of custody showing which reporter attested which file, when, and that nothing has been altered. + +The reporters work independently. The organizational server provides backup, coordination, and the ability to share verified evidence between reporters without breaking the chain of custody. + +### 3. Cross-organization coalition + +Three NGOs are documenting the same environmental disaster in different regions. Each organization runs its own FieldWitness server. Through federation -- a system where servers synchronize attestation records with each other -- they can verify each other's evidence without any central authority. When Organization A attests a water sample photograph and Organization B independently attests satellite imagery of the same site, both attestations can be presented together with a provable timeline and independent verification. + +Federation works over the internet when available, or via physical USB transfer when it is not. The system was designed for exactly this kind of decentralized, trust-nothing collaboration. + +--- + +## What FieldWitness does NOT do + +**FieldWitness does not protect your communications.** Use Signal, Wire, or another end-to-end encrypted messenger for that. FieldWitness protects evidence, not conversations. + +**FieldWitness does not anonymize your internet activity.** Use Tor or a VPN for that. FieldWitness can operate entirely offline, but it does not hide your network traffic when it is online. + +**FieldWitness does not replace a lawyer.** It produces evidence that is cryptographically verifiable, but whether a court accepts that evidence depends on jurisdiction, the judge, and the legal arguments made. FieldWitness gives your lawyer better evidence to work with. + +**FieldWitness does not require internet access.** It was built for environments where internet access is unavailable, unreliable, or actively dangerous. Every core function -- attestation, verification, evidence export -- works on an air-gapped laptop. + +**FieldWitness does not store your files in the cloud.** All data stays on your device (or your organization's server). Nothing is sent anywhere unless you explicitly choose to federate with a partner organization. + +--- + +## The deeper technical story + +This section is for developers, security reviewers, and grant evaluators who want to understand the cryptographic foundations. If you are a journalist evaluating FieldWitness, you can safely skip this -- everything above is the complete picture of what the tool does for you. + +### Cryptographic primitives + +- **Ed25519 digital signatures** bind each attestation to a specific identity. Ed25519 is the same signature scheme used by Signal, SSH, and WireGuard. +- **SHA-256 cryptographic hashes** fingerprint file contents. Any modification, no matter how small, produces a completely different hash. +- **Perceptual hashes (pHash, dHash)** for images enable verification even after an image has been re-compressed, resized, or screenshotted -- common when evidence passes through messaging apps. + +### Append-only hash chain + +Every attestation is recorded in an append-only hash chain -- a structure where each record includes the hash of the previous record. This means altering any record in the chain would break the hash linkage of every subsequent record. The chain is encoded in CBOR (a compact binary format) and can be independently verified without FieldWitness. + +### Merkle tree verification + +The chain supports Merkle tree consistency and inclusion proofs. These allow a third party to verify that a specific attestation is part of the chain without needing to download the entire chain -- important for large-scale deployments with thousands of attestations. + +### External timestamp anchoring + +FieldWitness supports RFC 3161 timestamping, the same standard used by Adobe, DigiCert, and other certificate authorities. A single external timestamp for the chain head implicitly timestamps every preceding record, because the chain is append-only. + +### C2PA bridge + +FieldWitness is building export capability to the C2PA (Coalition for Content Provenance and Authenticity) standard. This means FieldWitness attestations can be embedded in images in the format that Adobe, Microsoft, and the BBC use for content provenance -- enabling interoperability with the broader industry ecosystem. + +### Gossip federation + +For cross-organization deployment, FieldWitness servers synchronize attestation records using a gossip protocol. Servers periodically compare their chain state using Merkle roots. When they detect divergence, they exchange only the missing records. This design requires no central coordinator, works over intermittent connections, and supports offline synchronization via USB transfer. + +### Field security features + +For high-risk deployments, FieldWitness includes a killswitch (emergency data destruction), a dead man's switch (automated purge if check-in is missed), tamper detection, USB device whitelisting, and GPS geofencing. These features exist because some users work in environments where being caught with evidence is more dangerous than losing it. + +For the full threat model and security architecture, see [docs/security/threat-model.md](../security/threat-model.md). + +--- + +## Current status and what is needed + +FieldWitness is a working prototype. The core attestation system, hash chain, federation protocol, and field security features are implemented and tested. It runs as a Python command-line tool and a web application. + +**What works today:** + +- File attestation with Ed25519 signatures and SHA-256/perceptual hashing +- Append-only hash chain with Merkle verification +- Self-contained evidence packages with standalone verification +- Cross-organization federation (gossip sync and offline USB transfer) +- Emergency data destruction (killswitch and dead man's switch) +- Cold archive export for long-term evidence preservation +- Web UI for all core operations + +**What is needed:** + +- **Security audit.** The code has not been independently audited. For a tool that journalists may rely on in adversarial conditions, an audit is a prerequisite for responsible deployment. An application to the Open Technology Fund's Red Team Lab (which commissions free audits through firms like Cure53 and Trail of Bits) is planned. +- **Packaging for non-developers.** FieldWitness currently requires Python and pip to install. This excludes the vast majority of the target audience. A hosted demo instance, standalone desktop applications, and eventually a mobile app are needed to reach working journalists. See the [packaging strategy](packaging-strategy.md) for the roadmap. +- **C2PA export.** Bridging to the industry standard for content provenance is in progress. See the [C2PA integration plan](c2pa-integration.md). +- **Field testing.** The tool needs to be used by real journalists in real workflows to identify usability problems, missing features, and incorrect assumptions. +- **Institutional review.** Organizations like the Freedom of the Press Foundation, the Electronic Frontier Foundation, and the Committee to Protect Journalists have the expertise and credibility to evaluate whether FieldWitness meets the security bar for their constituents. + +FieldWitness is open source (GPL-3.0) and welcomes collaboration -- from code contributions and security review to feedback on whether this tool solves a problem you actually have. The most valuable contribution right now is honest criticism from people who work in journalism, human rights documentation, or digital security. + +Source code: [github.com/alee/fieldwitness](https://github.com/alee/fieldwitness)