Clarification about IP naming

[TheEnthusiasticAs]

Thx you guys for this proposal!

So, e.g., when the ETCLabs Core team wants to contribute an IP, they call it: ETCIP-thereOwnVersion.

(I am not a programmer)

[TheEnthusiasticAs]

The idea is also reasonable. I can also imagine to merge the naming-methods from *IP and Yaz, e.g.: ETCIP-L-123123. It shows, that the ETC community respects the devs (even without this they do it 😃 ) and not only there product. Furthermore, it gives a structure in the ETC repo.

[BelfordZ]

the version is a hash derived from the name of the *ip. This means that anyone who wants to support a proposal will have the same version hash, and thus no conflicts.

[phyro]

@BelfordZ I also have a question with the versioning so I'll ask here:
1.) Is the proposal name the Title attribute in the *IP template?
2.) How do we know 2 proposals have the same content? For instance lets say we have 2 ECIP repos for Geth and Parity clients. Someone opens a PR with the proposal on Geth repo and then Parity people see it and open the same PR on their repo. Parity implements the proposal and merges the PR and then people comment on the Geth proposal which causes a change to the content of the proposal. Geth client implements it and they now both have the same filename with the same hash, but a different content.
Should we use the hash of the content of the file instead (this would mean we can't have the version hash in the content itself, so maybe we could use some nonce/integer or something)?
3.) Names that base on hashes can become very hard to read in my opinion. Especially when we have Replaces and Superseded-by as hashes. I suggest we add a short title to it e.g. *IP-{title}-{8_bytes_hash}

[zmitton]

I like name scheme. wasn't really sure how to number an IP before (I think it was assigned by someone in an ivory tower?) so the determinism is an improvement.

Does any of this address the problem of where it is to be hosted?
What we like are all the github tools but it’s just another company we are somehow ok giving control of all IPs
We could use an open ETC registry for them and build tools to communicate everything in chain but that’s a whole thang
Logs are actually cheap enough to write entire blog posts onchain
A buck a page er something

To solve the current concerns I suggest the following (in addition to @BelfordZ's proposal):

Whenever ETC Labs creates an ECLIP that we need community to weigh in on, we simply cross-post it as an ECIP with (1) A link to the ECLIP, and (2) A note that says all discussion for this ECIP is to take place at the linked ECLIP.

This would allow users to avoid confusion because (a) they will still have one entry point to find and submit ethereum classic proposals, and (b) if anyone from ETC Labs tried to censor the discussion, the ECIP (being that point of entry) could re-open discussion back there.

[zmitton]

I guess the issue im most interested in solving is discovery. Admittedly I dont find the current EIP system ETH uses even very good at this.

deterministic numbering is an improvement regardless

[BelfordZ]

thank you all for giving this a look.

@phyro Ive created issues for discussion points you've mentioned. Here they are

1. Clarify what is being proposed here #4
2. How do we know 2 proposals have the same content? #5
3. Readability Problems #6

@zmitton agreed that the main feature here is the deterministic versioning -- which enables the dissolution of this 'forkaphobia'.

It doesn't necessarily resolve the issue of where its hosted, but it creates a framework in which they may be hosted in numerous places without much issue or confusion over what number to use if they can be created in any repo.

hmm the on chain idea is interesting -- but IMO leaving out the problem of how consensus on a *ip is achieved will help keep things simple for now.

[phyro]

@zmitton ethoxy/specs#4
since you said you're interested in discovery, what do you think about this URI proposal?