►
From YouTube: NFT Community Call #4
Description
The fourth NFT Subgraph Community Call took place March 25th.
Join the community and learn more on Discord:
The Graph: https://thegraph.com/discord
The Graph NFTs: https://discord.com/invite/EdZE6EmVKC
A
Hi
everybody
welcome
to
the
fourth
nft
subgraph
call.
We
took
a
a
week
off
last
week
and
we're
back
and
we've
got
a
few
new
people
on
the
call
today.
If
anyone
wants
to
just
give
a
shout
out
and
share
either
about
their
company
or
what
they're
working
on,
we
can
do
a
round
of
intros.
If
there's
there's
anybody
new.
A
B
A
All
right
well
yeah,
let's,
let's
jump
in
before,
we
start
just
a
little
house
cleaning.
So
you
know
we've
got
our
housekeeping.
We've
got
this
nft
air
table
set
up.
If
you
don't
have
access
just
you
know,
shoot
me
a
message
and
here
we're
tracking
all
the
different
nfts
that
we
want
to
have
subgroups.
For
so
I
see
that
people
added
a
few
more
and
and
and
if
anyone
has
a
chance
to
go
through
and
just
kind
of
update
the
status
on
any
of
these.
A
A
Big
thing
that
we've
been
focusing
on
in
the
last
few
calls
has
been
standardization,
and
we've
talked
about
a
few
of
these
different
areas
that
we
can
standardize
on.
And
you
know
one
of
the
the
things
that
we
we
discussed
was
how
you
know
for
for
many
of
these
there's
a
difference
between
kind
of
the
erc
standard
for
the
on
chain
data
data
and
what
we're
now
calling
the
grc's
or
which
is
basically
the
the
graph
equivalent
of
standards
at
the
the
sub
graph
level.
A
So
we
had
some
great
discussions
on
the
last
call
and
I
think
we
can
just
jump
straight
into
it
to
go
over
some
of
the
proposed
standards.
For
you
know
the
the
contracts
data,
the
nft
data-
and
you
know
this
ever-growing
metadata
field
to
see.
If
you
know
we
can
get
some
alignment
on
on
some
of
these
fields
so
and
see,
I
know
the
the
foundation
team
did
some
some
great
work
on
this
since
the
last
call,
and
would
you
guys
want
to
kick
that
off.
D
So
I
think
here
we
we
have
a
subgraph
entity
for
what
a
contract
should
look
like
or
when
an
nft
should
look
like
and
we've
delineated.
You
know
just
what
lives
on
the
contract
itself,
so
the
name
and
symbol.
Those
are
not
necessarily
nft
specific
things,
but
like
are
more
attributes
of
the
contract
and
then
for
the
nft,
we're
saying:
okay,
the
creator
should
be
an
account.
There
should
be
a
creator
fee,
that's
self-reported,
and
that
could
be
a
fee
entity.
D
We
can
hash
out
as
well,
and
the
metadata
is
is
like
another
thing
that
we
can.
We
can
hash
out,
but
I'd
say,
let's
start
here,
because
I
I
think
we
kind
of
ended
the
last
call
with
general
alignment
that
this
is
the
right
direction,
but
I
would
say:
let's
make
sure
that
this
is
what
we
want,
and
then
we
can
drill
into
each
of
the
entities
that
we
have
not
fleshed
out.
E
D
A
You
know,
I
think
it's
different
than
like
database
tables
or
something
where
you
want
to
have
the
data
normalized.
I
think,
at
the
api
layer.
It
actually
makes
sense
to
have
different
fields
that
are
either
like
computed
data,
or
you
know
things
like
that.
That
you
know
are
just
kind
of
for
convenience
because
that's
that's
part
of
what
you're
able
to
do
at
that
layer
is
kind
of
explode.
The
data
out
and
just
make
sure
that
it's
available
in
the
most
convenient
format
for
for
the
application.
A
Yeah
and-
and
I
just
there
was
a
message
from
hadrian
in
the
chat
saying
you
know:
if
everybody
does
that,
then
all
subgroups
will
have
a
contract
entity
and
it
all
have
different
meanings,
and
so
that's
that's
also
a
fair
point.
So
yeah
it's
it's
a
balance.
You
know,
I
think,
with
any
kind
of
design.
A
A
B
F
I
would
say
another
reason
why
events
data
concatenated
as
an
id
is
very
important
is
because
of
the
constraint
that
you
can
only
load
by
id.
So
if
you
want
to
update
a
given
entity
in
the
middle
of
a
handler,
you
need
to
be
able
to
fetch
that
id
based
off
of
the
event
information,
and
so,
if
you
know
the
token
id
for
example,
then
you
can
grab
that
nft
entity
and
make
the
necessary
updates
that
you
want.
F
F
A
Yeah
thanks
for
making
it,
I
think
it
it.
It
helps
to
get
everybody.
You
know
in
the
same
virtual
room,
yeah
get
get
to
consensus,
so
cool
like
what
do
we
think
are?
Maybe
the
more
controversial
parts
of
you
know
the
schema
here
and,
and
I
think
people
should
feel
totally
fine
bike
shedding.
You
know,
I
think
you
know
when
you're,
when
you're
trying
to
get
a
feature
out
the
door
bad
time
to
bike
shed
when
when
you've
got
everybody,
you
know
working
towards
standards.
F
E
B
D
I
mean
I'm
imagining.
Let
me
know
this
off
like
a
lot
of
the
stuff
like,
I
think
we
should
drill
into
what
what's
useful
and
then
I
think,
there's
probably
also
a
conversation
like
what's
required
and
what's
optional
right,
so
I
think
for
most
of
us
probably
the
contract
metadata
is
not
that
useful,
but
then
the
nft
metadata
it
is
useful
and
so
at
the
contract
contract
level
like
this
is
probably
optional,
but
then
this
is
probably
required
down
here.
A
B
F
F
Okay,
cool
yeah
like
so
so
we
use
like
we.
We
have
a
couple
of
fields
for
like
when
things
are
created,
so
we
have
like
a
created,
app
block
number
and,
like
I
created
that
time
stamp,
and
then
we
also
have
time
stamps
for
like
when
things
are
burned.
So
I
don't
know
how
many
of
the
contracts
that
are
standardized
are
inherit
the
erc721
burnable
standard,
but
I
think
it's
helpful
to
have
like
any
of
those
like
contract
level.
A
Yeah
now
one
thing
that
we're
going
to
be
working
on
is,
you
know,
I
think
we've
talked
about
both
of
these
features.
One
is
network
subgraphs,
so
like
an
ethereum
subgraph,
where
we're
indexing,
the
raw
like
blocks
transactions
accounts
all
that
kind
of
data
and
then
step
graph
composition,
so
it
it
might
be
that,
ideally,
once
we
get
those
two
features
in
what
we
have
here
is
just
like
a
reference
to
an
actual
like
block
or
transaction
entity.
D
D
B
A
B
D
So
couple
couple
directions:
I
think
we
can
take
this.
I
think
meta
nft
metadata
is
a
big
hairy
one.
So
maybe
we
save
that
for
later,
but,
like
a
transfer
event,
I
think
is
pretty
straightforward.
Sale
event.
I
know
there's
been
concern
over
before
in
terms
of
just
like
how
how
standard
it
is
across
all
nfts.
Do
we
want
to
chat
about
sale
event
first
and
then
go
into
the
metadata.
F
Yeah,
I
I
saw
a
proposal
that
I
thought
was
really
interesting
about
like
having
a
notion
of
like
general
fee
recipients.
I
I
don't
know
how
that
conversation
went
last
time,
but
I
can
speak
selfishly
in
zorah,
there's
more
than
just
a
a
buyer
and
a
seller.
There
are
actually
multiple
entities,
potentially
that
can
receive
or
be
the
recipients
of
a
successful
sale.
F
A
F
Yeah,
so
in
azura
nft
there
are
three
participants:
there's
an
owner,
so
the
current
owner
of
the
nft
there's
the
creator,
and
then
there
is
this
notion
of
the
previous
owner,
and
so
in
the
contracts
in
storage.
There
is
like
bid
shares
or
what
we
call
the
shares
of
the
sale
for
all
of
those
participants.
F
The
creator
and
the
owner
are
like
obligatory
and
the
previous
owner
is,
depending
on
the
like
the
providence
of
the
nft,
and
so
whenever
a
sale
is
is
finalized
before,
like
as
a
part
of
the
finalization
of
a
sale,
it
like
will
split
the
sale
up
into
the
necessary
shares
for
each
individual
entity
and
transfer
to
each
entity.
Discreetly,.
A
F
Ooh
and
like
an
azura
nft
is
composed
of
multiple
sale
events,
and
I
think
this
is
also
nice
for,
like
a
regular
nft
sale
where
there's
an
owner
and
a
creator
as
well,
where
it's
composed
of
two
different
sale
events
right
and
maybe
maybe
the
fields
can
be
more
generalized.
It's
not
like
buyer
and
seller,
but,
like
I
don't
know,
recipient
and.
F
E
D
I
wonder
if
there's
something
we
could
do
with
the
id
the
id
so
there's
couple
groupings
already
built
in
right.
We
have
the
the
web,
the
block
and
we
have
a
transaction.
We
have
the
hash
transaction
hash,
and
so
maybe
like
I'm
in
favor
of
like
turning
this
into
like
an
interface
and
basically
like
most
people
would
just
use
the
vanilla
cell
event.
But
then,
if
you're,
if
you
are
building
things
that
are,
that
have
a
little
more
functionality
than
what
what
you
can
do.
D
For
example,
like
breakfast,
I
think
for
zora.
You
could
probably
just
have
the
same
transaction
hash
just
happens
to
have
multiple
events
and
you're
just
reporting
each
of
those
events
separately
and
then,
if
you're
needing
more
fields,
you
can
extend
the
sale
event.
Interface
to
add
those
fields
for
your
xor
specific
sale
events.
But
then
everybody
else
will,
like
consumers,
will
be
able
to
just
walk
through
all
cell
events
and
not
have
to
know
the
underlying
implementation.
A
D
We,
I
think
I
I
think
majority
of
nfts
will
probably
just
have
like
buyer
and
seller,
but
then
I
think
for,
for
example,
for
the
zora
case.
This
is
where
maybe
you
can
add
a
field.
That's
like
the
previous
owner
or
something
like
that,
and
then
you
leave
one
of
these
fields.
Blank
and-
and
then
I
think
at
that
point
it'd
be
a
conversation
between
like
zora
and
whoever's
consuming,
there's
a
graph
on
like
how
to
interpret
that.
A
D
D
That
goes
to
creator,
and
that
could
be
his
own
event
and
we
don't
have
to
lump
into
sale,
because
I
think
the
sale
event,
if
I'm
understanding
correctly
for
for
platforms,
say
like
for
upshot
for
whoever
you
guys
are
probably
using
this
to
figure
out
like
when
the
entity
changes
hands
right.
So
I
don't
want
to
pollute
that
with
too
much
metadata
with
too
much
data.
D
C
Is
the
thinking
of
putting
a
royalty
in
every
event
that,
like
even
if
creator
fee,
is
global
for
the
contract
or
global
for
a
particular
creator
that
it
might
be
updatable,
so
you'll
want
the
historical
record
of
like
if
it
was
updated
for
past
events,
what
the
fee
was
at
the
time?
I
think
I
think
that
makes
sense.
If
that's
what
the
thinking
is.
F
F
F
F
Cinderworks
and
then
maybe
another
thing
is
like
the
currency,
I
I
don't
know
this
is
another
net,
and
this
is
another
specific
thing
for
zora,
but
we
accept
bids
in
any
currency
and
so
generally,
whenever
we
use
amounts.
We
also
like
are
explicit
in
the
currency
field
and
I
imagine,
as
erc
721
evolves.
More
contracts
will
also-
or
you
know,
market
contracts
will
accept
bids
and
you
know
transfers
and
stuff
in
arbitrary
currencies.
So
we
might
want
to
add
that
as
well.
C
A
This
is
another
one
where,
where
I'd
love
to
have
like
a
separate
sub
graph,
you
know
with
entities
for
like
you
know,
I
don't
know
if
it'd
be
tokens
or
coins
or
assets.
I
guess
I
guess
it'd
be
assets,
and
then
you
could
just
reference
like
the
the
asset
across
subgraphs
like,
like
you
know,
we
mentioned
with
with
the
block
eventually.
D
D
F
Yeah
and
then
that
way
we
can
easily
move
into
like
an
actual
currency
entity,
that's
provided
by
the
graph
in
a
future
date.
Right,
I
know
unit
swap
does
something
similar
where
they
actually
like,
pull
in
all
the
native
fields.
So
they'll
fetch
like
pertinent
data
from
the
erc20
contracts,
things
like
the
symbol,
the
decimals
etc,
but
it
sounds
like
we
don't
need
to
do
any
of
that
stuff.
D
B
D
D
C
G
F
I
think
the
same
thing
I
don't
know
if
this
comment
already
exists,
but
the
block,
hash
and
timestamp
things.
It
might
honestly
be
nice
to
standardize
it
across
all
things
that
we
save
it
on
it's
just
like
this
is
these.
Are
the
these?
Are
all
the
block
information
that
this
that
this
event
was
created
at
so
like?
D
A
A
A
F
D
D
B
I
just
wanted
to
add
that,
as
I
already
said
in
many
of
these
calls,
I
have
a
library
with
tools
that
I
linked
again
in
the
comments,
and
I
already
have
standard
interfaces
for
events
and
transaction
that
kind
of
stuff.
I
don't
think
I
have
something
for
block,
but
I
use
it
none
by
sub
graph,
and
I
invite
you
to
extend
so
here
you
can.
There
is
event
a
transaction
and
both
have
a
cs
file,
and
so
this
is
creating
it
and
you've
got
a.
D
D
Okay,
I
think
I'm
gonna
move
on
to
metadata
and
for
this
one
I'm
actually
gonna
put
sam
on
on
the
and
put
sam
on
to
share,
screen
and
walk
through,
maybe
because
sam's
put
a
lot
of
thought
into
metadata.
Just
because
he's
been
interacting
with
a
lot
of
different
nft
platforms.
So
we'd
love
for
for
him
to
walk
through
his
thinking
and
his
reasoning
and
figure
out
what
we
can
drive
to
alignment
on
as
a.
H
H
Essentially,
I
think,
where
we
landed
on
at
the
end
of
that
conversation
was
following
a
similar
solution.
That
zora
is
good
actually
to
have
breck
on
the
call,
because
a
lot
of
this
was
stemming
from
their
concepts
of
how
they've
created
these
metadata
schemas,
which
I
think
is
a
really
solid
idea.
Moving
forward.
H
The
metadata
schema
using
a
you
know,
json
schema
library
and
then
kind
of
understand
like
what
fields
are
expected
to
be
in
the
metadata.
What
fields
are
obviously
optional
or
mandatory.
I
think
I
don't
think
there's
been
a
huge
amount
built.
On
top
of
this.
I
tried
to
add
some
of
the
feedback
that
I
got
from
last
week
from
the
last
call
that
we
had
into
this
by
adding
like
optional
kind
of
params
into
the
into
these
kind
of
mock
interfaces
or
mock.
Schemas.
H
F
Yeah,
I
so
high
level
thoughts.
I
really
like
the
idea
of
having
a
core
schema
for
like
an
image
type
or
not
internet
shape,
but
a
a
type
of
content
right
now.
Our
schemas
are
definitely
geared
towards
like
platform
specific
metadata
so
like,
if
someone's
building
on
zora-
and
they
have
you
know
like
they're,
an
audio
platform
or
you're
like
a
script,
writing
platform
or
whatever.
You
might
have
your
own
metadata
for
your
own
platform
use
case.
H
Yeah,
I
guess
the
one
thing
that
I'm
definitely
less
familiar
with,
and
we
touched
upon
it
at
the
end
of
the
last
school-
is
how
to
how
this
could
be
incorporated
into
a
graph.
Obviously
one
way
is,
I
guess,
there's
a
few
different
options.
Right,
like
one
way
is,
there
is
a
url
leading
out
to
this,
which
I
guess
is
like
how
some
things
work.
H
Now,
where
you
just
add
in
the
metadata
field
in
the
subgraph,
it
would
just
link
directly
out
to
the
metadata,
and
you
would
have
to
do
like
passing
of
the
schema
and
look
up
and
everything
like
that.
Another
thing
could
be
to
kind
of
like
potentially
stringify
or
just
dump
the
contents
into
the
metadata
field
as
like
a
sub
object.
H
Potentially,
if
that's
even
possible,
I
don't
even
know
if
that's
even
a
thing
that
could
happen
or
stringified
and
the
other
one,
I
guess
would
be
to
kind
of
construct
a
a
kind
of
entity
similar
to
how
the
scheme.graphql,
like
building
our
own
scheme,
based
on
like
a
an
introspected
version
of
the
schema
and
kind
of
like
constructing
it,
either
dynamically
or
ahead
of
time.
But
I'd
definitely
be
open.
A
H
Yeah,
so
I
guess,
if
it's
indexed
purely
I
mean,
I
definitely
think
that,
like
the
subgraph
would
be
one
client,
I
think
really.
The
other
use
cases
are
other
dapps
right
that
are
trying
to
kind
of
like
pull
down
specific
contracts
like.
I
would
have
been
super
helpful,
for
example,
with
like
nfte.app.
H
If
there
was
a
way
that
I
could
have
kind
of
like
gone
ahead
and
pulled
the
schema
which
related
to
some
kind
of
json
schema
remotely
and
then
kind
of
understood
what
I
would
actually
have
access
to
ahead
of
time.
So
in
my
eyes
it's
kind
of
like
any
platform,
that's
trying
to
consolidate
or
trying
to
kind
of
like
aggregate,
multiple
or
just
one
type
of
contract,
because
bear
in
mind
that
these
contract,
these
schemes
could
be
updated
over
time
right.
H
They
could
be
upgraded
to
different
types
of
schemas,
so
one
one
nft
from
a
contract
might
be
might
have
a
different
nft
schema
if
there
is
at
some
point
in
the
future,
like
a
roll
out
of
an
upgrade
and
therefore
like
more
fields
might
be
added
on,
whereas
like
previous
ones
might
not
have
had
it.
I
had
it
so
the
schema
kind
of
changing
throughout
the
lifespan
of
my
ads
nfts
get
minted
could
be
potentially
interesting.
A
Yeah,
you
know,
I
think
all
of
that
could
be
supported
just
natively,
you
know.
So
I
guess
I
guess
here's
here's
my
my
thought
process
and
it
could
go
either
way.
So
I
saw
basically
the
question:
was
you
know
if
we
had
the
stepper
jason
schema?
How
would
it
get
parsed?
Is
it
you
know,
could
could
the
the
the
sub
graph
kind
of
dynamically
generate
the
tables
for
the
fields
and
and
the
subgraph
can't
dynamically
generate
tables?
A
You
know
subgraphs
are
upgradable,
so
you
know
you
can
have
different
versions
of
a
subgraph,
and
you
know
I
don't
know
that
you
can
do
it
today,
but
you
can
imagine
you
know
being
able
to
like
query
for,
like
the
history
of
a
subgraph,
to
get
past
versions,
see
the
past
schemas
things
like
that.
So
I
guess
it's
an
open
question.
F
H
Yeah
I
think
like
as
like
a
bootstrap
there's.
Obviously
you
know
you
know.
Github
is
like
a
straight
away.
I
think
there
is
definitely
I
think,
yeah
there's
a
lot
of
value
in
storing
it
decentralized
to
match
the
whole
rest
of
the
ecosystem,
so
yeah.
I
would
push
for
it
to
be
stored,
decentral,
stored
decentralized
as
well.
Yeah.
A
F
So
so,
how
does
that
work,
if,
like
many
nfts,
can
have
many
types
of
metadata
metadata?
Because
right
like
we're?
Not
it's
not
an
enforceable
thing
at
the
protocol
to
say
that,
like
the
uri
that
this
nft
is
attached
to
must
conform
to
this
schema
so
like
anyone
could
put
in
anything
at
the
uri,
and
the
challenge
that
I
keep,
I
don't
under
fully
understand
is
how
the
subgraph
would
be
able
to
parse
and
store
data
according
to
a
schema
that
it
doesn't
necessarily
know
it
will
conf
like
conform
to
yeah.
I
think
at.
D
A
A
That's
kind
of
like
a
general
philosophical
issue
with
kind
of
structured
versus
unstructured
data
right.
If
the
data
is
unstructured,
then
you
either
have
to
have
that
knowledge
of
the
application
or
you
have
to
do
more
brittle
kind
of
like
you
know,
processing
and
that's
kind
of
the
trade-off,
and
so
in
general
you
know,
I
think,
we're
in
favor
of
structured
data.
A
You
know,
I
think,
like
it
just
makes
things
more
sane,
and
so
you
know,
wherever
you
can
do
things
like,
have
a
field
that
describes
the
type
of
the
metadata
or
something
like
that.
That
then
just
like
allows
it
to
be
a
pretty
like
dry,
deterministic,
parsing
kind
of
process.
That's
an
improvement!
If
you
don't
have
that,
then
you
know
you,
you
can
write
more
brittle
code
that
basically
introspects
it
tries
to
parse
it.
A
D
D
B
Yeah,
where
is
that
same
yeah?
It's
the
same,
schema
that
some
proposed,
but
just
related
to
a
graphql,
schema
having
a
particular
base
metadata
interface
and
having
a
particular
type
for
each
known
madrid.
So
probably
this
is
a
draft.
It's
not
the
final
version.
I
just
posted
to
provide
an
idea
on
that,
hopefully,
for
for
next
meeting,
I
will
share
with
you
a
small
proof's
concept
of
that.
Having
a
couple
of
shades
on
file
is
supporting
different
metadata
and
parsing
it
within
nasograph.
G
So
any
advice
on
structuring
that,
while
conforming
to
standards
and
another
point
that
I
thought
was
pretty
interesting,
but
we've
actually
already
received
requests
for
localization.
So
actually
you
know
supporting
multiple
languages
and
local
characters.
I
know
this
is
slightly
specific,
but
I
think
like,
if
we're
really
going
for
you
know,
scale
and
supporting
a
lot
of
users
having
that
sort
of
support
early
on
might
be
useful.
H
H
But
I
imagine
there
being
like
and
resolutions
again
is
like
a
terrible
name,
but
some
kind
of
key
value
store
where
there's
like
kind
of
like
key
values
of
like
common
or
like
a
group
pre-agreed
upon
different
either
like
resolutions
or
like
sprite
sheets,
or
you
know,
high
definition,
low
definition
like
a
3d
like
you
can
imagine
with
video
like
they
could
be
hdr.
There
could
be
kind
of
like
3d,
like
there's
all
types
of
like
different
core
formats.
That
need
to
be
considered
that
a
video
could
be
available
in.
H
So
I
think,
like
some
kind
of
like
key
mapping
could
go
a
long
way
there,
and
I
think
this
is
where,
like
the
ability
to
compose
and
like
build
upon,
is
kind
of
quite
core
because,
for
example,
like
your
solution
might
have
like
many
different
types
of
formats.
That
are
specific
to
you
in
the
video
realm,
even
in
like
your
video
realm,
compared
to
other
video
kind
of
like
dapps
that
are
out
or
protocols
that
are
kind
of
like
coming
out.
H
G
B
A
Okay,
great
well
we're
getting
towards
the
end
of
time
here
so
yeah.
I
feel
like
the
the
weekly
cadence
feels
like
a
lot
generally.
I
also
know
that
the
nft
space
is
moving
super
fast
and
it
feels
like
we
never
run
out
of
things
to
talk
about,
so
you
know
I'm
for
for
keeping
it.
If
you
guys
are,
I
feel
like
we
can
continue
from
here
next
week,
and
you
know
we
can
try
to
work
on
a
an
agenda
over
the
telegram
ahead
of
time.
A
If
people
have
things
that
come
up
during
the
week
that
they
want
to
make
sure
that
they
have
a
chance
to
discuss
on
the
call
does
that
sound
good,
all
right,
awesome
well
super
productive
day,
and
you
know
special
shout
out
to
the
foundation
team
for
doing
such
a
great
job
capturing
all
of
those
you
know,
proposals
from
from
the
the
last
call
so
yeah
thanks
a
lot
everybody
and
see
you
at
next
week's
call
thanks.
Everyone
thanks.