Create EIP for package registry API

[pipermerriam]

What is wrong?

We've seen how the token ecosystem has benefited from having a standard API (ERC20) for interacting with tokens. We need the same for package registries.

How can it be fixed

We need an EIP which defines the standard set of methods and events for package registries. Functionality should include:

• Enumeration of all package name and version pairs (string, string)
• Retrieval of a specific version of a package (URI)
• Publishing a new package (package name, version, URI)
• Event that is fired each time a new package is published.

Discussion needs to be had around functionality and events which are non-append only such as:

• Updating a previously published version
• Deleting a previously published version

[pipermerriam]

cc @HACKDOM

[cbdotguru]

Edit: Went a little fast on this. So, initial thought here and maybe our guys @joshuahannan @diaswrd and @paulohp can jump in this as well. To keep it simple, have a storage array that lists package names bytes32[], not sure if we want to limit to 32 byte strings, then a mapping of bytes32 => bytes32[] which is an array of versions, and then map the hash of the name/version to uri? bytes32 => bytes

[pipermerriam]

Some thoughts:

package names can be up to 256 characters long (and probably should be validated as such). Need to use a string or bytes type for those.

You might look into the data structure in this library as it loosely provides all the functionality you need. https://github.com/ethpm/ethereum-indexed-enumerable-set-lib

Versions should also be bytes or string type. I don't think the length of these needs to be validated though it may be good to set some arbitrary upper bound (like 256 chars) just for good practice.

And URIs will also need to be bytes or string type since the URI could be arbitrarily long. I don't think any upper bound should be enforced.

[pipermerriam]

@HACKDOM do you have any thoughts on how authorization should work? Do you guys have any kind of pluggable auth model that will easily allow the owned pattern but still be extensible to allow more complex authorization patterns?

BTW, I think that a simple owned pattern is a good enough starting point.

And one more thing. It may be worth exploring a Logic-contract/DB-contract abstraction so that the actual package index contract can be upgraded without needing to migrate all the data to the new contract.

[cbdotguru]

I thought about this briefly. Are we talking at the registry level or the package insert/delete or both?

[cbdotguru]

Ref the string/bytes... we can’t do dynamic arrays of either correct? Should we look at incorporating Nick’s string lib?

[pipermerriam]

I thought about this briefly. Are we talking at the registry level or the package insert/delete or both?

Assuming you are referring to my comment about authorization, I'm thinking about it at the registry level.

[pipermerriam]

Ref the string/bytes... we can’t do dynamic arrays of either correct?

Yes, I think the way I did it before was:

• storing package names as the sha3(package_name) in a bytes32.
• keeping a mapping of sha3(package_name) => package_name for name lookups.
• repeat for versions and URIs.

[VoR0220]

I am very pro this standard discussion. That said...we need to get it right. ERC20 is flawed and hence the need for upgraded versions of the standard that we have all probably seen by now. Let's take our time with this and not standardize the first design we come up with.

[VoR0220]

Perhaps we should add a standard method for exposing this via ENS, enabling reverse proxies and what have you, with a standard identifier to make note that this is a registry. Perhaps then a standard for serialization of URIs.

[pipermerriam]

But in general I agree. At minimum, recommendations for how registries should be linked up with ENS would be great.

[VoR0220]

Working on fixed points this weekend...been too requested and i need everyone to get off my back regarding that :p when thats done i will come back to this with suggestions. Im beginning to think that ENS needs to come prepacked in ethereum clients of all flavors...would help a lot.

[cbdotguru]

There wasn't a clear spot for it yet so we initialized a package registry repo here, https://github.com/Majoolr/package-registry , to being the process of creating the example contract. @paulohp is going to start looking through a developing this week.

[cbdotguru]

Consideration should be given to either use functionality provided at https://github.com/ethpm/ethereum-indexed-enumerable-set-lib or https://github.com/Majoolr/ethereum-libraries/tree/master/LinkedListLib. Any ideas/opinions are welcome. Another question is, does list order matter. If so, we can look at including Nick’s string utils here https://github.com/Majoolr/ethereum-libraries/tree/master/StringUtilsLib to keep things in alphabetical order. Not sure if this should be done on-chain.

[pipermerriam]

@HACKDOM I'm inclined to say that sorting is problematic but I think the problems I'm thinking of are implementation specific. In the previous implementation you could make a call to registry.getPackageAtIndex(i). The registry kept an array of all of the packages and that function would return the one at the given index.

A piece of software which consumes this registry can keep track of the latest index that it's fetched and only fetch new packages when doing things like search, or displaying a list of known packages. If that list was sorted then this approach would no longer work.

Doesn't mean it's a bad idea, just that it'd be good to consider this use case.