back
41 comments
In the pre-smtp days, email links were over UUCP, which was often relayed via dial up lines which connected intermittently, on a schedule (e.g. every hour).

You also specified not just the destination, but also the route for the email to take, via a 'bang path': https://en.wikipedia.org/wiki/UUCP#Bang_path

Add in the situation of disk quotas for university students, but not email quotas, and you get the means, motive and opportunity for people to use the email spools of a mail servers around the world as an annex to their home directory...

Since the statute of limitations has expired I will admit to creating data archival systems using uucp as well as smtp. Back in the 80s before the morris worm and spam, when the internet was just for us geeks, you could usually connect to anyone's mail server on port 25 and hand it mail to be delivered just about anywhere. Sendmail was more concerned with connecting up all of the various networks than it was about authenticating a destination, so you could connect to just about anyone's mail server and ask it to deliver mail back to your server; of course your server would be conveniently offline for a period of time or drop the connection after checking the rcpt (chunk id) in the envelope until you either wanted the data back or needed to accept it so that it did not bounce. I probably have opq ("other people's queue") on a nine-track tape in the basement but have no way of loading it up again; anyone know what the odds are that a well-cared for tape reel circa 1986 (bad tar format) is actually worth sending somewhere to get read?
It's funny, you mention the statute of limitations, but wouldn't this act predate any laws that exist now to prevent it?
Similarly, in the early AOL days, there were several "warez" distribution lists going around which had the pirated software directly attached to the emails (not links to external websites). As long as the emails stayed in AOL, you could forward them instantly (there must have been some deduplication on the back end making the attachments basically a link to the same files).
Assuming the basement did not get overly warm or humid and the tape was not wound too tightly, you have better than a 50% chance of recovery.

Most recovery labs will offer you an estimate of costs before you commit any money.

I seem to recall people creating programs that would use gmail for data storage.

Also, UUCP sounds similar to Fidonet.

Technically, the data is not stored in the network, but in the buffer memory of the routers (and switches) in the path of the packets. So what this is really doing is externalizing the cost of storage to the network providers.

There is a problem called “Buffer bloat”¹ which is that many manufacturers of networking equipment provide too much buffer memory, which leads to TCP latency and timeouts, since TCP was not designed with these large buffers in mind. Using Pingfs will take up buffer space in networking equipment. This could either be a good thing, since it decreases the available buffer space, or it might be a bad thing since it might make networking providers increase their buffers.

I’m not sure how much of this comment is serious.

① http://www.bufferbloat.net/

A teacher told me in the 70s they used satellite communication as memory buffers, sending data over the air with getting it back a bit later as only goal. IIUC, the earliest form of memory device were doing the same using pressure waves in mercury.
It's this: https://en.wikipedia.org/wiki/Delay_line_memory
Yes, for the mercury ones, but it doesn't mention satellite air gap, which I find kind of hackish, the goal of the submitted post.
It is stored in the network cables aswell.

But you are probably correct, the time in the cables is probably not even close to the time the data is stored in the equipment itself.

I dunno, this is actually very reminiscent to me of how neurons (putatively) store information in their firing rates--at least in the short-term--before consolidating state into their synaptic weights.
This is crazy cool. Nevertheless, if everyone used it, we would saturate whatever network we are using and I am curious what it would do to traffic costs since you are basically bouncing around a whole bunch of data back and forth. Sounds expensive.

Still crazy cool.

Hi, author here.

Just like with iodine (dns tunnel) this was one thing me and my friends talked about that would be cool.

I actually started to implement this in haskell in 2011, and gave up after I had basic writes to files working. I can get dig out that code if anyone is interested.

The c version of the project hasnt gotten very far yet as you can see, I might pick it up again though.

Please share haskell implementation.
Just for the record: there was some previous work on that: http://lcamtuf.coredump.cx/juggling_with_packets.txt (see point 7)
ICMP delay-line memory.
Randomly accessed memory?
If we had space probes with ICMP support, you could use this to store data in the interplanetary æther.
You don't need ICMP for that, or even an active space probe. Just encode your data in laser pulses and bounce it off one of the retroreflectors we've put out there. There are at least three on the moon, or the LAGEOS satellites (https://en.wikipedia.org/wiki/LAGEOS) would work.
Hmm - quick research shows that laser communications have been demonstrated at up to around 1Gb/s; given the roundtrip time to a retroreflector on the moon, you could have around a 300MB buffer in flight at a time. Average latency to read or change a particular byte would be about 1.2 seconds, so not ideal for high performance applications. Also, wouldn't work when the moon was below the horizon. Plus installing additional retroreflectors on the moon to increase capacity would be quite expensive.
You don't need more retroreflectors, just ground lasers far enough apart (and someone with more physics than me to make an argument about the waves not interfering at the reflector)
brb, buying lasers
Prior Implementation: http://shysecurity.com/posts/PingFS
Could do some crazy docker things with this. Imagine bouncing around your entire P2P net on a .bit domain. Makes popcorn time look like a bunch of amateurs.
Could this be used to make networks of ultra-portable trackers?
Some radio HAMs have done this with packet radio and EME transmissions so the idea isn't new but this is really neat and likely much higher capacity.

Very slow refresh DRAM, next up, Mercury? (the planet or the metal, take your pick) ;)

I think you've just found the first application where high latency is actually desirable!
Hi bandwidth is desirable too because it's delay * bandwidth. From my location I think the optimal place might be hawaii, the place with the highest delay bandwidth product I mean. It might be optimal for other reasons too.
Can someone please explain what this does? I've read the readme, glanced through the code, and still have no idea.
ping packets (ICMP) can have any data you want as a payload (1,500 bytes or so). This is a joke filesystem that lets you store data by putting it in ping packets and sending them to other systems. To read the data, you just wait for the ping response to come back. Then, you send it again immediately so that you don't have to store it locally.

The amount of data you can store is a factor of the amount of bandwidth you have and the amount of latency available, where the more latency is better. Hypothetically, on a 10 gigabit connection with a 1 second ping time, you'd be able to store 1,250 megabytes. Of course that doesn't factor in packet loss, and finding something that's one second away that also can saturate a 10 gigabit connection is unlikely.

ICMP Echo packets or Ping packets send data to a (given) server which then replies with the exact packet (data) in return. In essence this program bounces your data back and fourth between a (given) server and your computer instead of storing it on a drive or on someone else's drive it. So your data is living on the internet, in the internet's delay between you and the remote server. This can be unsafe data storage if the link between you and the remote server ever dropped.
Looking at the code, what it "does" (specifically, 'being a filesystem' and 'storing data in icmp packets') isn't actually implemented yet. :)
In principle, one could store BxL/v in a cable of length L, where B is the bandwidth and v is the propagation speed of the signal.
Delay lines built on this principle were used in some old analog color TVs, for purposes of color correction: color info for a line was compared to the previous line, and differences were smoothed out. This resulted in less color resolution on the vertical, but also greatly reduced color noise and error.

The signal in the line was ultrasonic sound waves.

https://en.wikipedia.org/wiki/Delay_line_memory#Piezoelectri...

Yep, you can gang them for really nice guitar phasing effects...
Delay filters are built intentionally by RF engineers for pre-distortion and probably other purposes. I think the limit for such simple designs is ~100 ns.
Let's not forget http://stackoverflow.com/a/13000176/308851 !
A long time ago as a joke a few of us sketched out "netfs" that would use network switch forward buffers as a filesystem in a similar manner (constant resending), but never actually tried to make it. This is really neat.
Snapchat users would be truly delighted :)