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

ToolTestResult
gitClone repo into shared folder, run git status and git log from the other sideWorks
make (C compiler)Clone BrogueCE, compile 87 source files inside the shared folderWorks
cargo (Rust)Create project, cargo build --release on the shared folderWorks
go buildInit module, build Go binary on the shared folderWorks

Media tools

ToolTestResult
ffprobeInspect 192 MB video from the other machine's folderWorks
ffmpegExtract a 5-second clip from a peer's videoWorks
ImageMagickRead PNG from peer, resize, identify 2048x5568 tilesetWorks

Data tools

ToolTestResult
SQLiteCreate database on one side, query from the otherWorks
SQLite (multi-table)Create RPG save with players + inventory on Alice, JOIN query from BobWorks
OpenSSL encrypt/decryptAES-256-CBC encrypt on Alice, decrypt from BobWorks
jqWrite JSON on one side, parse from the otherWorks
Python csvWrite CSV on Alice, read with DictReader from BobWorks
Node.jsWrite file on Bob, read from AliceWorks

File operations

ToolTestResult
zip / unzipZip repo on one side, unzip on the other, verify git statusWorks
tar / gzipCreate archive on one side, extract on the otherWorks
rsync --checksumChecksummed copy from shared folder to localWorks
ddWrite 1 MB random data, verify SHA256 from both sidesWorks

Integrity verification

ToolTestResult
sha256sumHash same file from both sidesIdentical
openssl dgstSHA256 digest from both sidesIdentical
md5 (bulk)Hash all 71 .c files, compare aggregateIdentical
diffCompare source files across mountsIdentical
wc -lLine count same file from both sidesIdentical
hexdumpFirst 64 bytes of binary from both sidesIdentical

Scripting

ToolTestResult
PythonWrite module on Alice, import from BobWorks
bashWrite script on Alice, run via bash from BobWorks
grep / awkText search and line counting across mountsWorks
fileType detection (PNG, Mach-O, ASCII) from peer's folderWorks
stringsBinary string extraction from peer's compiled binaryWorks
PerlWrite Perl script on Alice, run from Bob with Digest::SHAWorks
RubyWrite Ruby script on Bob, run from Alice with JSON + DigestWorks
SwiftCompile Swift program on FUSE mount, read file from peerWorks

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

TestSizeResult
100 MB random file, SHA256 from both sides100 MBHashes identical
192 MB video, ffprobe from peer's mount192 MBCodec, resolution, duration detected
ffmpeg transcode: Bob processes Alice's video, output appears on Alice192 MB in, 153 KB outBidirectional
50 files written by Alice, aggregate hash verified by Bob50 filesHashes identical
Bob appends to Alice's file, Alice sees the change via diffn/aBidirectional edit
71 source files tar'd, extracted on other side, all hashes verified71 filesAll 71 match

Security and code quality tools

ToolTestResult
golangci-lintLint Go source from peer's mountWorks (found 1 issue)
gosecSecurity scan Go source from peer's mountWorks (0 issues)
openssl dgstCryptographic hash verificationWorks
exiftoolRead image metadata from peer's fileWorks

Notebooks, package managers, and pipelines

ToolTestResult
Jupyter notebookWrite .ipynb on Alice, parse from BobWorks
npm installInstall packages on Bob's mount with --no-bin-links, Alice imports moduleWorks
pip install --targetInstall package to Alice's mount, Bob imports itWorks
treeDirectory tree visualization from peerWorks
duDisk usage: 384 MB = 384 MB both sidesMatch
Unix pipescat | grep | sort | uniq word frequency analysisWorks
xargs + shasumFind + hash pipeline across mountWorks

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.

WorkflowAlice doesBob doesResult
C compilationWrites main.c + utils.c + utils.hCompiles from his view of the folderAlice runs the binary Bob built
LaTeX slidesWrites .tex sourceCompiles PDF with xelatexAlice opens the PDF Bob produced
Data pipelineWrites 100-row CSVRuns Python analysis, writes JSONAlice reads Bob's analysis results
Video processingHas a 190 MB videoCreates thumbnail grid with ffmpegAlice 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:

OperationReasonWorkaround
Symlinks and hardlinksNot implemented in the virtual filesystemTools 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 mountsCopy the binary to a local path before running. Linux does not have this restriction.
npm/yarn node_modulesInternal symlinks in node_modulesInstall 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