Should PeerId be mandatory for connecting to a host ?

[acul71]

Understanding PeerId Resolution in libp2p Ping Examples

This document explains how PeerId resolution works in different libp2p implementations when dialing peers, with a focus on JavaScript and Go implementations.

Implementation Comparison

Python-libp2p

Requires PeerId in multiaddr - Python's libp2p implementation mandates that the PeerId must be present in the multiaddr when dialing a peer.

JavaScript-libp2p

Supports PeerId-less connections - Can dial peers using just the transport address (IP:port) without requiring the PeerId upfront.

Go-libp2p

Supports PeerId-less connections - Similar to JavaScript implementation, can establish connections without PeerId in the multiaddr.

How It Works

1. Server Advertisement

Both JavaScript and Go implementations advertise their full address including both transport information and PeerId:

JavaScript:

// In startServer()
server.getMultiaddrs().forEach((ma) => {
  console.log(ma.toString())
})
// Output example: /ip4/127.0.0.1/tcp/PORT/p2p/QmHash...

Go:

// In runAsServer()
addrs := host.Addrs()
peerID := host.ID()
log.Printf("📡 Ping server listening on:")
for _, addr := range addrs {
    log.Printf("   %s/p2p/%s", addr, peerID)
}

2. Client Connection

Both implementations can connect using just the transport part of the address:

JavaScript:

// In startClient()
const ma = multiaddr(serverAddr)  // Can be just '/ip4/127.0.0.1/tcp/PORT'

Go:

// In runAsClient()
addr, err := multiaddr.NewMultiaddr(targetAddr)
peerInfo, err := peer.AddrInfoFromP2pAddr(addr)
if err := host.Connect(ctx, *peerInfo); err != nil {
    log.Fatalf("Failed to connect: %v", err)
}

3. Key Components

The automatic peer identification works because of the identify protocol included in both implementations:

JavaScript:

services: {
  identify: identify(),  // This enables automatic peer identification
  ping: ping()
}

Go:

// Identify protocol is built into the host by default
// No explicit service configuration needed

4. Under the Hood Process

When you dial without a PeerId, the following happens in both implementations:

1. The client connects to the transport address (IP+port)
2. The identify protocol automatically performs a handshake where:
   • The server sends its PeerId to the client
   • The client verifies the server's identity
   • The connection is established with the full peer information

5. Connection Manager Behavior

JavaScript Implementation:

// From packages/libp2p/src/connection-manager/dial-queue.ts
if (peerId != null) {
  const peerIdMultiaddr = `/p2p/${peerId.toString()}`
  resolvedAddresses = resolvedAddresses.map(addr => {
    const lastComponent = addr.multiaddr.getComponents().pop()
    
    // append peer id to multiaddr if it is not already present
    if (lastComponent?.name !== 'p2p') {
      return {
        multiaddr: addr.multiaddr.encapsulate(peerIdMultiaddr),
        isCertified: addr.isCertified
      }
    }
    return addr
  })
}

Go Implementation:

// Peer info extraction is more explicit
info, err := peer.AddrInfoFromP2pAddr(addr)
if err != nil {
    log.Fatalf("Failed to extract peer info: %v", err)
}
// The host automatically handles peer identification via identify protocol

Usage Examples

JavaScript

Both of these commands work:

# Using just transport address
node ping.js /ip4/127.0.0.1/tcp/PORT

# Using full address with PeerId
node ping.js /ip4/127.0.0.1/tcp/PORT/p2p/QmHash...

Go

Both of these commands work:

# Using just transport address
go run simple_ping.go /ip4/127.0.0.1/tcp/PORT

# Using full address with PeerId
go run simple_ping.go /ip4/127.0.0.1/tcp/PORT/p2p/QmHash...

Sample Output

JavaScript Server Output

Server Information:
Server PeerId: QmHash1...

Server addresses:
/ip4/127.0.0.1/tcp/49832/p2p/QmHash1...
/ip4/192.168.1.100/tcp/49832/p2p/QmHash1...

New connection from: QmHash2...  # Shows when client connects

Go Server Output

📡 Ping server listening on:
   /ip4/127.0.0.1/tcp/49832/p2p/QmHash...
🏓 Running as ping server...

JavaScript Client Output

Client Information:
Client PeerId: QmHash2...

Connecting to server at /ip4/127.0.0.1/tcp/49832...
Connected successfully!
Remote peer ID: QmHash1...  # Server's PeerId was discovered!

Starting ping sequence:
Ping 1: 15ms
Ping 2: 12ms
...

Go Client Output

🎯 Target: /ip4/127.0.0.1/tcp/49832
🏓 Sending 5 pings...
🔌 Connecting to QmHash1...  # PeerId discovered automatically
✅ Connected successfully
🏓 Ping #1: 15ms
🏓 Ping #2: 12ms
...

Pros and Cons

Pros of PeerId-less Connections

1. Flexibility in Discovery

   • Can connect to peers when only transport address is known
   • Useful for bootstrap scenarios
   • Simplifies initial peer discovery

2. Development and Testing

   • Easier to set up test environments
   • Reduces complexity in development scenarios
   • Allows for dynamic peer identification

3. Network Resilience

   • Can handle cases where PeerId changes but transport address remains
   • Useful for services with rotating peer identities

Cons of PeerId-less Connections

1. Security Considerations

   • Less explicit verification of peer identity
   • Potential for man-in-the-middle attacks if not properly secured
   • Relies heavily on the identify protocol for security

2. Performance Overhead

   • Additional round-trip for peer identification
   • Slight delay in connection establishment
   • More complex connection negotiation

3. Debugging Complexity

   • Harder to trace connection issues
   • Less explicit about which peer you're connecting to
   • Can mask connection problems

Use Cases

The ability to connect without knowing the PeerId upfront is useful for:

• Initial discovery scenarios
• Bootstrap nodes where you only know the IP:port
• Simple testing and development
• Services where the PeerId might change but the transport address stays the same

Best Practices

While connecting without a PeerId is possible in JavaScript and Go implementations, it's recommended to use the full address including PeerId when you know it because:

1. It provides additional security (verifying you're connecting to the expected peer)
2. It can prevent connection attempts to the wrong peer if the IP:port is being reused
3. It makes the connection intent explicit
4. It reduces the attack surface for potential security vulnerabilities

Technical Implementation

The automatic peer identification is handled by:

1. The identify protocol service
2. libp2p's connection manager
3. The multiaddr resolution system

This allows for flexible and secure peer connections while maintaining proper peer identification throughout the connection lifecycle.

Implementation Differences

JavaScript vs Go

• JavaScript: More abstracted peer management, automatic service integration
• Go: More explicit peer info extraction, tighter integration with host implementation
• Both: Support the same core functionality with different architectural approaches

Python vs Others

• Python: Requires explicit PeerId, more conservative approach
• JavaScript/Go: Support flexible peer identification, more permissive approach

[acul71]

@sumanjeet0012 @pacrob @dhuseby @seetadev
Should we align PeerId behaviour in py-libp2p to go and javascript implementation ?

[pacrob]

I don't see any reason not to if we're looking for parity with the other implementations.

[Xyncgas]

Libp2p for me would be a library connecting to other computers
I can use security options if I wanted to and it's a pleasure to get something out of the box if I am not implementing my own security
It can be imo accepted as specification made but I should get to choose if I am using it and we can use other packages or libraries for providing securities for example quantum computer advancing and people can replace the current algorithm for another one because they are no longer the 'good one'