abff08f4813c

It’s definitely warranted as a random person.

See https://security.stackexchange.com/questions/262444/should-i-worry-about-compromised-firmware-when-reinstalling-an-os from an admin point of view and also https://www.binarydefense.com/resources/blog/running-malware-below-the-os-the-state-of-uefi-firmware-exploitation/ for a technical discussion on how such compromises work and can survive even a new OS reinstall.

Also note that things like your mac address could be leaked out and collected (as per https://theprepared.com/forum/thread/turn-off-your-wifi-when-you-dont-need-it-and-other-tips-on-how-to-prevent-hacking-and-tracking/ ) though Apple specifically has a private mac address spoofing feature to combat this. A lot of this collection is automated, as to cast as wide a net a possible.

So I dug into the source code a bit to see how it’s used. It turns out that IPFS might actually optional, as per the log line on https://github.com/hyprspace/hyprspace/blob/master/p2p/node.go#L213 (“Getting additional peers from IPFS API”)

The list of required bootstrap peers is hardcoded in the same file, but a few lines above, specifically at https://github.com/hyprspace/hyprspace/blob/master/p2p/node.go#L181

I say might be because - while the required bootstrap peers include a bunch of ones based on bootstrap.libp2p.io - there is a long list of hardcoded ip addresses and I don’t recognize any of them.

So those might be libp2p.io ip addresses, but they might also be IPFS ip addresses, or even belong to someone else altogether. (Edit: There are WHOIS tools online like https://lookup.icann.org/en that can be used to look these up and figure out who they belong to if you are really curious, but I can’t be bothered to do that right now.)

In any case, it looks like the way this works is that from a peer, libp2p tries to look up additional peers, and so on. So at most IPFS would be used as a way to get a listing, but once the desired peer is found, IPFS is cut out of the picture for that particular connection and NAT hole punching is used to establish a direct connection between peers instead (as per the linked wikipedia article, https://en.wikipedia.org/wiki/Hole/punching/(networking )

I guess they back either other up. Like archive.is is able to take archives from archive.org but the saved page reflects the original URL and the original archiving time from the wayback machine (though it also notes the URL used from wayback itself plus the time they got archived it from wayback).

While this would almost certainly work, it would be nice if the root cause can be discovered and either fixed or worked around. Having to reinstall everytime one needs to free up disk space is … less than ideal.

This is actually very easy. You can copy the files from the container, even while it’s not running, onto your host system to edit there, and then copy them back afterwards.

See the top answer on https://stackoverflow.com/questions/22907231/how-to-copy-files-from-host-to-docker-container for step by step instructions on how to do this.