During the call, ben was briefly talking about importing interfaces through their JSON-ABI as an interoperability measure. The relevant issue in the Solidity repo is here: https://github.com/ethereum/solidity/issues/1687
A comment by alex suggests to put these abi-json interfaces in their own files in the standard-io-input (as part of the “sources” field) and add a “kind” field for each source file where this would be something like “abi-json”.
This “kind” field would also make it easier for projects spanning multiple languages.
For interfaces import I’d suggest to have an ability of file import, like so:
interface Token from './erc20.json'
And for JSON files with custom structure it’s possible to define a path inside of JSON:
interface Token from './erc20.json#contracts[0].abi'
Where ./erc.json is a path to ABI file and #contracts[0].abi is a path inside of JSON object. It uses some trick as URL suppose hash wouldn’t be sent with a request and should be handled on the client, it’s safe to use hash in paths like so. And handle it with solidity compiler itself.
@rumkin I’m not hugely familiar with how the solidity compiler handles imports - but this seems a little out of scope for the ethpm v3 specification. I could be wrong though, so feel free to bring this up at the next sync.
There is now a machine-readable schema to validate v3 manifests - it can be found under spec/v3.spec.json in the ethpm-spec repo.
The examples in the ethpm-spec repo have been updated to reflect the changes in the spec - for a visual idea of what v3 packages might look like. You can find them under their respective folders under /examples/ with the file name v3.json @ https://github.com/ethpm/ethpm-spec
This spec is still a WIP - though we’ll be trying to finalize it within the next sync or two - so the sooner we get any suggested changes, the better. To give everyone enough time to go over the changes / examples, let’s plan our next sync for Thursday, April 16 - at 9AM CST / 3PM CET. If that time doesn’t conflict with anybody, I’ll post a zoom link here shortly before. Cheers!
Just a heads up, if you’re not already attending the solidity online conference. There’s going to be an ethpm discussion tomorrow at 8:55 pm central european time. The conversation will revolve around ethpm devx and the v3 technical specification. If you can make it, it’d be great to see everyone there!
Hey all - to continue with the discussion from today’s solidity summit we’ll have a call next Thursday, May 7 at 9AM CST / 3PM CET. I’ll post a zoom link here shortly before.
General friendly reminder / ping about the sync tomorrow. It should be the last sync before finalizing the v3 spec! Hope to see y’all there - i’ll post the zoom link here shortly before start time.
Yeah, @njgheorghita would it be possible to draft a blog post about this so we can Tweet it out and get Last Call comments on it before you draft the EIP?
Yeah, that would be excellent. Tweet blasts are much appreciated as my twitter game is pretty weak. I’ll type it up and link it here as soon as it’s ready.
Moving conversation here @njgheorghita since this isn’t really about the EIP structure (which is all that should really be discussed in PRs).
I’m specifically referring to the source checksum which explicitly says that it is required if there is no URI (meaning the file is not available on a content-addressable filesystem). Either you have a URI like ipfs://… or swarm://…, or you don’t. In the case that you do, the checksum field is redundant. In the case that you don’t, the checksum field is useless.
In the case that you don’t have a URI - it is required to include the contract source as a string (under the “content” key) in which case the checksum field is also required, containing a checksum object with the algorithm used to generate a hash and the resolved hash of the inlined source.
What is the purpose of including the checksum in this scenario? What problem does it solve? What value does it provide to the user?
If my memory serves correctly, this requirement was enforced to enable tooling / frameworks to perform additional verification of any in-lined source assets. It is possible for ethpm packages to be imported solely as a json file (for example… if a user copy/pastes the json directly from an ipfs explorer rather than importing via the ipfs uri), in which case requiring the checksum provides some extra confidence in the authenticity of the inlined sources. However, if a user is interacting with the ethpm ecosystem as it was intended, then this requirement is overkill. I’d be on board to update the requirement to include a Checksum object along with inlined sources to just a recommendation, unless there are other objections.
Why not checksum the entire file in that case, as is common practice throughout the industry (serving a file hash as well as the file itself to protect users from MITM attacks)? This way, users in such a scenario can use existing tooling rather than needing custom tooling. This also would mean the entire file would be checksummed, rather than just part of the file.
@fubuloubu If I understand your example correctly, it would fall under the third category where the package creator could populate the Checksum object with the ipfs cid.
@MicahZoltu Correct me if I’m wrong, your concern is that in #1 requiring the Checksum object is redundant. I’m ok with dropping the requirement for a Checksum object to a recommendation in the first scenario.
Yes, in (1) the checksum provides no value because the payload source and the checksum source are the same which means it is trivial to put in a checksum that matches the provided payload.
In (2) no checksum is needed.
In (3) a checksum is valuable and I am OK with it being required there.