ERC lightning talks | Devcon Bogotá

foreign [Music] Annette is currently still in a podcast interview but I think she will come also later I'm quickly gonna give an overview of what's going to happen in the next I think we have like one and a half hours you can already see a bit on my like drawn slides I don't like PowerPoint that much um like what will be the what will be essentially like the the the content of of this entire session we have uh lined up as like six seven speakers including me um we are going to Center all of these talks Around The ethereum Magicians and specifically we're going to talk about um ERC proposals so ethereum request for uh for for comments right so basically everything that didn't fit into uh Annette and Tim bico's earlier session I think like it was about two weeks two days ago about the ethereum core roadmap so how this works each speaker has roughly 15 minutes and then we have a usually like a five minute break where we can set up the next speaker and maybe there's even like time for questions I guess we will have some talks about timestamps in ethereum get locks from Ronin that just entered the room by chance we will have some talks about Soul Bond tokens about music nfts about yeah d-soc we will have two people speaking about the the problems in the web 3 music space about content types in in nfts and then we'll also have a a very recent EIP namely I think it's for the domain separator in EIP 712 so um I I wanna I Wanna Give before like we start with the speakers I think I wanna I Wanna Give a quick talk myself though kind of kind of like my own like lightning talk and and it I want to make it about kind of this weird thing that the ercs are which are essentially just like immutable um contracts that are almost like as immutable as uh a transaction in ethereum and uh the problem that comes with it which is that like we don't really know how to upgrade them and you know throughout this whole year of you know bull market and and everything especially in the uh nft eco nft ecosystem I think um you know there was a there there's starting to be this debate basically around like how can we actually do Innovation with these uh contracts if you cannot change them anymore right and so like what can we do about it and I've tried to kind of like Express that where you know like this contract uh this this document this proposal that once you once you put it into the the final status then it's really like locked like this like this locker and we can't really unlock it anymore and so we have to find ways of like still upgrading it and that's that's what I I want to try to motivate that actually and I want to try to make like an optimistic case for what it's actually cool so but first of all I think we have to backtrack a bit and and this so this is a comment from uh I believe the the GitHub thread on Erp 2612 the uh the the permit standard that allows you basically it's like a replacement for erp20 tokens where instead of sending the approval on chain and like kind of like wasting all of the scars for the transaction envelope you you technically could sign a transaction get that gives the spending contract uh the permission with your signature and so the idea I guess would have been that new use cases are kind of enabled and that also um that also we can save a lot of gas especially like considering that you know each erp20 transfer is essentially like two transfers right today and so if we could already condense that to one I think the gas savings would be uh quite significant considering like how much we are transacting with erp20 tokens so this comment is actually a critique though on that standard and basically it I I don't even like fully know the entire history but I know that I think the the standard has like some issues it's not really in in final mode either and then you know like many uh companies have like kind of diverged from it and and they're like non-compliant and that's like I think with this standard so it kind of shows I think maybe a a a bear bearish case for for this kind of um standardization approach and then um the other case which I had to deal with myself uh personally because I I crawl nfts this is the interface for the Zora M nft contract and m stands for media nft and you know I I think my first exposure to this was that I was kind of like disappointed because essentially when you call the token URI like the regular token URI you are expecting a Json and uh but what I'm getting back is a media file and so I have to actually have to actually go to the Token metadata URI and that's where the metadata is right I mean the name is descriptive of that and and so I was a bit disappointed because I couldn't like I had to basically build like this uh this like custom logic around it but on the other hand I'm also empathetic with that because uh in the regular nft the media file which has been like traditionally the image is literally in a uh Json object that we call metadata so I I mean in my opinion that says a lot about how we think about nfts and that we see the image or like the media that is attached to the nft kind of like as metadata to something that is the nft that is kind of like maybe like a financial instrument then or whatever and so I I think it's actually beautiful that they that you know that they made the case that we should actually use the token URI to embed the media file directly and to Center really the nft around the media file and not uh make the media file a mere uh metadata field so foreign and apart from all of this uh like pessimism I think there's there's another good reason for uh submitting and and being active on this forum and it's because you get a ton of exposure to uh to your ideals so this is a thread here that I made I think around in in April and it's about uh like a specification for soul bound tokens or we now call them account bound tokens and this threat has gotten 9000 views and if you would sort by the replies it's actually the top uh the top controversial threat on the entire forum for the for the entire year apparently so I mean while that is uh concerning to me because apparently a lot of people have opinions about this it's also on the other hand it was a like a beautiful chance of of receiving feedback and also called lack of receiving constructive feedback which with which without that this standard wouldn't wouldn't have gone where where it went today so I initially started this um as a non-transferable token uh specification and basically now we have can we have like moved into consensual minting um and into like yeah basically like having the the signature being checked by both the sender and the receiver and you know we are actively talking about all of the Privacy challenges of Soul Bond tokens and so this has really become basically like a space where this entire standard all the solar token things everything is like very verbosely documented and and I I think it's awesome because I I wouldn't have had these ideal ideas by myself so I think this is like a community effort and it's cool um and so by the way I'm like basically these slides are all a um Eve magicians blog post essentially and uh I need to find a bit my way but so the so so basically one of the but kind of like one of the one of the problems of the EIP uh standards process is that it's it it's it's truly permissionless and it's open to everyone essentially because you can just go to like the uh you know like github.com ethereum eips and you can submit your own EIP and as long as you are uh complying to the uh the formatting rules and you're like you know you're like um receptive to the to the feedback of the EIP editors and you're not like mean to them or whatever you you will actually get your document merged and that document will show up on eips.etherium.org so that's really cool um and that's really a strength but it's also a weakness and I think this uh I guess it's like a bit of a famous cartoon in the in the uh in these standards community at least where you know like the there's like the this XKCD comic uh you know where there's like 14 competing standards for a use case and then there's this one guy saying hey that's crazy like why do we need 14 standards we should have one standard that has all of the uh that addresses of the use case and suddenly we have like 15 standards right so so it's kind of a problem in the ERC process as well that we just have like a lot of verbosity and and duplication and and so on so it's like you know on one side we have like the strength the openness and also this like uh yeah it's almost like a Spam problem or whatever but I wanna I wanna I wanna still motivate and I wanna I wanna say that I I find this actually awesome and I find it awesome because I think that there's a difference between a a temporarily emergent consensus and a consensus that is more like spontaneous and probably like from this kind of like uh you know like group or a committee of experts and so I I've tried to visualize that with the two different kind of approaches the two different extremes so to say where you know on one side we have more like a market driven adoption where the individual kind of uh makes the decision by themselves they they do all of the due diligence and and they come to the conclusion that they want to use a standard and then on the other hand and this is maybe true for uh yeah like more I think like groups that have to make decisions rather quickly and and like uh yeah like close to time I think you have this basically this this spontaneous committee consensus where you know 51 can basically overrule the uh 49 and I and I want to make I just want to uh kind of make this argument that you know I I believe that the temporarily uh continuously emerging consensus is actually the the cooler one the the one that has like a that ends up having like a stronger signal over time and that's because I I mean there's one hecky way of just like proving that and that's uh that if you consider like how organizations are run today then it's probably mostly in like this 51 51 consensus style right and then on the other side you have this totally chaotic evolutionary kind of thing that that is the market that somehow also figures out like what is the best decision but completely different and not by talking to each other and so I I think and I mean by no means is this uh Financial advice but I I would always bet on the market and not on like an individual uh committee actually and and so I I think that's that's actually the better uh the better approach and and also I mean I guess it's also the reason why like much of our critical infrastructure is like running that way like I don't think there's like a you know like a central planning for the Food Network in a city or uh stuff like that um and so so the question is though like how how can we overcome this this uh this immutability of of contracts and how can we actually still innovate on those standards and and this is especially true with uh with all of the like this you know all of the eyeballs that have have like went into the nft space and and you know kind of this difficulty of of innovating with the standard and and I mean sadly also with being non-compliant to the standard and just trying to grow uh externally from standards and and so I think immutability does not necessarily mean uh stagnation I I think actually there is now we are starting to see a pattern emerged where people are starting to really upgrade the standard and they are doing it in a way where they are basically like um yeah basically bolting um kind of this one lock to the other almost like a like like in a I don't know on these bridges that sometimes you can see as a tourist kind of thing so so I think um over the last half a year that has really happened so uh for example we now have a standard uh event for emitting a uh an event when the metadata is updated in in an NLT standard and that's uh the one on the top right it's the 4906 that essentially just emits an event we now have a very uh interesting standard for that basically splits the user and the owner into two different groups and I think especially with you know with d-soc kind of making us aware that there are only that that there are like subsets of ownership where kind of ownership represents this bucket of right and then you know you can have fructose and you're kind of Usos and abusers and so on um this this is starting to become really really interesting right we have like different kind of roles that could interact with the nft and then this could have like different economies and so that's I want to give a shout out that's 4907 and then I guess maybe like a a more Infamous one is the is the royalties one and it's the 2980 81 and that's basically an optional an an optional royalties location mechanism for nfts that is implemented I think in uh in many nft marketplaces and and again I I just want to highlight that I think it is definitely possible to upgrade uh these things and like we are we are doing that I just think that probably the time Horizon that we're looking at this and where you know we're like drawn to being a bit more pessimistic I think maybe we or I mean personally maybe I have to be more patient and just like trust in the process and um yeah I guess I have five more minutes so I'm also gonna uh of course I'm gonna shill a uh a standard that I did myself which is the minimum uh So Gone token and it works in the exact same way where basically we are extending and even breaking the EAP 721 interface and essentially uh we're allowing people to lock an nft so you can emit a locked event and an unlocked event depending on whether the transfer function should be uh should be reverting or not and then we also have this view function that allows you to always check whether a token is locked and the purpose for this is that um that if you were if you were to just use like the plane um 721 standard which actually it has a kind of like a small uh line in it where it says like that these uh nfts can also be they can be used as a reader like a read-only registry the problem is that indexes and wallets and so on wouldn't really recognize it because a computer cannot reason from let's say you know the transfer is reverting to you know this thing is like locked because it could also be that you have done like something else like something something else wrong you know and so therefore the error might be referring to something else so I I personally think that's useful and that's final now also and it's building on uh uh 721 yeah I mean now I'm at uh 17 minutes the next we're gonna have the next speaker um thank you for also giving me the chance to give this little talk and um I want to ask to Stage Ronan I don't know the exact finances thank you okay thank you for coming here um and kind of to explain it I'm not too sure demo and I wanted to show it in real time but the Wi-Fi made me so made me realize that I should probably uh have it already done and show you the result um so basically the proposal is to improve so what I'm building I'm building a indexer so that kind of take all the event of a contract and contract the state which is our most a smart contract system under State for the client for yeah for basically having data about it and most projects use a backend which is at odd with the vision of of decentralized application so yeah my idea was simply let's index in the browser and of course uh it doesn't work for everything um because of the scale of some of these of these systems so for example if you wanted to index all the nft uh you could do in the browser but it will take a while um but for some other case it actually worked very well um and so I was doing so I have this game so the whole state of the game is actually here so you have all the fleet is gaming space you have planet and Fleet uh you can there's two main things and it's like I think this state is around seven megabyte but it's not actually I didn't implement the full uh so I have an index I have the same indexer running on the graph um and I didn't finish to implement it fully here that's what I expect maybe to get to 20 megabytes of State um and I can on the normal Network I don't know what normal means but it cannot it took five seconds to think the whole thing and if you can obviously um uh but I made an assumption that uh in my in my game there is this notion of time so every event um so the state the the contract will kind of lazily update per time and I think it's quite a common thing in it's my contract and unfortunately when you fetch the logs which is a mechanism by which you index and manage to get back the state all this event basically which um you don't have access to the timestamp at which they open it's just some reason uh they didn't so to add that so there is a blockage the block number but there is no block timestamp and so my game actually when I uh I need the timestamp and so because I don't have the timestamp in the logs I get like 20 000 events here and what I need to do then I need to request 20 000 times um depending I mean a bit less because you can have uh same even an event in the same block but you I have to request that on top and because it's a in browser indexer it uses eip119393 which is like the the wallet interface and I cannot do batch request I have to do all these requests and so uh I have this version we actually is still running from last time and sometime here or out because the RPC is not happy that I'm so the RPC of metamask because again here it's a juicy static web page there is nothing no back-end um and it all only rely on the fact that the user have a eip1193 wallet in that case it's metamask and if you if you look at my settings It's actually an RPC uh somewhere else but uh so it's still querying all of these to get the timestamp while the other one have been finished a long time ago and only actually you see 580 request is actually 300 because the other one now is just to get the latest block and nothing is really happening in that game right now um while this one is still like fetching the the state so it's going to reach probably 20 000 to sync or maybe even more um um yeah so so the proposal I wanted to show you a kind of a really example but the proposal is um is basically to add this to the Json object so it's a very simple change you can do in a in your node so in goatorium or what whatever and so actually finally enough uh like team pushed me to go to the core Dev meeting the other day and actually I'm going to and so we are the interesting discussion about it but um so I kind of so most of it I already say but the idea is that you must so what I could do is that I could add the timestamp to the to the event itself uh but obviously when you do your contract you know that there is a block information so there is no need to add the timestamp to the event it's just a waste of gas um and time is an important aspect of many smart contracts and block number cannot be a replacement for them and the reason why is because uh block number timings can change across chains but also there is no guarantee that a single chain will not keep it and you could probably emulate an average block time using smart contract itself but it's kind of a ugly work around um and black block times them already easily available like the block hash or the block number and another so I've been discussing about a few people readers and yeah but this is extra data you have to put in in the log object but it's small and the alternative is to to fetch all of these anyway um so of course for the one we don't care about timestamp then they they have an extra a small but I feel it's small enough alternative but I would not consider as alternative actually I could use them as complementary uh so when I mentioned them I'm not saying I don't want them actually I want them um but I feel they they will not replace you um so yeah basically when alternative is to add batch um a batch API for Erp 1193 it was actually part of the conversation initially but it was dropped but I think it's it's a valid one to have and but my opinion it doesn't offer the same Advantage as having the box timestamp in the log um and another EIP that I didn't see it yet is to have a great graphql API uh so basically an alternative to eip1193 and with graphql you can ask what you want which make it more efficient as well uh for transferring data so if you don't care about the timestamp you don't need and actually this one could really by actually solving the first one so this one is really an alternative but uh I don't see any reason to just um add another one especially I think graphql is not supported in all the node implementation today um and so as I say I went to the core Dev and we had the feedback and the main feedback was that hey there is no point to do it because we are going to make uh the logs uh not being accessible after a certain time and so the argument was like you will never have that many log and so requesting the timestamp anyway won't matter uh and so my reply is that uh so it's an easy change uh so my next action would be to make a PR I guess for goitream um and and the number of log actually can still be significant um so even if we remove past log we still want to to have access to them but actually the main issue with that with that feedback is that we need to really think how we are going to solve the state access about um if we we don't have access to pass logs how do we are going to index uh in a decentralized manner um because of course if you have a backhand you know you solve your problem but we we don't want to have a back-end right you want to be able to use tornado cache from your browser without relying with only relying on your node and so so I think I don't know for me that I would like to to have discussion as a community how we can so solve that like I know there is work on the uh around like right now about portal things portal Network um and so but I think it's important we um we understand like the point of view of application developer that don't want to be involved with our application once it's launched um and another thing yeah so I mentioned like most systems already rely on the log events we need this system anyway and even some EIP have been using it to kind of speed up the the needle kind of minimize the gas cost which is eip1155 like you can't query the balance of all the token that the user owned from the smart contract and so you're always a smart contract to be more efficient and it's because it has been the result of everybody acknowledging that we use logs and event to reconstruct the state um but that interestingly one of the things about in the code of meeting was that that was not the vision initially but now we evolve we understand what we need and so I think yeah that I I will end with uh with like yeah let's discuss about how to solve this being able to rebuild uh the state from from the client it's kind of all for me yeah any question thank you thank you Ronan thank you for close uh do so we have uh we have time for questions do we have any questions in the contract what are your thoughts on using Getters in the contract as opposed to events to get the data for a UI yeah so so far I I can talk about my game actually on that front so the first version I really wanted to launch the first version without any back end so the first version of the game the first Alpha uh I didn't have an indexer using the log and I was fetching all the data and it is not actually it's not efficient either because uh especially list of things and and you are wasting gas to support that in many cases like so this is uh what I mentioned eip1155 not having access to the balance and we could also think about um your seven to one um enumerable extension which add actually a lot of gas cost overall um so I and I think from what we have seen everybody like even to to do that role so I think that's what we should do and minimize the role of the yeah minimize the gas cost we basically that was when we Nima is the things that happen on the Chain if we can do it of chain but it's assume we have a system to retrieve it that's why I think it's important to discuss because maybe the conclusion is like oh actually we cannot and we have to pay gas to do that but I hope it's not the case hello everyone I'm gonna start my timer so I have a reference point here uh yeah this is my first time actually talking at Defcon this is my second Devcon um I'm super happy to be contributing back and sharing knowledge and the sparking debate and ideas so thanks for having me and thanks Tim for organizing this as well and it so today I wanted to talk about uh eip4973 Badges and the financializing towers and Beyond as well uh so firstly a little bit about me my name is Rahul I'm co-founder of this little baby company that we started called autospace uh and I've been in the crypto ecosystem since 2016. I started off with my journey also with music I was building nfts to assetize music royalties back in 2017 did not work uh they moved on to SoundCloud got fomo with those and I got back to crypto full time now uh so I think I want to start with uh how this year had started actually like uh we think that there's this paper called decentralized Society uh and it centered our attention on this notion that web3 centers around expressing transferable Financial assets rather than encoding social relationships of trust uh when everything is transferable things can be sold to the highest bidder so you know we wanted to challenge that uh and that's that's what that problem is what gave to this idea and working with Tim on this EIP uh what we call account bound tokens not to be confused with sold down tokens or you may be but semantically speaking we kind of uh you can Define this as non-transferable tokens bound to an account and then our goal here was to really it's very semantic based again like to create special ownership Deeds or creating like permission Primitives but really to create a new ownership experience through this primitive you can read more about this uh we have written a more extensive uh article on this uh however ever since we started we saw we noticed this account on tokens uh debate had kind of like exploded you know there's soul-bound tokens there was Community about tokens ens name bound tokens now human bound tokens uh what we're actually seeing is this non-transferable tokens is a spectrum and you you can Define what is being bound to and what is that binding strategy and you can kind of uh this is this is where the explosion of ideas are coming and as a builder I feel like some of the nfts nft spec is kind of over optimized for what we actually express our ideas through so we're kind of like craving for new tools and new uh new instruments to kind of like uh build our ideas right and at Auto space we we call something smaller something simpler we call them badges which is powered by eip4973 accountable tokens so uh I want to dive right into it like because because ever since Soul bound tokens was kind of like really a Hot Topic it kind of sparked like a lot of hot debates or uh and it's it's debates are great like because uh it really helped us intellectually navigate the space and like get like a pluralistic opinion uh from various uh parties uh one of the first things uh or concerns they put out like I think was permanence you know what if I don't want a sold out token or an account token you know anymore and the second one is a lack of consent what if I get an nft like that's non-transferable airdrop to be with my uh personal details you know what would happen you know and key rotation you know like I I what if I lose access to my key wallet yeah I want to like I mean uh to my wallet or do I want to change my wallet and lastly this more popular active debate about like uh verifiable credentials and abts on Chain versus off-chain identity uh so lots of things uh very simply put uh there we've written again lots of uh detail on this but I can kind of summarize this uh these were the design decisions that helped us input into erp4973 so permanence when we talk about uh in general what we baked into it is uh burning and dissociation from the so the owner of the Soul bomb token or account bomb token can dissociate from uh from the token itself and then lack of consent uh non-transferable tokens through organ tokens cannot be air dropped you need to have a two-way consent which I will dive into a little bit later and with other space we're actually actively looking into recovery mechanisms like Community Based recovery especially if you lose access and you have all these non-transferable tokens uh and lastly avts versus verifiable credentials use both really it's not mutually exclusive uh they have like good use cases and it's really we're in the early stages of kind of like the debate and application so I'm kind of excited of what would actually come out of this next year uh so like on a very high level like I'm oversimplifying this but like you can see the key differences like if you look at like various uh angles or various uh Dimensions right if you look at transferability consent removal issuance expiration and fungibility but I think uh I want to bring Focus to where consent and issuance uh that's that's really what we wanted to like did not want to compromise on there when it came to a non-transferable token design so let's Dive Right In like so this is the erc4973 at a glance you could just npm install that very easy so that's a very uh very light interface right like it's just expresses so we can kind of like dive into what this uh actually does so firstly this top section right this transfer event balance off on or off this is this was mainly to ensure backward compatibility backward compatibility to nft in general so we actually implement the ierc 721 mm metadata uh so one of the things that building this EIP actually it was super amazing learning experience uh we actually didn't have the transport event first and then we were kind of missing all these stuff like etherscan was not showing the log events for example or metamask was not showing the uh the the interesting metadata so we we actually started using the transfer event which is such a simple change everything started working automatically you know like uh the support the interoperability actually came came for free and that's one of the reasons we went back to the transfer that although in a non-transferable event token you can argue that transfer has no makes no sense but this was one of the design decisions that we learned like to kind of Ensure backward compatibility uh and the next one and this is really the where the consent really comes into play so if you see the function there's like three three parameters right like the from the URI and the signature so we call this a take flow so you cannot actually mint an account bound token unless it's two parties involved so it's like a peer-to-peer fully mutually consented protocol right so you can think about this as like okay Alice designs and ABT described by a spec which is hosted by a token URI Alice then wants to issue the ABC to Bob uh Alice can only do that if this if if he signs using aip712 signature and provide that's capturing her consent so now that one party consent is established Bob can now take the SBT he would then basically authenticate by providing the circuit URI the signature from Alice and then prove that I can take this uh so this is uh in Auto space we actually call this the allow list flow so I'm just like adding people to an allow list I'm like signing uh people uh for to a badge and the give flow is actually its inverse uh it's uh it's when the when Alice designs an ABT Bob wants the ABT so signs it and then Alice can now give the ABT to Bob so this in order space we call it the airdrop flow so if you if you give a badge you can just like basically I want this and 100 people say I want this you can actually do an airdrop through uh through an account token and the last bit is this one it's uh the unequiv this basically means complete dissociation from the account bound token so only the owner of the token can dissociate so these are like basically the fundamental building blocks that kind of like help this uh create this very bare minimum uh very simple very it's highly functional highly utilitarian uh EIP 4973 and then Auto space we are kind of like uh building more flavors or more layers around it but this all the what this had serves at the fundamental has been working really good for us so far and I also call actively contribute to the EIP and uh yeah it's been super exciting and learning in general so moving on to the other side of what that the topic I wanted to chat about as well which is the financialization right at outer space where like the badges we see this in like six six areas how we can use a non-transferable token a membership model non-financial rewards uh and recognition onboarding quests to end with the badge assess the reputation uh more nuanced governance models and then unlock access permissions of these batch holders but I want to bring attention to this bit this bit of uh that's non-financial uh rewards and recognition I mean I think we can all agree that uh the ecosystem is like hyper financialized uh and we want to challenge that status quo like you know you if you're in a position of wealth and influence you can buy tokens and if your community is basically to design their governance on a one token one vote system so person of influence can basically assert their entire influence through that power it's basically plutocracy right so we want to challenge that and we want to move towards more towards the one human one vote but uh for us we see the one account one vote as a necessary step to kind of get to one human one vote uh and then this is really Fresh Off The Grill right this happened like a few days ago uh the mango markets uh the hacker exploited mango for 100 million hacker turns around uh offense to return the funds and he used 32 million of those votes to say yes to his own proposal because he hacked those and then executed that proposal and I think we can do better than this right like uh it's a that's a no-brainer I feel but it's really the takeaway that I wanted to kind of uh here have here is uh let's move away from the one token one vote system and away from plutocracy and uh I think let's let's explore new forms of governance I think it is no one-size-fits-all I think we're in a stage where the ecosystem is growing so so fast and we as Builders we we definitely need more uh instruments at our toolkit we need to spark debate yeah apply rigor get feedback so I'm glad that I'm kind of like getting a lot of that here in Devcon so that's uh that's a lot that's it and that's a Dali otter we are uh we don't work we just create these Dolly orders most of the time if you're as surprising my team is surprisingly good at creating daily orders you can scan this it'll give you more information about us uh yeah that's that's it thank you thank you Raul um we have some time left three minutes do we have questions ah yes okay hey um can you elaborate a bit on the account through the recovery part yeah absolutely so um so one of the things with account recovery uh it actually came up pretty actively in the debate like hey if I have badges in my account if you have non-transport like tokens what if I want to rotate my keys uh then how do I do this and that's one of the criticisms that were pointed at sold down tokensen initially uh quite frankly I feel this is a this is not a soul bound problem or a soul bound token problem this is a entire protocol ethereum problem and I feel like we need to wait until we need to do this better and then we can absolutely adopt it but we are looking at two ways of recovery one is a proactive recovery and a reactive recovery but we are offloading this to the community in our protocol at least so it's basically like moving from moving your phone like if you're importing your number uh from one phone to the other so you're actually doing a proactive action so you have to kind of like prove that you are the owner of this account and the account that you're porting over to but the way we're thinking about this is uh you can't transfer these tokens but you can burn all the tokens as the owner of the current account and you can get it reissued through the the issuing authority which is generally the communities or Davos the other aspect is reactive recovery which is where like I lost everything then you know that's a tricky one you have to establish with your uh like your Dao for example that hey I'm the same person behind this new wallet like you have to re-issue it and one of the models we are looking at there is reassurance but the community perhaps can revoke those badges so that's that's how we're kind of thinking about it thanks more more questions we have time for one more question here oh um uh just a quick thing regarding um uh recovery through burning and then reissuing it would be awesome if there was a way to do that atomically yeah right but the other question was what is the status of the EIP is there time to still make breaking changes uh or is it already like so widely adopted and this kind of relates to this stagnation discussion but I think it's yeah that's a good question I should have actually uh put the stats on it I mean uh people are already using it we've seen uh I don't know maybe like a 150 300 hits on probably somewhere on GitHub so we are actively thinking about backward compatibility when we're adding but the EIP is in review stage at the moment uh yeah when and now we're kind of talking about expiration uh as a as to be baked into a badge where you can give like a 30-day expiration badge for example especially if you're like joining a dial you get guest batch for example you know you can do some interest so expiring badge is something we're looking at but uh yeah like we are this is one of the forums we're hoping to get feedback on like you know where should we park it should we get feedback or have invest in extensions and like uh because there's a lot of utility this can deliver in its current form you know and then uh it would be uh strange to perhaps like you know stretch this timeline because I think uh I've seen aips go for years thank thank you Raul uh Applause please thank you uh yeah um I'm just gonna while the next speaker Sweetman is um going to set up the uh the laptop and so on I'm just gonna walk you through the rest of our timetable which is by the way here so uh next up is uh sweetman.

eath and he's going to talk about uh music the music nft engineer then we have Andres who is going to talk about uh web3 the web 3 music nft multiplayer problems I'm very excited about that I think it's uh like it comes out of water and music research then we have Ian who is going to talk about uh Rich content types in nfts and then finally we have Francisco who is going to talk about a uh like a very recent EIP called 5267 I think which uh I think it defines the domain separator of EIP 712 so yeah if you're familiar with that I guess it's you you kind of understand what it is if not then I recommend going to eips.etherium.org and reading up on it um uh yeah okay I do have a lot of music nfts for y'all today so first I'll ask a couple questions who has a music nft okay who owns any nfts on optimism who owns nfts on arbitrum who owns nfts on polygon my goal is by the end of this you will have your hand up for all of those hi I'm sweetman.ie aka the music nft engineer and today we're going to talk about music metadata first the problem you're going to see QR codes throughout this the ones on that side are from musicians in Latin America if you want to support creators here in Latin America scan that by the nft support local creators on this side you'll see cc0 music nfts 100 Freeman on different chains and so they'll be scattered throughout if you want some nfts momentum the problem don't worry the same QR codes are going to be a little bit hidden in here music platforms are not creating music nfts this is a very spicy take that I like to hold you'll see on the your left side these are metadata from the top nft platforms up top you've got Zora creator in the middle you've got catalog and down at the bottom you've got sound you'll notice that they each have different metadata but honestly there's no real differentiation between the metadata of a music nft and a normal nft in most cases over here on this side you'll see the music metadata standard this includes the same attributes as a normal nft in addition to attributes that matter for music attributes like lossless audio attributes like BPM attributes like duration these are things that matter when we're talking about platforms like Spotify or Zora wanting to index these nfts and to be able to differentiate between a music nft and a normal nft why does this matter when we talk about ethereum congrats we're in the ethereum Wizards room we have merged and so now the next kind of goal in our identity crisis as a community is how do we get Global adoption I see music nfts as the Trojan Horse for ethereum adoption while a lot of people don't care about nfts most people do care about music and so if we can build platforms that allow music nfts to plug seamlessly into the existing infrastructure we can allow for more and more people to be consuming the ethereum technology that we know and love but the big challenge right now is that musicians are using these platforms that don't really differentiate metadata between normal nfts and music nfts next the opportunity another set of nfts oh yeah the last one I'm sorry I didn't I didn't shout out the Creator so the last Creator this first nft is caspiel we've got Colombo in the audience um manager of cast peel and so that nft is from a musician named caspiel who dropped on Zora Creator and that is a music video of her latest music video reflejo and uh all of my music nfts are cc0 from a musician named Sagrado based out of Mexico my favorite because he does everything cc0 this next one over here we've got another Zora nft I think we've got tranky in the audience who helped a Buenos Aires Creator named uh well created a platform called unun and so if you scan this it'll take you over to unun to Mint some music nfts from local Buenos Aires creators and this one is another one from Sagrado and this one I believe is on polygon last one was optimism this one's on polygon the opportunity we have an opportunity right now to standardize music metadata right now it's been in discussions you might have heard about telegram groups you might have heard about different chats that are scattered amongst the music nft ecosystems maybe you've talked with Hi-Fi Labs about their music nft standards maybe you've talked with Zora there's a lot of different standards out there we have not really reached consensus and I find that awesome because there's no gatekeeper there's nobody that's telling us this is how it is it's very much a bottom-up what does each Creator want to use when they're making their music nfts um and again the full music metadata standard over there on this other side how you can help again the music metadata standard is not something that we're gonna have Sony or Warner or some record label is going to come down and say this is how it is it's going to be bottom up from the engineers that are building from the creators that are choosing what platforms to build on each of us as individuals is choosing which memes we want to propagate in order to make the mess the best metadata win the final set of nfts we've got this is a catalog nft from a Creator named hey Bella who is also based here in Colombia in Medellin and this one is an arbitrum nft the same nft um by Sagrado spread the memes all the ethereum Wizards all of you Builders we are building um it's important that we propagate proper music metadata when we're building if we're giving these musicians poor metadata we're setting them up for failure in the long term as Spotify as iTunes as these other big platforms the future tapes the spin amps our indexing music nfts if we're not putting beats per minute if we're not putting keys if we're not putting the credits on chain we're missing out and so what I've been working on is I cloned the Zora metadata render which is an architecture that allows us to decouple the erc721 the erc1155 all the tokens we know and love from the metadata that they represent and so we have a full music metadata standard that's fully on chain deployed on ethereum mainnet polygon mainnet optimism mainnet arbitrim mainnet as well as test nets for all those Chains It's live the contracts are verified it's fully running on a platform that I built called decent um and so what I'd like to ask the community here I'm not very familiar with the IPS I'm not really familiar with what we do as a community the formal way I'm really used to building with the musicians on the ground I don't know if we need an EIP for like proper music metadata for us to get aligned I don't know if we just need to talk with the Zoras to properly plug in the music metadata render into the Zora stack so that musicians can use it maybe it's just me writing an EIP with Hi-Fi labs and getting it plugged in there there's a lot of different ways we can propagate this meme out into the ecosystem I don't really know what to do and I'm not going to claim that I'm like the king of all this I just would like to have the conversation more um and so I'd like to ask for help in propagating these music metadata memes so we can help musicians adopt this technology so that musicians can start leveraging these web3 rails that make us and the technology that we love so powerful and groundbreaking and like fundamentally changing the world that we know and love that's it Viva La Musica these are all the music nfts that I showed throughout and then these are a lot of musicians that are based in Argentina and Buenos Aires in Argentina as well as Colombia that I work with on a regular basis and so if you want to talk to some musicians that are based here in Latin America and you want to like get their thoughts or help them out or talk to them about the music nfts that they're making I've attached all their Twitter handles above so please reach out to them they are the people that are on the ground doing this I am just some random engineer that's up here talking to y'all so uh with that we've still got 10 minutes so I kind of zoomed through that I believe the rest of the time open to any questions from the community thank you sweet man hand of applause [Applause] so do we have any questions in the audience raise your hand if you have any questions yes hi um I was wondering like uh how what was your process in navigating to the EIP like how did you gather information about like music metadata is a very complex structure right like uh and there's not having consensus over metadata just sounds like a classic music industry to be honest so I was wondering like how was your process to getting to the the stage and the EIP generally to be clear there is no EIP right now this is this is a bunch of blank data I copied EI I took a screenshot of eip721 and I blanked out the data to just kind of like put the meme in your head as something that we can do I don't question back to you do you think this is something we could do with an EIP or does this feel like you say like the music industry is too decentralized for us to come up with an eip4 music metadata standard I think yes uh there is one part that's probably up for uh like off Chain versus own chain I think if you have that perimeter very clearly uh I think this is this is exciting yeah in in an attribute I didn't talk about all of these uh all of these decent nfts 100 of them metadata is on chain so one of the awesome Parts about l2s is it's incredibly cheap to store all metadata on chain and so we can store that entire music metadata on chain for less than a penny and so musicians that are based in Latin America cannot afford to do transactions on each mainnet um but by offering them these rails to be able to create music metadata we can also offer them the opportunity to put it fully on chain so that there's no trust needed in apis like what sound uses or even like the delay you get by uploading to ipfs if you're not using a dedicated Gateway when you store it all on chain you get that instant availability that you get on optimism of a trim polygon and the other l2s thank you more we have more time for questions if there are yes um it wasn't clear do you want to write an EIP for this or do you not want to do it I'm very open to it I'm I'm here in the community I my entire life is music nfts and so if the community decides that we want an EIP I'm about it um I'm I'm very much of the belief that I don't I don't want to say like this is the way I like hearing like the music metadata standard I didn't come up with that that came out a catalog and I'm just propagating that Meme because it's in my opinion the best meme yeah no I I think um a great first step would be to public like it seems you've done a lot of research to publish that in some written form maybe in The ethereum Magicians form uh to just kind of keep it make it visible and someone else can then maybe pick it up and formalize it and they're in the IP that would be very valuable and I I want to offer a counter I don't think that you specifying something and standardizing something would be like imposing your view of things on the world it's just offering an option right and whether that's adopted or not depends on on the on the rest like you've said but having an option that is uh there and specified and like standardized is extremely powerful and I don't think it's imposing anything in any way thank you do you want to take more questions we have more time love to especially if it's from Dan hey um it's quite funny because obviously I wrote they bought a music report yesterday they came out on this subject have you not read it yet I have not interested in because there's definitely points of conflict between how we're seeing this um and for me having worked like the whole has inside the Beast as it were um one of the biggest issues in music industry comes around multi-party consensus around data points and also conflicts and that's always been my assistance about pulling everything on chain um because it it makes things much more complicated to and it also creates friction around how much you can actually trust something versus if it's housed somewhere else in some kind of on-chain registry that can be updated by multi-parties and so that's why my feeling on this has always been that music nft data should be minimally viable and contextual Rich data should be kept elsewhere but in a fair way if that makes sense so just interesting what you think about that what are your thoughts on the um the metadata render architecture that zores put out where the Creator is able to there's a trusted party um a role that is able to go back in and update that metadata when they choose does that make a difference or you still think the best solution is fully off chain well he decides who the trusted party is the creator but what if there's multiple creators I'm excited to hear Colombo's talk on that yeah this is the challenge right and then you've got differentiological buyers Publishers uh producers um all these people who are part of this Rich soup of um influencer creates a piece of art like at the moment the music entities were in a pretty nice place in there it's usually been one person putting something out um but gets complicated as soon as like that expands right um and I think like it's really important that as we're thinking through this we need to be you know thinking for like Mass adoption and how to do all that Point well taken nice we uh yeah if you are taking more questions we have two more minutes yes okay yeah tranky um this is more just a comment about whether or not you want to do like an EIP or something I was in a talk yesterday that was like see something called like c a i p it was kind of over my head I'm not gonna lie like Captain but it was a different type of like Improvement proposal sort of like Coalition about self-related like l2s and things I mean and addresses so it could be they have a the GitHub that's like set up so I think an initial interesting step could just be forked or GitHub and turn it into like a music metadata IP thing mmip or something I don't know but yeah just a suggestion yes so here's the catalog standard um and you're talking about cap 19 is like cross chain assets in here we have references to other uh types of assets and so you'll see in fields like artwork you have a URI and a mime type which is very normal but then you also have this nft field which can link to other nfts and that follows the cap 19 standard of cross chain so you can actually link different nfts if like for example all the nfts I just made from Sagrado are derivative nfts of an original nft I did not link the original nft and that's a downside on me and I'm going to publicly say that like I could obviously do better but the standard is already up to date so that if we want to link other assets within our nfts we can and so when we're thinking about composing nfts is music that's built on top of stems or music that's built on top of other music or a remix that's built on top of music that's built on top of stems the metadata can link back to those underlying works so that we can always be pointing the credit back to those original users did I miss the point of your question I heard cap 19 and I wanted to show this is mainly just mainly referring to the structure they have like on GitHub for like organizing Community like input so I think just like forking the GitHub they have would be a great place to start if you were trying to like start the process of figuring out how to like you know just like coordinate between a lot of people forking their repo seems like a good place to start just start housing that information in some place thank you thank you thank you yeah that's it we don't have more time so thank you very much Sweetman and next up is Andres and uh we are staying actually in music and now we are talking about um the web 3 uh music multiplayer problems and I'm very excited about that talk as well thanks uh not a lot of experience presenting but um here we are so we started off a few months ago a in the whatever music Dao researching about splits and um we basically got two three main conclusions some of them are very obvious some probably not that much one is that a blockchains can serve as a a login as a log of information and hopefully look into the future even like a global jurisdiction notary system with a legal validation the second one is that a blockchains have uh the the abduction architecture is based on a single a singular point of a connection or entry for the user and the third one is that a split protocols as we understand them in blockchain are focused on distribution of funds but us creators think about splits more on ownership than really a about it being a financial so what is the problem the problem is copyright right we all know it's the problem and it is the solution and copyright law has been used and has been abused uh but it's still the only a or the or the most widely used form of monetization of intellectual property right and if we're looking to the Future where each time we have less and less a jobs available we have a growing Creator class we need to keep copyright as one of those essential ways of monetization for creators and the the copyright industry is big is played with with problems but to narrow them down it is mainly a human problem like it always is and it is that people do not register their intellectual property as close to the moment of Genesis as possible which is actually the the best way to protect intellectual property and um so and this is maybe because creators think that registering or then speaking about legal aspects in the moment of creation kills the Bible so uh that actually gives birth to a lot of problems I like I've been up you know like I've had problems with uh um processes in which I have been in the studio I'm a music producer so I have been in a studio uh We've made a hit song everybody is super excited right the process as it is done it is that um at least in music creators get together in a studio and uh they songwrite they beat make they record and then they they bounce off the audio program which is a a WAV file or an MP3 and then that MP3 gets shared among the the co-creators and it's either emailed to us or it's uh WhatsApp and we can listen to the music or what we made and vibe to it and uh hopefully the next day know if what we did was whack or if it's a hit record right um so personally I have been in those situations and I have been muscled out or cut out of hit records because the more Savvy people will head out and register the the copyright of the song and this is a story that kind of like repeats itself endlessly in um in music making so what would the ideal process be the ideal process would be would be to register to have a mechanism to register the IP as soon as possible Right in a nutshell a in a nutshell it would protect the creators and hopefully in consensus be able to register this IP in consensus right so we have a solution right we have temp temporarily called it a copyright wallet and a copyright wallet it allows it's a tool basically it's a tool that is inserted in the job to be done it's a you know like a small sharp tool that is inserted in a job CB Dom process and it allows for in multiplayer mode deploying uh registry time stamping a registry on the blockchain of that intellectual property so this is the sign coming from a musician right but in essence what it is is a an application an extension an extension app that would uh register the title of the song let's say in this case the ownership splits of the participants and a mechanism to drag and drop the media the same way the uh uh a a chat with you know like have access to to listening to a voicemail or or a shared audio the mobile wallets of the participants would receive that audio and they will receive a notification too accept or deny their participation in the in the in that creative process and if there is consensus then a smart contract is deployed and the non-transferable nft is minted as registry so and before we go to Future iterations I would like to obviously uh I think this is time better spent if we if we open up a discussions because I mean this could be a a tool that obviously expand and is composed on but I would like to basically just open the floor to questions to see if uh if uh if we can get to a technical solution because the question that like the questions that we have is in the main question we have is does this really need to be a wallet or can it be a can it be a built in a simpler way so thank you Andres um do we have questions feedback raise your hand please yes see you thanks um maybe we could go back to the previous slide I just had a question about like what you're saying in ownership splits and it's kind of related to what you were saying where like ownership splits are more than just like who's getting what percentage of like mint revenue or something like that it's much more so when you're in that top left corner when you say ownership splits are you already like envisioning this like breaking down into like mechanical and like publishing royalties or are you trying to not necessarily be skeuomorphic and instead do other types of ownership splits or what's what's the idea here I guess a greater question that just how much of the current music industry are we trying to recreate on Chain versus maybe moving to stuff that's better in some way not that I even know that's better but yeah yeah that's a good question and and the answer would be a either we um one of two answers it I'm guessing the the Dynamics uh the current Dynamics are more of like you songwrite and you fixate on a on a recording immediately right just because the tools are available so people are not writing songs with their guitar but they just fixed like they just record them immediately and that is just because we have the tools to do it uh unlike before we used to like Write Sheet Music or or write song there a lyrics on paper uh so but the but I guess the the answer to that would be we could either do two Registries or just split uh percentages because at the same time you know like writing and mastering is basically a master like or like recording is like a 50 50 Endeavor right so we could um split from just one big chunk of 100 of ownership or mint you know specifics any more feedback we have more time yes so is is the biggest reason we want it to be a wallet so that we can have that kind of signature based approval like like the question from Dan in the last talk of um deciding when the metadata would get to be updated or if a piece of work can be included into a movie or if the rights could be included like you have that signature step from each of the participants is that the reason kind of thinking of it as a wallet or what what's the reason uh to have a wallet be the mechanism for controlling the rights so that is one reason and the other reason is and this is very personal you know like looking into the future what I think that would happen or would would happen or would make sense if it would happen is that this contract is like the master contract of all the IP that is derivative from this original registry so from this original registry and we spoke about it briefly on Twitter uh we could also have some form of progress nfts where everybody is for example we go into the studio and then we somebody's gonna come and feature a song right that it was not he was not or she was not in the studio in the on the first day of the recording then there's a way of tracking the progress of the intellectual property obviously you could go like even deeper with a Content ID mechanisms and whatnot but but I think that this smart contract would probably evolve to be like the master contract where you would mint the one of one of the song or the 10 editions of uh the the video and all the derivative works and the cruel the value in one contract basically hey um something I'm very interested in is easing time as a constraint to force kind of consensus between a group um and this feels like it could be quite a good that could be quite interesting to bring into this that I actually wrote something about this thing like February or something um about making multi-seq wallets in a similar sort of way but when I was when I did that design I was I proposed that you have like a time period that can be defined in which data can change and at that point it's finalized and boom it goes and that's that how do you feel about that in terms of like the this workflow like um you know do you see that you've got multiple parties kind of putting their information in do you think that should be locked down at certain point or how are you thinking about time as a concept within uh within this kind of a formalization I think Dan I think the the ideal scenario is that creatives get agree on percentages of ownership immediately I wish you right yeah we wish but if the tool is available that might be an incentive right and if we fulfill the promise of value through these a specific type of um a creative product then we might be able to take it a step further because right you know like 20 years ago split like splits were non-existent basically Publishers and record labels were the ones actually doing the paperwork but it has evolved in the creative mind that they own their their their creation said that they want to be a part of split so more and more you see like producers and artists and songwriters be like okay like let's you know like let's show me the splits right or let's negotiate the splits hopefully as soon as possible and this is kind of just like inserting it in that moment of you bounce the song you share it is there consensus how do we how are we you know like splitting the ownership of this let's log it on the blockchain and um and it should serve as a proof of work in case there's like legal challenges on on on the process uh yeah I have a question so I understand this um or I my mind tries to abstract this like um the concept of self-sovereignty in intellectual property but then I see this like conflict between the existing structures and the structures the social structures basically and standards that would have to evolve If This Were to actually come and have any chance at becoming like the dominant form of of um you know managing um creative IP I'm wondering how you see like the end game of this playing out how how can this actually um went out over the structures that we have right now which are very strong power structures well the the grand idea would be to finally have a global copyright database right if that makes sense it has been tried several times I know a lot of people are accepted into that or I don't know if it if it even it's a good idea but um but there has been efforts in you know like like just sharing the information but the power struggle between Corporation makes it makes it impossible right they don't want to uh just um have that be one entity and um and that's that and that's where the efforts have died is it good or is it bad I don't know I mean a probably haven't thought about the the the consequences but just transparency on data I think should be publicly available and should be um you know like uh just like a public good last question thank you um are these splits renegotiatable at a certain period after a set time um what does that look like what's the current kind of discourse regarding that yes so copyright law actually states that you're right in of on an idea is immutable nobody can take that away from you so a hypnosis can buy the the Bruce Springsteen catalog but you know like Merk could never say he sang those songs right even though he he owns the financial exploitation of of the IP so and that's like a like maybe a super example but having the possibility of making you like the immutable having the immutable record of you were there even though you might see the financial retribution of that IP you have the right to be credited as the author thank you thank you Andre thank you for the talk I think I really liked what you there was like this one quote that you said like copyright is immutable that uh it's definitely something I think we can uh probably all take home and think about for a while uh next up is uh Ian and Ian is going to talk about rich content type types in nfts and yeah if you are new here basically what we are doing is the ERC lightning talks we are the East magicians and we are talking about ethereum requests for comments proposals so not the core Dev consensus layer stuff but the solidity interfaces application um like these standards um yeah so thanks for having me Tim it was wild we met at youth Berlin a while back and see you back in the space yeah um I'm gonna give a quick talk on canonical media and EIP content type so the notes are basically I'm just going to flip through Json and talk about it uh the notes in Json are on GitHub if you have questions beyond the talk or you're watching it recorded make a GitHub issue probably the easiest way to respond and I'm just going to open a conversation about kind of what we've done previously as an organization at Zora What I've Done personally for certain nft projects and rendering so if you go to the original EIP 721 the metadata scheme is pretty lightweight you have a name description and image it was designed an era of crypto punks cryptokitties where you tracked ownership and the image just kind of showed a cute item or like the thing and then that became more and more important with time I think it was left pretty open-ended for people to build out from here and I do like that idea of a very minimal standard and then people can run with it but I think at some point that standard can also be improved so an example is and I've had co-workers ask me this all the time most recently somebody asked how do I made a presentation and the easiest thing to do would be to export your keynote or figma as a PDF and then mint it right well unfortunately the metadata standard just says image so what people have done openc kind of added animation URL to show an animation which could be a web page gltf audio a bunch of random grab bag of content and the great part about an image is if you want to render it as a consumer you just pop it into an HTML image tag or you put an image viewer images are pretty well defined on how to render animations get a lot more complex what we could do is we could convert the presentation into an HTML viewer and upload the HTML viewer that becomes pretty cumbersome and a little bit difficult because the original content is the PDF it's not the HTML viewer and the way Zora approached this with the Zora protocol in 2020 that I didn't really work on that was before my time was to separate this concept of metadata and content content was one thing metadata was another and the idea here is that the nft represents you own a particular ID and that particular ID represents a canonical off-chain content so I highly recommended to use ipfs which is decentralized distribution layer but as a future proofing also used a hash function shot 256 which fits really well into a standard solidity data type the Azora core v0 solidity has a function for the token URI which is not the metadata as the standard defines it breaks the standard but is actually the canonical content so if we were to Mint a presentation it would be the PDF and then the metadata is defined also incredibly simply as name description mime type inversion the mime type is useful for rendering as I said you need to have some idea of what you're going to render before and fetching it from the server just to figure out what the mime type is is a little bit frustrating so this here calls the token URI it returns a ipfs file and then here that file is just text of these two icons the token metadata URI is name description mine type textplane so that tells the Zora platform to render a text plane image of that per text plane of that nft and I don't think there have been a lot of platforms that support this so when you try to look at an open C good luck um and that brings me to my next point of thinking about going back in Computing history of what people have done to solve this problem this is a multi-part form data it's used for email kind of and used when you upload files in a classic web form it has content type and it has a certain set of attachments you can kind of think of this as an email attachment so I think having content type is quite important content like maybe we can talk about that a little bit later and then the body of that exact content here you have an example um sorry got out of weight so an example of what we could do is add a new field to the metadata standard either through a secondary proposal mechanism or the EIP standard that represents what we just talked about and there's a lot of details here to unpack so one of them is maybe you'll want to include the content directly should it be body or should it be encoded in a data URI in that case the content type is redundant but when you have an external pinned file you really want that content type for rendering it just makes life so much easier from a platform and indexing standpoint if you have a really obscure file type let's say somebody loves to upload Illustrator files you could use an indexer to find every illustrator file with a very simple content standard and I think the idea here is you have a token ID represented by a file and the metadata describes that file is but that file when you need to have a file with your nft is the highest resolution the most um the highest resolution the most well-known version of that an example is Zora was brought on to work with the Warhol Foundation to Mint one of the original computer nfts and it was made on an Amiga with a beta version of software an art collector is really frustrated that the nft was a tiff file but it was built with the Zora protocol meaning it did support Tiff files however nobody else did so what we had to end up doing is use the external URL which is an openc extension to link to something to link to the Tiff and then switch the image URI to become a PNG that renders everywhere and this is after back and forth with conservationist and with different protocols as to what they expect the nft to be now if we were to use the content standard we could Define the image that renders as a preview with ipfs and then we could use the Amica mime type or just a binary blob with some notes around it in the description to refer to the original media and I think that would help conservationists feel better that the nft is representing what it really represents and not needed to be converted into a new format to be an nft and a second example of this is mirror so if you were to Mint a mirror Marketplace essay this is what it shows it just shows a cover image of the text of the title a description which is a link to mirror and that's it I think there might be like the author information in the properties but it would be really cool if quixotic has a relationship with mirror and they could download the canonical markdown file and start rendering it on their site or at least say hey there's a canonical markdown file associated with this and like GitHub it would just open a markdown viewer if it understood it and we can take a look at the Json here so if mirror currently what they have is they have a Content field and it goes to an are we file which is a custom content type they've defined it's quite and Rich has a lot of information but it has the body the author information signature information and stuff they use to run their platform is is if we're coming at this from a perspective of an indexer this is not very helpful we could try to expand that content field but that could be any file type as I said before it could be some binary blob or it actually could be useful Json so if it's defined as Json or maybe an extension to Json you could use that but the ID here is would be the markdown and if Mirror Has extra information they could use their own fields to refer to that information within the content file or outside there's a way you can actually add Json headers to markdown files so you know the file itself is an abstraction is really powerful in this case but if you were to rewrite this using content you could use text markdown and then quixotic could easily parse that not just for mirror but from Zora tools if somebody were to Mint a markdown file and this has happened before when Matthew ball wanted to Mint his original metaverse essay on Zora but we wanted compatibility with more marketplaces and we wanted parts of the metadata to be fully on chain the solidity contract renders the metadata Json on chain but it links to an HTML file of the markdown content because that's what animation URL supports so we're having to change the media type into something that fits within an nft an easy way to avoid that and also if you look at an open C it doesn't properly parse an animation URI with an ipfs colon slash right now but you can see the metadata is getting loaded in but the essay experience being a tiny box is really frustrating and links don't work for security reasons here it's slightly better but also links don't work due to security reasons the sandboxing on an iframe is actually pretty difficult to work with If This Were A markdown file you could just run it through whatever markdown renderer or even provide a link and just show the preview image associated with the nft a final example of this is the dead ringers um it is a part of the Ringer's art blocks collection and it is a follow-up limited time Edition where funds went to charity and it was a very large SVG megabytes and megabytes SVG and I believe manifold helped with the mint and the original file for image was an SVG but that SVG broke wallets and people were not happy because an SVG is text and for you to encode text you actually have to turn the SVG into some sort of bitmap format and then convert it again and resize it so it's really difficult to resize in SVG and most marketplaces pass through the SVG but this particular SVG was so large it started breaking stuff so what they had to do is they actually had to update that and change the image to a PNG that did render well but it was a 12 21 000 by 43 000 pixel PNG which also caused some problems because marketplaces taking the PNG or whatever image file resize it to reasonable size and display it so what we could do now with this particular proposed standard would be to include the optimized image that renders well within marketplaces and then have the canonical content be the super high resolution file the artist intended so if you own that to your wish to display it you can then download that original file and work with it as you will and if you were to take the content type you could then encode the image SVG XML and then a URI and then optionally include a sha256 if you're using airweed that's actually a really nice way of verifying that the file is what it is because airweave doesn't use content addressable hash so the the link to ipfs for every file is unique per file but for our weave it's different so the idea here is the sha256 is a really standard way for a very long time of verifying that a file matches a file and can be included in this so overall the idea of this proposal is to add in a Content field and the idea with content is it's quite simple it doesn't have any underscores and it's the first time I think there's going to be some proposal or thought process around creating nested structures in the metadata but I think it's quite useful because content underscore type content it just doesn't like we already have Json we can Nest this um but type URI shot 256 and potentially potentially body for those that want to directly put plain text in but I feel like a URI encoding is also usually a fine option I'd love to hear what different creators of Standards or media have another thought was you could have some sort of attachments Associated say you have an image that a product you're selling as an nft and you have a slideshow I recently worked with the team to show a product and the slideshow had five images you could theoretically include those as attachments in your um and then that would be rendered as like a generic attachment on media I think that's a little out of the scope for this project though and I would like to kind of focus on um I would like to focus on this idea of a single canonical file instead of a set of files because it makes sense to have a single file and a single nft ID relate to each other and to not really focus on banners and colors and multiple sizes kind of on the side of open graph where you have this media how do you render it well on a Marketplace or in another context I think that's out of scope for this particular Focus um and the meaning of canonicals to have a standard or primary authoritative body on a subject so the URL is the authoritative idea of what that nft is and it's left up to interpretation of the Creator or the platform to figure out how to best Express that and use it my open questions are should this be an EIP within The ethereum Magicians group chat that's a pretty widely debated topic of metadata is included in the original proposal but it's not really defined beyond that and it's defined quite Loosely so one thing I like to do is try to stick to proposals and I'll typically use the Key Properties instead of whatever has been defined otherwise because it's in the 1155 spec but I am mixing the 1155 spec with the 720 ones back the non yet and then multiple files just an open question so I'm going to wrap up if you're interested in asking questions from the recording or want to continue the discussion um I have a GitHub of these files and this is my Twitter and zoom in a little bit and then the one last thing is there was an on-chain version of this EIP content type that used mime content URI and hash and this is kind of the inspiration for the off chain version of this proposal Unchained ideas if you have dynamically generated SVG it's more composable it's easier just to return a struct but I think now kind of working on more projects and finding more examples the off chain example is more compelling and you can still generate a Json blob on chain including the content field so it kind of works both ways I just think this is a better start to the approach a way to approach this project then including a new getter function as an EIP within the solidity world this is all off-chain metadata we're talking about I have a little bit of time so be glad to open it up for questions yes thank you Ian thank you round of applause [Applause] we have one question hi I'm Marcus nice to meet you um if this was implemented as an EIP what do you think the second and third order effects of this would be I hope the very first um thing is indexers Pro platforms would include it in minting so manifold actually does really try hard to include a lot of metadata they do image image underscore URL image includes the hash and the URL and the content type and some other data so I think kind of thinking with them to figure out what their needs are but once you start having stuff minted in this format I think it's going to hit indexers and then once indexers can understand this people can say oh I can upload Illustrator files I can upload webgl shaders I can upload some binary form like you can actually now mint a solidity contract and when somebody buys it they'll feel more assured that they're actually buying a solidity contract rather than somebody sit or the file of a selected contract rather than somebody saying oh here is a solidity contract and what I typically have advised creators to do is actually explain it and link in the description the ipfs URL of the canonical media it's Packy but it seems to have worked and that would kind of remove that and allow for use users to see like a link and I've seen artists on Twitter talking about using unlockable media and open C to include the source files and if the artist is comfortable they could just include the source files and it would be a link or some sort of description on Plat marketplaces and since this is relatively easy to implement once a few start I think it would start spreading thank you we have another one here hi hello congrats for the project um so content type is a response header an attp right thinking about you know the second order effects have you thought or worked on the request headers equivalent like the accept and then having some specific wild cards such as Text slash and then wildcard so the one problem when you're indexing is that a lot of times ipfs is really slow people's servers go down if you're able to get the metadata on the client a lot of people hot link directly to an ipfs Gateway and pulling the content type out of the headers really allows for a better set of expectations when you're indexing and rendering the nft but your question is to kind of use the HTTP response conversation to define the Mind type rather than put it in the metadata yeah sure so there is the content negotiation step right so and then you have from the accept request header and more often you have like some sort of wild card there right so that can help uh you know more generic applications to accept let's say image slash column uh wildcard something so I think a lot of the off off-chain nfts go through a decentralized Gateway provider and those Gateway providers are not very like you're out the control of the server retrieving decentralized media is out of the control of the user in most cases so you can't rely on a server negotiation you're thinking of a world maybe where there's a server that is connected to the URI of the nft and that's becoming a lot less common because that means you're now having a centralized point of failure so the idea here is if you put it in the Json there'll at least be some intentionality if you're on some weird version of ipfs like node that doesn't understand the media it's serving or there's a bug in it you'll still have something that kind of works or have an expectation of what the original intention was thank you do we have more questions maybe one last question okay otherwise ah yes okay we have fun you hear you define the um content type inside the Json um to like save some uploads could you define the data in the collection as well that's actually a great question that I didn't have time to address but mirror and Zora and a few other platforms have editions and I think utilizing a singular nft metadata in the contract URI which is an openc extension is a really effective way to handle that and right now I know most platforms that do additions support the contract URI so for dead ringers and for Zora editions the contract URI is actually generated on chain and sometimes we'll put an ipfs depending on how big the content is and that includes image it includes animation if every single thing in the collection is the same and we use that internally in our infrastructure to give a preview if there's no mints yet or like what that whole collection's supposed to be there's no standard around it but this would also slot quite well within the contract metadata if you wanted to have a canonical contract um content field it should just work thank you Ian Round of Applause thank you very much thank you everybody next up is Francisco from openc thank you which is gonna speak about EIP 5267 and I have been saying the entire time that it's a it's about the domain separator so yeah okay gladly um yeah so sorry we're gonna move on from nfts now um it's going to be about erc20s which are boring now but okay um I'm correction I'm not from openc I work at open Zeppelin uh maintain and develop open sampling contracts which obviously maintains many ERC implementations and so this is a really important topic to me um so this eib that I'm going to be talking about is really quite tiny um but I want to use it more as an excuse maybe to talk about the process of building an EIP and what the kind of steps that I think uh one should follow so because like eip1 which it's not here but maybe you've all seen it kind of defines the series of stages like draft review last call and final but it doesn't really say what should happen in each of those stages so I want to share how I personally I'm thinking about that as I develop an EIP so the problem at hand here is the erc20 permits anyone that has used a amm a decentralized exchange before knows that in order to do a token exchange you need to approve first and then transfer and this EIP permit is one way of foregoing the initial approved transaction and replacing it with a signature that allows you to allows you to do it all in just one transaction by just including the signature in the first transaction so this saves gas it is one less transactions and it uses the signature instead but it's kind of weird if you use an exchange or an aggregator you don't really see this being used very often um I think uh main maybe it's just for like usdc uh exchanges supported but there are many other tokens that have this and don't so the question that was in the back of my mind is like why is this why is that so weird so the this EIP underneath uses uh this other EIP 712 which is a special kind of signature um it's a signature not of a blob which is what we see uh often uh most most usually but of a kind of typed data structure so it's kind of important because it allows you to give more structure to it in the case of permit you will include the amount that you're allowing um you will include and expires uh timestamp and a nouns and so on and this is an important uh standard because wallets can Implement support for it and show this structured data to the user in a nice way one of the important things in these EAP is the notion of a domains so when you make an approval for say usdc you don't want an attacker to take that signature and kind of send it to die right you don't want an attacker to reuse the signature in a different domain so every signature has this domain separator inside of it that makes sure that the signature is only valid in one domain so this is the um right so the decentralized exchange has no way of knowing um given some arbitrary token what domain they want to use um and I think yeah I think that is the reason why this hasn't been really adopted so you will see that um the erc20 permit ERC defines a getter that gives you the hash but really the 712 RPC endpoint requires the entire domain object and there is really no way to find it here so this is where eip5267 comes in um now we will see now it's a very simple function that literally just allows you to obtain the domain this is the domain object that you will need to pass into the 712 sign RPC call and and as you can see like it's extremely simple now what was also at the back of my mind is that this was this is not also a failure of the spec uh 12 2612 so permit but it was also in a way of failure of the process because if the 2612 authors had kind of gone all the way and kind of talked to decentralized exchanges and thought through uh what it would entail to adopt that they would have realized that this was missing so I didn't only want to tackle the technical problem here but also think about how can I uh carry out the process for the CIP to make sure and other erc's to make sure that the sort of failure of the process doesn't present itself so the question is how do we get this now which is in a review stage how do we get it now to final what needs to happen in order to get it to final so some of the things that I've done um and that I would recommend you all do when you build your VIPs um so you should reach out to all interested parties and like applications and companies and uh projects that you think will be using this and really you should be kind of bothering them to give you feedback to look at it and give you feedback so I've reached out to uh one inch and unit Swap and kind of seen try to get from them is this useful to you would it does this solve a real problem from for you um and generally the answer in this case has been yes um in the ethereum magician threat there's also been a couple of interesting comments and common questions I have taken some of the questions and documented them as part of the EIP as well and also some concerns that have arised uh so many of those concerns in the case of this eifb were about the backwards compatibility uh section which is here but um most of the discussion of The ethereum Magicians threat made me realize that even though I wrote this section kind of thought about it there really are many more unanswered questions so I wanted to do some more work to figure out the real backward compatibility story so another another thing that I've started doing which I think is a really good exercise is to implement it and not only like the solidity part of it but also the many parts of the stack again so I've just uh started this EI uh repository with the implementation and most importantly a little app which is just a front-end app which is what I imagine that a the central X exchange will kind of be doing behind the scenes and here I'm putting myself in the shoes of I am the UI for one inch and this is what I'm going to be doing and just kind of really figuring out if it works if I can actually produce the signatures that they will need to produce and also to use this to figure out the backwards compatibility story and I still need to develop this a little bit further but I'm hoping that I'm going to come up with a good and kind of uh comprehensive answer then I can then go back in the EIP and document it there to make sure that it really answers the concerns that were raised in The ethereum Magicians thread so I think uh yeah that's it again it was very quick but these are some of the um things that I've been experimenting with in order to get this to a final stage I think uh there are we see many eaps that take more of a fast track and get to a final stage which is you know it's better in a way because we know that these processes can be long and it's really annoying but um then you get to a final stage and it doesn't necessarily mean anything if it hasn't been thoroughly tested and then you're really going to run into some issues when say open Zeppelin implements it and people start deploying it and you realize oh this this isn't really enough um so um then you need to start thinking about like a follow-up EIP and it's all uh really much more complicated than it should be if we do things better before we get to a final stage so anyway those are some of my ideas thank you um happy Tuesday questions if any yes thank you very much do we have questions yes hey really cool uh first uh comment it reminds me of uh like the Amazon six page written narrative way of you have to like sharpen your point or your case and then you go around and get feedback from people and then incorporate that in a fact at the end of the document to like because you know other people have those concerns or objections so that's really awesome um do you can you just speak a little bit more about that process and how you've followed up with people maybe on this one or something in the past so it's one thing for somebody to say it looks great maybe give some feedback on The ethereum Magician's post but really an eip's success or failure is like people using it like you just spoke to so have you have a good example of like following back up with protocols and actually getting them to implement the EIP as part of your uh kind of Biz Dev work if you call it yeah so uh good question I haven't thought about that too much yet um but um one of the things that I I personally struggle with is that I feel like I'm in a bit of a conflict of interest position because of being on opens up and contracts maintainer it's like it's going to be really easy for me to put this in the contract and make people use it but I don't want to force it down people so for example one thing that I uh could do and now that I'm thinking about I think it will be a great idea is to talk to this one-inch developer that I talked about and maybe uh try to get them to to walk me through do they really see do they like really see themselves implementing this and maybe what is the timeline um and kind of yeah just trying to get more concrete data on on their plans and try to try to get them to commit um maybe that's what I I would do thank you uh more questions feedback maybe uh people that have used this or or 712 raise your hand if you have a question okay then thank you very much Francisco Round of Applause thank you thank you yeah and that's essentially it that was the ERC lightning talks from The Magicians I hope you all liked it um you can find each and everyone hopefully uh on the East magician's forum and I'm looking forward to all of the posts that are coming out of these discussions I'm I want to thank you all for participating uh like so much in this conversation and I I really appreciate that we were having like a back and forth between the audience and uh and the presenters and so on and yeah it was great to be able to host this and yeah thank you very much and see you around [Applause]