---
# System prepended metadata

title: Charting path through libp2p proposals

---

# Charting path through libp2p proposals


### [[Active connection management]] _[Proposal #81](https://github.com/protocol/web3-dev-team/pull/81)_
- 
### [[Web IPFS nodes ability to connect (out of the box)]] _[Proposal #70](https://github.com/protocol/web3-dev-team/pull/70)_
-
### [[Rendezvous implementation and deployment]] [Proposal #67](https://github.com/protocol/web3-dev-team/pull/67)
- 
### [[Fast lane IPNS]] _[Proposal #66](https://github.com/protocol/web3-dev-team/pull/66)_
-
### [[IPFS PubSub based content routing]] _[Proposal #64](https://github.com/protocol/web3-dev-team/pull/64)_
### [[Symbiosis protocol]] _[Proposal #18](https://github.com/protocol/web3-dev-team/pull/18)_
-
### [[Reliable Mutability Primitive]] _[Proposal #19](https://github.com/protocol/web3-dev-team/pull/19)_
- 
### [[DHT in JS for effective content/service discovery]] _[Proposal #30](https://github.com/protocol/web3-dev-team/pull/30)_
- 
### [[Distributed signaling]] _[Proposal #43](https://github.com/protocol/web3-dev-team/pull/43)_
- 
### [[Enable pubsub]] _[Proposal #53](https://github.com/protocol/web3-dev-team/pull/53)_



TODO:
- [ ] Iterate on this document to make it readable/usable
- [ ] Setup call with Jacob and David Dias, Raul and Steven
- [ ] Find out why don't we have delagated DHT put/get
    - Do we really need `get` ?
- [ ] Figure out what Alex meant here https://github.com/protocol/web3-dev-team/pull/30#discussion_r578223786


# Notes

## Discovery

We can already kind of do this with DHT through delegated routing.
    - It will not help with IPNS.
    - It is still very centralized.
    - Creates load on the delegate nodes.
    - People can not add their own delegates.

- [ ] Leverage local nodes as delegates out of the box.
- [ ] Make it easy to add new delegates.

- Browsers are not able discover nodes
    - DHT protocol
        - Through "delegate protocol" browser nodes will be able to find peers
            - For the CID
            - For pubsub topic
            - Domain specific topic
        - 💭 Seems like a Rendezvous
    - Rendezvous protocol (could help)
        - Will help you discover nodes by service or interest, but not a content.
        - ⚠️ Pubsub Topics probably not going to do it.
    - Discovery ~~protocol~~ (for nodes per intereset group)
        - https://github.com/libp2p/go-libp2p-discovery
        - peers do it locally
        - Rendezvous
        - DHT (though delegated routing)
        - pubsub (⚠️ not with go)
        
    - Delegate protocol
        - Delegate node will keep a record of blocks your peer has and direct peers that need it to you you.
        - You'll tell delegate you have it.
        - Would be an improvement (in terms of effeciency) but does not unlock new capability.
- Discovery method on libp2p client

## Connectivity 

- browsers cannot dial go nodes out of the box
    - go nodes do not listen on websocket (by default)
    - go nodes do not have SSL certificates + DNS (by default)

### Options

#### SSL Setup figured out

- We have something like `libp2p.io` where `peerid.libp2p.io` is a subdomain with SSL setup.
    - 
- David dias had some idea with IPV6 to address this.

- [ ] Enable websocket by default (create proposal to enable it)
- [ ] 



##### Disadvantages

- Will not address inbound connections in browsers
    - We could use realy to call to browser and ask for callback and then drop relay.

##### Problems

- Is it even viable to have domain and SSL for every single node ?
- 


#### WebRTC in GO

- [ ] WebRTC transport in go-ipfs
- [ ] Go nodes need to listen for webrtc connections by default
- [ ] Decentralize signaling
    - Use minimal signalling node that can be discovered and used to exchange SDP Offers
    - Use limited relays from Project Flare

Problems:
- Browser nodes cannot have a lot of connections?
- Not available in worker threads
- Demanding on CPU
- Centralized Signalling

#### Relay

Allowing browser nodes to connect to nodes that don speak WebRTC or have SSL setup.
https://github.com/libp2p/go-libp2p-circuit/blob/master/relay.go#L70

- [ ] Implement active relay.
- [ ] Leverage local node as active relay.
- [ ] Verify if the host will take accept connection through the active relay by default.
- [ ] Dialer leverages active relay.
    - Or maybe discovery can store relayed addresses
- [ ] Enable active realy
- [ ] Enable auto realy

~~- Can TURN servers play that role ?~~

Solutions:

- Active relay
  - Web node puts address in the bootsrap
  - Activate relay protocol (TODO: verify this)
  - We need a deployable node (with active relay enabled) that you can drop to bootstrap list.


Solution: AutoRelay enabled by default in go-ipfs and js-ipfs.

Disadvantage:
- Hop connectivity (realy has proxy all the traffic)
~~- Multiple hops~~
    ~~- maybe active relay can address this ?~~
- PL would need to subsidze the cost for operating some relays.
    - Maybe we can it easier than running own centralized TURN.
        - Client needs a relay in bootstrap list.
        - Host needs to enable active relay
            - https://github.com/libp2p/js-libp2p-relay-server

Advantage:
- Simple to do.

    - => JS Proactive Connection Establishment

#### Decentralized signaling

#### Signaling relay 

New multiaddr that encodes
1. An address to the dialable node that can do WebRTC SDP exchange.
2. WebRTC address of the node.


### Problems

- Peer with webRTC only transport will not be able to dial/be dialled unless it has an open connection with a signaling relay
- Signaling node needs SSL