foreign
[Music]
Annette is currently still in a podcast
interview but I think she will come also
later
I'm quickly gonna give an overview of
what's going to happen in the next I
think we have like one and a half hours
you can already see a bit on my like
drawn slides I don't like PowerPoint
that much
um like what will be the what will be
essentially like the the the content of
of this entire session we have uh lined
up as like six seven speakers including
me
um we are going to Center all of these
talks Around The ethereum Magicians and
specifically we're going to talk about
um ERC proposals so ethereum request for
uh for for comments right so basically
everything that didn't fit into uh
Annette and Tim bico's earlier session I
think like it was about two weeks two
days ago about the ethereum core roadmap
so how this works each speaker has
roughly 15 minutes and then we have a
usually like a five minute break where
we can set up the next speaker
and maybe there's even like time for
questions I guess we will have some
talks about timestamps in ethereum get
locks from Ronin that just entered the
room by chance we will have some talks
about Soul Bond tokens about music nfts
about yeah d-soc we will have two people
speaking about the the problems in the
web 3 music space
about content types in in nfts and then
we'll also have a a very recent EIP
namely I think it's for the domain
separator in EIP 712 so
um I I wanna I Wanna Give before like we
start with the speakers I think I wanna
I Wanna Give a quick talk myself though
kind of kind of like my own like
lightning talk and and it I want to make
it about kind of this weird thing that
the ercs are which are essentially just
like immutable
um contracts that are almost like as
immutable as uh a transaction in
ethereum and uh the problem that comes
with it which is that like we don't
really know how to upgrade them and you
know throughout this whole year of you
know bull market and and everything
especially in the uh nft eco nft
ecosystem I think um you know there was
a there there's starting to be this
debate basically around like how can we
actually do Innovation with these uh
contracts if you cannot change them
anymore right and so like what can we do
about it and I've tried to kind of like
Express that where you know like this
contract uh this this document this
proposal that once you once you put it
into the the final status then it's
really like locked like this like this
locker and we can't really unlock it
anymore and so we have to find ways of
like
still upgrading it and that's that's
what I I want to try to motivate that
actually and I want to try to make like
an optimistic case for what it's
actually cool
so
but first of all I think we have to
backtrack a bit and and this so this is
a comment from uh I believe the the
GitHub thread on Erp 2612 the uh the the
permit standard that allows you
basically it's like a replacement for
erp20 tokens where instead of sending
the approval on chain and like kind of
like wasting all of the scars for the
transaction envelope you you technically
could sign a transaction get that gives
the spending contract uh the permission
with your signature and so the idea I
guess would have been that new use cases
are kind of enabled and that also
um
that also we can save a lot of gas
especially like considering that you
know each erp20 transfer is essentially
like two transfers right today and so if
we could already condense that to one I
think the gas savings would be uh quite
significant considering like how much we
are transacting with erp20 tokens
so this comment is actually a critique
though on that standard and basically it
I I don't even like fully know the
entire history but I know that I think
the the standard has like some issues
it's not really in in final mode either
and then you know like many uh companies
have like kind of diverged from it and
and they're like non-compliant and
that's like I think with this standard
so it kind of shows I think maybe a a a
bear bearish case for for this kind of
um
standardization approach and then um the
other case which I had to deal with
myself uh personally because I I crawl
nfts this is the interface for the Zora
M nft contract and m stands for media
nft and you know I I think my first
exposure to this was that I was kind of
like disappointed because essentially
when you call the token URI like the
regular token URI you are expecting a
Json and uh but what I'm getting back is
a media file and so I have to actually
have to actually go to the Token
metadata URI and that's where the
metadata is right I mean the name is
descriptive of that and and so I was a
bit disappointed because I couldn't like
I had to basically build like this uh
this like custom logic around it but on
the other hand I'm also empathetic with
that because
uh in the regular nft the media file
which has been like traditionally the
image is literally in a uh Json object
that we call metadata so I I mean in my
opinion that says a lot about how we
think about nfts and that we see the
image or like the media that is attached
to the nft kind of like as metadata to
something that is the nft that is kind
of like maybe like a financial
instrument then or whatever and so I I
think it's actually beautiful that they
that you know that they made the case
that we should actually use the token
URI to embed the media file directly and
to Center really the nft around the
media file and not uh make the media
file a mere uh metadata field so
foreign
and apart from all of this uh like
pessimism I think there's there's
another good reason for uh submitting
and and being active on this forum and
it's because you get a ton of exposure
to uh to your ideals so this is a thread
here that I made I think around in in
April and it's about uh like a
specification for soul bound tokens or
we now call them account bound tokens
and this
threat has gotten 9000 views and if you
would sort by the replies it's actually
the top uh the top controversial threat
on the entire forum for the for the
entire year apparently so I mean while
that is uh concerning to me because
apparently a lot of people have opinions
about this it's also on the other hand
it was a like a beautiful chance of of
receiving feedback and also called lack
of receiving constructive feedback
which with which without that this
standard wouldn't wouldn't have gone
where where it went today so I initially
started this um as a non-transferable
token
uh specification and basically now we
have can we have like moved into
consensual minting
um and into like yeah basically like
having the the signature being checked
by both the sender and the receiver and
you know we are actively talking about
all of the Privacy challenges of Soul
Bond tokens and so this has really
become basically like a space where this
entire standard all the solar token
things everything is like very verbosely
documented and and I I think it's
awesome because I I wouldn't have had
these ideal ideas by myself so I think
this is like a community effort and it's
cool
um
and
so by the way I'm like basically these
slides are all a um Eve magicians blog
post essentially and uh I need to find a
bit my way but so the so so basically
one of the but kind of like one of the
one of the problems of the EIP uh
standards process is that it's it it's
it's truly permissionless and it's open
to everyone essentially because you can
just go to like the uh you know like
github.com ethereum eips and you can
submit your own EIP and as long as you
are uh complying to the uh the
formatting rules and you're like you
know you're like um
receptive to the to the feedback of the
EIP editors and you're not like mean to
them or whatever you you will actually
get your document merged and that
document will show up on
eips.etherium.org so that's really cool
um and that's really a strength but it's
also a weakness and I think this uh I
guess it's like a bit of a famous
cartoon in the
in the uh in these standards community
at least where you know like the there's
like the this XKCD comic uh you know
where there's like 14 competing
standards for a use case and then
there's this one guy saying hey that's
crazy like why do we need 14 standards
we should have one standard that has all
of the uh that addresses of the use case
and suddenly we have like 15 standards
right so so it's kind of a problem in
the ERC process as well that we just
have like a lot of verbosity and and
duplication and and so on so it's like
you know on one side we have like the
strength the openness and also this like
uh yeah it's almost like a Spam problem
or whatever but
I wanna I wanna I wanna still motivate
and I wanna I wanna say that I I find
this actually awesome and I find it
awesome because I think that there's a
difference between a a temporarily
emergent consensus and a consensus that
is more like spontaneous and probably
like from this kind of like uh you know
like group or a committee of experts and
so I I've tried to visualize that with
the two different kind of approaches the
two different extremes so to say where
you know on one side we have more like a
market driven adoption where the
individual kind of uh makes the decision
by themselves they they do all of the
due diligence and and they come to the
conclusion that they want to use a
standard and then on the other hand and
this is maybe true for uh yeah like more
I think like groups that have to make
decisions rather quickly and and like uh
yeah like close to time I think you have
this basically this this spontaneous
committee consensus where you know 51
can basically overrule the uh 49 and I
and I want to make I just want to uh
kind of make this argument that you know
I I believe that the temporarily uh
continuously emerging consensus is
actually the the cooler one the the one
that has like a that ends up having like
a stronger signal over time and that's
because I I mean there's one hecky way
of just like proving that and that's uh
that if you consider like how
organizations are run today then it's
probably mostly in like this 51 51
consensus style right and then on the
other side you have this totally chaotic
evolutionary kind of thing that that is
the market that somehow also figures out
like what is the best decision but
completely different and not by talking
to each other and so I I think and I
mean by no means is this uh Financial
advice but I I would always bet on the
market and not on like an individual
uh committee actually and and so I I
think that's that's actually the better
uh the better approach
and and also I mean I guess it's also
the reason why like much of our critical
infrastructure is like running that way
like I don't think there's like a you
know like a central planning for the
Food Network in a city or uh stuff like
that
um
and so
so the question is though like how how
can we overcome this this uh this
immutability of of contracts and how can
we actually still innovate on those
standards and and this is especially
true with uh with all of the like this
you know all of the eyeballs that have
have like went into the nft space and
and you know kind of this difficulty of
of innovating with the standard and and
I mean sadly also with being
non-compliant to the standard and just
trying to grow uh externally from
standards and and so I think
immutability does not necessarily mean
uh stagnation I I think actually there
is now we are starting to see a pattern
emerged where people are starting to
really upgrade the standard and they are
doing it in a way where they are
basically like
um yeah basically bolting
um kind of this one lock to the other
almost like a like like in a I don't
know on these bridges that sometimes you
can see as a tourist kind of thing so so
I think um over the last half a year
that has really happened so uh for
example we now have a standard uh event
for emitting a uh an event when the
metadata is updated in in an NLT
standard and that's uh the one on the
top right it's the 4906 that essentially
just emits an event we now have a very
uh interesting
standard for that basically splits the
user and the owner into two different
groups and I think especially with you
know with d-soc kind of making us aware
that there are only that that there are
like subsets of ownership where kind of
ownership represents this bucket of
right and then you know you can have
fructose and you're kind of Usos and
abusers and so on
um this this is starting to become
really really interesting right we have
like different kind of roles that could
interact with the nft and then this
could have like different economies and
so that's I want to give a shout out
that's 4907
and then I guess maybe like a a more
Infamous one is the is the royalties one
and it's the 2980
81 and that's basically an optional
an an optional royalties location
mechanism for nfts that is implemented I
think in uh in many nft marketplaces and
and again I I just want to highlight
that I think it is definitely possible
to upgrade uh these things and like we
are we are doing that I just think that
probably the time Horizon that we're
looking at this and where you know we're
like drawn to being a bit more
pessimistic I think maybe we or I mean
personally maybe I have to be more
patient and just like trust in the
process and um yeah I guess I have five
more minutes so I'm also gonna uh of
course I'm gonna shill a uh a standard
that I did myself which is the minimum
uh So Gone token and it works in the
exact same way where basically we are
extending and even breaking the EAP 721
interface and essentially uh we're
allowing people to lock an nft so you
can emit a locked event and an unlocked
event depending on whether the transfer
function should be uh should be
reverting or not and then we also have
this view function that allows you to
always check whether a token is locked
and the purpose for this is that um
that if you were if you were to just use
like the plane
um
721 standard which
actually it has a kind of like a small
uh line in it where it says like that
these uh nfts can also be they can be
used as a reader like a read-only
registry the problem is that indexes and
wallets and so on wouldn't really
recognize it because a computer cannot
reason from let's say you know the
transfer is reverting to
you know this thing is like locked
because it could also be that you have
done like something else like something
something else wrong you know and so
therefore the error might be referring
to something else so I I personally
think that's useful and that's final now
also and it's building on uh
uh 721 yeah I mean now I'm at uh 17
minutes the next we're gonna have the
next speaker
um thank you for also giving me the
chance to give this little talk and um I
want to ask to Stage Ronan
I don't know the exact finances thank
you
okay thank you for coming here
um
and kind of to explain it I'm not too
sure demo and I wanted to show it in
real time but the Wi-Fi made me so made
me realize that I should probably uh
have it already done and show you the
result
um so basically the proposal is to
improve so what I'm building I'm
building a
indexer so that kind of take all the
event of a contract and contract the
state which is our most
a smart contract system
under State for the client for yeah for
basically having data about it and most
projects
use a backend which is at odd with the
vision of of decentralized application
so yeah my idea was simply let's index
in the browser and of course uh it
doesn't work for everything
um because of the scale of some of these
of these systems so for example if you
wanted to index all the nft
uh you could do in the browser but it
will take a while
um but for some other case it actually
worked very well
um and so I was doing so I have this
game so the whole state of the game is
actually here
so you have all the fleet
is gaming space you have planet and
Fleet uh you can there's two main things
and
it's like I think this state is around
seven megabyte but it's not actually I
didn't implement the full uh so I have
an index I have the same indexer running
on the graph
um
and I didn't finish to implement it
fully here that's what I expect maybe to
get to 20 megabytes of State
um and I can on the normal Network I
don't know what normal means but it
cannot it took five seconds to think the
whole thing and if you can obviously um
uh but I made an assumption that uh in
my in my game there is this notion of
time so every event
um
so the state the the contract will kind
of lazily update per time and I think
it's quite a common thing in it's my
contract and unfortunately
when you fetch the logs which is a
mechanism by which you index and manage
to get back the state all this event
basically which
um you don't have access to the
timestamp at which they open
it's just some reason uh they didn't so
to add that so there is a blockage the
block number but there is no block
timestamp and so my game actually when I
uh I need the timestamp and
so because I don't have the timestamp in
the logs I get like 20 000 events here
and what I need to do then I need to
request 20 000 times
um depending I mean a bit less because
you can have uh same even an event in
the same block but you I have to request
that on top and because it's a in
browser indexer it uses
eip119393 which is like the the wallet
interface and I cannot do batch request
I have to do all these requests and so
uh I have this version we actually is
still running from last time and
sometime here or out because the RPC is
not happy that I'm so the RPC of
metamask because again here it's a juicy
static web page there is nothing no
back-end
um and it all only rely on the fact that
the user have a
eip1193 wallet in that case it's
metamask and if you if you look at my
settings It's actually an RPC uh
somewhere else but
uh so it's still querying all of these
to get the timestamp while the other one
have been finished a long time ago and
only actually you see 580 request is
actually 300 because the other one now
is just to get the latest block and
nothing is really happening in that game
right now
um while this one is still like fetching
the the state so it's going to reach
probably 20 000 to sync or maybe even
more
um
um yeah so so the proposal
I wanted to show you a kind of a really
example but the proposal is
um is basically to add
this to the Json object so it's a very
simple change you can do in a in your
node so in goatorium or what whatever
and so actually finally enough uh like
team pushed me to go to the core Dev
meeting the other day and actually I'm
going to and so we are the interesting
discussion about it but
um so I kind of
so most of it I already say but the idea
is that you must
so what I could do is that I could add
the timestamp to the to the event itself
uh but obviously when you do your
contract you know that there is a block
information so there is no need to add
the timestamp to the event it's just a
waste of gas
um and time is an important aspect of
many smart contracts and block number
cannot be a replacement for them and the
reason why is because uh block number
timings can change across chains but
also there is no guarantee that a single
chain will not keep it and you could
probably emulate an average block time
using smart contract itself but it's
kind of a
ugly work around
um and black block times them already
easily available like the block hash or
the block number
and another so I've been discussing
about a few people readers and yeah but
this is extra data you have to put in in
the log object but it's small and the
alternative is to to fetch all of these
anyway
um so of course for the one we don't
care about timestamp then they they have
an extra a small but I feel it's small
enough
alternative but I would not consider as
alternative actually I could use them as
complementary
uh so when I mentioned them I'm not
saying I don't want them actually I want
them
um but I feel they they will not replace
you
um so yeah basically when alternative is
to add batch
um a batch API for Erp 1193 it was
actually part of the conversation
initially but it was dropped but I think
it's it's a valid one to have and but my
opinion it doesn't
offer the same Advantage as having the
box timestamp in the log
um and another EIP that I didn't see it
yet is to have a great graphql API uh so
basically an alternative to eip1193 and
with graphql you can ask what you want
which make it more efficient as well uh
for transferring data so if you don't
care about the timestamp you don't need
and actually this one could really
by actually solving the first one so
this one is really an alternative but uh
I don't see any reason to just
um add another one especially I think
graphql is not supported in all the node
implementation today
um
and so as I say I went to the core Dev
and we had the feedback and the main
feedback was that hey there is no point
to do it because we are going to make uh
the logs
uh not being accessible after a certain
time and so the argument was like you
will never have that many log and so
requesting the timestamp anyway won't
matter uh and so my reply is that uh so
it's an easy change
uh so my next action would be to make a
PR I guess for goitream
um and and the number of log actually
can still be significant
um so even if we
remove past log we still want to to have
access to them but actually the main
issue with that with that feedback is
that we need to really think
how we are going to solve the state
access about
um if we we don't have access to pass
logs how do we are going to index uh in
a decentralized manner
um because of course if you have a
backhand you know you solve your problem
but we we don't want to have a back-end
right you want to be able to use tornado
cache from your browser without relying
with only relying on your node
and so so I think I don't know for me
that I would like to to have discussion
as a community how we can so solve that
like I know there is work on the uh
around like right now about portal
things portal Network
um and so but I think it's important we
um we understand like the point of view
of application developer that don't want
to be involved with our application once
it's launched
um
and another thing
yeah so I mentioned like most systems
already rely on the log events we need
this system anyway
and even some EIP have been using it to
kind of speed up the
the needle kind of minimize the gas cost
which is eip1155 like you can't query
the balance of all the token that the
user owned from the smart contract and
so you're always a smart contract to be
more efficient and it's because it has
been the result of everybody
acknowledging that we use logs and event
to reconstruct the state
um
but that interestingly one of the things
about in the code of meeting was that
that was not the vision initially
but now we evolve we understand what we
need and so I think yeah that I I will
end with uh with like yeah let's discuss
about how to solve this being able to
rebuild uh the state from from the
client
it's kind of all for me yeah any
question
thank you thank you Ronan thank you for
close
uh do so we have uh we have time for
questions do we have any questions
in the contract
what are your thoughts on using Getters
in the contract as opposed to events to
get the data for a UI
yeah so
so far I I can talk about my game
actually on that front so the first
version I really wanted to launch the
first version without any back end so
the first version of the game the first
Alpha uh
I didn't have an indexer using the log
and I was fetching all the data and it
is not actually it's not efficient
either because uh especially list of
things and and you are wasting gas to
support that in many cases like so this
is uh what I mentioned eip1155 not
having access to the balance and we
could also think about
um your seven to one
um enumerable extension which add
actually a lot of gas cost overall
um so I and I think from what we have
seen everybody like even to to do that
role so I think
that's what we should do and minimize
the role of the yeah minimize the gas
cost we basically that was when we Nima
is the things that happen on the Chain
if we can do it of chain but it's assume
we have a system to retrieve it that's
why I think it's important to discuss
because maybe the conclusion is like oh
actually we cannot and we have to pay
gas to do that but I hope it's not the
case
hello everyone I'm gonna start my timer
so I have a reference point here uh yeah
this is my first time actually talking
at Defcon this is my second Devcon
um I'm super happy to be contributing
back and sharing knowledge and the
sparking debate and ideas so thanks for
having me and thanks Tim for organizing
this as well and it
so today I wanted to talk about uh
eip4973 Badges and the financializing
towers and Beyond as well uh so firstly
a little bit about me my name is Rahul
I'm co-founder of this little baby
company that we started called autospace
uh and I've been in the crypto ecosystem
since 2016. I started off with my
journey also with music I was building
nfts to assetize music royalties back in
2017 did not work uh they moved on to
SoundCloud got fomo with those and I got
back to crypto full time now
uh so I think I want to start with uh
how this year had started actually like
uh we think that there's this paper
called decentralized Society uh and it
centered our attention on this notion
that web3 centers around expressing
transferable Financial assets rather
than encoding social relationships of
trust uh when everything is transferable
things can be sold to the highest bidder
so you know we wanted to challenge that
uh and that's that's what that problem
is what gave to this idea and working
with Tim on this EIP uh what we call
account bound tokens not to be confused
with sold down tokens or you may be but
semantically speaking we kind of uh you
can Define this as non-transferable
tokens bound to an account and then our
goal here was to really
it's very semantic based again like to
create special ownership Deeds or
creating like permission Primitives but
really to create a new ownership
experience through this primitive you
can read more about this uh we have
written a more extensive uh article on
this
uh however ever since we started we saw
we noticed this account on tokens uh
debate had kind of like exploded you
know there's soul-bound tokens there was
Community about tokens ens name bound
tokens now human bound tokens uh what
we're actually seeing is this
non-transferable tokens is a spectrum
and you you can Define what is being
bound to and what is that binding
strategy and you can kind of uh this is
this is where the explosion of ideas are
coming and as a builder I feel like some
of the nfts nft spec is kind of over
optimized for what we actually express
our ideas through so we're kind of like
craving for new tools and new uh new
instruments to kind of like uh build our
ideas right and at Auto space we we call
something smaller something simpler we
call them badges which is powered by
eip4973 accountable tokens
so uh I want to dive right into it like
because because ever since Soul bound
tokens was kind of like really a Hot
Topic it kind of sparked like a lot of
hot debates or uh and it's it's debates
are great like because uh it really
helped us intellectually navigate the
space and like get like a pluralistic
opinion uh from various uh parties uh
one of the first things uh or concerns
they put out like I think was permanence
you know what if I don't want a sold out
token or an account token you know
anymore
and the second one is a lack of consent
what if I get an nft like that's
non-transferable airdrop to be with my
uh personal details you know what would
happen you know and key rotation you
know like I I what if I lose access to
my key wallet yeah I want to like I mean
uh to my wallet or do I want to change
my wallet and lastly this more popular
active debate about like uh verifiable
credentials and abts on Chain versus
off-chain identity uh so lots of things
uh very simply put uh there we've
written again lots of uh detail on this
but I can kind of summarize this uh
these were the design decisions that
helped us input into erp4973 so
permanence when we talk about uh in
general what we baked into it is uh
burning and dissociation from the so the
owner of the Soul bomb token or account
bomb token can dissociate from uh from
the token itself and then lack of
consent uh
non-transferable tokens through organ
tokens cannot be air dropped you need to
have a two-way consent which I will dive
into a little bit later and with other
space we're actually
actively looking into recovery
mechanisms like Community Based recovery
especially if you lose access and you
have all these non-transferable tokens
uh and lastly avts versus verifiable
credentials
use both really it's not mutually
exclusive uh they have like good use
cases and it's really we're in the early
stages of kind of like the debate and
application so I'm kind of excited of
what would actually come out of this
next year
uh so like on a very high level like I'm
oversimplifying this but like you can
see the key differences like if you look
at like various uh angles or various uh
Dimensions right if you look at
transferability consent removal issuance
expiration and fungibility but I think
uh I want to bring Focus to where
consent and issuance uh that's that's
really what we wanted to like did not
want to compromise on there when it came
to a non-transferable token design
so let's Dive Right In like so this is
the erc4973 at a glance you could just
npm install that very easy so that's a
very uh very light interface right like
it's just expresses so we can kind of
like dive into what this uh actually
does so firstly this top section right
this transfer event balance off on or
off this is this was mainly to ensure
backward compatibility backward
compatibility to nft in general so we
actually implement the ierc 721 mm
metadata uh so one of the things that
building this EIP actually it was super
amazing learning experience uh we
actually didn't have the transport event
first and then we were kind of missing
all these stuff like etherscan was not
showing the log events for example or
metamask was not showing the uh the the
interesting metadata so we we actually
started using the transfer event which
is such a simple change everything
started working automatically you know
like uh the support the interoperability
actually came came for free and that's
one of the reasons we went back to the
transfer that although in a
non-transferable event
token you can argue that transfer has no
makes no sense but this was one of the
design decisions that we learned like to
kind of Ensure backward compatibility
uh and the next one and this is really
the where the consent really comes into
play
so if you see the function there's like
three three parameters right like the
from the URI and the signature
so we call this a take flow so you
cannot actually mint an account bound
token unless it's two parties involved
so it's like a peer-to-peer fully
mutually consented protocol right so you
can think about this as like okay Alice
designs and ABT described by a spec
which is hosted by a token URI Alice
then wants to issue the ABC to Bob
uh Alice can only do that if this if if
he signs using aip712 signature and
provide that's capturing her consent
so now that one party consent is
established Bob can now take the SBT he
would then basically authenticate by
providing the circuit URI the signature
from Alice and then prove that I can
take this uh so this is uh in Auto space
we actually call this the allow list
flow so I'm just like adding people to
an allow list I'm like signing uh people
uh for to a badge and the give flow is
actually its inverse uh it's uh it's
when the when Alice designs an ABT Bob
wants the ABT so signs it and then Alice
can now give the ABT to Bob so this in
order space we call it the airdrop flow
so if you if you give a badge you can
just like basically I want this and 100
people say I want this you can actually
do an airdrop through uh through an
account token
and the last bit is this one it's uh the
unequiv this basically means complete
dissociation from the account bound
token so only the owner of the token can
dissociate so these are like basically
the fundamental building blocks that
kind of like help this uh create this
very bare minimum uh very simple very
it's highly functional highly
utilitarian uh EIP 4973 and then Auto
space we are kind of like uh building
more flavors or more layers around it
but this all the what this had serves at
the fundamental has been working really
good for us so far and I also call
actively contribute to the EIP and uh
yeah it's been super exciting and
learning in general
so moving on to the other side of what
that the topic I wanted to chat about as
well which is the financialization right
at outer space where like the badges we
see this in like six six areas how we
can use a non-transferable token a
membership model non-financial rewards
uh and recognition onboarding quests to
end with the badge assess the reputation
uh more nuanced governance models and
then unlock access permissions of these
batch holders
but I want to bring attention to this
bit
this bit of uh that's non-financial uh
rewards and recognition I mean I think
we can all agree that uh the ecosystem
is like hyper financialized uh and we
want to challenge that status quo like
you know you if you're in a position of
wealth and influence you can buy tokens
and if your community is basically to
design their governance on a one token
one vote system so person of influence
can basically assert their entire
influence through that power
it's basically plutocracy right so we
want to challenge that and we want to
move towards more towards the one human
one vote but uh for us we see the one
account one vote as a necessary step to
kind of get to one human one vote
uh and then this is really Fresh Off The
Grill right this happened like a few
days ago uh the mango markets uh the
hacker exploited mango for 100 million
hacker turns around uh offense to return
the funds and he used 32 million of
those votes to say yes to his own
proposal because he hacked those and
then executed that proposal and I think
we can do better than this right like uh
it's a that's a no-brainer I feel but
it's really the takeaway that I wanted
to kind of uh here have here is uh let's
move away from the one token one vote
system and away from plutocracy and uh I
think let's let's explore new forms of
governance I think it is no
one-size-fits-all I think we're in a
stage where the ecosystem is growing so
so fast and we as Builders we we
definitely need more uh instruments at
our toolkit we need to spark debate yeah
apply rigor get feedback so I'm glad
that I'm kind of like getting a lot of
that here in Devcon so that's uh that's
a lot that's it and that's a Dali otter
we are uh we don't work we just create
these Dolly orders most of the time if
you're as surprising my team is
surprisingly good at creating daily
orders you can scan this it'll give you
more information about us uh yeah that's
that's it
thank you thank you Raul
um we have some time left three minutes
do we have questions ah yes okay
hey
um can you elaborate a bit on the
account through the recovery part
yeah absolutely so um
so one of the things with account
recovery uh it actually came up pretty
actively in the debate like hey if I
have badges in my account if you have
non-transport like tokens what if I want
to rotate my keys
uh then how do I do this and that's one
of the criticisms that were pointed at
sold down tokensen initially uh quite
frankly I feel this is a this is not a
soul bound problem or a soul bound token
problem this is a entire protocol
ethereum problem and I feel like we need
to wait until we need to do this better
and then we can absolutely adopt it but
we are looking at two ways of recovery
one is a proactive recovery and a
reactive recovery but we are offloading
this to the community in our protocol at
least so it's basically like moving from
moving your phone like if you're
importing your number uh from one phone
to the other so you're actually doing a
proactive action so you have to kind of
like prove that you are the owner of
this account and the account that you're
porting over to but the way we're
thinking about this is uh you can't
transfer these tokens but you can burn
all the tokens as the owner of the
current account and you can get it
reissued through the the issuing
authority which is generally the
communities or Davos the other aspect is
reactive recovery which is where like I
lost everything then you know that's a
tricky one you have to establish with
your uh like your Dao for example that
hey I'm the same person behind this new
wallet like you have to re-issue it and
one of the models we are looking at
there is reassurance but the community
perhaps can revoke those badges so
that's that's how we're kind of thinking
about it thanks
more more questions we have time for one
more question here
oh
um
uh just a quick thing regarding
um
uh recovery through burning and then
reissuing it would be awesome if there
was a way to do that atomically yeah
right but the other question was what is
the status of the EIP is there time to
still make breaking changes uh or is it
already like so widely adopted and this
kind of relates to this stagnation
discussion but I think it's yeah that's
a good question I should have actually
uh put the stats on it I mean uh people
are already using it we've seen uh I
don't know maybe like a 150 300 hits on
probably somewhere on GitHub so we are
actively thinking about backward
compatibility when we're adding but the
EIP is in review stage at the moment uh
yeah when and now we're kind of talking
about expiration uh as a as to be baked
into a badge where you can give like a
30-day expiration badge for example
especially if you're like
joining a dial you get guest batch for
example you know you can do some
interest so expiring badge is something
we're looking at but uh yeah like we are
this is one of the forums we're hoping
to get feedback on like you know where
should we park it should we get feedback
or have invest in extensions and like uh
because there's a lot of utility this
can deliver in its current form you know
and then uh it would be uh strange to
perhaps like you know stretch this
timeline because I think uh I've seen
aips go for years
thank thank you Raul uh Applause please
thank you
uh
yeah
um
I'm just gonna while the next speaker
Sweetman is um going to set up the uh
the laptop and so on I'm just gonna walk
you through the rest of our timetable
which is by the way here so uh next up
is uh sweetman.eath and he's going to
talk about uh music the music nft
engineer then we have Andres who is
going to talk about uh web3 the web 3
music nft multiplayer problems I'm very
excited about that I think it's uh like
it comes out of water and music research
then we have Ian who is going to talk
about uh Rich content types in nfts and
then finally we have Francisco who is
going to talk about a uh like a very
recent EIP called
5267 I think which
uh I think it defines the domain
separator of EIP
712 so yeah if you're familiar with that
I guess it's you you kind of understand
what it is if not then I recommend going
to
eips.etherium.org and reading up on it
um
uh yeah okay I do have a lot of music
nfts for y'all today so first I'll ask a
couple questions who has a music nft
okay who owns any nfts on optimism
who owns nfts on arbitrum
who owns nfts on polygon
my goal is by the end of this you will
have your hand up for all of those
hi I'm sweetman.ie aka the music nft
engineer and today
we're going to talk about music metadata
first the problem you're going to see QR
codes throughout this the ones on that
side are from musicians in Latin America
if you want to support creators here in
Latin America scan that by the nft
support local creators
on this side you'll see cc0 music nfts
100 Freeman on different chains and so
they'll be scattered throughout if you
want some nfts
momentum
the problem
don't worry the same QR codes are going
to be a little bit hidden in here
music platforms are not creating music
nfts this is a very spicy take that I
like to hold you'll see on the your left
side these are metadata from the top nft
platforms
up top you've got Zora creator in the
middle you've got catalog and down at
the bottom you've got sound
you'll notice that they each have
different metadata but honestly there's
no real differentiation between the
metadata of a music nft and a normal nft
in most cases
over here on this side you'll see the
music metadata standard
this includes the same attributes as a
normal nft in addition to attributes
that matter for music attributes like
lossless audio attributes like BPM
attributes like duration these are
things that matter when we're talking
about platforms like Spotify or Zora
wanting to index these nfts and to be
able to differentiate between a music
nft and a normal nft
why does this matter
when we talk about ethereum congrats
we're in the ethereum Wizards room we
have merged and so now the next kind of
goal in our identity crisis as a
community is how do we get Global
adoption
I see music nfts as the Trojan Horse for
ethereum adoption while a lot of people
don't care about nfts most people do
care about music and so if we can build
platforms that allow music nfts to plug
seamlessly into the existing
infrastructure we can allow for more and
more people to be consuming the ethereum
technology that we know and love but the
big challenge right now is that
musicians are using these platforms that
don't really differentiate metadata
between normal nfts and music nfts
next the opportunity
another set of nfts oh yeah the last one
I'm sorry I didn't I didn't shout out
the Creator so the last Creator this
first nft is caspiel we've got Colombo
in the audience
um manager of cast peel and so that nft
is from a musician named caspiel who
dropped on Zora Creator and that is a
music video of her latest music video
reflejo and uh all of my music nfts are
cc0 from a musician named Sagrado based
out of Mexico my favorite because he
does everything cc0
this next one over here we've got
another Zora nft I think we've got
tranky in the audience who helped a
Buenos Aires Creator named uh well
created a platform called unun and so if
you scan this it'll take you over to
unun to Mint some music nfts from local
Buenos Aires creators
and this one is another one from Sagrado
and this one I believe is on polygon
last one was optimism this one's on
polygon
the opportunity we have an opportunity
right now to standardize music metadata
right now it's been in discussions you
might have heard about telegram groups
you might have heard about different
chats that are scattered amongst the
music nft ecosystems maybe you've talked
with Hi-Fi Labs about their music nft
standards maybe you've talked with Zora
there's a lot of different standards out
there we have not really reached
consensus and I find that awesome
because there's no gatekeeper there's
nobody that's telling us this is how it
is it's very much a bottom-up what does
each Creator want to use when they're
making their music nfts
um and again the full music metadata
standard over there on this other side
how you can help
again the music metadata standard is not
something that we're gonna have Sony or
Warner or some record label is going to
come down and say this is how it is it's
going to be bottom up from the engineers
that are building from the creators that
are choosing what platforms to build on
each of us as individuals is choosing
which memes we want to propagate in
order to make the mess the best metadata
win
the final set of nfts we've got this is
a catalog nft from a Creator named hey
Bella who is also based here in Colombia
in Medellin and this one is an arbitrum
nft the same nft
um by Sagrado
spread the memes
all the ethereum Wizards all of you
Builders we are building
um
it's important that we propagate proper
music metadata when we're building if
we're giving these musicians poor
metadata we're setting them up for
failure in the long term as Spotify as
iTunes as these other big platforms the
future tapes the spin amps our indexing
music nfts
if we're not putting beats per minute if
we're not putting keys if we're not
putting the credits on chain we're
missing out
and so what I've been working on is I
cloned the Zora metadata render which is
an architecture that allows us to
decouple the erc721 the erc1155 all the
tokens we know and love from the
metadata that they represent
and so we have a full music metadata
standard that's fully on chain deployed
on ethereum mainnet polygon mainnet
optimism mainnet arbitrim mainnet as
well as test nets for all those Chains
It's live the contracts are verified
it's fully running on a platform that I
built called decent
um and so what I'd like to ask the
community here I'm not very familiar
with the IPS I'm not really familiar
with what we do as a community the
formal way I'm really used to building
with the musicians on the ground I don't
know if we need an EIP for like proper
music metadata for us to get aligned I
don't know if we just need to talk with
the Zoras to properly plug in the music
metadata render into the Zora stack so
that musicians can use it maybe it's
just me writing an EIP with Hi-Fi labs
and getting it plugged in there there's
a lot of different ways we can propagate
this meme out into the ecosystem I don't
really know what to do and I'm not going
to claim that I'm like the king of all
this I just would like to have the
conversation more
um and so I'd like to ask for help in
propagating these music metadata memes
so we can help musicians adopt this
technology so that musicians can start
leveraging these web3 rails that make us
and the technology that we love so
powerful and groundbreaking and like
fundamentally changing the world that we
know and love
that's it Viva La Musica these are all
the music nfts that I showed throughout
and then these are a lot of musicians
that are based in Argentina and Buenos
Aires in Argentina as well as Colombia
that I work with on a regular basis and
so if you want to talk to some musicians
that are based here in Latin America and
you want to like get their thoughts or
help them out or talk to them about the
music nfts that they're making I've
attached all their Twitter handles above
so please reach out to them they are the
people that are on the ground doing this
I am just some random engineer that's up
here talking to y'all so uh with that
we've still got 10 minutes so I kind of
zoomed through that I believe the rest
of the time open to any questions from
the community
thank you sweet man hand of applause
[Applause]
so do we have any questions in the
audience
raise your hand if you have any
questions yes
hi
um I was wondering like uh how what was
your process in navigating to the EIP
like how did you gather information
about like music metadata is a very
complex structure right like uh and
there's not having consensus over
metadata just sounds like a classic
music industry to be honest so I was
wondering like how was your process to
getting to the the stage and the EIP
generally to be clear there is no EIP
right now this is this is a bunch of
blank data I copied EI I took a
screenshot of eip721 and I blanked out
the data to just kind of like put the
meme in your head as something that we
can do I don't question back to you do
you think this is something we could do
with an EIP or does this feel like you
say like the music industry is too
decentralized for us to come up with an
eip4 music metadata standard
I think yes uh there is one part that's
probably up for uh like off Chain versus
own chain I think if you have that
perimeter very clearly uh I think this
is this is exciting yeah in in an
attribute I didn't talk about all of
these uh all of these decent nfts 100 of
them metadata is on chain so one of the
awesome Parts about l2s is it's
incredibly cheap to store all metadata
on chain and so we can store that entire
music metadata on chain for less than a
penny and so musicians that are based in
Latin America cannot afford to do
transactions on each mainnet
um but by offering them these rails to
be able to create music metadata we can
also offer them the opportunity to put
it fully on chain so that there's no
trust needed in apis like what sound
uses or even like the delay you get by
uploading to ipfs if you're not using a
dedicated Gateway when you store it all
on chain you get that instant
availability that you get on optimism of
a trim polygon and the other l2s
thank you more we have more time for
questions if there are yes
um it wasn't clear do you want to write
an EIP for this or do you not want to do
it I'm very open to it I'm I'm here in
the community I my entire life is music
nfts and so if the community decides
that we want an EIP I'm about it
um I'm I'm very much of the belief that
I don't I don't want to say like this is
the way I like hearing like the music
metadata standard I didn't come up with
that that came out a catalog and I'm
just propagating that Meme because it's
in my opinion the best meme yeah no I I
think um a great first step would be to
public like it seems you've done a lot
of research to publish that in some
written form maybe in The ethereum
Magicians form uh to just kind of keep
it make it visible and someone else can
then maybe pick it up and formalize it
and they're in the IP that would be very
valuable and I I want to offer a counter
I don't think that you
specifying something and standardizing
something would be like imposing your
view of things on the world it's just
offering an option right and whether
that's adopted or not depends on on the
on the rest like you've said but having
an option that is uh there and specified
and like standardized is extremely
powerful and I don't think it's imposing
anything in any way
thank you do you want to take more
questions we have more time love to
especially if it's from Dan
hey
um it's quite funny because obviously I
wrote they bought a music report
yesterday they came out on this subject
have you not read it yet I have not
interested in because there's definitely
points of conflict between how we're
seeing this
um and for me
having worked like the whole has inside
the Beast as it were
um one of the biggest issues in music
industry comes around multi-party
consensus around data points and also
conflicts
and that's always been my assistance
about pulling everything on chain
um because
it it makes things much more complicated
to and it also
creates friction around how much you can
actually trust something versus if it's
housed somewhere else in some kind of
on-chain registry that can be updated by
multi-parties and so that's why my
feeling on this has always been that
music nft data should be minimally
viable and contextual Rich data should
be kept elsewhere but in a fair way if
that makes sense so just interesting
what you think about that
what are your thoughts on the
um the metadata render architecture that
zores put out where the Creator is able
to there's a trusted party um a role
that is able to go back in and update
that metadata when they choose does that
make a difference or you still think the
best solution is fully off chain
well he decides who the trusted party is
the creator
but what if there's multiple creators
I'm excited to hear Colombo's talk on
that yeah this is the challenge right
and then you've got differentiological
buyers Publishers uh producers
um all these people who are part of this
Rich soup of
um influencer creates a piece of art
like at the moment the music entities
were in a pretty nice place in there
it's usually been one person putting
something out
um but gets complicated as soon as
like that expands right
um and I think like it's really
important that as we're thinking through
this we need to be you know thinking for
like Mass adoption and how to do all
that
Point well taken
nice we uh yeah if you are taking more
questions we have two more minutes yes
okay yeah tranky
um this is more just a comment about
whether or not you want to do like an
EIP or something I was in a talk
yesterday that was like see something
called like c a i p it was kind of over
my head I'm not gonna lie like Captain
but it was a different type of like
Improvement proposal sort of like
Coalition about self-related like l2s
and things I mean and addresses so it
could be they have a the GitHub that's
like set up so I think an initial
interesting step could just be forked or
GitHub and turn it into like a music
metadata IP thing
mmip or something I don't know but yeah
just a suggestion
yes so here's the catalog standard
um and you're talking about cap 19 is
like cross chain assets
in here we have references to other uh
types of assets and so you'll see in
fields like artwork you have a URI and a
mime type which is very normal but then
you also have this nft field which can
link to other nfts and that follows the
cap 19 standard of cross chain so you
can actually link different nfts if like
for example all the nfts I just made
from Sagrado are derivative nfts of an
original nft I did not link the original
nft and that's a downside on me and I'm
going to publicly say that like I could
obviously do better but the standard is
already up to date so that if we want to
link other assets within our nfts we can
and so when we're thinking about
composing nfts is music that's built on
top of stems or music that's built on
top of other music or a remix that's
built on top of music that's built on
top of stems the metadata can link back
to those underlying works so that we can
always be pointing the credit back to
those original users did I miss the
point of your question I heard cap 19
and I wanted to show this
is mainly just
mainly referring to the structure they
have like on GitHub for like organizing
Community like input so I think just
like forking the GitHub they have would
be a great place to start if you were
trying to like start the process of
figuring out how to like you know
just like coordinate between a lot of
people forking their repo seems like a
good place to start just start housing
that information in some place
thank you thank you thank you yeah
that's it we don't have more time so
thank you very much Sweetman
and next up is Andres
and uh we are staying actually in music
and now we are talking about
um the web 3 uh music multiplayer
problems and I'm very excited about that
talk as well
thanks uh
not a lot of experience presenting but
um
here we are so we started off a few
months ago a
in the whatever music Dao researching
about splits and um
we basically got two three main
conclusions some of them are very
obvious some probably not that much one
is that a blockchains can serve as a a
login as a log of information and
hopefully look into the future even like
a global jurisdiction notary system
with a legal validation
the second one is that a blockchains
have uh the the abduction architecture
is based on a single a singular point of
a connection or entry
for the user and the third one is that a
split protocols as we understand them in
blockchain are focused on distribution
of funds but us creators think about
splits more on ownership than really a
about it being a financial
so what is the problem
the problem is copyright right we all
know it's
the problem and it is the solution and
copyright law has been used and has been
abused uh but it's still
the only a
or the or the most widely used form of
monetization of intellectual property
right and if we're looking to the Future
where each time we have less and less a
jobs available we have a growing Creator
class we need to keep copyright as one
of those essential ways of monetization
for creators and
the the copyright industry is big is
played with with problems but to narrow
them down it is mainly a human problem
like it always is and it is that people
do not register their intellectual
property as close to the moment of
Genesis as possible which is
actually the
the best way to protect intellectual
property and um
so and this is maybe because creators
think that registering or then speaking
about legal aspects in the moment of
creation kills the Bible so uh
that actually gives birth to a lot of
problems I like I've been up you know
like I've had problems with uh
um processes in which I have been in the
studio I'm a music producer so I have
been in a studio uh We've made a hit
song everybody is super excited right
the process as it is done it is that um
at least in music creators get together
in a studio and uh they songwrite they
beat make they record and then they they
bounce off the audio program which is a
a WAV file or an MP3
and then that MP3 gets shared among the
the co-creators and it's either emailed
to us or it's uh WhatsApp and we can
listen to the music or what we made and
vibe to it and uh
hopefully the next day know if what we
did was whack or if it's a hit record
right
um
so
personally I have been in those
situations and I have been muscled out
or cut out of hit records because the
more Savvy people will head out and
register the the copyright of the song
and this is a story that kind of like
repeats itself endlessly in um in music
making so what would the ideal process
be
the ideal process would be would be to
register
to have a mechanism to register the IP
as
soon as possible Right in a nutshell a
in a nutshell it would protect the
creators and hopefully
in consensus
be able to register this IP in consensus
right so
we
have a solution right we have temp
temporarily called it a copyright wallet
and a copyright wallet
it allows it's a tool basically it's a
tool that is inserted in the job to be
done it's a you know like a small sharp
tool that is inserted in a job CB Dom
process and it allows for in multiplayer
mode deploying
uh registry
time stamping a registry on the
blockchain of that intellectual property
so
this is the sign coming from a musician
right but in essence what it is is a
an application an extension an extension
app
that would uh register the title of the
song let's say in this case
the ownership splits of the participants
and a mechanism to drag
and drop the media
the same way the uh
uh a a chat with you know like have
access to to listening to a voicemail or
or a shared audio the mobile wallets of
the participants would receive that
audio and they will receive a
notification too
accept or deny
their participation in the in the in
that creative process and if there is
consensus then a smart contract is
deployed
and the non-transferable nft is minted
as registry
so and before we go to Future iterations
I would like to obviously uh I think
this is time better spent if we if we
open up a discussions because I mean
this could be a a tool that obviously
expand and is composed on but I would
like to basically just open the floor to
questions to see if uh if uh
if we can get to a technical solution
because the question that like the
questions that we have is in the main
question we have is does this really
need to be a wallet or can it be
a
can it be a built in a simpler way
so thank you Andres
um do we have questions feedback raise
your hand please yes
see you
thanks
um maybe we could go back to the
previous slide I just had a question
about like what you're saying in
ownership splits and it's kind of
related to what you were saying where
like ownership splits are more than just
like who's getting what percentage of
like mint revenue or something like that
it's much more so when you're in that
top left corner when you say ownership
splits are you already like envisioning
this like breaking down into like
mechanical and like publishing royalties
or are you trying to not necessarily be
skeuomorphic and instead do other types
of ownership splits or what's what's the
idea here I guess a greater question
that just how much of the current music
industry are we trying to recreate on
Chain versus maybe moving to stuff
that's better in some way not that I
even know that's better but yeah
yeah that's a good question and and the
answer would be a either we
um one of two answers it
I'm guessing the the Dynamics uh the
current Dynamics are more of like you
songwrite and you fixate on a on a
recording immediately right just because
the tools are available so people are
not writing songs with their guitar but
they just fixed like they just record
them immediately and that is just
because we have the tools to do it uh
unlike before we used to like Write
Sheet Music or or write song there a
lyrics on paper
uh so but the but I guess the
the answer to that would be we could
either do two Registries or just split
uh percentages because at the same time
you know like writing and mastering is
basically a master like or like
recording is
like a 50 50 Endeavor right so
we could um split from just one big
chunk of 100 of ownership or
mint you know specifics
any more feedback we have more time yes
so is is the biggest reason we want it
to be a wallet so that we can have that
kind of signature based approval like
like the question from Dan in the last
talk of um
deciding when the metadata would get to
be updated or if a piece of work can be
included into a movie or if the rights
could be included like you have that
signature step from each of the
participants is that the reason kind of
thinking of it as a wallet or what
what's the reason uh to have a wallet be
the mechanism for controlling the rights
so that is one reason and the other
reason is and this is very personal you
know like looking into the future what I
think that would happen or would would
happen or would make sense if it would
happen is that this contract is like the
master contract of all the IP that is
derivative from this original registry
so from this original registry and we
spoke about it briefly on Twitter uh we
could also have some form of progress
nfts where everybody is for example we
go into the studio and then we
somebody's gonna come and feature a song
right that it was not he was not or she
was not in the studio in the on the
first day of the recording then there's
a way of tracking the progress of the
intellectual property obviously you
could go like even deeper with a Content
ID
mechanisms and whatnot but but I think
that this smart contract
would probably evolve to be like the
master contract where you would mint
the one of one of the song or the 10
editions of uh the the video and all the
derivative works and the cruel the value
in one contract basically
hey
um
something I'm very interested in is
easing time as a constraint to force
kind of consensus between a group
um and this feels like it could be quite
a good that could be quite interesting
to bring into this
that I actually wrote something about
this thing like February or something
um about making multi-seq wallets in a
similar sort of way but when I was when
I did that design I was I proposed that
you have like a time period that can be
defined in which data can change and at
that point it's finalized and boom it
goes and that's that
how do you feel about that in terms of
like the this workflow like
um you know do you see that you've got
multiple parties kind of
putting their information in do you
think that should be locked down at
certain point or how are you thinking
about time as a concept within uh within
this kind of a formalization
I think Dan I think the the ideal
scenario is that creatives get agree on
percentages of ownership immediately
I wish you right yeah
we wish but if the tool is available
that might be an incentive right and if
we
fulfill the promise of value through
these a specific type of um
a creative product then we might be able
to take it a step further because right
you know like 20 years ago split like
splits were non-existent basically
Publishers and record labels were the
ones actually doing the paperwork but it
has evolved in the creative mind that
they own their their their creation said
that they want to be a part of split so
more and more you see like producers and
artists and songwriters be like okay
like let's you know like let's show me
the splits right or let's negotiate the
splits hopefully as soon as possible and
this is kind of just like inserting it
in that moment of you bounce the song
you share it is there consensus how do
we how are we you know like splitting
the ownership of this let's log it on
the blockchain and um
and it should serve as a proof of work
in case there's like legal challenges on
on on the process
uh yeah I have a question so I
understand this
um or I my mind tries to abstract this
like
um the concept of self-sovereignty in
intellectual property but then I see
this like
conflict between the existing structures
and the structures the social structures
basically and standards that would have
to evolve If This Were to actually come
and have any chance at becoming like the
dominant form of of um you know managing
um creative IP I'm wondering how you see
like the end game of this playing out
how how can this actually
um went out over the structures that we
have right now which are very strong
power structures
well the
the grand idea would be to finally have
a global copyright database
right if that makes sense it has been
tried several times I know a lot of
people are accepted into that or I don't
know if it if it even it's a good idea
but
um
but there has been efforts in you know
like like just sharing the information
but the power struggle between
Corporation makes it makes it impossible
right they don't want to uh just um
have that be one entity and um and
that's that and that's where the efforts
have died
is it good or is it bad I don't know I
mean a
probably haven't thought about the the
the consequences but just transparency
on data I think should be publicly
available and should be
um you know like uh just like a public
good
last question
thank you
um are these splits renegotiatable at a
certain period after a set time
um what does that look like what's the
current kind of discourse regarding that
yes so copyright law actually states
that you're right
in of on an idea is immutable nobody can
take that away from you so a hypnosis
can buy the the Bruce Springsteen
catalog but you know like Merk could
never say he sang those songs right even
though he he owns the financial
exploitation of of the IP so and that's
like a like maybe a super example but
having the possibility of making you
like the immutable having the immutable
record of you were there even though you
might see the financial retribution of
that IP you have the right to be
credited as the author
thank you thank you Andre
thank you for the talk
I think I really liked what you there
was like this one quote that you said
like copyright is immutable that uh it's
definitely something I think we can uh
probably all take home and think about
for a while uh next up is uh Ian
and Ian is going to talk about rich
content type types in nfts
and yeah if you are new here basically
what we are doing is the ERC lightning
talks we are the East magicians and we
are talking about ethereum requests for
comments proposals so not the core Dev
consensus layer stuff but the solidity
interfaces application
um
like these standards
um yeah so thanks for having me Tim it
was wild we met at youth Berlin a while
back and see you back in the space yeah
um I'm gonna give a quick talk on
canonical media and EIP content type so
the notes are basically I'm just going
to flip through Json and talk about it
uh the notes in Json are on GitHub if
you have questions beyond the talk or
you're watching it recorded make a
GitHub issue probably the easiest way to
respond and I'm just going to open a
conversation about kind of what we've
done previously as an organization at
Zora What I've Done personally for
certain nft projects and rendering so if
you go to the original EIP 721 the
metadata scheme is pretty lightweight
you have a name description and image it
was designed an era of crypto punks
cryptokitties where you tracked
ownership and the image just kind of
showed a cute item or like the thing and
then that became more and more important
with time I think it was left pretty
open-ended for people to build out from
here and I do like that idea of a very
minimal standard and then people can run
with it but I think at some point that
standard can also be improved so
an example is and I've had co-workers
ask me this all the time most recently
somebody asked how do I made a
presentation
and the easiest thing to do would be to
export your keynote or figma as a PDF
and then mint it right well
unfortunately the metadata standard just
says image so what people have done
openc kind of added animation URL to
show an animation which could be a web
page gltf audio a bunch of random grab
bag of content and the great part about
an image is if you want to render it as
a consumer you just pop it into an HTML
image tag or you put an image viewer
images are pretty well defined on how to
render animations get a lot more complex
what we could do is we could convert the
presentation into an HTML viewer and
upload the HTML viewer that becomes
pretty cumbersome and a little bit
difficult because the original content
is the PDF it's not the HTML viewer
and the way Zora approached this with
the Zora protocol in 2020 that I didn't
really work on that was before my time
was to separate this concept of metadata
and content content was one thing
metadata was another and the idea here
is that the nft represents you own a
particular ID and that particular ID
represents a canonical off-chain content
so I highly recommended to use ipfs
which is decentralized distribution
layer but as a future proofing also used
a hash function shot 256 which fits
really well into a standard solidity
data type
the Azora core v0 solidity has a
function for the token URI which is not
the metadata as the standard defines it
breaks the standard but is actually the
canonical content so if we were to Mint
a presentation it would be the PDF and
then the metadata is defined also
incredibly simply as name description
mime type inversion the mime type is
useful for rendering as I said you need
to have some idea of what you're going
to render before and fetching it from
the server just to figure out what the
mime type is is a little bit frustrating
so this here calls the token URI it
returns a ipfs file
and then here that file is just text of
these two icons
the token metadata URI is name
description mine type textplane so that
tells the Zora platform to render a text
plane image of that per text plane of
that nft and I don't think there have
been a lot of platforms that support
this so when you try to look at an open
C good luck
um and that brings me to my next point
of thinking about going back in
Computing history of what people have
done to solve this problem this is a
multi-part form data it's used for email
kind of and used when you upload files
in a classic web form it has content
type and it has a certain set of
attachments you can kind of think of
this as an email attachment so I think
having content type is quite important
content like maybe we can talk about
that a little bit later and then the
body of that exact content
here you have an example
um sorry got out of weight
so an example of what we could do is add
a new field to the metadata standard
either through a secondary proposal
mechanism or the EIP standard that
represents what we just talked about and
there's a lot of details here to unpack
so one of them is maybe you'll want to
include the content directly should it
be body or should it be encoded in a
data URI in that case the content type
is redundant but when you have an
external pinned file you really want
that content type for rendering it just
makes life so much easier from a
platform and indexing standpoint if you
have a really obscure file type let's
say somebody loves to upload Illustrator
files you could use an indexer to find
every illustrator file with a very
simple content standard
and I think the idea here is you have a
token ID represented by a file and the
metadata describes that file is but that
file when you need to have a file with
your nft is the highest resolution the
most
um
the highest resolution the most
well-known version of that an example is
Zora was brought on to work with
the Warhol Foundation to Mint one of the
original computer nfts and it was made
on an Amiga with a beta version of
software an art collector is really
frustrated that the nft was a tiff file
but it was built with the Zora protocol
meaning it did support Tiff files
however nobody else did so what we had
to end up doing is use the external URL
which is an openc extension to link to
something to link to the Tiff and then
switch the image URI to become a PNG
that renders everywhere and this is
after back and forth with
conservationist and with different
protocols as to what they expect the nft
to be now if we were to use the content
standard we could Define the image that
renders as a preview with ipfs and then
we could use the Amica mime type or just
a binary blob with some notes around it
in the description to refer to the
original media and I think that would
help
conservationists feel better that the
nft is representing what it really
represents and not needed to be
converted into a new format to be an nft
and a second example of this is mirror
so if you were to Mint a mirror
Marketplace essay this is what it shows
it just shows a cover image of the text
of the title a description which is a
link to mirror and that's it I think
there might be like the author
information in the properties
but
it would be really cool if quixotic has
a relationship with mirror and they
could download the canonical markdown
file and start rendering it on their
site or at least say hey there's a
canonical markdown file associated with
this and like GitHub it would just open
a markdown viewer if it understood it
and we can take a look at the Json here
so if mirror currently what they have is
they have a Content field and it goes to
an are we file which is a custom content
type they've defined it's quite and Rich
has a lot of information but it has the
body the author information signature
information and stuff they use to run
their platform
is is if we're coming at this from a
perspective of an indexer
this is not very helpful we could try to
expand that content field but that could
be any file type as I said before it
could be some binary blob or it actually
could be useful Json so if it's defined
as Json or maybe an extension to Json
you could use that but the ID here is
would be the markdown and if Mirror Has
extra information they could use their
own fields to refer to that information
within the content file or outside
there's a way you can actually add Json
headers to markdown files so you know
the file itself is an abstraction is
really powerful in this case
but if you were to rewrite this using
content you could use text markdown and
then quixotic could easily parse that
not just for mirror but from Zora tools
if somebody were to Mint a markdown file
and this has happened before when
Matthew ball wanted to Mint his original
metaverse essay on Zora
but we wanted compatibility with more
marketplaces and we wanted parts of the
metadata to be fully on chain
the solidity contract renders the
metadata Json on chain but it links to
an HTML file of the markdown content
because that's what animation URL
supports so we're having to change the
media type into something that fits
within an nft
an easy way to avoid that and also if
you look at an open C it doesn't
properly parse an animation URI with an
ipfs colon slash right now but you can
see the metadata is getting loaded in
but the essay experience being a tiny
box is really frustrating and links
don't work for security reasons here
it's slightly better but also links
don't work due to security reasons the
sandboxing on an iframe is actually
pretty difficult to work with If This
Were A markdown file you could just run
it through whatever markdown renderer or
even provide a link and just show the
preview image associated with the nft
a final example of this is the dead
ringers
um it is a part of the Ringer's art
blocks collection and it is a follow-up
limited time Edition where funds went to
charity and it was a very large SVG
megabytes and megabytes SVG
and I believe manifold helped with the
mint and the original
file for image was an SVG
but that SVG
broke wallets and people were not happy
because an SVG is text and for you to
encode text you actually have to turn
the SVG into some sort of bitmap format
and then convert it again and resize it
so it's really difficult to resize in
SVG and most marketplaces pass through
the SVG but this particular SVG was so
large it started breaking stuff so what
they had to do is they actually had to
update that and change the image to a
PNG that did render well but it was a 12
21 000 by 43 000 pixel PNG which also
caused some problems because
marketplaces taking the PNG or whatever
image file resize it to reasonable size
and display it so what we could do now
with this particular proposed standard
would be to include the optimized image
that renders well within marketplaces
and then have the canonical content be
the super high resolution file the
artist intended so if you own that to
your wish to display it you can then
download that original file and work
with it as you will
and if you were to take the content type
you could then encode the image SVG XML
and then a URI and then optionally
include a sha256 if you're using airweed
that's actually a really nice way of
verifying that the file is what it is
because airweave doesn't use content
addressable hash so the
the link to ipfs for every file is
unique per file but for our weave it's
different so the idea here is the sha256
is a really standard way for a very long
time of verifying that a file matches a
file and can be included in this so
overall
the idea of this proposal is to add in a
Content field and the idea with content
is it's quite simple it doesn't have any
underscores and it's the first time I
think there's going to be some proposal
or thought process around creating
nested structures in the metadata but I
think it's quite useful because content
underscore type content it just doesn't
like we already have Json we can Nest
this
um but type URI shot 256 and potentially
potentially body for those that want to
directly put plain text in but I feel
like a URI encoding is also usually a
fine option I'd love to hear what
different creators of Standards or media
have
another thought was you could have some
sort of attachments Associated say you
have an image that a product you're
selling as an nft and you have a
slideshow I recently worked with the
team to show a product and the slideshow
had five images you could theoretically
include those as attachments in your
um and then that would be rendered as
like a generic attachment on media I
think that's a little out of the scope
for this project though and I would like
to kind of focus on
um
I would like to focus on this idea of a
single canonical file instead of a set
of files because it makes sense to have
a single file and a single nft ID relate
to each other and to not really focus on
banners and colors and multiple sizes
kind of on the side of open graph where
you have this media how do you render it
well on a Marketplace or in another
context I think that's out of scope for
this particular Focus
um
and the meaning of canonicals to have a
standard or primary authoritative body
on a subject so the URL is the
authoritative idea of what that nft is
and it's left up to interpretation of
the Creator or the platform to figure
out how to best Express that and use it
my open questions are should this be an
EIP within The ethereum Magicians group
chat that's a pretty widely debated
topic of metadata is included in the
original proposal but it's not really
defined beyond that and it's defined
quite Loosely so one thing I like to do
is try to stick to proposals and I'll
typically use the Key Properties instead
of
whatever has been defined otherwise
because it's in the 1155 spec but I am
mixing the 1155 spec with the 720 ones
back
the non yet and then multiple files just
an open question
so I'm going to wrap up if you're
interested in asking questions from the
recording or want to continue the
discussion
um I have a GitHub of these files and
this is my Twitter
and zoom in a little bit
and then the one last thing is there was
an on-chain version of this EIP content
type that used mime content URI and hash
and this is kind of the inspiration for
the off chain version of this proposal
Unchained ideas if you have dynamically
generated SVG it's more composable it's
easier just to return a struct but I
think now kind of working on more
projects and finding more examples the
off chain example is more compelling and
you can still generate a Json blob on
chain including the content field so it
kind of works both ways I just think
this is a better start to the approach a
way to approach this project then
including a new getter function as an
EIP within the solidity world this is
all off-chain metadata we're talking
about
I have a little bit of time so be glad
to open it up for questions yes thank
you Ian thank you round of applause
[Applause]
we have one question
hi I'm Marcus nice to meet you um if
this was implemented as an EIP what do
you think the second and third order
effects of this would be
I hope the very first
um thing is indexers
Pro platforms would include it in
minting so manifold actually does really
try hard to include a lot of metadata
they do image image underscore URL image
includes the hash and the URL and the
content type and some other data so I
think kind of thinking with them to
figure out what their needs are but once
you start having stuff minted in this
format I think it's going to hit
indexers and then once indexers can
understand this people can say oh I can
upload Illustrator files I can upload
webgl shaders I can upload some binary
form like you can actually now mint a
solidity contract and when somebody buys
it they'll feel more assured that
they're actually buying a solidity
contract rather than somebody sit or the
file of a selected contract rather than
somebody saying oh here is a solidity
contract and what I typically have
advised creators to do is actually
explain it and link in the description
the ipfs URL of the canonical media it's
Packy but it seems to have worked and
that would kind of remove that and allow
for use users to see like a link and
I've seen artists on Twitter talking
about using unlockable media and open C
to include the source files and if the
artist is comfortable they could just
include the source files and it would be
a link or some sort of description on
Plat marketplaces and since this is
relatively easy to implement once a few
start I think it would start spreading
thank you we have another one here
hi hello congrats for the project
um so content type is a response header
an attp right
thinking about you know the second order
effects have you thought or worked on
the request headers equivalent like the
accept and then having some specific
wild cards such as Text slash and then
wildcard
so the one problem when you're indexing
is that a lot of times ipfs is really
slow people's servers go down if you're
able to get the metadata on the client a
lot of people hot link directly to an
ipfs Gateway and pulling the content
type out of the headers really allows
for a better set of expectations when
you're indexing and rendering the nft
but your question is to kind of use the
HTTP response conversation to define the
Mind type rather than put it in the
metadata yeah sure so there is the
content negotiation step right so and
then you have from the accept
request header and
more often you have like some sort of
wild card there right so that can help
uh you know more generic applications to
accept let's say image slash column uh
wildcard something so I think a lot of
the off off-chain nfts go through a
decentralized Gateway provider and those
Gateway providers are not very like
you're out the control of the server
retrieving decentralized media is out of
the control of the user in most cases so
you can't rely on a server negotiation
you're thinking of a world maybe where
there's a server that is connected to
the URI of the nft and that's becoming a
lot less common because that means
you're now having a centralized point of
failure so the idea here is if you put
it in the Json there'll at least be some
intentionality if you're on some weird
version of ipfs like node that doesn't
understand the media it's serving or
there's a bug in it you'll still have
something that kind of works or have an
expectation of what the original
intention was
thank you do we have more questions
maybe one last question
okay otherwise ah yes okay
we have fun
you hear you define the um content type
inside the Json
um to like save some uploads could you
define the data in the collection as
well
that's actually a great question that I
didn't have time to address but mirror
and Zora and a few other platforms have
editions and I think utilizing a
singular nft metadata in the contract
URI which is an openc extension is a
really effective way to handle that and
right now I know most platforms that do
additions support the contract URI so
for dead ringers and for
Zora editions the contract URI is
actually generated on chain and
sometimes we'll put an ipfs depending on
how big the content is and that includes
image it includes animation if every
single thing in the collection is the
same and we use that internally in our
infrastructure to give a preview if
there's no mints yet or like what that
whole collection's supposed to be
there's no standard around it but this
would also slot quite well within the
contract metadata if you wanted to have
a canonical contract
um content field it should just work
thank you Ian Round of Applause thank
you very much
thank you everybody
next up is Francisco from
openc thank you which is gonna speak
about EIP
5267 and I have been saying the entire
time that it's a it's about the domain
separator so yeah okay gladly
um yeah so sorry we're gonna move on
from nfts now um it's going to be about
erc20s which are boring now but okay
um I'm correction I'm not from openc I
work at open Zeppelin uh maintain and
develop open sampling contracts which
obviously maintains many ERC
implementations and so this is a really
important topic to me
um
so this eib that I'm going to be talking
about is really quite tiny
um but I want to use it more as an
excuse maybe to talk about the process
of building an EIP and what the kind of
steps that I think uh one should follow
so because like eip1 which it's not here
but maybe you've all seen it kind of
defines the series of stages like draft
review last call and final but it
doesn't really say what should happen in
each of those stages so I want to share
how I personally I'm thinking about that
as I develop an EIP
so the problem at hand here is the erc20
permits anyone that has used a amm a
decentralized exchange before knows that
in order to do a token exchange you need
to approve first and then transfer and
this EIP permit
is one way of foregoing the initial
approved transaction and replacing it
with a signature that allows you to
allows you to do it all in just one
transaction by just including the
signature in the first transaction
so
this saves gas it is one less
transactions and it uses the signature
instead but it's kind of weird if you
use an exchange or an aggregator you
don't really see this being used very
often um I think uh main maybe it's just
for like usdc uh exchanges supported but
there are many other tokens that have
this and don't so the question that was
in the back of my mind is like why is
this why is that so weird so
the this EIP underneath uses uh this
other EIP 712
which is a special kind of signature
um it's a signature not of a blob which
is what we see uh often uh most most
usually but of a kind of typed data
structure so it's kind of important
because it allows you to give more
structure to it in the case of permit
you will include the amount that you're
allowing
um you will include and expires uh
timestamp and a nouns and so on and this
is an important uh standard because
wallets can Implement support for it and
show this structured data to the user in
a nice way one of the important things
in these EAP
is the notion of a domains so when you
make an approval for say usdc you don't
want an attacker to take that signature
and kind of send it to die right you
don't want an attacker to reuse the
signature in a different domain so every
signature has this domain separator
inside of it that makes sure that the
signature is only valid in one domain so
this is the
um right so the decentralized exchange
has no way of knowing
um given some arbitrary token what
domain they want to use
um and I think
yeah I think that is the reason why this
hasn't been really adopted so you will
see that
um the erc20 permit ERC defines a getter
that gives you the hash but really the
712 RPC endpoint requires the entire
domain object and there is really no way
to find it here so this is where
eip5267 comes in
um now
we will see now it's a very simple
function that literally just allows you
to obtain the domain this is the domain
object that you will need to pass into
the 712 sign RPC call and and as you can
see like it's extremely simple now
what was also at the back of my mind is
that this was this is not also a failure
of the spec uh 12 2612 so permit but it
was also in a way of failure of the
process because if the 2612 authors had
kind of gone all the way and kind of
talked to decentralized exchanges and
thought through uh what it would entail
to adopt that they would have realized
that this was missing so I didn't only
want to tackle the technical problem
here but also think about
how can I uh carry out the process for
the CIP to make sure and other erc's to
make sure that the sort of failure of
the process doesn't present itself
so the question is how do we get this
now which is in a review stage how do we
get it now to final what needs to happen
in order to get it to final so some of
the things that I've done
um and that I would recommend you all do
when you build your VIPs
um so you should reach out to all
interested parties and like applications
and companies and uh projects that you
think will be using this and really you
should be kind of bothering them to give
you feedback to look at it and give you
feedback so I've reached out to uh one
inch and unit Swap and kind of seen try
to get from them is this useful to you
would it does this solve a real problem
from for you
um and generally the answer in this case
has been yes
um in the ethereum magician threat
there's also been a couple of
interesting comments and common
questions I have taken some of the
questions and documented them as part of
the EIP as well and also some concerns
that have arised uh
so many of those concerns in the case of
this eifb were about the
backwards compatibility uh
section which is here but um
most of the discussion of The ethereum
Magicians threat made me realize that
even though I wrote this section kind of
thought about it there really are many
more unanswered questions so I wanted to
do some more work to figure out the real
backward compatibility story so another
another thing that I've started doing
which I think is a really good exercise
is to implement it and not only like the
solidity part of it but also the many
parts of the stack again so I've just
uh started this EI uh repository with
the implementation and most importantly
a little app which is just a front-end
app which is what I imagine
that a the central X exchange will kind
of be doing behind the scenes and here
I'm putting myself in the shoes of
I am the UI for one inch and this is
what I'm going to be doing and just kind
of really figuring out if it works if I
can actually produce the signatures that
they will need to produce and also
to use this to figure out the backwards
compatibility story and I still need to
develop this a little bit further but
I'm hoping that I'm going to come up
with a good and kind of uh comprehensive
answer then I can then go back in the
EIP and document it there
to make sure that it really answers the
concerns
that were raised in The ethereum
Magicians thread so
I think uh yeah that's it again it was
very quick but these are some of the um
things that I've been experimenting with
in order to get this to a final stage I
think uh there are we see many eaps that
take more of a fast track and get to a
final stage which is you know it's
better in a way because we know that
these processes can be long and it's
really annoying but um
then you get to a final stage and it
doesn't necessarily mean anything if it
hasn't been thoroughly tested and then
you're really going to run into some
issues when say open Zeppelin implements
it and people start deploying it and you
realize oh this this isn't really
enough
um so um then you need to start thinking
about like a follow-up EIP and it's all
uh really much more complicated than it
should be if we do things better before
we get to a final stage so anyway those
are some of my ideas thank you
um happy Tuesday questions if any yes
thank you very much
do we have questions yes
hey really cool uh first uh comment it
reminds me of uh like the Amazon six
page written narrative way of you have
to like sharpen your point or your case
and then you go around and get feedback
from people and then incorporate that in
a fact at the end of the document to
like because you know other people have
those concerns or objections so that's
really awesome
um do you can you just speak a little
bit more about that process and how
you've followed up with people maybe on
this one or something in the past so
it's one thing for somebody to
say it looks great maybe give some
feedback on The ethereum Magician's post
but really an eip's success or failure
is like people using it like you just
spoke to so have you have a good example
of like following back up with protocols
and actually getting them to implement
the EIP as part of your uh kind of Biz
Dev work if you call it yeah so uh good
question I haven't thought about that
too much yet
um but
um one of the things that I I personally
struggle with is that I feel like I'm in
a bit of a conflict of interest position
because of being on opens up and
contracts maintainer it's like it's
going to be really easy for me to put
this in the contract and make people use
it but I don't want to force it down
people so for example one thing that I
uh could do and now that I'm thinking
about I think it will be a great idea is
to talk to this one-inch developer that
I talked about and maybe uh
try to get them to to walk me through do
they really see do they like really see
themselves implementing this and maybe
what is the timeline
um and kind of yeah just trying to get
more concrete data on on their plans and
try to try to get them to commit
um maybe that's what I I would do
thank you uh more questions feedback
maybe uh people that have used this or
or 712
raise your hand if you have a question
okay then thank you very much Francisco
Round of Applause thank you thank you
yeah and that's essentially it that was
the ERC lightning talks from The
Magicians I hope you all liked it
um you can find each and everyone
hopefully uh on the East magician's
forum and I'm looking forward to all of
the posts that are coming out of these
discussions I'm I want to thank you all
for participating uh like so much in
this conversation and I I really
appreciate that we were having like a
back and forth between the audience and
uh and the presenters and so on and yeah
it was great to be able to host this and
yeah thank you very much and see you
around
[Applause]