Files
zeekay fb2b7f6d5c zip declares its ops in Rust, and projects them with the Go one's projector
A Rust developer writes Rust handlers, with Rust types and Rust doc comments,
and gets every projection from that source — the same deal a Go developer has
had. No .zap is written by hand and no Go program declares a Rust service's
ops.

The split falls on a measured seam. What is native per language is DECLARING an
op and RUNNING it; what is shared is the projection logic, driven from a neutral
description of the registry.

  Manifest      the registry with the Go taken out: ops, types, fields, wire
                names, prose. App.Manifest fills one in by reflection; a
                proc-macro fills one in as a Rust crate compiles.
  Project*      the OpenAPI document, the MCP tool list, the CLI and the ZAP
                IDL, read off a Manifest. Go's own three now go through them —
                the whole existing suite is the oracle — so Go keeps no private
                path for them and the other languages cannot rot.
  cmd/zipc      the build-time projector. It reads a manifest, or the fragments
                a compiler wrote, and writes the four documents.
  rust/         zip in Rust: #[zip::ops] on an impl block, #[derive(zip::Wire)]
                on a type, a router, a JSON binder, an HTTP door and a ZAP door.
                The wire is generated by zapgen from wire.zap; nothing here
                spells a byte offset by hand and nothing links Go.

The layout rule moved out of the manifest and into the projector, so the offsets
in a .zap are derived once for all three languages rather than three times;
TestProjectZAPMatchesRegistry pins that derivation against the layout the Go
encoder actually writes.

One service, written twice — corpus/info in Go and rust/examples/info in Rust,
fourteen ops each — is the gate. The OpenAPI document, the MCP tool list and the
CLI command tree come out byte-identical, and the ZAP schema agrees on every
struct, type and offset; it differs only where a field carries the declaring
language's own case convention and where the ledger names a type the way the
person who must change it would grep for it.
2026-09-15 11:41:56 -07:00

201 lines
5.9 KiB
JSON

[
{
"Service": "chain",
"Name": "bootstrapped-get",
"OperationID": "get_chain_bootstrapped",
"Summary": "Bootstrapped reports whether a chain has finished bootstrapping on this node.",
"Description": "Bootstrapped reports whether a chain has finished bootstrapping on this node.",
"Method": "GET",
"Path": "/chain/bootstrapped",
"Args": [],
"Flags": [
{
"Name": "chain",
"Field": "chain",
"Type": "string",
"Help": "Chain is the alias or id of the chain to ask about.",
"Required": true
}
],
"Example": {
"chain": "X"
}
},
{
"Service": "chain",
"Name": "id-get",
"OperationID": "get_chain_id",
"Summary": "ChainID resolves a chain's alias to the id it names.",
"Description": "ChainID resolves a chain's alias to the id it names.",
"Method": "GET",
"Path": "/chain/id",
"Args": [],
"Flags": [
{
"Name": "alias",
"Field": "alias",
"Type": "string",
"Help": "Alias is the name the chain answers to, such as \"X\".",
"Required": true
}
],
"Example": {
"alias": "X"
}
},
{
"Service": "chains",
"Name": "list",
"OperationID": "get_chains",
"Summary": "Chains are the chains this node is running, which is a subset of the chains the P-Chain knows about.",
"Description": "Chains are the chains this node is running, which is a subset of the chains\nthe P-Chain knows about.",
"Method": "GET",
"Path": "/chains",
"Args": [],
"Flags": null,
"Example": null
},
{
"Service": "fees",
"Name": "list",
"OperationID": "get_fees",
"Summary": "Fees are the transaction fees this node charges, in nLUX.",
"Description": "Fees are the transaction fees this node charges, in nLUX.",
"Method": "GET",
"Path": "/fees",
"Args": [],
"Flags": null,
"Example": null
},
{
"Service": "lps",
"Name": "list",
"OperationID": "get_lps",
"Summary": "LPs is where the network's stake stands on every current Lux Proposal.",
"Description": "LPs is where the network's stake stands on every current Lux Proposal.",
"Method": "GET",
"Path": "/lps",
"Args": [],
"Flags": null,
"Example": null
},
{
"Service": "network",
"Name": "id-get",
"OperationID": "get_network_id",
"Summary": "NetworkID is the number of the network this node is on.",
"Description": "NetworkID is the number of the network this node is on.",
"Method": "GET",
"Path": "/network/id",
"Args": [],
"Flags": null,
"Example": null
},
{
"Service": "network",
"Name": "name-get",
"OperationID": "get_network_name",
"Summary": "NetworkName is the name of the network this node is on.",
"Description": "NetworkName is the name of the network this node is on.",
"Method": "GET",
"Path": "/network/name",
"Args": [],
"Flags": null,
"Example": null
},
{
"Service": "node",
"Name": "id-get",
"OperationID": "get_node_id",
"Summary": "Identity is this node's id, with the proof it holds the staking key that id is derived from.",
"Description": "Identity is this node's id, with the proof it holds the staking key that id is\nderived from.",
"Method": "GET",
"Path": "/node/id",
"Args": [],
"Flags": null,
"Example": null
},
{
"Service": "node",
"Name": "ip-get",
"OperationID": "get_node_ip",
"Summary": "Address is where this node tells its peers to reach it.",
"Description": "Address is where this node tells its peers to reach it.",
"Method": "GET",
"Path": "/node/ip",
"Args": [],
"Flags": null,
"Example": null
},
{
"Service": "node",
"Name": "version-get",
"OperationID": "get_node_version",
"Summary": "NodeVersion is what this node is running: its own release, the database format it reads, and the VM protocol it speaks.",
"Description": "NodeVersion is what this node is running: its own release, the database format\nit reads, and the VM protocol it speaks.",
"Method": "GET",
"Path": "/node/version",
"Args": [],
"Flags": null,
"Example": null
},
{
"Service": "peers",
"Name": "list",
"OperationID": "get_peers",
"Summary": "Peers are the nodes this one is connected to.",
"Description": "Peers are the nodes this one is connected to. A list of node ids narrows the\nanswer to those, and no list asks for all of them.",
"Method": "GET",
"Path": "/peers",
"Args": [],
"Flags": [
{
"Name": "node-i-ds",
"Field": "nodeIDs",
"Type": "json",
"Help": "NodeIDs are the peers to answer for; none asks for all of them.",
"Required": false
}
],
"Example": {
"nodeIDs": []
}
},
{
"Service": "upgrades",
"Name": "list",
"OperationID": "get_upgrades",
"Summary": "Upgrades is the upgrade schedule this node runs.",
"Description": "Upgrades is the upgrade schedule this node runs.",
"Method": "GET",
"Path": "/upgrades",
"Args": [],
"Flags": null,
"Example": null
},
{
"Service": "uptime",
"Name": "list",
"OperationID": "get_uptime",
"Summary": "Uptime is how much of the network, by stake, reports having seen this node up.",
"Description": "Uptime is how much of the network, by stake, reports having seen this node up.",
"Method": "GET",
"Path": "/uptime",
"Args": [],
"Flags": null,
"Example": null
},
{
"Service": "vms",
"Name": "list",
"OperationID": "get_vms",
"Summary": "VMs are the virtual machines installed on this node, and the feature extensions its UTXO chains understand.",
"Description": "VMs are the virtual machines installed on this node, and the feature\nextensions its UTXO chains understand.",
"Method": "GET",
"Path": "/vms",
"Args": [],
"Flags": null,
"Example": null
}
]