 My name is Tim. 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 gonna 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 Like what will be the what will be essentially like the the content of of this entire session we have Lined up as like six seven speakers including me We are going to send all of these talks around the ethereum magicians and specifically We're gonna talk about ERC proposals so if you request for For for comments, right? So basically everything that didn't fit into a Net and Tim bike course 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 Ronan that just entered the room by chance We will have some talks about Soulbound tokens about music NFTs about yeah desock We will have two people speaking about the problems in the web three music space About content types in in NFTs and then we'll also have a Very recent EIP namely, I think it's for the domain separator in EIP 712 so I want to I want to give a before like we start with the speakers I think I want to I want to 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 this like immutable Contracts that are almost like as immutable as a transaction in ethereum and 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 NFT ecosystem I think You know that there was a there's starting to be this debate basically around like how can we actually do innovation? With these 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 This 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 lock 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 I believe the the github thread on eip 26 12 the The the permit standard that allows you basically it's like a replacement for eip 20 tokens where instead of sending the approval on chain and like kind of like wasting all of this gas for the Transaction envelope you you technically could sign a transaction that gives the spending contract De-permission with your signature and so the idea I guess would have been that new use cases are kind of enabled and that also That also we can save a lot of gas Especially like considering that you know each eip 20 transfers essentially like two transfers right today And so if we could already condense that to one I think the gas savings would be Quite significant considering like how much we are transacting with eip 20 tokens So this comment is actually a critique though on that standard and basically it 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 Companies have like kind of diverged from it and and they're like non-compliant nest like I think with this standard So it kind of shows I think maybe a bear bearish case for for this kind of Standardization approach and then The other case which I had to deal with myself personally because I Crawl NFTs This is the interface for the Zora M NFT contract and M stands for media NFT and you know 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 Jason and 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 so I was a bit disappointed because I couldn't like I had to basically build like this There's like custom logic around it, but on the other hand, I'm also empathetic with that because In the regular NFT the media file which has been like traditionally the image is literally in a Jason object that we call metadata so that 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 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 Make the media file a mere metadata field so yeah and Apart from all of this like pessimism, I think there's there's another good reason for submitting and and and being active on this forum and it's because you get a ton of exposure to To your idea. So this is a threat here that I made I think around in in April and it's about Like a specification for soulbound tokens or we now call them account bound tokens and this Threat has gotten 9,000 views and if you would sort by the replies. It's actually the top The top controversial threat on the entire forum for the for the entire year apparently So I mean why while that is 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 like of receiving constructive feedback Which with which without that this standard wouldn't wouldn't have gone where it went today So I initially started this as a non-transferable token Specification and basically now we have we have like moved into consensual minting 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 soulbound tokens And so this has really become basically like a space where this entire Standard all the soulbound token things everything is like very verbose Lee documented and and I think it's awesome Because I wouldn't have had these ideal ideas by myself. So I think this like a community effort and it's cool and So by the way, I'm like basically these slides are all a Eve magicians block post essentially and I need to find a bit my way but so the so so basically one of the But what kind of like one of the one of the problems of the EIP? Standards processes that it's it's it's it's truly permissionless and it's open to everyone essentially because you you can just go to like the You know like github.com slash a theorem slash EIPs and you can submit your own EIP and as long as you are complying to the the formatting rules and you're like, you know, you're like 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 merge and that document will show up on EIPs or the theorem org So that's really cool and that's really a strength, but it's also weakness and I think this I Guess it's like a bit of a famous cartoon in the in the in the standards community at least where you know like This like the this XKCD comic You know where there's like 14 competing standards for a use case and then this is one guy saying hey That's crazy like why do we need 14 standards? We should have one standard that has all of the that addresses all 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 and duplication and and and so on so it's like, you know on one side We have like the strength the openness and also this like Yeah, it's almost like a spam problem or whatever, but I Want to I want to I want to still motivate and I want to I want to say that I find this actually awesome and I find it awesome because I think that there's a difference between a Temporarily emergent consensus and a consensus that is more like spontaneous and probably like from this kind of like You know like group or a committee of experts And so I've tried to visualize that with the two different kind of approaches that 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 Makes the decision by themselves. They they do all of the diligence 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 Yeah, like more I think like groups that have to make decisions rather quickly and and and like yeah like close to time I think you have this basically this this this spontaneous committee consensus where you know 51% can basically overrule the 49% and I and I want to make I just want to Kind of make this argument that you know, I believe that the temporarily Continuously emergent consensus is actually the the cooler one that the one that has like a strong that ends up having like a stronger signal Over time and that's because I mean there's one hecky way of just like proving that and that's That if you consider like how organizations are run today, then it's probably mostly in like this 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 think and I mean by no means is this financial advice, but I I would always bet on the market and not on like an individual Committee actually and and so I think that's that's actually the better the better approach and And and also I mean I guess it's also the reason why like much of our critical infrastructure is like run in 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 stuff like that and so So the question is though like how how can we overcome this this this immutability of of contracts and how can we actually still innovate on those standards and and this is especially true with With all of the like this, you know all of the eyeballs as 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 externally from standards and and so I think immutability does not necessarily mean Stagnation I think actually there is now we are starting to see a pattern Emerge where people are starting to really upgrade the standard and they're doing it in a way where they are basically like Yeah, bolting basically bolting kind of this one lock to the other almost like a like like in the I Don't know on these bridges that sometimes you can see as a tourist kind of thing So so I think over the last half a year that has really happened. So for example, we now have a standard event for emitting a an event when the Metadata is updated in an NFT standard and that's the one on the top right. It's the 4906 that essentially just emits an event. We now have a very interesting Standard for that basically splits the user and the owner into two different groups And I think especially with you know with desock 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 can have usus and up up usus and so on This this is starting to become really really interesting, right where 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 more infamous one is the is the royalties one And it's the 2980 81 and that's basically an optional An an optional Roy royalties location mechanism for NFTs that is implemented I think in in many NFT marketplaces and and and again I just want to highlight that I think it is definitely possible to upgrade 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 Yeah, I guess I have five more minutes. So I'm also gonna of course. I'm gonna chill a Standard that I did myself, which is the minimum Soulbound token and it works in the exact same way where basically we are extending and even breaking the EIP 721 interface and essentially 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 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 and the purpose for this is that That if you were if you were to just use like the plain 721 standard which Actually, it has a kind of like a small line in it where it says like that these 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 could also be that you have done like something else like something something else wrong You know and so therefore the arrow 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 721 yeah, I mean now I'm at 17 minutes the next we're gonna have the next speaker Thank you for also giving me the chance to give this little talk and I want to ask to stage Ronan a We go Wagga. I don't know Thank you Okay, thank you for coming here Say so I it's a you're I want to present a very simple proposal and Kind of to explain it I wanted to show a demo and I wanted to show it in real time But the Wi-Fi made me so maybe realize that I should probably Have it already done and show you the result 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 construct the state which is our most a smart contract system And all states for the client for yeah for basically having data about it and most project Use a back-end which is at odd with as a vision of of decentralized application So here my idea was simply let's index in the browser and of course It doesn't work for everything Because of the scale of some of these of the system so for number if you wanted to index all the NFT You could do in the browser, but it will take a while But for some other case it actually worked very well 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 So it's kind of a gaming space. You have planet and fleets they can as the 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 So I have an index. I have the same index are running on the graph And I didn't finish to implement it fully here. That's why I expect maybe to get to 20 megabyte of state And I can only normal network. I don't know what normal means, but It kind of it took five seconds to think the whole thing and if you can obviously But I made an assumption that In my in my game, there is this notion of time so every event So the state the contract will kind of lazily update part time and I think it's quite a common thing in smart contract and unfortunately When you fetch the logs, which is a mechanism by which you index and manage to get back the state all these event basically which You don't have access to the timestamp at which they happen It just some reason They didn't thought to add that so there's a block hash block number but there's no block timestamp and so my game actually when I I need the timestamp and So because I don't have the timestamp in the logs I get like 20,000 event here and what I need to do then I need to request 20,000 times Depending on a bit less because you can have same event in the same block, but I have to request that on top and Because it's a in browser indexer. It use EIP 1193 which is like the wallet interface and I cannot do battery quest. I have to do all these requests and so I have this version We actually is still running from last time and sometimes error out because the RPC is not happy that time So the RPC of MetaMask because again here, it's just a static web page. There is nothing no back-end And it all only rely on the fact that the user have a EIP 1193 wallet in that case is MetaMask and if you if you look at my settings, it's actually an RPC somewhere else, but So it's still querying all of these to get the timestamp Well, the other one have been finished a long time ago and only actually you see 580 requests it's actually 300 because the other one now is just to get the latest block and nothing is really happening in that game right now While this one is still like fetching the state, so it's going to reach probably 20,000 to sync or maybe even more Yeah, so that's the proposal I Wanted to show you a can of a really example, but the proposal is basically to add This to the json object. So it's a very simple change you can do in In your node so in go ethereum or what whatever and so actually if I nearly enough like team pushed me to go to the Cordev meeting the other day and I'm going to and so we had a very interesting discussion about it, but so I can of So most of it I already say but the idea is that you most So what I could do is that I could add the timestamp to the to the event itself But obviously when you do your contract, you know that there is a block information So there's no need to add the timestamp to the event. You just a waste of gas And time is an important aspect of many smart contract and block number cannot be a replacement for them And the reason why is because block number timings can change across chains But we also there is no guarantee that a single chain will not keep it and you could probably emulate Another age block time using smart contract itself, but it's kind of a ugly work around And black block time stem already easily available like the block hash or the block number and The another so I've been discussing about a few people is Yeah, but this is extra data you have to put in the log object But it's small and the alternative is to to fetch all of these anyway So of course for the one we don't care about time stem then they have an extra Small but I feel is small enough I would also consider alternative, but I would not consider as an alternative actually I could consider them as complementary So when I mentioned them, I'm not saying I don't want them actually I want them But I feel they said they will not replace Thank you, so yeah, basically one alternative is to add batch A batch API for EIP 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 block time stamp in the log and Another EIP that I didn't see yet is to have a great graphql API So basically an alternative to EIP 1193 and because graphql you can ask what you want Which make it more efficient as well for transferring data So if you don't care about the time stamp, you don't need and actually this one could really By actually solving the first one. So this one is really an alternative, but I don't see any reason to just Add the other one, especially I think graphql is not supported in all the node implementation today And So as I say I went to the core dev and we had the feedback and the main feedback Was that I There is no point to do it because we are going to make the logs 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, it won't matter And so my reply is that So it's an easy change So my next action would be to make a PR I guess for Goetherium And and the number of log actually can still be significant so even if we Remove past log we still want 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 state access about If we we don't have access to past log, how do we are going to index in a decentralized manner? Because of course if you have a back-end, 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 cash from your brother 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 wrong Like right now but portal things portal network And so but I think it's important we We understand like the point of view of application developer that don't want to be involved with our application once it's launched and another thing Yeah, so I mentioned like most system already rely on the log event So we need this system anyway and even some EIP I've been using it to kind of speed up the The need or kind of minimize the gas cost, which is EIP 1155 like you can't query the balance of all the tokens That are either 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 But that interestingly in the one of the thing about in the cord of meeting was that That's what's not the vision initially But now we evolve we understand what we need and so I think yeah that I will learn with With like yeah, let's discuss about how to solve this being able to rebuild the state from from the client Scan off all for me any question. Thank you. Thank you Ronan And of course Do so we have we have time for questions. Do we have any questions? 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 can talk about my game actually on that one 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 I I Didn't have an indexer using the log and I was fetching all the data and it is not actually is not efficient either because especially list of things and and you are wasting gas to support that in many cases like So this is what I why I mentioned you IP 1155 not having access to the balance and we could also think about Yeah, seven to one Enumerable extension which I'd actually a lot of gas cost overall So and I think from what we have seen Everybody like even 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's what we minimize the things that happen on the chain If we can do it off chain, but this 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 Yeah, this is my first time actually talking at Defcon. This is my second Defcon So we're happy to be contributing back and sharing knowledge and Sparking debate and ideas. So thanks for having me and thanks Tim for organizing this as well So today I wanted to talk about EIP 4973 Badges and de-financializing Tows and beyond as well So firstly a little bit about me. My name is Rahul. I'm co-founder of this little baby company that we started called order space And I've been in the crypto ecosystem since 2016. I started off with my journey also with music I was building NFTs to asset highs music royalties back in 2017 did not work And moved on to SoundCloud got FOMO with Dows and I got back to your crypto full-time now So I think I want to start with how this year had started actually like We think that there was this paper called decentralized society And it centered our attention on this notion that web three centers around Expressing transferable financial assets rather than encoding social relationships of trust When everything is transferable Things can be sold to the highest bidder. So, you know, we wanted to challenge that and That's that's what that problem is what gave to this idea and working with Tim on this EIP What we call account bound tokens not to be confused with soulbound tokens or you may be But it's semantically speaking. We kind of 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 that 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 We have written a more extensive Article on this However ever since we started we saw we noticed this account bound tokens Debate had kind of like exploded, you know, there's soulbound tokens There was community bound tokens EMS name bound tokens now human bound tokens what we're actually seeing is this non-transferable tokens is spectrum and You you can define what is being bound to and what is that binding strategy and you can kind of This is this is where the explosion of ideas are coming and as a builder I feel like some of the NFTs Instrument NFTs back 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 new instruments to kind of like build our ideas right and At autospice we we call something smaller something simpler. We call them badges It was powered by EIP 4973 account bound tokens So I want to dive right into it like because because Ever since soulbound tokens was kind of like really a hot topic It kind of sparked like a lot of hot debates or and it's it's debates are great like because It really helped us intellectually navigate the space and like kept like a pluralistic opinion from various Parkies one of the first things or concerns they put out like I think was permanent You know, what if I don't want a soulbound token or an account bound 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 Personal details, you know, what would happen? You know and key rotation, you know Like I what if I lose access to my key wallet or I want to like I mean to my wallet or I want to change My wallet and lastly this more popular active debate about like verifiable credentials and ABT's on-chain versus off-chain identity So lots of things very simply put There we've written again lots of Detail on this but I can kind of summarize this These were the design decisions that helped us input into EIP 4973 So permanence when we talk about In general what we baked into it is burning and Dissociation from the so the owner of the soulbound token or account bound token can dissociate from from the token itself and the lack of consent a Non-transferable tokens through account bound tokens cannot be airdropped you need to have two-way consent Which I will dive into a little bit later and with order 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 and lastly ABT's versus verifiable credentials Use both really it's not mutually exclusive 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 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 Angles or various dimensions right if you like a transferability consent removal issuance expiration and fungibility, but I think I want to bring focus to where Consent and issuance. That's that's really what we wanted to like did not want to compromise on when it came to Non-transferable token design So let's dive right in like so this is the ERC 4973 at a glance you could just NPM install that very easy So that's a very Very light Interface right like it's just expresses so we can kind of like dive into what this Actually does so firstly this top section right this transfer event balance off owner off This is this was mainly to ensure backward compatibility backward compatibility to NFT in general So we actually implement the IRC 721 mm metadata So one of the things so that building this EIP actually it was super amazing learning experience We actually didn't have the transfer event first and then we were kind of missing all this stuff like ether scan Was not showing the log events for example or metamask was not showing 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 the support the interoperability actually came came for free And that that's one of the reasons we we went back to the transfer event although in a non-transferable event Token you can argue that transfer has no sense makes no sense But this was one of the design decisions that we learned like to kind of ensure backward compatibility And the next one and this is really that 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 the signature So we call this a take flow So you cannot actually mint an account bounce 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 an ABT described by a spec which is hosted by the token URI Alice then wants to issue the ABT to Bob Alice can only do that if this if she signs using EIP 7 12 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 token URI the signature and from Alice and then prove that I can take this So this is in order space. We actually call this the allow this flow. So I'm just like adding people to an allow list I'm like signing people for to a badge and The to give flow is actually it's inverse It's 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 air drop flow So if you if you give a badge, you can just like basically I want this and hundred people say I want this You can actually do an airdrop through through an account bound token and the last bit is this one It's the unequiv. This basically means complete dissociation from the account bound token So only the owner of the token can dissociate So that these are like basically the fundamental building blocks that kind of like help this Create this very bare minimum very simple very utility highly functional highly utilitarian EIP for 973 and then order space. We are kind of like building more flavors or more layers around it but this all the What this had served at the fundamental has been working really good for us so far and I also call actively contribute to the EIP and Yeah, and 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 definitialization, right at order space. We're 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 And recognition onboarding quests to end with the badge assess the reputation 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 that's non-financial Rewards and recognition. I mean, I think we can all agree that the ecosystem is like hyper financialized 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 co-governance on a one-token one-vote system So a person of influence can basically assert their entire influence through that power So 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 for us we see the one account one vote as a necessary step to kind of get to one human one vote And then this is really fresh out the grill, right this happened like a few days ago The mango markets the hacker exploited mango for a hundred million hacker turns around 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 it's a it's a no-brainer I feel but really the takeaway that I wanted to kind of Here have here is let's move away from the one-token one-vote system and away from plutocracy And I think let's let's let's explore new forms of governance. I think it is no one size fits all I think we are in a stage where the ecosystem is growing so so fast and we as builders We we definitely need more instruments at our toolkit. We need to spark debate 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 that's a lot. That's it. And that's a dali author. We are We don't work. We just create these dali orders most of the time We are as surprising my team is surprisingly good at creating dali orders. You can scan this It'll give you more information about us Yeah, that's that's it Thank you. Thank you, Raul We have some time left three minutes. Do we have questions? Ah, yes, okay Hey Can you elaborate a bit on the account for the recovery part? Yeah, absolutely. So Well, one of the things with account recovery It actually came up pretty actively in the debate like hey if I have badges in my account if you have non-transferable account tokens What if I want to rotate my keys? Then how do I do this and that's one of the criticisms that were pointed at soulbound tokens and initially quite frankly, I feel this is a This is not a soulbound problem or soulbound 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 off-loading 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 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 The way we are thinking about this is 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 dows The other aspect is reactive recovery, which is where like I lost everything Then you know, it's that's a tricky one You have to establish with your like your dow for example that hey I'm the same person behind this new wallet like you have to reissue it and one of the models We are looking at there is re issuance, 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 Just quick thing regarding Recovering Recovery through burning and then reissuing it would be awesome if there was a way to do that atomically But the other question was what is the status of the EIP? Is there time to still make breaking changes or is it already like so widely adopted it and this kind of relates to this Technician discussion, but I think it's yeah, that's a good question. I should have actually put the stats on it I mean People are already using it. We've seen. I don't know. Maybe like 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 Yeah, when and now we're kind of talking about expiration as a Has 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 towel you get guest badge for example, you know, you can do some interesting action so expiring badges something we're looking at but Yeah, like we are this is one of the forms We are hoping to get feedback on like, you know, where should we park it should we get feedback or have invest in extensions and like Because there's a lot of utility this can deliver in its current form, you know, and then it would be Strange to put perhaps like, you know, stretch this timeline because I think I've seen the IPs go for years Thank you. Thank you, Raul applause, please Yeah, I'm just gonna buy while the next speaker sweet man is going to set up the Laptop and so on I'm just gonna walk you through the rest of our timetable which is by the way here. So Next up is sweet man. ETH and he's gonna talk about music the music NFT engineer Then we have Andres who is going to talk about Web three the web three music NFT multiplayer problems. I'm very excited about that. I think it's Like it comes out of water and music research Then we have Ian who is going to talk about rich content types in NFTs and then finally we have Francisco who is going to talk about a Like a very recent EIP called 52 67. I think which 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 this if not then I Recommend going to EAPs dot ethereum.org and reading up on it 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 arbitram? 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 daddy aka the music NFT engineer and today We're gonna talk about music metadata First the problem you're gonna 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 CC zero music NFTs 100% free mint 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 gonna be a little bit hidden in here Music platforms are not creating music NFTs. There's 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 aetherium congrats, we're in the aetherium 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 aetherium 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 aetherium 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 shout out the creator So the last creator this first NFT is Caspial. We've got Colombo in the audience Manager of Caspial and so that NFTs from a musician named Caspial who dropped on Zora creator And that is a music video of her latest music video reflejo and All of my music NFTs are CC0 from a musician named Segrado 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 Will 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 Segrado 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? 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 labels gonna come down and say This is how it is It's gonna 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 means we want to propagate in order to make them 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 Columbia and Medellin and this one is an arbitra Menft the same NFT by Segrado Spread the memes all the ethereum wizards all of you builders we are building 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 are 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 ERC 721 the ERC 1 1 5 5 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 main net Polygon main net optimism main net Arbitra main net 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 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 to form a way I'm really used to building with the musicians on the ground I don't know if we need any IP 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 in the ecosystem I don't really know what to do and I'm not gonna claim that I'm like the king of all this I just would like to have the conversation more And so I'd like to ask for help in propagating these music metadata memes so that we can help musicians adopt this technology so that musicians can start leveraging these web three rails that make us in The technology that we love so powerful and groundbreaking and 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 with that We've still got 10 minutes, so I kind of zoomed through that. I will leave the rest of the time open to any questions from the community Thank you, sweet man hand of applause So do we have any questions in the audience? Raise your hand if you have any questions. Yes Hi, I was wondering like 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 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 yeah, I took a screenshot of EIP 721 and I blanked out the data to just kind of like Put the meme in your head is 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 EIP for a music metadata standard. I Think yes There is one part that's probably up for Like off-chain versus on-chain. I think if you have that perimeter very clearly I think this is this is exciting In an attribute I didn't talk about all of these All of these decent NFTs 100% of the metadata is on chain So one of the awesome parts about all twos 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 ETH mainnet 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 arbitra and polygon and the other L2s Thank you more do it. We have more time for questions if there are yes It wasn't clear it. Do you want to write any AP 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 to be IP. I'm about it 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 of catalog and I'm just propagating that mean because it's in my opinion the best mean Yeah, if you know, I think I'm a great first step would be to public It seems you've done a lot of research to publish that in some written form maybe in the theory magicians form To just kind of keep it make it visible and someone else can then maybe pick it up and Formalize it in there 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 have said but having an option that is 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 It's quite funny because obviously I wrote the water music ripple yesterday. They came out on this subject Have you know ready yet? I have not just in because there's definitely points of conflict between how we're seeing this and for me Having worked like rule has inside the beast as it were One of the biggest issues in the music industry comes around multi-party consensus around data points and also conflicts and that's always been my hesitance about pulling everything on chain because 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? the metadata renderer architecture that Zores put out where the creator is able to There's a trusted party on a role that is able to go back in and update that metadata When they choose this does that make a difference or you still think the best solution is fully off-chain? Well, who decides who the trusted party is the creator But what if there's multiple creators? I'm excited to hear Columbus talk on that. Yeah This is the challenge right and then you've got different writers writers publishers producers all these people who are part of this rich soup of Influencer creates a piece of art by the moment the music entities were in a pretty nice place And that is usually being one person putting something out But shit gets complicated as soon as like they expand right 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 and how to do all that Point well taken Nice we 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 a EIP or something. I was in a talk yesterday That was like see something called like see a IP it was kind of over my head I'm not gonna lie like cap 10 But it was a different type of like improving proposal sort of like coalition about Stuff related like L2s and things and addresses so it could be they about 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 the music metadata IP thing MMIP or something. I don't know but yeah, just a suggestion Yes, so here's the catalog standard and you're talking about cap 19 is like cross-chain assets in here we have references to other 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 Segrado our derivative NFTs of an original NFT I did not link the original NFT and that's a downside on me and I'm gonna 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 work 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 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 for their repo seems like a good place to start just start housing that information in some place Thank you. Yeah, that's it. We don't have more time. So thank you very much sweet man and next up is Andres and We are Staying actually in music and now we are talking about the web 3 Music multiplayer problems and I'm very excited about that talk as well. Thanks. Hey not a lot of experience presenting but Here we are so we started off a few months ago a in the water and music now researching about splits and 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 The the blockchain architecture is a based on a single a singular point of a connection or entry for the user and the third one is that a splits protocols as we understand them in blockchain are focused on distribution of funds but us creators think about splits more on ownership then really 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 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 There the copyright industry is Bay 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 So and this is maybe because the creators think that registering or then speaking about legal aspects in the moment of creation kills the vibe so a That actually gives birth to a lot of problems I like I've been up, you know, like I've had problems with a Processes in which I have been in the studio. I'm a music producer. So I have been in the studio a We've made a hit song Everybody's super excited, right? The the process as it is done. It is that a Least in music creators get together in a studio and They song write they beat make they record and then they bounce off the audio program, which is a way 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 What's up? And we can listen to the music or what we made and vibe to it and And Hopefully the next day know if what we did was whack or if it's a hit record, right? And 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 And this is a story that kind of like repeats itself endlessly in In music making so what would the ideal process be? The ideal process be would would be to register To have a mechanism to register the IP as soon as possible, right in a nutshell In a nutshell, it would protect the creators and hopefully Inconsensus 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 a 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 the job to be done process and it allows for in multiplayer mode deploying 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 that That would 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 A Chat would 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 to accept or deny their participation in the In that creative process and if there is consensus then a smart contract is deployed And the non-transferable and ST is minted as Registry so and before we go to future iterations I would like to obviously I think this is time better spent if we if we open up a discussions because I mean this could be a Tool that obviously expand and it's composed on but I would like to basically just open the floor to questions to see if if a We can get to a technical solution because the question that like the questions that we have is And 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 Do we have questions feedback raise your hand, please? Yes Thanks, um Maybe we could go back to the previous slide I just had a question about like what you're saying and ownership splits and it's kind of related to what you were saying we're 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 skew morphic 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 What's better, but yeah Yeah, that's a good question and the answer would be a Either we One of two answers I'm guessing the dynamics The current dynamics are more of like you song write 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 Unlike before we used to like write sheet music or or write song there a lyrics on paper a So but the but I guess the the answer to that would be we could either do do two registries or just split 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 split from just one big chunk of a hundred percent of ownership or Mint, you know specifics any more feedback with 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 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 to have a wallet be the mechanism for controlling the rights? So that is one reason a 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. 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 on 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 a the The video and all the derivative works and the cruel the value in one contract basically Hey Something I'm really interested in is using time as a constraint to force kind of consensus between a group And this feels like it could be quite a good that could be quite interesting to bring into this That actually wrote something about this in like February or something I'm about but making multi-sig 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 then 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? you know, do you see that you've got multiple parties kind of put in their information and do you think that should be locked down at a certain point or Yeah, how are you thinking about time as a concept within within this kind of formalization? I Think then I think the ideal scenario is that creatives get agree on percentages of ownership immediately. I Wished 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 a Creative products, then we might be able to take it a step further because right, you know, like 20 years ago Split like splits were nonexistent 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 creations 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 And it should serve as a proof of work in case there's like legal challenges on the process Yeah, I have a question so I understand this Or I my mind tries to abstract is like the concept of self-sovereignty in intellectual property, but then I see this like conflict between the existing structures and the structures 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, you know managing Creative IP. I'm wondering how you see like the end game of this playing out. How can this actually? Win 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 a But there has been efforts in you know, like sent like just sharing the information But the power struggle between comp corporation makes it makes it impossible, right? They don't want to just Have that be one entity and 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 consequences, but just transparency on data. I think should be publicly available and should be You know like just like a public good Last question Thank you Are these splits read negotiable at a certain period after a sad time? 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 Hypnosis can buy the the Bruce Springsteen catalog But you know like Merck could never say he sang those songs, right? Even though he owns the financial exploitation of of the IP so and that's Like a like maybe a super example, but a 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 Definitely something I think we can probably all take home and think about for a while. Next up is 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 ETH magicians and We are talking about ethereum request for commons proposals. So not the coral dev consensus layer stuff, but the Solidity interfaces application Like these standards Yeah Thanks for having me Tim. It was wild. We met at ETH Berlin a while back and see you back in the space. Yeah I'm going to give a quick talk on canonical media and EIP content type So the notes are basically I'm just going to split through JSON and talk about it 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 the era of crypto punks crypto kitties 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 asking this all the time most recently somebody asked how do I met 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 as image So what people have done open see 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 approach 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 Zora core v0 solidity has a function for the token URI Which is not the metadata as the standard defines it breaks the standard But it's 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 named description mime type text plane So that tells the Zora platform to render a text plane image of that particular 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 And that brings me to my next point of thinking about going back and 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 set 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 actually got content Here you have an example Sorry 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 the data you or I 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 that file when you need to have a file with your NFT is the highest resolution the most 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 and art collectors were really frustrated that the NFT was a TIF file, but it was built with the Zora protocol meaning it did support TIF files However, nobody else did so what we had to end up doing is use the external URL Which is an open C extension to link to something to link to the TIF and then switch the image URI to become PNG that renders everywhere and this is after back and forth with Conservationists 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 Amiga mind 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 the 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 R. We file Which is a custom? Content type they defined it's quite and rich has a lot of information But it has the body the author information Signature information and stuff they used to run their platform The problem 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 idea here it 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 as 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 from 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 support 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 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 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 an 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 taken 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 NFT or 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 were 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 airweave, 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 but type URI SHA256 and potentially potentially body for Those that want to directly put plain text in but I feel like URI encoding is also usually a fine option and I'd love to hear what different creators of standards or media have Another thought was you couldn't have some sort of attachments associated Say you have an image that the 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 and your 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 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 and The meaning of canonical is to have a standard or primary authoritative body on a subject so that 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 aetherian magicians group chat It'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 1150 spy 5 sec with a 721 spec The non yeah, 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 I have a github of these files and this is my Twitter I'm 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 on-chain the idea is 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 kind of 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 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 We have one question Hi, I'm Marcus. Nice to meet you. If this was implemented as an e a EIP What do you think the second and third order effects of this would be I? Hope the very first thing is indexers Platforms would include it in minting so manifold actually does really try hard to include a lot of metadata They do image image underscore a URL image includes the hash and the URL and the content type and some other data So I think kind of syncing with them to figure out what their needs are But once you start having stuff minted in this format I think it's gonna hit indexers and then once indexers can understand this people can say oh, I can upload illustrator files I can upload Web GL 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 solidity 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 tacky, but it seems to have worked And that would kind of remove that and allow for 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 plot marketplaces and since this is relatively easy to implement Once a few start, I think it would start spreading Yeah, thank you. We have another one here Hi, hello, congrats for the project So content type is a response header on a TTP, 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 wildcards 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 hotlink 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 mime 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 wildcard there Okay, so that can help, you know more generic applications to accept. Let's say image slash call a slash wildcard 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 at least be some intentionality if you're on some weird version of IPFS like node That doesn't understand the media at 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 Here you define the Content time inside the JSON 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 additions and I think Utilizing a singular NFT metadata in the contract URI, which is an open-sea 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 additions the contract URI is actually generated on chain and sometimes will put an IPFS depending on how big the content is and That includes image and 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 mince yet or like what that whole collection 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 Content field it should just work Thank you Ian round of applause. Thank you very much. Thank you everybody Next up is Francisco from Open-sea, thank you Which is gonna speak about EIP? 52 67 and I have been saying the entire time that it's a it's about the domain separator So, yeah, okay gladly Yeah, so sorry we're gonna move on from NFTs now. It's gonna be about your C20s, which are boring now But okay. I'm a correction. I'm not from Open-sea. I work at Open Zeppelin maintain and develop open Zeppelin contracts, which obviously maintains many ERC implementations and so This is a really important topic to me So this EIP that I'm gonna be talking about is really quite tiny 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 One should follow so because like EIP one 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 Yeah, so the problem at hand here is The ERC 20 permits anyone this 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 permits is one way of Forgoing the initial approved transaction and replacing it with a signature that allow 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 same dream step But it's kind of weird if you use an exchange or an aggregator You don't really see this being used very often. I think mean maybe it's just for like us DC Exchange is 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 this other EIP 712 which is a special kind of signature It's a signature not of a blob, which is what we see Often most most usually but of a kind of typed data structure So it's kind of important because it allows you to get more structured to it in the case of permit You will include the amount that you're allowing You will include and expires timestamp and annonce and so on and This is an important standard because wallets can implement support for it and show the structured data to the user in a nice way one of the important things in these EIP 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 know one 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 Right so the decentralized exchange has no way of knowing Given some arbitrary token what domain they want to use and I think Yeah, I think that is the reason why this hasn't been really adopted So you will see that the ERC 20 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 EIP 5267 comes in 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 in the back of my mind is that this was this is not also a failure of the spec 1226 12 so permits but it was also in a way a 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 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? Carry out the process for the CIP to make sure and other ERC's to make sure that this 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 and that I would recommend you all do when you build your EIPs So you should reach out to all interested parties and like applications and companies and 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 one inch and uniswap and kind of seen Try to get from them. Is this useful to you? it does this solve a real problem for you and Generally the answer in this case has been yes In the Ethereum magician threat, there's also been a couple of interesting comments on 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 So many of those concerns in the case of this EIP were about the Backwards compatibility Section which is here, but Most of the discussion of the Ethereum machine strength 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 Started this EIP repository with the implementation and most importantly a little app, which is just a front-end app Which is what I imagine That a decentralized 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 Comprehensive answer that 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 aetherian magician's thread. So I Think yeah, that's it again. It was very quick, but these are some of the Things that I've been experimenting with in order to get this to a final stage. I think There are what we see many EIP's 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 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 opens up and implements it and people start deploying it And you realize oh fuck this. This isn't really enough So then you need to start thinking about like a follow-up EIP and it's all 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 Happy to take questions if any yes, thank you very much Do we have questions? Yes Hey really cool first comment it reminds me of 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 will 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 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 magicians 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 kind of Is dev work if you call it? Yeah, so a good question. I haven't thought about that too much yet but One of the things that I I personally Struggled with is that I feel like I'm in a bit of a conflict of interest position because of being an opens up in Contracts maintainer. It's like it's gonna be really easy for me to put this in the contracts and make people use it But I don't want to force it down people. So, um, for example, one thing that I 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 Try to get them to to Walk me through do they really see that like really see themselves implementing this and maybe what is the timeline? And kind of yeah, just trying to get more concrete data on on their plans and try to try to get them to commit Maybe that's what I I would do thank you more questions feedback, maybe people that have used this or 712 Raise your hand if you have a question Okay Then thank you very much Francisco round of applause. Thank you Yeah, and that's essentially it that was the ERC lightning talks from the magicians. I hope you all liked it You can find each and everyone. Hopefully on the ETH magicians 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 like so much in this conversation And I really appreciate that we were having like a back and forth between the audience and 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