Every tool just works on the shared folder
May 2026
We connected two machines with KEIBIDROP and ran every program we could think of on the shared virtual folder. Compilers, version control, video processing, image editing, databases, text processing, archival tools. Everything worked. File integrity held across every operation.
This is the result of presenting the shared files through the operating system's filesystem interface. Programs do not know the files are remote. They read and write as if the folder were local. KEIBIDROP handles the encrypted streaming from the peer transparently.
What we tested
Two machines connected over an encrypted peer-to-peer channel. Alice's shared files appear as a folder on Bob's machine, and vice versa. We ran these operations across the shared folders.
Build tools
| Tool | Test | Result |
| git | Clone repo into shared folder, run git status and git log from the other side | Works |
| make (C compiler) | Clone BrogueCE, compile 87 source files inside the shared folder | Works |
| cargo (Rust) | Create project, cargo build --release on the shared folder | Works |
| go build | Init module, build Go binary on the shared folder | Works |
Media tools
| Tool | Test | Result |
| ffprobe | Inspect 192 MB video from the other machine's folder | Works |
| ffmpeg | Extract a 5-second clip from a peer's video | Works |
| ImageMagick | Read PNG from peer, resize, identify 2048x5568 tileset | Works |
Data tools
| Tool | Test | Result |
| SQLite | Create database on one side, query from the other | Works |
| SQLite (multi-table) | Create RPG save with players + inventory on Alice, JOIN query from Bob | Works |
| OpenSSL encrypt/decrypt | AES-256-CBC encrypt on Alice, decrypt from Bob | Works |
| jq | Write JSON on one side, parse from the other | Works |
| Python csv | Write CSV on Alice, read with DictReader from Bob | Works |
| Node.js | Write file on Bob, read from Alice | Works |
File operations
| Tool | Test | Result |
| zip / unzip | Zip repo on one side, unzip on the other, verify git status | Works |
| tar / gzip | Create archive on one side, extract on the other | Works |
| rsync --checksum | Checksummed copy from shared folder to local | Works |
| dd | Write 1 MB random data, verify SHA256 from both sides | Works |
Integrity verification
| Tool | Test | Result |
| sha256sum | Hash same file from both sides | Identical |
| openssl dgst | SHA256 digest from both sides | Identical |
| md5 (bulk) | Hash all 71 .c files, compare aggregate | Identical |
| diff | Compare source files across mounts | Identical |
| wc -l | Line count same file from both sides | Identical |
| hexdump | First 64 bytes of binary from both sides | Identical |
Scripting
| Tool | Test | Result |
| Python | Write module on Alice, import from Bob | Works |
| bash | Write script on Alice, run via bash from Bob | Works |
| grep / awk | Text search and line counting across mounts | Works |
| file | Type detection (PNG, Mach-O, ASCII) from peer's folder | Works |
| strings | Binary string extraction from peer's compiled binary | Works |
| Perl | Write Perl script on Alice, run from Bob with Digest::SHA | Works |
| Ruby | Write Ruby script on Bob, run from Alice with JSON + Digest | Works |
| Swift | Compile Swift program on FUSE mount, read file from peer | Works |
Bidirectional
All operations work in both directions. Alice writes a file, Bob reads it. Bob writes a file, Alice reads it. Both can write and read at the same time. A Python module written on Alice can be imported by a script running on Bob. A Node.js program on Bob writes output that Alice reads immediately.
Large files and complex pipelines
| Test | Size | Result |
| 100 MB random file, SHA256 from both sides | 100 MB | Hashes identical |
| 192 MB video, ffprobe from peer's mount | 192 MB | Codec, resolution, duration detected |
| ffmpeg transcode: Bob processes Alice's video, output appears on Alice | 192 MB in, 153 KB out | Bidirectional |
| 50 files written by Alice, aggregate hash verified by Bob | 50 files | Hashes identical |
| Bob appends to Alice's file, Alice sees the change via diff | n/a | Bidirectional edit |
| 71 source files tar'd, extracted on other side, all hashes verified | 71 files | All 71 match |
Security and code quality tools
| Tool | Test | Result |
| golangci-lint | Lint Go source from peer's mount | Works (found 1 issue) |
| gosec | Security scan Go source from peer's mount | Works (0 issues) |
| openssl dgst | Cryptographic hash verification | Works |
| exiftool | Read image metadata from peer's file | Works |
Notebooks, package managers, and pipelines
| Tool | Test | Result |
| Jupyter notebook | Write .ipynb on Alice, parse from Bob | Works |
| npm install | Install packages on Bob's mount with --no-bin-links, Alice imports module | Works |
| pip install --target | Install package to Alice's mount, Bob imports it | Works |
| tree | Directory tree visualization from peer | Works |
| du | Disk usage: 384 MB = 384 MB both sides | Match |
| Unix pipes | cat | grep | sort | uniq word frequency analysis | Works |
| xargs + shasum | Find + hash pipeline across mount | Works |
Collaborative workflows: each person does one step
The shared folder is not just for reading. Both sides can write. This means two people can work on the same project where each person handles a different step, and the results appear on the other side immediately.
| Workflow | Alice does | Bob does | Result |
| C compilation | Writes main.c + utils.c + utils.h | Compiles from his view of the folder | Alice runs the binary Bob built |
| LaTeX slides | Writes .tex source | Compiles PDF with xelatex | Alice opens the PDF Bob produced |
| Data pipeline | Writes 100-row CSV | Runs Python analysis, writes JSON | Alice reads Bob's analysis results |
| Video processing | Has a 190 MB video | Creates thumbnail grid with ffmpeg | Alice sees 50 KB JPEG of thumbnails |
The shared folder acts as a workspace where each person contributes their part. Alice provides source files, Bob processes them with tools Alice does not have installed. The output appears in Alice's view of the folder without any file transfer step. This works for cross-compilation, media processing, data analysis, document production, or any pipeline where different people have different tools.
What does not work
Two categories of operations are not supported on the shared folder:
| Operation | Reason | Workaround |
| Symlinks and hardlinks | Not implemented in the virtual filesystem | Tools like uv, npm, yarn that create symlinks in node_modules need --no-bin-links or install outside the shared folder. pip install --target works. |
| Execute binaries directly (macOS) | macOS blocks execution from FUSE mounts | Copy the binary to a local path before running. Linux does not have this restriction. |
| npm/yarn node_modules | Internal symlinks in node_modules | Install locally, or use pip --target for Python packages which avoids symlinks. |
Why this works
KEIBIDROP presents the peer's files through the operating system's virtual filesystem interface. Every program that reads files through standard system calls (open, read, write, stat, readdir) works without modification. The programs do not need plugins, drivers, or special configuration. They open a file from a folder and the data arrives from the peer over an encrypted channel.
The file metadata (names, sizes, permissions, timestamps) syncs when the connection establishes. The file contents stream on demand as programs read them. Writes go to a local cache and sync back. The encryption overhead is under 2% of the connection speed.
Install guide · Source code