How to Use

Start here

P2PNetwork is easiest to understand when you launch the pieces in the same order they are used by the network.

1. Start the registry and bootstrap layer.
2. Start one or more peer nodes.
3. Open the GUI if you want a visual view of the running network.
4. Use the CLI or desktop controls to inspect active peers and discovered peers.

Before you run anything

Make sure these values are consistent across the nodes that should talk to each other:

• the registry URL in the config files
• the shared password used by the bootstrap API
• the discovery topic
• the ports each node listens on
• the human-readable names you want to show in the network

If any one of those diverges, the node may still start, but it will behave like it belongs to a different network segment.

Bootstrap workflow

The bootstrap node is the first thing the rest of the network depends on.

What it does:

• creates a libp2p host on its configured port
• picks a usable external address from the host addresses
• posts its peer ID, address, and name to the registry service
• unregisters itself when it shuts down cleanly

How to run it:

.\build.ps1

That build script emits the binaries under bin/. Once you have a bootstrap binary, start it with the bootstrap configuration file and keep it online while peers join the network.

Peer workflow

The peer runtime is the CLI-oriented node.

When it starts, it:

• loads config.yaml
• fetches the current bootstrap list from the registry server
• converts those addresses into libp2p peers
• creates the node and starts DHT-backed discovery
• opens an interactive prompt for live control

The available commands are:

connect <multiaddr>
peers
discovered
exit

Use connect when you already know a peer address and want to attach directly. Use peers to inspect the active connection list. Use discovered when you want to see what the discovery layer has found but not yet connected.

GUI workflow

The GUI is for the same network behavior with a visual front end.

It gives you:

• a start and stop toggle for the node
• the current node name
• a view of connected peers
• a refresh action so the view stays current

The name field is editable only before the node starts. That is intentional: once a node is running, changing its name in place would make the runtime state harder to reason about.

Typical launch order

The simplest operational sequence is:

1. Start the registry API.
2. Launch the bootstrap node.
3. Launch one CLI peer.
4. Launch another peer or the GUI.
5. Verify that peer IDs appear in the connected list and that discovery yields other active nodes.

That order gives you a clean mental model of the network, because each new node has something to connect to before it begins discovery.

Troubleshooting tips

• If a node cannot fetch bootstrap peers, check the server field in the config file first.
• If bootstrap registration fails, verify the shared password and confirm the registry endpoint is reachable.
• If discovery is empty, confirm the topic matches on every peer.
• If nodes start but do not connect, inspect the listening ports and the addresses being advertised.
• If the GUI shows no peers, confirm that the node has actually started and that the bootstrap list was non-empty.

When to use this page

Use this page when you want to actually run the system. For architecture, go back to the homepage. For downloads, go to the release redirect page. For service behavior, use the services page.