►
From YouTube: NFT Subgraph Community Call #2
Description
The second NFT Subgraph Community Call took place March 4th.
Join the community and learn more on Discord:
The Graph: https://thegraph.com/discord
The Graph NFTs: https://discord.com/invite/EdZE6EmVKC
A
Hi,
everyone
welcome
to
the
second
nft
subgraph
community
call.
So
we
had
a
really
great
call.
Last
week
where
we
went
over
all
of
the
different
things
that
people
are
building
around
nfts.
We
did
a
subgraph
showcase,
which
is
really
cool
to
see
things
from
you
know,
foundation,
wearable,
known
origin,
a
bunch
of
others,
and
we
came
away
with
a
bunch
of
suggestions
for
things
that
we
can
add
to
like
tooling,
to
make
building
nft
subgraphs
easier.
A
A
A
You
know
low,
moderate,
high
and
and
an
owner
that
we
could
assign
for
them.
Then
we
might
want
to
track
different
kind
of
improvements
that
we
want
to
make
to
existing
subgraphs
the
standards.
These
are
the
ones
that
we
discussed
on
the
last
call.
So
these
might
be
like
you
know,
entity
types
or
interfaces.
A
So
so
the
big
ones
that
were
raised
last
week.
One
was
the
missing
ipfs
metadata,
and
this
is
basically
a
problem
with
when
you're
syncing
a
sub
graph.
If
you
know
at
the
time
that
a
handler
is
called
a
given,
ipfs
file
isn't
available,
then
it'll
just
time
out
and
keep
going
and
and
there's
no
like
callback
mechanism.
In
case,
then
the
file
becomes
available
at
a
later
date,
so
that
kind
of
results
in
some
missing
data.
So
this
is
an
improvement
we
can
make
on
the
infrastructure
side.
A
You
know,
like
you,
know,
here's
a
a
a
particular
improvement
that
would
be
valuable
to
everybody.
I
I
can
provide
input
on.
You
know
how
it
should
work,
but
maybe
say
you
don't
have
the
resources
to
actually
do
it
yourself.
Then
we
can
also
try
to
find
a
dev
shop
or
and
and
we've
got
several
partners
that
we
work
with
that
can
help
with
the
development.
A
A
A
B
A
C
A
A
A
C
A
Cool
yeah
last
week
we
you
know
we
we
did.
The
showcase
of
people
had
a
chance
to
kind
of
chat
about.
You
know
their
subgraphs
breck.
I
don't
think
you
were
on
the
call
last
week.
Would
you
maybe
want
to
just
you
know,
share
a
bit
about?
Maybe
what
zora
is
building
what's
like
captured?
You
know
in
the
subgraph
already.
F
A
market
mechanism
and
the
owner
of
an
existing
zora
token
also
is
in
full
charge
and
has
ownership
of
the
sell
side
of
the
liquidity
of
the
market,
and,
and
you
know
so,
anyone
can
place
a
bid
and
then
the
owner
can
accept
and
ask.
We
have
some
we've
also
pushed
down
like
royalties
and
and
stuff
like
that,
also
down
to
the
contract
level.
F
So
it
doesn't
exist
on
individual
marketplaces
and
it's
like
you
know,
it's
coded
into
the
blockchain
as
well,
and
then
our
our
subgraph,
just
like
indexes
all
the
data
that
that's
required
so
like
the
main
entities
are
like
media,
which
is
essentially
just
our
erc
721s
and
then
bid
activity.
Ask
activity,
transfers
things
like
that,
so
all
the
basic
data
that
you
would
need
to
be
able
to
to
interact
with
with
zora
in
like
a
web
2
context.
All
exists
within
our
subgraph.
A
A
So
you
mentioned
it
was
kind
of
an
extension
of
you
know.
721,
you
know
here
for
the
different
types
you
know
I
put
721
1155
and
like
marketplace
is:
does
that
feel
right?
You
know
to
to
you
guys
or
or
how
would
you
think
about
the
different?
Like
you
know,
types
of
you
know,
contracts
or
things
that
would
be
getting
indexed.
B
So
I
guess
a
distinction
I'd
make
between
the
subgraphs
is
the
ones
which
have
sort
of
been
built
to
support
an
application
on
like
on
a
given
on
a
given
contract
versus
the
sort
of
the
wiggle
wag
and
those
other
ones
which
are
more
like
sort
of
directories.
Of
anything.
So
say
that,
like
the
nifty
ink,
one
is
super
specific
to
some
of
the
needs
of
essentially
a
front
end
versus
like
and
and
has
some
like
peculiarities
so
like
we
have.
B
It
has
its
own
royalties
type
system
and
sort
of
marketplace
built
in
which
are
like
not
necessarily
part
of
the
elc
721
standard.
And
so
I
guess
it's
that
challenge
where
some
of
these
could
be
composed
into
like
a
larger
directory,
whereas
you've
also
got
the
directory
ones,
which
are
just
gonna,
be
missing
a
lot
of
the
like
specific
logic
per
contract.
So
I
don't
know
if
that
distinction
makes
sense
to
other
people.
A
A
Yet
people
have
kind
of
jumped
straight
to
those
larger
ones
in
some
cases,
but
maybe
the
ideal
architecture
is
to
have
individual
subgraphs
for
all
those
pieces
and
then
have
like
what
you're
describing
which,
which
I
it
would
be
its
own
type
of
subgraph
as
well
for
sure
that's
kind
of
like
an
aggregation
or
we
could
think
of
a
good
name.
For
that.
C
Yeah,
so
I
was
just
gonna
say
like
an
example
is
like
foundation
right
now.
We,
those
are
separate
contracts
and
we
index
both
in
one
subgraph,
but
I
think
the
future
actually
probably
looks
more
like
everybody
has
a
standardized
way
of
like
indexing,
their
721
or
1155,
and
then
you
could
index
your
marketplace.
However,
you
want
as
like,
an
additional
layer
that
way
like
there's,
more
interoperability,
right,
yeah.
C
Yeah
and
we
we
index
both
and
there's
one
subgraph,
but
that
in
the
world,
where
there's
a
composition,
I
think
that
actually
should
be
split
out
and
then
everybody
probably
would
be
doing
the
same
thing
like
if
you
have
your
own
marketplace.
But
then
you
have
your
own
like
nft,
like
you
should
split
that
out.
So
there's
separation
of
concern
and
people
interrupt
at
different
layers.
F
Yeah
I
I
fully
agree
with
that,
because
it
does
feel
like
you
can
easily
bucket,
like
most
of
these
contracts
are
at
a
base,
layer,
ert,
721
or
erc1155,
and
if
you
can
come
up
with
a
standard
for
defining
a
subgraph
for
those
two
ercs,
then
we
have
a
base
layer
of
composability
at
the
subgraph
layer.
And
then
you
can
build
your
own
marketplace
logic
and
work
on
a
marketplace
standard
as
well.
A
F
A
F
F
A
A
A
C
It's
interesting
because
it's
not
an
exact
erc
721
on
the
base
contract,
but
they
do
have
an
auction
within
that
original
contract.
They
were
one
of
the
first
to
put
that
in
place,
but
then
there's
also
a
wrapped
punks
contract
that'll
convert
it
to
a
721,
but
then
you
also
have
a
lot
of
sales
happening
on
like
open
c.
A
A
C
A
So
we
can
leave
it
like
that,
so
yeah
I
mean
if
we
had
to
guess
how
many
different
of
these
types
of
you
know.
You
know
tokens
and
marketplaces.
Do
we
think
they're?
There
are.
I
guess
that
was
the
question
for
hadrian,
which
here
holy
crap,
you're
saying
there's,
oh,
I
don't
know
yet
all
721
registries,
so
there's
over
5,
000
registries.
D
D
So,
basically,
what
so,
the
sub
graph?
What
it
does
is
it's
looking
for
for
the
erc
721
events
and
whenever
it
sees
an
erc721
event.
It
knows
the
contracted
sender,
and
so
basically
it
is
added
as
an
entity
in
the
subgraphs
and
then
we
also
add
entities
for
the
token
and
they
are
attached
to
the
token
registry,
but
both
for
my
subgraphs
and
and
one
answer
graph.
G
D
E
A
D
A
Wow,
okay,
yeah!
That's
that's
massive,
so
you
know
for
for
most
people
you
know
is.
Is
it
how
helpful
is
it
to
have
a
subgraph
that
kind
of
dynamically
picks
up
all
of
the
721s
base,
based
on
kind
of
the
contract
signatures
versus?
I
guess
kind
of
having
a
curated
list
of
721s
like
how
do
people
think
about
how
these
things
should
be
aggregated.
E
E
So
actually,
my
subgraph
is
also
an
npm
package
that
you
can
install
and
you
have
your
subgraph
while
you
develop.
So
when
you
create
a
new
nft
project,
you
don't
even
need
to
write
a
subgraph
for
it
while
you
develop,
so
you
have
a
local
developer
experience
where
you
have
your
graph
node
with
that.
You
can
query
and
then
build
your
app
around
that.
So
this
is
also
an
aspect.
A
Yeah
that
that
is
interesting
I
mean
so
I
would
imagine
that
most
marketplaces-
or
you
know,
dapps,
that
that
are
kind
of
aggregating.
These
things
would
want
to
be
able
to
somewhat
choose.
Do
we
think
that
that's
right
and
that
kind
of
you
know
each
one
you
know,
is
you
know
we
would
want
to
include
a
different
set
of
nfts,
that
they're
interested
in.
E
Yeah
I
mean
actually
I
mean
the.
There
is
also
the
issue
of
like
your
curation,
because
you
you
can't
by
having
this
graph
generic.
I
love
it
in
local
development,
but
then,
when
you
build
an
app,
you
have
lots
of
issues.
So
that's
why,
for
example,
I
was
building
a
marketplace
like
and
the
choice
the
plan
was
to
use
subgraph,
but
then
we
had
issue
with
metadata
like
in
some.
Some
of
the
token
image
are
not
existing,
and
I
was
comparing
this
with
openg
in
opencv.
E
They
had
the
data,
I
don't
know
where
it
came
from,
so
I
think
a
lot
of
projects
are
collaborating
with
opencv,
for
example,
and
so
they
they
can
provide
something
which
is
not
even
available
on
chain
or
even
in
the
meta
data.
It
seems
so
considering
all
of
that
generic
subgraph
to
me
is
it's
a
goal
that
we
should
reach
to,
but
in
practice
it's
not
that
easy.
G
A
Okay,
yeah
that
that
that
makes
sense
all
right,
so
you
know
here.
I
think
we
can
keep
this
going,
as
is
just
a
list
of
subgraphs
that
either
exist
or
or
that
that
people
would
want
to
have
created-
and
I
think
it'd
be
really
helpful.
Maybe
if,
after
the
call,
if
you
know
now,
you've
all
been
invited
to
this
air
table
and-
and
this
is
a
table
that
we
can
try
to
keep
up
to
date
to
basically
track-
you
know,
building
of
different
subgraphs.
A
I
created
this
table
because
I
kind
of
assumed
that
there
would
be
you
know,
improvements
that
we
want
to
make
to
existing
subgraphs
is
there?
Is
there
anything
like
that?
You
know
that
comes
to
mind,
for
you
know
things
that
you
know
features
that
would
be
nice
to
have
in
subgraphs
that
you
know
just
aren't
there
yet.
A
A
So
you
know
you
want
all
of
the
data
to
be
accurate.
You
know,
if
there's
something
like
you
know,
there's
metadata,
that's
just
missing
you
could,
I
think,
consider
that
a
type
of
inaccuracy
in
the
data
and
then
there's
like
completeness,
which
basically
comes
down
to
the
schema
of
you,
know
what
what
fields
are
being
populated
for
the
different
entities.
A
So
we
could
take
a
look
at
them
one
by
one,
but
I
guess
in
general
the
way
that
I
would
track
improvements
or
new
feature.
Development
would
be
in
terms
of
new
entity
types
that
that
can
be
added
new
fields
that
that
could
be
added
to
existing
entity
types
or
maybe
like
improving,
like
the
the
the
accuracy
of
something
that
maybe
isn't
as
high
quality
as
it
could
be.
E
A
D
D
Here
it
is
okay,
so
this
is
the
sub
graph
and
just
like
we
discussed
previously
like
if
the
higher
level
is
what
I
call
token
registries-
and
here
you
have
a
list
of
a
lot
of
address
that
are
all
addresses
of
token
registries
and
you
can
get
their
name
and
in
terms
of
their
symbol.
But
you
can
also
get
the
list
of
tokens
that
they
hold
and
I'm
going
to
show
it
here
because
it
will
be
simpler.
D
Like
you
have
a
list
of
all
tokens
and
obviously,
from
old
token,
you
can
go
back
to
the
registry,
they
are
identified
by
an
integer,
obviously,
and
they
have
an
owner.
And
when
you
go
back
to
the
owner,
you
can
obviously
get
a
list
of
for
the
token,
and
this
will
be
all
the
token
across
all
the
possible
registries.
D
And
then
the
idea
is
that
I
try
to
have
a
view
of
all
the
events
that
are
happening
within
this
context
and
like,
if
you
go
to
that
token,
you
will
see
all
the
transfer
and
all
the
okay.
This
is
wrong.
If
you
check
that
out-
or
it
will
be,
don't
do
missing,
but
okay,
like
for
the
transfer,
you
can
see
how
the
transfer
happen.
So,
if
you
were
to
to
take,
let's
go
and
take
the
very
first
token.
D
Okay,
we
we've
got
the
the
registry
that
it's
attached
to.
We
also
got
it's
it's
identifier.
You
see
that
it's
id
it's.
Basically,
the
concatenation
of
both
and
you've
got
its
owner,
which
again
is
an
object,
so
you
can
get
like
its
id
yeah.
I'm
gonna
remove
this
one
for
currently
and
then
you
can
see
all
the
transfer
events,
and
so
here
we
see,
we've
got
two
transfer
events,
and
so
we
can
see
from
and
two
so
basically
there
is
there
is
this
this
from
zero
to
this
address.
D
So
this
is
a
mint
and
then
there
has
been
one
transfer
already
and
when
you
have
a
look
at
the
transfer,
it
goes
deeper
than
that
you
can
get
the
transaction
id
if
you
ever
want
to
go
on
it
or
scan
and
see
the
transaction
so
yeah.
This
is,
and
basically
this
transfer
is
an
event
and
every
event
is
like
an
abstract
interface
and
from
that
you
get
the
id
obviously
of
the
transaction.
D
But
you
get
the
block
number
the
timestamp
from
a
transaction.
You
can
see
all
the
other
events
that
are
attached
to
the
same
transaction
again.
Blinking
and
you've
got
timestamps,
so
you
can,
you
can
sort
the
transfers,
and
that
was
my
approach
of
being
unopinionated
about
what
is
the
actual
owner
of
what
is
the
actual
artist
or
or
creator
of
our
contracts.
Since
I've
got
this
transfer
history,
that's
stored
into
the
subgraph,
and
I
can
sort
it
by
timestamp.
D
If
I
want
this
helped
me
go
back
to
to
basically
anything
that
is
part
of
the
standard.
So
if
ever
an
rc721
is
a
bit
modified
and
there
is
non-standard
features
to
manage
fees
built
into
the
contract
for
artists
or
stuff
like
that,
I
will
not
capture
it,
but
basically
anything
that
is
part
of
the
standard
should
be
captured.
A
Yeah
so
there's
quite
a
few
entities
here
that
I
guess
weren't
in
our
list
of
of
things
to
standardize
on
would
you
mind
stopping
to
share?
I
guess
yeah.
So
here
we've
got
like
the
transfers
accounts.
If
we
go
back
to
you
know
the
list
that
we
had,
and
maybe
people
can
look
at
their
own
subgraphs
and
see.
If
there's
you
know
things
that
they
would
add
or
any
of
those
entities
like
the
transfers
or
or
things
like
that
things
that
people
think
would
be
worth
standardizing
on.
C
F
So
one
philosophical
question
I
have
is:
does
it
make
sense
to
create
entities
based
off
of
events?
I
think
for
transfers
it
does,
but
rather
does
it
make
sense
to
maybe
make
a
user
or
like
an
account
an
entity
and
then
keep
track
of
the
like
the
current
approved
user
for
that
or
the
current
approved
account
for
that
account,
rather
than
like
all
the
approvals
that
that
happen
over
time.
This
is
something
that
that
I
raveled
with,
or
it
was
wrangling
with
when
I
was
building
the
zoro.
F
Subgraph
is
like
it
like,
like
logically,
it
makes
sense
to
index
based
off
of
events,
but
also
it
makes
sense
to
like
have
the
subgraph
just
be
like
in
sync,
with
the
state
of
whatever
the
contract
storage
is,
and
I
wasn't
sure
where,
where
people
would
sat
on
that
so
like
for
us,
we
track
approvals,
but
it's
on
the
user
entity.
So
we
don't
have
like
an
approval
entity
itself.
F
C
Yeah,
I
was
going
to
say
the
same
thing
I
think
transfer
may
be
less
so
just
because
you
can
get
the
owner
pretty
easily,
but
then,
like
for
approvals,
you
probably
index
both
the
event
and
the
current
state.
So
you
have
basically
like
current
approval
and
then
there's
like
the
approval
event,
or
we
can
call
it
something
else,
but
essentially
you
have
a
you.
Can
you
can
get
both
yeah.
A
And
then,
here
last
time
someone
talked
about
events
for
which,
like
I
guess,
the
transfer
was
just
one
of
the
events.
So
I
guess
that's
that's
another
thing
here
is:
is
it
better
to
just
have
a
generic
events,
kind
of
thing,
of
which
maybe
events
is
like
an
interface
and
then
there's
there?
Are
these
different
types
of
events
that
that
kind
of
implement
the
interface
and
that's
a
way
of
being
able
to
get
a
single
feed
of
events
with
different
types,
but
each
each
type,
I
guess,
has
specific
fields
to
it.
A
So
so
that
could
be
a
route.
So
let's
kind
of
go
through
these.
You
know
one
by
one
then,
and-
and
you
know
I
think
so-
for
the
standardization.
I
think
what
what
would
be
helpful
here
is,
I
guess,
a
survey
of
the
different
subgraphs
and
kind
of
how
they've
implemented
similar
concepts
and
then
maybe
trying
to
come
up
with
a
proposal
for
what
an
ideal
you
know
schema
would
look
like
for
these
things
and
then
maybe
at
the
next
call.
A
B
A
C
F
Metadata
think
it
should
be
a
first
class.
I
feel
very
strong
enough
to
be
a
first
class
citizen
on
the
contract
itself
and
on
the
subgraph.
It's
like
actu.
Arguably,
it's
the
most
important
information
and
leaving
it
up
to
metadata
where
that
can
be
tampered
with
or
it
can
be.
Not
provable.
Cryptographically,
I
think
is,
is
not
optimal
and
that's
not
that's.
That's
something
that
we
would
have
felt
very
strongly
about,
at
least
at
zora.
G
Yeah
in
eap,
1155
like
there
is
a
standard
field
of
the
creator
of
the
nft
and
in
in
many
of
erc
721
platforms.
They
also
have
their
own.
Let's
say
like
fields
like
named
differently
for
the
creator,
but
I'm
not
sure
if
the,
if
they
mean
the
same
notion,
is
it
the
greater
the
kind
of
technical
address
or
it's
like
the
real
address
of
the
artist
or
something
else.
Yeah
should
be
investigated.
F
G
C
Yeah,
big
big
plus
one
on
like
this
being,
I
think,
probably
the
most
important
field
as
like
nfts
have
evolved
and
then
right
now.
I
think
it
is
different
on
almost
everybody
foundation
we
we
basically
looked
at
what
people
have
out
there
and
we
saw
like
super
used
token
creator
singular
as
like
the
the
field,
and
we
just
adopted
that,
but
just
like
every
everybody
has
a
different
field.
So
I
would
say
we
have
to
standardize
on
the
contract
and
then
we
should
definitely
standardize
on
the
subgraph.
C
A
B
C
F
A
And-
and
I
I
think
with
standardization,
if
these
things
are
like
interfaces,
then
it
doesn't
mean
that
you
have
to
be
limited
to
the
interfaces
right.
It
means
that,
like
at
a
minimum,
these
things
are
shared
and
then
there
can
be
additional
fields
yeah,
so
unfortunately,
maybe
I'll
I'll
change
the
type
here,
because
not
everybody's
accepted
the
air
table
invites
so
I
don't
think
I
can
put
you
as
a
collaborator,
but
I'm
just
gonna
for
now
say
single
line
text.
A
A
G
A
A
Oh
yeah,
no
sorry
I
I
would.
I
would
imagine
that
we
would
want
to
take
something
like
the
metadata.
That's
on
the
nft
and
parse
it
into
something.
That's
more
semantically
meaningful
in
the
subgraph
schema
as
opposed
to
even
having
like
a
metadata.
You
know,
entity
on
on
the
sub
graph,
or
you
know
entity
does.
Does
that
sound,
reasonable.
C
F
F
I'm
wondering
if
it's
maybe
possible
to
add,
like
a
json
blob
object
and
this
like
as
a
scalar
type.
So
you
could
just
shove
the
raw
like
json.
If
it
is
json
from
you,
know,
ipfs
or
wherever
it's
stored.
That
way
like
you
could
have
some
higher
level
service.
That's
consuming
stuff
from
a
subgraph
to
be
able
to
parse
the
json
and
have
it
actually
live
in
an
indexed
query
layer
versus
having
to
wait
on
an
ipfs
to
pull
it,
which
is
like.
B
Yeah,
I
guess
like
like
the
nature
of
this,
is
it's
always
going
to
be
a
load
of
optional,
optional
fields,
but
I
think
I
guess
the
thing
would
be
to
start
to
define
what
those
might
be,
or
at
least
to
inherit
the
overseas
type
standards
like
at
least
from
my
experience.
The
challenge
here
has
been
more
like
the
ipfs
stuff
stops
and
stops
this
actually
making
it
into
the
subgraph,
because
we
can't
reliably
get
it
in
time.
So
this
currently
isn't
even
a
problem
at
the
outfit.
The
subgraph
level.
A
F
A
Well,
this
sounds
like
a
place
where
we
can
make
some
tooling
improvements,
so
should
we
say
like
kind
of
in
parsing
or
something
could
be
something
for
us
to
track.
You
know
we
can
say
like
for
metadata,
because
if,
if
people
are,
you
know
feeling
pain
with
some
of
these
things,
you
know
would
be
worth
filing
issues
and
we
can
see
how
we
can
improve
the
functionality
of
what
you
can
do
with
assembly
script.
C
I
have
two
quick
points
I
want
to
make
before
I
actually
hop
off
soon,
but
yeah
one
is
break.
I
actually
really
like
the
way
you
guys
did
with
your
metadata
standard
for
zora.
Actually,
an
interesting
thing
we
could
do
here
is
just
like
you
self-reflect
right,
like
you
have
something
on
the
metadata.
It
tells
you
what
like
version
or
what
parser
it
should
really
be
using
and
then
like
that
logic
could
be
part
of
like
the
indexing
right.
C
So
like
yeah
you,
you
know
what
you
know,
what
the
the
the
versioning
is
and
then
you
could
pull
in
the
code
to
properly
parse
that
and
then
we
gotta
figure
out
like
at
what
level
the
entity
has
to
be
like
standardized
and
works
across
the
board,
but
I
think
that
could
be
a
at
least
a
start
in
terms
of
how
we,
how
we
think
about
this.
The
second
point,
just
because
I
got
out
is
the
t
standard.
C
I
just
want
to
be
clear,
at
least
from
my
perspective,
I
think
the
most
important
one
is
the
creator
fee
on
the
nft,
because
marketplaces
can
have
their
own
fees,
but
like
we
can
offload
that
everybody
will
do
that
somewhat
differently.
But
the
fee
standard
that
I
was
talking
about
in
the
last
call
is
just
like:
what
does
the
creator
get
as
a
royalty
on
all
security,
all
subsequent
sales,
and
that
should
be
self-reported
and
honored
and.
A
Thank
you
so
much
alfizzo
and
yeah
thanks
everyone
for
making
the
second
nf2
subgraph
call.
I
feel
like
this
was
a
really
productive
part
of
the
conversation
here.
So
I
think,
helping
to
align
on
standards,
and
then
you
know
we'll
do
the
work
on
our
side
to
help
with
the
tooling
and
if
anything
comes
up
for
new
subgraphs
or
improvements
to
subgraphs
during
the
week.
You
now
have
access
to
the
air
table
and
we
can
keep
this
up
to
date
and
get
all
of
these
work
streams
done
through
to
completion.