Skip to content

Commit

Permalink
Add IPFS warning
Browse files Browse the repository at this point in the history
  • Loading branch information
@ehmry
ehmry committed Dec 22, 2018
1 parent fb379dd commit 124d8cc
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion nixos/modules/services/network-filesystems/ipfs.nix
View file
Original file line number Diff line number Diff line change
Expand Up @@ -74,7 +74,7 @@ in {

services.ipfs = {

enable = mkEnableOption "Interplanetary File System";
enable = mkEnableOption "Interplanetary File System (WARNING: may cause severe network degredation)";

This comment has been minimized.

Sign in to view

Copy link
@veprbl

veprbl Dec 22, 2018

Member

What does this mean?

This comment has been minimized.

Sign in to view

Copy link
@ehmry

ehmry Dec 23, 2018

Author Contributor

It means IPFS will exhaust NAT slots and DOS local networks. I went around for week trashing peoples networks and getting complaints until I realized it was because I turned on this service.

This comment has been minimized.

Sign in to view

Copy link
@McSinyx

McSinyx Nov 16, 2020

Member

Is this still a thing today? I've been running a IPFS node on my laptop even before this comment and at least for the last year or so I don't recall any network degradation.

This comment has been minimized.

Sign in to view

Copy link
@chkno

chkno Jun 24, 2023

Member

Nix is currently evaluating alternatives for binary cache hosting (Call to action, Long-term strategy, Peer-to-peer binary cache RFC/working group/poll). IPFS has come up. Inviting the general user base to participate in distributed cache hosting has come up. It would be incoherent to broadly invite the NixOS user base, in the spirit of community support and general good will, to enable an IPFS-based mechanism if, at the same time, they are warned that doing so "may cause severe network degredation"

Is this warning added in Dec 2018 still relevant? I notice that the 2015 kubo Hey, maybe we should have any network constraints/limits? issue was finally resolved in 2022 with the creation of a resource-manager module within libp2p.

This comment has been minimized.

Sign in to view

Copy link
@vcunat

vcunat Jun 25, 2023

Member

Well, if someone wants to replace a high-performance CDN similar to cache.nixos.org (or be part of such a distributed solution), they should expect high stress on their connection. I believe that holds whatever solution is taken, not just IPFS. Being behind a couple NAT layers is generally problematic for such services.

This comment has been minimized.

Sign in to view

Copy link
@ehmry

ehmry Jun 25, 2023 •
edited
Loading

Author Contributor

It would be incoherent to broadly invite the NixOS user base, in the spirit of community support and general good will, to enable an IPFS-based mechanism if, at the same time, they are warned that doing so "may cause severe network degredation".

I totally agree. The matter at hand is the order of actions you take, do you experiment, remove the warning, and then invite people, or do you remove the warning, invite people, and call it an experiment afterwards.

This comment has been minimized.

Sign in to view

Copy link
@vcunat

vcunat Jun 25, 2023 •
edited
Loading

Member

As for distributed cache.nixos.org, so far I've seen just some brainstorming around those threads. Not an invitation for people to widely start deploying it. EDIT: and as I linked there, IPFS was evaluated a few years ago for this purpose and ended up not considered usable (which might have changed as well).

Besides, IPFS addresses the CDN part, but that does remain for free by Fastly without any hint of ending. What was discussed now was storage.

This comment has been minimized.

Sign in to view

Copy link
@chkno

chkno Jun 25, 2023

Member

I not looking to settle "Would IPFS work?" here. I'm looking for information on "Is IPFS worth considering at all?"

Volunteers that seed installation media with bittorrent or run (non-exit) TOR nodes expect usage of their connection, not "high stress" or "severe network degredation". These distributed networks are not disruptive for casual users. Their software provides controls for how much bandwidth to use, which libp2p recently implemented.

I agree that the correct action order here is to experiment before removing this warning. Separate from the larger binary cache crisis scare, I also just want this text string in the nixpkgs repo to be locally correct -- if the upstream project corrected this defect, nixpkgs' packaging of this project should reflect that.

Concretely: What changes to the nixos kubo test would make folks in this thread feel good about removing this warning? Would you feel good about approving a PR that both 1. adds a test (that passes with current kubo and fails with historical kubo) that shows that a connection count limit is honored and 2. removes this warning?

(On IPFS as archive vs IPFS as CDN: ipfs-cluster collaborative clusters look like an especially low-coordination-overhead way to allow casual volunteers to help store the 425 TB archive, even if we continue to use a CDN in front of it. If our archive mechanism is robust enough to maybe work without a CDN in front of it, bonus. That might mean a little less scrambling if, later, separately, the project's CDN sponsorship becomes in jeopardy.)

user = mkOption {
type = types.str;
Expand Down

0 comments on commit 124d8cc

Please sign in to comment.