Private vs Default network


I have a choice between private and default public newtork for our product. While default public network would give several benefits like access to public pin services and similar stuff I’m really concerned about updates. There are no auto updates in our desktop application and if we distribute certain version of ipfs node with our app wouldn’t it happen at some point that

  • everything breaks, i.e. users wouldn’t be able to connect, data would be not discovered &c? Pretty obvious it will at some point. But how often breaking changes are introduced in ipfs? Every year? Every few months?

  • if we go with a public network but with our own bootstrap nodes would it be possible to maintain some kind of a detached segment of the network for some time (until users update) that still works in case of breaking changes?

  • I’ve found a few topics on this forum that say ‘update urgently or new protocol would cause crashes’. For example: Are you running an old version of go-ipfs **prior to 0.4.20**? PLEASE UPGRADE NOW! This is alarming even in case of autoupdates available. Are there any warranties that would not happen again? I assume not.

  • If we choose to go with public network does it mean that our release cycle should become tied to ipfs releases? Probably yes. At lease there should be service releases of our product forced by IPFS releases.

  • If we choose to go with private networks are there any ways to setup some kind of relay/connection between private & public networks that can be managed in house and give us a wider window for updates and a possibility of having a kill switch in case of changes that can cause crashes?

  • Do I understand correctly that given my constraints the best option for me is to go with a private network?

Thank you.

Almost never. In 5 year there has been like 1 or 2 changes which may have potentially affected very old clients (years old). The network has even avoided certain optimizations to not completely break old but not too old clients.

Your nodes will work with your nodes, that’s for sure.

Many protocols are the same, but if a version is broken due to a bug, or uses a protocol that is insecure, you may expect that the bugs are fixed and the protocols upgraded at some point. But things are quite mature now.

That’s up to you. Newer ipfs versions are going to work better.

No, you cannot bridge a public and a private network.

No. imho, you are exaggerating backwards compatibility issues, and if you are doing any maintenance on your product at all, it should not be hard to follow ipfs releases from time to time (months). Also, communication between your nodes cannot be broken because other nodes upgrade. A private network is useful if you want to fully isolate the communications (for privacy, security etc).

I see a lot positive feedbacks for reworking the hash in the future in ipfs’s github, they are not doing it now but they are trying to stack up the changes that needs to be done on hashes, when it’s a lot changes to be made they will make those changes at once and you can still use your old client with your old protocol.

No, you cannot bridge a public and a private network.

Not to confuse things but isn’t that basically what IPFS Cluster is, private cluster nodes bridged to the public IPFS network?

IPFS Cluster peers interact via a separate private network. They control IPFS peers via http-api which can be configured on the public or on private network themselves.

Gotcha, so they’re just two separate networks, one public and the other private that just supervises the public nodes. Thanks.

Thank @hector @Xyncgas for your responses and time spent. Everything became a bit more clear for me.

1 Like