the internet is my (your) filesystem now

there is, somewhere deep in modern computing, a recurring temptation to believe that distance is an implementation detail.

once you abstract enough layers (RFC 1925 §6 once again), rename a few problems, and put a nice control plane on top, it becomes very easy to convince yourself that storage is just “somewhere else,” latency is “acceptable,” and persistence is really a matter of optimism. from there, the next logical step is obvious: why keep buying constantly more expensive SSDs and HDDs (because of the AI) when the internet can be your filesystem?

the idea is elegant in the same way many bad ideas are elegant.

if data remains in flight long enough, then technically it is not occupying disk. with enough high-latency paths, enough buffering, enough retransmissions, and a healthy disrespect for round-trip time, we should be able to preserve state without the vulgarity of local storage. every extra millisecond of delay becomes, in spirit, another tiny storage tier.

this is also a good excuse to return to an idea my friend Piotr Jabłoński mentioned years ago: maybe we do not need more storage capacity at all. maybe we just need more packets spending more time on the wire. maybe “disk full” is not a capacity problem, but a failure to think of the network as a sufficiently large delay line. just like lack of funds for AI is not a problem because we can just create circular economy to fund it from our governments (read: our) money.

unfortunately, physics continues to be poorly aligned with product marketing (and PowerPoints will take anything).

filesystems tend to care about ordering, durability, and predictable access to data. networks, especially wide and busy ones, are more comfortable offering jitter, loss, reordering, congestion, and occasional opportunities for personal growth. pretending one is the other is not a new mistake, but modern systems have become remarkably good at hiding where the trick stops working.

which is precisely why the thought experiment is useful.

if you push this idea far enough, it becomes a neat way to expose several fallacies at once: that remote is close enough to local, that transport and storage are interchangeable, that delay can always be amortized away, and that abstraction layers repeal underlying constraints. they do not. they merely postpone the moment at which you have to admit what kind of system you are really building.

naturally, the irresponsible idea has already advanced to the prototype stage. there is a rust implementation.

that does not make it a good idea. but it does make it a more educational one.