Run a service — NoderaMC

A tracker or a rendezvous point is a hint about where to start looking, never an authority. Here is how to run one.

Two services keep peers able to find and reach each other. Neither is in charge of anything.

TrackerRendezvous relay
Answers"Who is on this world?""How do I reach that peer?"
Listens on0.0.0.0:25600, TCP and UDP0.0.0.0:25601, TCP
HoldsSoft state: who announced what, recentlyLive circuits, and nothing else
Costs youAlmost nothingBandwidth — a relayed circuit's traffic goes through you
Imageghcr.io/ashu11-a/noderamc:tracker-latestghcr.io/ashu11-a/noderamc:rendezvous-latest

Both are single static binaries with no database behind them. Both drain on SIGTERM — refuse new work, tell the peers, tell the trackers, finish what is in flight — so taking yours down is an operation rather than an incident. Peers discover services through the lists they hold and migrate off one that is draining.

The relay only carries traffic it has to. When a direct path can be opened between two peers it steps out of the way; when it cannot, it bridges an encrypted circuit it cannot read.

Why running one is a small decision

Neither service is authority, and that is not a policy — it is enforced by the peers.

Every service proves its own identity before a peer will dial it. Everything a service says about a world, an identity, a membership or a vote is checked against signatures the peers already hold. A hostile tracker cannot invent a world, forge a peer, or change what happened in a region.

The most a broken or malicious service can do is omit: hide a peer from you, or hand you one that is not reachable. That degrades discovery. It cannot corrupt a world, and it cannot make one machine's account of a region beat the committee's.

Which is also why there is no curated registry and no privileged list: because a service cannot lie about anything that matters, the list this project publishes is one store among however many you add, and it is deletable like any other. The official list is on this site, and publishing your own is a JSON file against a schema.

Self-updating, and what it proves

Both services can replace their own binary from a published release. The update channel is empty by default, so nothing happens unless an operator sets one: somebody who chose to run a tracker did not thereby agree to let it fetch and execute new code.

When it is on, the service compares the published SHA-256 of its own asset against the digest of the file it is executing — a version string would never change, because the rolling prerelease republishes under one tag. It verifies before it touches anything, and it drains before it swaps.

It does not prove who published the release, because no signing key exists yet: the signature check is built and tested, and it is waiting on a key that does not exist. Until then the lane verifies integrity and says so on every check. The gap is confined to a lane you have to switch on, and it is written down rather than glossed over, as tracker limitation L-81.

Start here

Run a tracker is the shorter of the two and the more useful one to add to the network. Run a relay costs more bandwidth.

The two reference pages — tracker and rendezvous — are the complete settings and endpoint lists, for when you are past the first hour. Both, and the two guides, are the repository's own documents mirrored rather than rewritten, so they cannot drift from what the binaries do.