Assume you have a 10 GB blu ray movie that you want to watch without waiting for upload/ donwload time.

Maybe you host it on a server on another continent, where you got a 200ms RTT.

And your wire at home supports around 500Mbps - approx 62 MB/s.

Thus to Download it fully, would take around: 161 seconds if you use the full wire and on the happy case.

But to actually watch it and skim through it, you do not need to use the full wire, but around ~11 Mbps for a 2-hour 10 GB film, which is like 2% of the wire. The only hard part is random jumps, as each seek is a full RTT.

If you prefetch too aggresivelly you hide this RTT, but if the wire is saturated, and if you have a cache miss, then you will hang and wait until the request goes through. Might be upt to 1-2 seconds. The whole game is to pace yourself such that you stay ahead of the consumption rate, without saturating the wire.

Basically it went the "sshfs over iroh" approach, and instead of OP's post, it has eager metadata file sharing, and on demand file access. It is still a work on progress, but you can use git juse fine over the fuse mount points without introducing a new tool (edit: but do note that I did not encounter problems with large worktrees, as I do not use them in my flow, and still has some quirks). And still have similar "cold path" access times.

I touch on some insights of hiding the latency, the direct Alice to Bob connection, and has some recorded demos. Goes the generic approach.

You can watch it here if you are interested, but its around 25 minutes.

The first part is about the Post Quantum Crypto, and making direct IPv6 connections work.

The second part is about the filesystems in userspace that hide the latency. (The second part is around minute 12:00, and I think it is the relevant part to this discussion/ thread).

https://passthesalt.ubicast.tv/videos/2026-keibidrop-post-qu...

Setup: a Linux box on the other side of Romania (compared to where I am living) reading from a Windows box in Singapore (~200 ms RTT)

- reading 1 MiB of a 1 GB remote file pulls only 16 MiB (~98% avoided) - this is because of my fine tuning optimization choice - first byte approx: 2.3s - git-LFS repos also clone cold over the mount byte-perfect (separate Mac - Linux run on a ~20 ms RTT)

The thing that I do differently is that my metadata is eagerly pushed, as I optimized for content streaming.

And 100k-file tree mounts I did not test yet.

But my goal was to have instant file access for generic files between apps, and peer to peer, supports also Windows :D

here is the tool: https://github.com/KeibiSoft/KeibiDrop

But my TP-Link router blocks by default inbound IPv6 connections, without any option to configure it, still bad for pure IPv6 bidirectional streaming, gaming or services on home networks.

https://keibidrop.com

https://github.com/KeibiSoft/KeibiDrop/

It leverages virtual mount points to make file metadata available between Alice and Bob, and make the files appear as if locally.

So for example instead of waiting to upload then download a Blu Ray movie, or a large game, you can just add it into the virtual mountpoint and your recipient can instantly play it, or install it, and the download happens in the background with random offset jumps, and caches it locally.

My favorite part of it is Chapter 2 the bit manipulation tricks.

I managed to get around 8192 using Serge Skoredin's approach from the blog post last year: https://skoredin.pro/blog/golang/cpu-cache-friendly-go

Also tried some of the techniques in this blog post, and managed to squeeze a bit more with the insights from your post.

As soon as I merge this one, will create another release that fixes the fallback; and hopefully also get the apps in ios and gplay stores. https://github.com/KeibiSoft/KeibiDrop/pull/143

https://keibidrop.com/ repo: https://github.com/KeibiSoft/KeibiDrop

Might tend to deviate and waste time, needs guiding once in a while, and to check what is it spewing out, point it in the correct direction.

If I had to output the code myself, would take around 8 hours of constant writing to get around 1k LoC of code. For FUSE level tricky stuff, I might need to spend 3 weeks for 10 LoC. Very easy to burnout and build pain.

https://github.com/KeibiSoft/KeibiDrop

It took me 2 years ago around 2k hours to build a cross platform FUSE vault, without using AI assisted tools.

The pain was debugging through logs and system traces. And understanding how things work.

Now managed to ship this one much faster, as an after hours project. Started it in may 2025, and around end of November 2025 started using claude on it.

Just by dumping logs into claude, and explaining the attack vector for the problems, saved me the FML moments of grindings walls of syscalls on 3 platforms.

I would say much easier to progress, and ship with the same rigour, minimize my time, focus and brain power involvement such that I can put the energy somewhere else.

But I warn you, there are still some kinks. Only 75% pjdfstest (filesystem test suite) passes in terms of POSIX compliance. I do not support hardlinks/symlinks by design.

I was trying last to use postgresql on the virtual filesystem, then once the server is stoped, to remove the lock file, and open it on the peer. and some files got corrupted while running this test.

https://keibisoft.com/tools/keibidrop-vs-alternatives.html

its more towards vibey marketing talk and at the same time tried to keep it as honest as possible.

Here I skipped the server part. I just connect two devices.

If they both use the virtual mountpoint

MountAlice and MountBob

They get an underlying SaveAlice and SaveBob on disk.

so what gets dropped in MountAlice gets saved to SaveAlice, and appears in MountBob.

Once bob accesses it in MountBob it gets cached to SaveBob (like saved persistently to disk). But while the transfer happens a mmap is saved to disk to keep track of the segments that were transmited.

If changes happen on Alice for the file, GetAttr metadata is synced when the filehandler on Alice is released. and Bob knows to request the parts of the file that changed.

It did not go for the full-on folder sync. I went for a synced filesystem while the peers are connected.

And because ios and android do not have FUSE, i also added the option to add a file/ pull a file, that does the same thing.

So now, you can add folders/ files on android/ ios. and mount them as a filesystem on your desktop and do magic with them, and if they get changed you can export them back from the phone to the gallery or w/e files

for 1. i send a mutlicast of max 512 bytes on 224.0.0.167:26999 every 3 seconds 2. not really caching, just have a map of people that get discovered.

and god bless, I just rolled with this. if people will use the tool and they will complain about it, then it will be a problem for later. for me between my home devices did not notice inconveniences.

in total around 200 lines of golang.