BitGraph Recorder
A macOS app. Drop files or a folder on it and each drop becomes a recording: one self-contained folder holding the files, the proof, and the Ethereum anchors. Hand somebody the folder and they have the whole BitGraph.
Download for MacVersion 0.1.17 · macOS 14 or later, Apple silicon · Release notes and checksum
BitGraph Recorder is software of Argento Computing Inc., provided under the Terms. Individual use and verification are free. Recording inside your own product, service or internal systems is licensed by separate agreement; get in touch.
What a recording is
BitGraph (IMG_4021.png)/ IMG_4021.png a hard link to your file proof.json bitgraph/1 ethereum-anchors/ when they land BitGraph (Photos 2026, 412 files)/ ...the tree, mirrored... proof.json manifest.json the set's manifest members.jsonl every member's row and inclusion path
Nothing points at anything. The proof file is the proof, and a recording checks on its own: no library, no index, no settings, no network.
What it does not do
- It never writes into your folders. The folder you dragged out of is left exactly as it was.
- It never moves your files. Your file does appear inside the recording folder. On the same disk it is a hard link: the same bytes under a second name, no new disk used, so editing the original in place changes what the recording holds and a check then says so. Where a link is not possible, another drive or a filesystem without links, it copies instead, and the recording says which it did. Your original stays where it was either way.
- It never writes the fused bytes. They are virtual: the original plus the proof rebuilds them exactly, so they are only written when you export. The export checks the rebuilt bytes against the committed digest as it writes them, and if they do not match, no file is handed over. A new file that does not match its proof is worse than no new file.
- No login, no account, no upload. Files are hashed on your Mac. Making a BitGraph is two HTTPS calls, and neither carries your file: digests, sizes, a file’s first bytes for the placement choice, the slot record and the placement id. Afterwards the app fetches the Ethereum anchors for the position and checks the update feed; nothing about your files travels.
Setting up
The first run asks one thing: what to call your BitGraph folder and where it lives. ~/BitGraph is offered. Put it on the Desktop or in Documents and macOS asks once whether the app may use that folder; the app cannot record until it is allowed. An existing folder is continued, never replaced.
The app lives in the menu bar and opens one window. Move or rename the folder later and the app says so and asks where it went; Change folder… does the same on purpose. Pointing at a folder that already has recordings in it carries on with everything in it.
The gesture
- One new file is recorded on landing.
- One file already on record opens its BitGraph instead.
- Two or more are listed first, then made as one BitGraph at one position, each file a member. Only a batch gets asked.
- A folder holding a BitGraph is the same list: each file a recording covers carries what the check said, the rest are new, and Record records the new ones alone. Nothing records on landing when a recording is in the drop.
Two files with the same bytes in one drop are one member: the record is by content, and the second name is covered by the first. Your BitGraph folder itself can never be dropped, and a drop of the folder above it walks around it.
The window has two sections. Record is where things are recorded and checked; New holds the two ways in that are not a drag, Record a BitGraph… and Check a folder…. Calendar is the library: the month’s days, each a row saying how many recordings it holds, and a day opens to its recordings. A recording opens to its proof, read off the disk.
Export
Export BitGraph on a recording’s page writes a folder to hand to somebody: the original exactly as it is, proof.json, the new fused file rebuilt from the two and checked against the committed digest on the way out, and the Ethereum anchors that have landed. It carries everything a check needs.
The reader
Dropping a folder that holds BitGraphs reads them, wherever in it they sit, and records nothing until Record is pressed for what is new. A folder somebody sends you checks on its own, because a recording carries everything a check asks for. Four outcomes, and the differences between them are the point.
| verified | the bytes rebuild the artifact this position committed |
| failed | something contradicted; it names which side |
| could not be checked | a gap on this side, never counted as a failure |
| not recorded | no proof in this folder covers these bytes, which is not a fault |
Bytes alone cannot tell a file that was altered from one that was never recorded, so neither is called a failure. The same check runs anywhere with npx @mikeargento/bitgraph-audit; see Verification.