Dillo Proposes Asciinema Proof for Human Patches
In a blog post published May 25, 2026 on the Dillo website, Rodrigo Arias Mallo proposed using Asciinema session recordings as evidence that a Free and Open Source Software (FOSS) patch was authored by a human. Arias Mallo describes Asciinema as a small CLI recorder that captures keystrokes, terminal output, and timing, producing compact, gzip-friendly files. The post lists advantages such as low contributor overhead and small file size, and limitations including lack of coverage for graphical editors like VS Code and privacy concerns; Arias Mallo suggests private transmission to reviewers where appropriate. The author also cautions that large language models (LLMs) could potentially generate fake recordings, creating an asymmetric-complexity problem for provenance checks.
What happened
In a blog post published May 25, 2026 on the Dillo website, Rodrigo Arias Mallo proposed using Asciinema session recordings as a proof artifact to show that a patch was written interactively by a human. The post states that Dillo seeks to accept "fully human created contributions" and that relying on contributors' assertions alone is insufficient, per the author. Arias Mallo documents tradeoffs and practical considerations for the idea.
Technical details
Arias Mallo describes Asciinema as a small CLI program that records keystrokes, terminal output, and the timing between events, then replays the session so it appears as originally recorded. The blog post argues that the files compress well because they store text plus timing metadata, making uploads feasible. The author notes limitations: the approach only covers terminal-based editors (it does not capture activity inside graphical IDEs such as VS Code), and recordings include development noise that contributors may prefer not to disclose. The post suggests private delivery of recordings to maintain reviewer confidentiality.
Editorial analysis
Recording interactive editing sessions is an intuitive provenance signal because it exposes human error patterns, pauses, and iterative debugging that are currently hard for LLM-generated output to mimic convincingly. At the same time, industry observers and the author highlight an "asymmetric complexity" problem: generative models can be used to synthesize convincing terminal sessions, raising the bar for any single provenance artifact.
Context and significance
For FOSS maintainers and contributor-onboarding workflows, lightweight session recordings are a low-friction signal that could reduce uncertainty about first-time patches. However, provenance of code is an arms race: single artifacts without cryptographic attestation or independent verification can be forged. Complementary measures such as attested builds, signed commits, and reviewer heuristics are relevant in this space.
What to watch
Indicators to follow include adoption of session-recording workflows in other projects, tooling that attaches cryptographic signatures or timestamps to recordings, community discussion about privacy and opt-in policies, and any tooling aimed at detecting synthetic terminal recordings.
Scoring Rationale
The proposal is a practical, low-cost way for maintainers to gather provenance signals, relevant to many FOSS projects. Its impact is moderate because the approach is limited to terminal workflows and faces forgery risks from LLMs, so it is unlikely to become a universal solution without stronger attestation.
Practice interview problems based on real data
1,500+ SQL & Python problems across 15 industry datasets — the exact type of data you work with.
Try 250 free problems
