-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
remove Val API and add links to outside spec/standards repos #1366
Conversation
djrtwo
commented
Aug 16, 2019
- removed Validator API from specs repo. This API has been migrated to https://github.com/ethereum/eth2.0-apis and will serve as a central location for additional APIs as created and standardized.
- add links for api, metrics, and interop standards repos to README
README.md
Outdated
@@ -37,6 +37,14 @@ See the [Eth 2.0 Phase 2 Wiki](https://hackmd.io/UzysWse1Th240HELswKqVA?view) fo | |||
* [Beacon node API for validator](specs/validator/0_beacon-node-validator-api.md) | |||
|
|||
|
|||
## Additional specifications for client implementers | |||
|
|||
Additional specifications and standards outside of core consensus can be found in the following repos: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, networking spec is also "outside of core consensus" but we leave them here for more visibility/engagements, right? Could you elaborate why only moving restful APIs away? Is it for letting the clients take eth2.0-apis
as a submodule?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I said outside of core consensus, I meant more broadly, that a client doesn't really have to implement any of these APIs. This only aids in interoperability and standards for dev tooling. The cycle on which these might emerge and the standards around them is likely to be pretty independent of the core specs. I also think we might want to write tests against these APIs which would even more so clutter this repo.
I mispoke with "core consensus". I meant more broadly, the things that a client must conform to.
What will happen to non-API standards (light client, test formats, networking, key store, HD wallets, checksums, ...)? Would it make sense to migrate standards to |
Generally I like tests, generation and formats to live together. But this doesn't mean we can't split it up. I would keep spec-tests, spec-tests-format, spec-test-generation, and welll... the spec, in this specs repository. But then move apis, apis-test-format, apis-test-generation etc. to the new apis repository. Same thing for the other eth2 components. |
Right now some standards are being placed here and some in eth2.0-pm. Maybe makes sense for a new repo. As for the light client, it is connected enough to the core spec that testing might be easier at lesat initially done here, but it too might evolve to an independent repo at some point |