Services

Services at a glance

P2PNetwork only has one server-side service today, but that service carries a lot of weight. It is the registry that makes bootstrap discovery practical.

GET /

Returns the currently registered bootstrap nodes as JSON.

POST /register

Adds or replaces a bootstrap node after verifying the shared password.

DELETE /register/{peer_id}

Removes a bootstrap node from the registry after password validation.

GET /health

Reports service health and the current number of registered nodes.

Registry responsibilities

The registry service is intentionally narrow. It is not a general purpose node database and it is not trying to model the whole network.

Its job is to:

• hold the current bootstrap list
• protect writes with a shared password
• return the latest set of nodes to peers and GUI clients
• keep the file-backed registry durable across process restarts

That narrow scope is useful. It makes the service easy to reason about, easy to replace, and easy to document.

Data model

Each registry entry stores:

• peer_id
• address
• name

Those fields are enough for a joining node to turn the registry entry into a usable libp2p peer address. The registry does not need to know about peer discovery state, connection count, or application behavior.

Write path behavior

When a bootstrap node registers itself, the service:

1. validates the password
2. loads the current registry file
3. removes any older entry for the same peer ID
4. appends the fresh node record
5. writes the full registry back to disk

That replace-on-write behavior keeps stale duplicate bootstrap rows from building up when the same node restarts.

Shutdown behavior

Bootstrap nodes are expected to remove themselves when they exit cleanly. That keeps the registry from advertising dead nodes for longer than necessary.

In practical terms:

• clean shutdowns should trigger a DELETE call
• forced shutdowns may leave stale bootstrap rows behind until the next cleanup
• peers should still be prepared to skip dead or unreachable bootstrap targets

This is normal for a lightweight registry. The network remains usable as long as at least one registered bootstrap node is alive and reachable.

Operational notes

The service is most valuable when it stays simple and stable.

• Keep the registry URL consistent in every config file.
• Keep the shared password in sync with the bootstrap runtime.
• Treat the registry file as operational state, not as source code.
• Prefer adding new behavior in the peer or GUI layer before expanding the registry schema.

Service boundaries

The registry does not do peer discovery. It does not manage active sessions. It does not know whether a peer is connected or merely discoverable.

That boundary is deliberate:

• registry = where to start
• discovery = how to find others
• connection tracking = who is actually connected

Keeping those concerns separate makes the system easier to debug when one layer is healthy and another is not.

Related docs

• How to Use for end-to-end startup and CLI control
• Downloads for release access
• the homepage for live repository status and project overview