would it be possible to serve the config route?

[rolfyone]

I know currently this serves /eth/v2/debug/beacon/states/..., but I was wondering if it'd be possible to serve
/eth/v1/config/spec, either from a static yaml file or from a connected server...

I guess what I'm interested in ultimately, is a scenario where we could initialise just using checkpointz, reading the network configuration from the spec endpoint, and the state from the states endpoint. Imagining something like holesky where we update checkpointz to serve the updated configuration without doing a release of all nodes...

So maybe if a client was initialised with
./cl_client --checkpointz-server https://my-checkpointz-server.io
and the client can download network config, genesis if it needs it, finalized if it needs it.... whatever the client needs, just with that initial information of the base url of the checkpointz server...

Another scenario may be a custom network, where they want to spin up servers and just configure separately. I'd assume that clients would download the spec once, and store it, downloading the spec each startup may drive undesirable load on the checkpointz instances, but maybe it's more desirable (although you could brick your nodes).

Anyway, it's probably worth a discussion, and this seems like a good place to have it :)

[samcm]

Sounds like a plan! Checkpointz already serves that route (I added it when I thought that being able to chain checkpointz instances together was a good idea 🙃). We also serve a couple more routes than required: https://github.com/ethpandaops/checkpointz/blob/master/pkg/api/handler.go#L49-L74

I might need to update the spec struct to include any new fields that've been added - will leave this issue open for now as a reminder.

Let me know if checkpointz can serve anything else that'd help with the --checkpointz-server endeavour 🙏