Private networks: graduate to stable feature

[hsanjuan]

After someone complained about how reliable it is to use this experimental feature I can only say that we should graduate it to stable.

The docs say the criteria is

• A) More people using it and reporting how it works
• B) Better docs

I think A is fulfilled. We recommend using IPFS private networks when the usecase arises and I'm not aware of any really bad issues for ipfs itself. As a libp2p feature it is even more used. With cluster it never gave me issues.

I can get some work done on B).

(post 0.5.0)

[benhylau]

I have use cases for this in a couple projects with a 3-6 month roadmap. Would appreciate docs about how it works, particularly:

• what private means in a content addressable network
• how it is implemented
• what are the risks (e.g. content gets leaked into public ipfs if x happens, any forward secret guarantees)

Having timelines and existing resources (perhaps on this issue) would be useful. Thanks!

[Stebalien]

Basically, everyone on the network uses the same symmetric key to encrypt all traffic (on top of the other encryption we do). This means you can't join without this symmetric key.

---

Forward secrecy: connections are already encrypted and secured with a Diffie-Hellman handshake before they're re-encrypted with this shared secret. So yes, it does have forward secrecy.

However, if you leak the secret key, anyone with access to the secret key can now join the network unless you rotate the secret key first.

---

Timeline: We plan on marking this feature "stable" in 0.6.0, once we have support for QUIC on private networks as well.

[hsanjuan]

Timeline: We plan on marking this feature "stable" in 0.6.0, once we have support for QUIC on private networks as well.

Can we put it on the milestone?

[Stebalien]

Done.