Centralized point of failure in JS-IPFS

I recently started looking into the IPFS ecosystem and I am trying to build an application using JS-IPFS but I realized that it depends on a rendezvous server (signaling server) to work.

This made me think about this centralized point of failure that the application depends on. Isn’t this a centralization which goes against the core of IPFS?

I realize that DHT and Circuit Relay is not finalized yet, but would these two services solve the aforementioned problem?

I also saw that there was a Go-implementation available and does this implementation suffer from the same problem with the centralized point of failure?

1 Like

The rendezvous server is a temporary measure for web browsers until proper dht / relay is implemented:

Relay is needed in situations where nodes are behind NAT, reverse proxies, firewalls and/or simply don’t support the same transports (e.g. go-ipfs vs. browser-ipfs). Even though libp2p has modules for NAT traversal (go-libp2p-nat), piercing through NATs isn’t always an option. The circuit relay protocol exists to overcome those scenarios.

AFAIK the goal is for your bootstrap nodes to provide relay feature, if you need it.

You can track progress in: