Winterhuman
Winterhuman
Oh, I see what you mean now, nevermind then
Looks like it is, it's even in the TBD milestone (https://github.com/ipfs/kubo/milestone/54), I'll close this issue then and leave a comment linking to this issue. Thanks!
@BigLep I'm afraid I have scarce little knowledge of coding (I'm a docs/spec person at best), someone else will have to handle this unfortunately
Here's some more information: - I have one router/modem. - I believe UPnP is disabled on my router. - It's definitely not CGNAT, or at the very least CircuitV2 is...
As a guess, I think what's happening is the daemon's usual process is to assume the node is public at the beginning no matter what, thus triggering the swarm announce...
@lidel Any update on this issue?
Just a wild guess, but, maybe check journalctl and specifically look for OOM killers; the node might not be using all the ram but the system might be preventing it...
Ah I see, thanks for explaining! I do think this is still a UX problem though, people won't think to use `ipfs pin add` to fetch large amounts of content;...
What about protecting `ipfs get` data from GC, waiting until the amount of data reaches the GC threshold, and then, pausing the fetch and asking the user "**CID** has exceeded...
That's what the `--exceed gc` option is for, to assume the answer is "yes" ahead of time ("with some sort of --exceed-gc option to say yes beforehand")