ETHPM = metadata by Nick Gheorghita

talk about EPM and a lot of this piggy backs off what Liddy was talking about with the source verified project how we kind of are attempt to find like a mutually compatible data structure for both our projects I'll probably start by giving just a little just little history of EPM how it works where we are where we're going and try to open up fair discussion as soon as possible each p m is a decentralized package manager we're just trying to do what package managers in other languages do for aetherium it's their two main components one is a JSON schema so essentially every DPM package is just a JSON object and the schema defines how you arrange your contract assets in standardize it and second component is an on chain registry specification this is just a read and write API for your on chain registry so this is a pretty simplified version but just give you the full workflow you start with a smart contract then you create adjacent object that represents those contract assets you publish that JSON file to any content addressable file system mostly ipfs and then you would write these three pieces of data to an on chain registry the package name the package version and the content addressed URI and that constitutes a package release and inside a package you can also include any number of contracts and any number of unchained deployments it's really up to the package out there to choose what they think is important to include it in the package and so we also have defined your I scheme so with this one string you can plug that into any tooling or framework that supports EPM and now that tooling will framework will go to the blockchain look at the URI pull down a JSON object and expose the contract assets and whatever way is you full EPM started in 2016 ish it was a joint effort between Piper Miriam from the PM Foundation and Tim Coulter from truffle one important thing to keep in mind is v1 had a single on chain package registry this was decided not to be great it's a lot of maintenance overhead and introduces some security assumptions that weren't ideal but also it made the developer experience a little better and so far today EP M v1 has had much more usage than v2 this is mainly because of truffle truffles integrated very nicely into its workflow so it's easy to use EPM v2 which is the current version of today broke the single on train registry model and now we have federated registries so if your package out there and you want to publish your packages you're responsible for deploying your own Unchained registry where you know only authorized party names are allowed to release packages so far to date we've got a pretty wide range of tooling we have a CLI we have a remix plugin native support and browny JavaScript Python libraries a web Explorer but truffle is still in the-- one and we haven't seen great usage or like a large amount of v 2 packages floating around although v2 support for truffle is in the pipeline and should be available in the next major bump version bump but yes so this is just to say that like developer experience has been really important in adoption for EPM without the nice integrated truffle workflow we kind of had this chicken egg problem protocols and companies package author or smart contract writers don't here demand to publish EPM packages and smart contract devs are you know happy to copy and paste code from github to build off of other people's code and so on the right is just some of the top level keys in the json schema and so EPM v3 it started the conversation started in the source verify getter channel trying to find a data structure at a standardized jason schema that can work for both of our uses and this is just really nice because it was very important it's like it's proven very important for package management for it to be as simple as possible for developers otherwise we'll just copy and paste our code and so now with native support and the compiler you know we'll just automatically seed the ecosystem with a ton of packages and hopefully this like spurs adoption and better like software development practices rather than copy and pasting code we've had some productive workshops over the past month we're quite close I'd say to finalizing the v3 spec there's still some technical like edge cases to iron out but yeah so once we iron this out the next step would be to create an EIP and then work on implementation and yeah this is essentially the workflow that I envisioned or like one instance of it where a protocol or auditor would have this widget in their github you just click it to copy/paste the URI and then you can plug it into any framework or tooling that you want it's a really simple spec to implement it's just Jason so NPM is used a lot but that's only for JavaScript tooling which is an ideal and NPM also comes with some security concerns and so I mean that's the background I would like to open up for discussion here's some important links I mean you can find everything from EPM calm the theory magicians working group is where most of the discussion is happening and so yeah if anyone has any questions it seems like we have a shortage of packages in theory 'im open Zeppelin is a phenomenal job of like building the standard library but standard libraries only gets you so far and so if anyone has any thoughts on a developer workflow it'd be interesting to hear those why is this something you want to use would you find this useful and then if not we can move on into the technical details