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?
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.
– https://github.com/libp2p/specs/tree/master/relay
AFAIK the goal is for your bootstrap nodes to provide relay feature, if you need it.