This network does not require a single hardware model. We publish identity rules, protocol requirements, and compatibility checks. You deploy by your own method, then connect through verified interfaces. For a few high-trust cases, prebuilt hardware or node-equity arrangements may exist, but the normal route is spec-based access.
What matters is protocol compatibility, identity integrity, and rule compliance.
Operators build their own node by their own method, then verify against the published interface standard.
In limited strategic cases, a node may be supplied as hardware or introduced under a special partnership model.
Not every node has the same rights. Join type determines scope, responsibility, and trust level.
Anchor node. Governance, audit root, identity source, protocol publication. Not open for public self-enrollment.
high trustprivate controlrule sourceLong-running production node. Stable location, durable connectivity, suitable for service execution and regional support.
long uptimestable sitework nodePortable presence node. Used for temporary online presence, witness logging, travel access, and light network participation.
portablelight servicespresenceReserve nodes are held for backup and expansion. Edge nodes are public-facing access points. Service nodes provide narrow scoped functions under published constraints.
backupregional accesslimited rightsThis is a specification network. Operators are free to implement by their own practical route. The network cares about identity, protocol behavior, endpoint correctness, and compliance with trust rules. Hardware standardization is optional, not mandatory.
Select the node type you want to run: edge, service, witness, mobile, or a fixed node by invitation.
Generate a node ID, transport keys, and a minimal metadata file declaring endpoint, role, and operator contact.
Use VPS, mini PC, local machine, colo host, or portable box. Implementation path is yours.
Verify that transport, keys, metadata format, and interface behavior match the published network contract.
Provide node ID, public key, location label, endpoint, and optional capabilities for verification.
Get PASS, WARN, or FAIL. Only passing nodes can request active network admission.
{
"node_id": "node-example-001",
"role": "edge",
"operator": "Example Operator",
"region": "EU",
"endpoint": "example.org:51820",
"public_key": "BASE64_PUBLIC_KEY",
"capabilities": ["presence", "rpc"],
"policy_version": "v1.0"
}
[Interface] PrivateKey = YOUR_PRIVATE_KEY Address = 10.66.66.50/32 [Peer] PublicKey = NETWORK_PUBLIC_KEY Endpoint = core.example.org:51820 AllowedIPs = 10.66.66.0/24 PersistentKeepalive = 25
The actual values, routes, and permissions depend on your assigned role and trust tier.
Result states: PASS WARN FAIL
POST /api/join-check
{
"node_id": "node-example-001",
"role": "edge",
"endpoint": "example.org:51820",
"public_key": "BASE64_PUBLIC_KEY",
"metadata_url": "https://example.org/node.json"
}
Submission is not automatic admission. Public-facing node categories may be self-service. Higher-trust categories require review or invitation.
For rare machine-specific strategic deployments, a prebuilt node or a hardware-backed contribution model may be offered separately.
You do not need to physically build every node yourself once the specification is stable.
Different operators can satisfy the same protocol through different deployment methods.
The rule source, audit authority, and high-trust backbone can remain under tighter control.