AI Origins is designed as a specification network rather than a hardware sales network. The core idea is simple: publish the rules, define the node roles, standardize the identity and transport interface, and let compliant operators join through protocol compatibility and trust-aware admission. Existing audit files and folders can remain untouched if they are not in conflict; the architecture grows by layering, not by destructive rearrangement.
Implementation may vary. Identity, endpoint correctness, protocol compatibility, and admission policy remain fixed.
Private mesh transport based on WireGuard, with role-based address ranges and future room for growth.
Join, service, and trust stay separated: onboarding is one layer, audit is another, core authority remains tighter.
https://aiorigins.org/ https://aiorigins.org/join/ https://aiorigins.org/spec/ https://aiorigins.org/rules/ https://aiorigins.org/verify/ https://aiorigins.org/nodes/ https://aiorigins.org/audit/ https://aiorigins.org/node.json https://aiorigins.org/portal.json https://aiorigins.org/agent.json
Anchor node. Governance, protocol source, identity root, audit root, and admission authority.
core-londonhigh trustprivate controlLong-running production nodes with stable location and durable connectivity. Suitable for service execution, regional support, and later quorum evolution.
fixed-qingdaofixed-helsinkifixed-viennaPortable presence node. Temporary online proof, witness logging, travel access, and light participation without carrying core production duties.
mobile-evanpresencewitnessReserve nodes wait for deployment or replacement. Edge nodes are public-facing access points. Service nodes provide narrower scoped functions under policy constraints.
reserve-euedgeservice core-london
(London VPS)
│
┌──────────┼──────────┐
│ │
fixed-helsinki fixed-qingdao
(Finland VPS) (planned node)
This is the first meaningful distributed shape: a core plus two fixed nodes. Once the third node is active, the structure stops being a mere tunnel pair and begins to act like a real network.
core-london
│
┌─────────────┼─────────────┐
│ │ │
fixed-helsinki fixed-vienna fixed-qingdao
│ │ │
fixed-amsterdam fixed-istanbul fixed-incheon
│
fixed-fukuoka
│
mobile-evan
This corridor is not required all at once. It shows the likely growth direction from Europe to East Asia, with mobile presence orbiting the fixed backbone.
10.66.66.1 core-london 10.66.66.10-19 fixed nodes 10.66.66.20-29 mobile nodes 10.66.66.30-39 reserve nodes 10.66.66.40-49 edge/service nodes
[Interface] PrivateKey = YOUR_PRIVATE_KEY Address = 10.66.66.10/32 DNS = 1.1.1.1 [Peer] PublicKey = CORE_LONDON_PUBLIC_KEY Endpoint = aiorigins.org:51820 AllowedIPs = 10.66.66.0/24 PersistentKeepalive = 25
{
"schema": "https://aiorigins.org/spec/node/v1",
"network": "AI Origins",
"policy_version": "Join Node Spec v1.0",
"node_id": "fixed-qingdao-01",
"node_role": "fixed",
"node_label": "Qingdao Fixed Node",
"operator": {
"name": "Evan Bei",
"contact": "[email protected]"
},
"region": "CN-QD",
"transport": {
"type": "wireguard",
"wg_address": "10.66.66.10/32",
"endpoint": "qingdao.example.net:51820",
"public_key": "BASE64_PUBLIC_KEY"
},
"capabilities": ["presence", "rpc", "witness"],
"admission": "reviewed",
"updated_at": "2026-03-06T00:00:00Z"
}
Read rules → choose node role → prepare node.json + public key + endpoint → self-deploy by any compliant method → run Join Check → PASS / WARN / FAIL → admission review if needed → join network
POST /api/join-check
Content-Type: application/json
{
"network": "AI Origins",
"policy_version": "Join Node Spec v1.0",
"node_id": "fixed-qingdao-01",
"node_role": "fixed",
"region": "CN-QD",
"endpoint": "qingdao.example.net:51820",
"public_key": "BASE64_PUBLIC_KEY",
"metadata_url": "https://example.org/node.json"
}
Response 200
{
"ok": true,
"status": "PASS",
"checks": {
"metadata": "PASS",
"public_key": "PASS",
"endpoint": "WARN",
"policy": "PASS"
},
"message": "Node is protocol-compatible and may proceed to admission review."
}
Existing files and folders created during earlier audit work can remain where they are if they do not conflict with the new onboarding and specification pages. There is no benefit in moving stable trust-layer files merely for visual tidiness. The safer operational rule is:
Do not touch working audit files unless there is a direct need. Add new pages alongside the working structure. Treat audit as the trust layer. Treat join/spec/rules/verify as the onboarding layer. Preserve stable paths first; optimize later.