►
From YouTube: NFT Community Call #5
Description
The 5th NFT Subgraph Community Call took place April 1st.
Join the community and learn more on Discord:
The Graph: https://thegraph.com/discord
The Graph NFTs: https://discord.com/invite/EdZE6EmVKC
A
B
Cool,
thank
you
any
of
excited
to
be
to
be
part
of
this
and
going
to
do
a
quick
demo.
So,
okay,
let
me
share
my
screen,
so
this
is
showtime.
So
showtime
takes
every
single
nft
on
on
ethereum.
Well,
I
mean
with
an
opinionated
decision
on
digital
art
and
really
is
a
social
network
rather
than
the
marketplace,
and
so
these
are.
B
I
can
go
to
my
profile
right
now
and
you
can
see
my
created
owned
and
liked
nfts
with
the
new
spotlight
feature
that
we
just
released
today
so
like
usually
an
artist
is
like
one
nft
that
they
promote,
and
so
this
is
my
nft,
because
I
like
moonwalking,
I
guess
and
yeah.
We
have
a
leaderboard
for
the
top
creators
ranked
by
likes
and
social
data
that
is
centralized
for
now,
because
you
know
we
want
this
to
be
to
be
fast
and
we
wanted
to
to
reiterate
very
quickly.
B
But
of
course
the
goal
is
for
everything
to
go
on
chain
in
a
decentralized
social
protocol,
but
that's
that's
for
later
and
so
yeah
you
can
filter
by
collections.
Probably
a
lot
of
teams
here
can
see
their
their
protocol.
If
you're
missing,
please
let
us
know
and
we'll
add
you
straight
away
and
then
user
spotlights
is
like
people
who
split
their
own
nfts
to
the
top
of
their
page,
which
is
what
we
see
in
the
homepage
and
yeah.
B
That's
a
demo
of
showtime
for
now
and
latest
also
top
liked
in
fts
as
well.
Sorry
latest
nfts
that
are
mentioned
from
the
top
platforms
and
then
trending
and
fts,
which
are
the
most
liked
and
ft
so
people
and
other,
like
famous
artists,
are
there
it's
pretty
cool,
so
yeah,
quick
but
but
concise?
That's
that's
funny.
Thank
you.
So
much.
B
A
B
Exactly
like,
I
feel
like
it's
just
a
better
is
a
better
model,
because
you
know
sponsored
posts
on
instagram
with
the
influencer
economy
is
largely
lifting
instagram
right.
They
are
taking
most
of
the
profits,
and
so
it's
exciting
to
to
just
trying
to
make
people
move
away,
and
hopefully
we'll
have
a
mobile
version
very
soon.
So
we
can
take
over
the
web
2
world.
A
Yeah
and
then
it's
it's
nice
also
how
it's
this
like
kind
of
aggregator
and
and
you
can
browse
all
of
these
nfts,
but
also
like
linking
out
to
the
underlying
platform.
So
it's
a
very,
like
you
know,
symbiotic
kind
of
relationship
with
the
mpt
platforms.
So
it's
a
very,
very
cool
and
yeah.
You
know,
I
think,
we're
getting
closer
and
closer
with
the
3
stack,
but
there's
there's
obviously
still
a
lot
of
work
to
do
with
that.
A
You
know
this
year,
and
so
I
think
this
kind
of
thing
where
some
of
those
features,
I
guess,
are
implemented
in
a
more
centralized
way,
but
I'm
sure
you
guys
are
are
keeping
a
close
look
at
how
the
stack
is
developing
and
you
know
we'll
be
kind
of
progressively
decentralizing.
You
know
those
different
features
for.
B
B
We
want
to
to
switch
and
be
able
for
people
to
tune
in
their
nfc,
for
free
and
and
to
do
all
of
those
actions
so
that
it
can
be
more
than
digital
art,
which
is
really
expensive,
but
it
can
be
any
kind
of
media.
That's
definitely
where
we're
going
and
so
not
just
not
just
like
the
social
data
but,
like
anything,
has
to
be
extremely
fast
and-
and
this
is
why,
like
calls
like
this
already
helpful,
because
we
we
need
to
be
able
to
just
secure
web
free
data
as
fast
as
possible,.
A
Yeah
absolutely
so
you
know
on
that
kind
of
topic
of
you
know,
progressive
decentralization,
you
know,
so
something
that's
been
on
my
mind.
Is
you
know
how
people
are
storing
nft
metadata?
You
know,
I
feel,
like
you
know,
the
the
nft
spec
itself
is
is
pretty
loose.
You
can
put
any
kind
of
like
uri
for
the
metadata.
The
metadata
itself.
Can
you
know
point
to
images
that
are
stored.
A
I
think
people
might
find
in
five
years
ten
years
that
their
nfts,
that
they
thought
were
theirs,
aren't
actually
there
and
so
I'm
kind
of
curious
how
people
are
you
know
going
about
solving
for
that?
You
know
what
are
the
issues
that
they've
kind
of
run
into
building
kind
of
their
their
apps
and
and
if
people
have
experimented
with
different,
like
storage
networks
or
types
of
solutions
for
kind
of,
like
you
know,
long-term
permanent
storage.
B
Yeah,
it
seems
like
ipfs
is
the
leading
solution.
However,
ipvs
doesn't
have
an
incentivization
layer
right
now,
I
don't
think
falcon
is
live
or
people
are
using
psychology,
I'm
not
sure,
but
so
idfs
is
there,
but
still
like.
If
no
one
is
hosting
those
nodes.
If
there's
no
incentive
layer,
then
this
is
still
susceptible
to
be
taken
down,
and
so
that's
that's
pretty
bad,
and
then
I
guess,
what's
funny
at
showtime,
is
like
we
use
the
open
cpi
which
they
use
to
store
on
google
cloud
plus
the
ipfs.
B
So
we
technically
like
if
the
open
cpi
goes
down
today,
showtime
would
largely
go
down
so
yeah
like
we
definitely
need
to
rely
on
on
more
distance
race
parties
to
post
and
also
like
having
this
information
layer
as
well,
because
it
seems
like
it's
a
it's
good
to
host
ipfs
nodes,
but
if
they
stop
hosting
those,
then,
for
instance
like
the
the
people
69
million
piece.
I
think
there
was
some
research
on
it
like
it
is,
which
is
great,
but
I
don't
think
there's
it's
like
maker's
place.
B
Sorry
yeah,
it's
maker's
place
who's
like
responsible
for
hosting
that,
and
so
maybe
someone
can
correct
me
but
like
we
need,
like
some
people
to
like
post
it
in
a
kind
of
like
altruistic
manner
or
at
least
a
platform,
and
so
I
guess
this
is
the
problem
right
now
and
then
other
than
ipfs.
I'm
not
sure.
Maybe
people
store
nfc
on
a
weave
or
other
data
storage.
I'm
actually
quite
curious
about
this.
C
Yeah,
I
could
chat
through
how
we
think
about
this
foundation,
so
we
we
use
ipfs
kind
of
like
alex
mentioned
as
the
storage
layer,
and
then
I
totally
agree
that,
like
their,
the
incentive
layer
is
missing
right.
So
what
we
you
currently
use
is
we
use
pinata.
They
are
a
pinning
service,
so
we
pay
them
like
a
monthly
bill
and
then
they
go
and
pin
everything
for
us
to
make
sure
things
are
available
and
I
think
a
couple
notes
there.
C
I
think
that's
a
layer
of
abstraction,
that's
necessary
for
this
phase
of
entities,
but
I
think,
like
the
the
future
that
I
think
I
see
happening
is
that
collectors
and
creators
should
should
know
that
this
is
happening
right.
That
somebody
needs
to
make
sure
things
are
available
and
they
should
be
the
ones
that
take
on
the
responsibility
of
making
sure
that
asset
stays
alive,
and
I
think
they
can
do
that.
We
we
are
in
talks
with
both
the
protocol,
labs
team
and
our
weave
team.
C
So,
like
basically
like
a
couple
things,
I
would
push
for
those
teams
to
like
make
tools
available
and
make
it
like
very
user
friendly,
so
that
people
can
go
and
like
they
understand,
what's
happening
and
they
can
just
go
pay
for
pinning
right
and
then
I
think
the
the
second
thing
here
is.
I
think
I
would
love
to
explore
a
way
to
like
bake
this
into
the
graph
as
well.
C
It's
like
how
do
we
make
it
so
that,
as
part
of
maybe
the
indexing
you
know
process
like
we
are
also,
you
know
having
an
incentive
kind
of
layer
for
the
decentralized
storage
being
associated
with
it,
with
an
asset
as
well.
So
I
think
that's
something
exploring
then
I
know
I
know
like
reeve
has
their
own.
C
There
is
what
we're
talking
to
them
about
is
their
bridge,
which
I'll
drop
here,
there's
a
free
service
right
now
I
don't
imagine
I'll
stay
free
forever,
but
you
can
literally
just
like
hit
a
post
endpoint
and
pass
an
ipvs
hash
and
they'll
use
rv
and
the
economic
model
of
r
weave
to
make
sure
it
stays
pinned
forever
right.
But
then
r
weave
also
has
their
own
native
kind
of
like
storage
layer.
A
Yeah,
so
you
know
ipfs,
I
think,
is
like
strictly
better
than
http
uris.
You
do
still
have
to
deal
with
with
the
pinning
question
and
the
incentivization
for
storage,
but
at
least,
if
you're
using
ipfs.
You
know
that
you
know
if
you
know
whatever
platform
goes
down,
somebody
else
can
step
in
and
ensure
that
the
the
date
is
pinned
and
everything
continues
to
run,
and
so
I
think
we
still
have
to
solve
the
long-term
storage
problem,
but
it's
a
big
step
forward
now
what
what
issues
have
people
run
into
with
that?
A
A
One
is
maybe
they
feel
like
it
loads
faster,
and
so
maybe
if
they
have
issues
you
know
it's
like
slow
to
like
pull
the
metadata
directly
from
ipfs,
then
that's
one
reason
why
they
would
do
it
and-
and
the
second,
I
guess,
is
for
the
style
of
nfts,
where
the
metadata
itself
is
like
mutable.
They
want
to
be
able
to.
Like
I
don't
know,
like
return
different
data,
you
know
you
know,
based
on
on.
A
C
More
specifically,
I
think
if
people
do
want
to
add
immutability,
I
know
there's
conversations
in
the
telegram
like
maybe
it's
something
where
I've
seen
the
pattern.
We
do
this
for
burn,
but,
like
the
the
creator
has
to
also
be
the
owner
and
then
they
could
change
things.
Maybe
that
would
be
like
one
way
to
do
it,
but
I
would
make
that
on
chain
so
that
there's
a
history
of
it.
C
Having
happened,
I
don't,
I
think
it's
a
anti-pattern
for
for
for
there
to
be
like
one
end
point
things
change
under
the
hood
and
then
like
there's
no
record
of
it.
I
think
that's
just
against
the
ethos
of
what
we're
building
towards
here,
but
I
do
like,
for
example,
some
collectibles.
It's
cool
to
you
like
you,
don't
know
what
you're
buying
and
then
they
reveal
it.
That's
a
cool
interaction,
so
I
see
that
being
a
use
case,
but
for
art
I
would.
I
would
lean
away
from
that.
A
Yeah
I
agree
completely
and
then
some
people
in
their
metadata
will
actually
reference
uris
that
include
the
ipfs
gateway
right,
and
I
guess
that
makes
it
so
that
the
client
can
be
a
little
dumber
and
just
kind
of
like
you
know,
hitting
that
link
directly.
But
I
mean
that
also.
I
guess
you,
you
could
parse
that
if
you
knew
that
it
was
there
and
remove
it
and
just
kind
of
have
the
ipfs
hash.
But
do
people
see
kind
of
like
issues
with
that
again
kind
of
just
like
hard
coding
to
specific
domains.
C
C
I
think
it's
like
the
ipf,
that's
you
know
as
the
protocol
and
then
and
then
of
the
cid
after
that,
and
then
I
know
like
browsers.
They're
working
on
getting
more
browser,
so,
like
bray,
for
example,
supports
us
natively
now
they'll,
let
you
configure
like
on
the
client
side
which
gateway
you
want
to
use,
but
there's
also
like
a
safe
public
default,
and
then
I
think,
over
time
I
imagine
just
to
to
get
more
popular.
C
D
And
the
the
stuff
that
includes
the
gateway
isn't
like
it's
not
the
worst
case
right,
because
at
least
you
still
have
like
the
qm
hash
in
it,
but
it's
obviously
not
ideal.
I
think
there's
like
this.
There
might
be
like
a
class,
and
I
don't
know
if
it's
what
you're
trying
to
protocol
labs
about
you
know
of
kind
of
like
a
product,
that's
separate
from
the
nft
marketplaces
that
maybe
represent
some
kind
of
like
a
gallery
where
it's
some
entity
that
you
can
pay.
You
know
some
convenient
service
where
you
say
hey.
D
I
have
this
nft
and
I
want
you
to
guarantee
you
will
store
and
maybe
display
this
nft
in
this
setting.
I
don't
know
where
the
marketplace
is
kind
of
intersect
with
that,
but
we're
not
going
to
be
able
to
avoid.
I
don't
think
the
kind
of
economic
requirement
to
say
well,
someone
has
to
somewhere
pay
for
a
hard
drive
with.
You
know,
bandwidth
to
actually
store
this
thing.
A
Yeah-
and
I
mean
there's
just
no-
no
way
that
that's
going
to
be
too
expensive
right,
I
mean
like
these.
Things
are
teeny.
You
know
if
you've
got
like
a
megabyte
that
you
want
to
store
for
50
years.
I
mean
that
should
legitimately
cost,
like
you
know
like
under
a
dollar
or
something
right,
and
it's
just
a
matter
of
having
like
the
the
the
pieces
in
place
so
that
you
can
conveniently
pay
the
dollar
and
they
can
be
the
creator.
It
can
be
the
owner.
You
know
it's,
I
think
it's
easier.
A
A
You
know
fully
decentralized
storage
and
linking,
I
think
you
know,
it'll
really
make
a
really
big
difference
and
we
should
get
there
as
soon
as
we
can
and
then
I,
I
think,
it'd
be
nice
to
hear
from
people's
experiences.
I
don't
know
who
who
here
you
know
if
anyone
has
tried
using
these
storage
networks,
you
know
between
our
weave,
saya
and
filecoin.
A
A
Cool
all
right,
then:
let's
move
on
to
the
next
agenda
item.
So
last
week
we
went
into
pretty
good
depth
on
kind
of
the
high
level
schema
for
nfts.
We
looked
at
like
you
know,
contracts
and
and
had
some
great
discussion
around
that,
and
then
I
think
we
broke
right
before
going
into
more
detail
about
the
metadata
field
itself
and
specifically
how
to
deal
with
different
like
media
types.
D
C
A
Cool
and
then
I
think
we
also
kind
of
had
a
discussion
both
with
sam
and
breck
from
zora
about
using,
like
a
separate
jason,
schema
kind
of
format.
For
these
you
know
different
media
types,
so
we
don't
have
breck
on
the
call
today,
but
I
think
it
would
be
worth
either
if,
if
someone
knows
how
zora
is
storing
that
stuff
today,
we
could
take
a
look
at
it
or
we
could
leave
that
for
for
next
time.
E
Yeah,
I
mean
I'm
not
sure,
there's
particularly
a
huge
amount
more
than
what
we
we
kind
of
started
discussing
last
week.
To
be
honest,
we
obviously
had
a
few
different
options
that
we
would
essentially
kind
of
defer
to
as
the
kind
of
like
core
set
of
primitive
schemas,
so
kind
of
like
images,
video
audio
and
maybe
like
3d
as
well
and
still
and
and
any
other
things
that
we
deem
as
like
a
primitives
and
then
using
the
json
schema.
E
We
can
obviously
like
compose
those
together
by
building
on
top,
so
platform
specific
ones
can
add
their
own.
They
can
kind
of
like
enrich
it
with
their
own
specific
set
of
data
if
they
need
that,
but
ultimately
they
should
always
defer
to
like
a
base
class
right
like
a
base
schema
like
it
similar
to
how
it
works.
Now,
there
should
always
be
a
minimal,
minimal,
viable
set
of
data
that
you
can
pull
from,
and
then
we
kind
of
like
build
on
top
of
that,
but
yeah,
I
think
like
it's
all
like.
E
Yes,
I
think,
like
I'm,
I'm
very
open
as
to
what
is
contained
in
these
kind
of
like
these
primitive
json
schemas.
I
would
be
quite
happy
for
people
to
like
this
is
kind
of
like
a
first
draft
from
my
kind
of
like
perspective,
but
I'd
be
very
interested
to
see
what
I've
missed
and
what
people
think
should
and
shouldn't
be
there
as
like,
mandatory
or
even
optional
fields,
images,
image
and
video
are
probably
like
the
two,
probably
highest
highest
use
case,
highest
trafficked
ones.
E
I
guess,
in
terms
of
like
the
content
that
we're
seeing
at
the
moment,
but
I'd
be
interested
to
see
like
audio
and
3d
and
any
other
primitives
that
people
would
see
as
well
like.
I
guess,
one
that
is
missing
from
here
is
text
like
pure
text
content
like
if
people
are
actually
publishing
articles-
or
you
know
stories
or
whatever
it
might
be,
a
long
form
copy.
So
I'd
be
interested
in
seeing
what
that
might
look
like
as.
E
Yeah,
I
guess
what
we
could,
what
could
always
be?
There
is
like
a
references
property
where
it
like
references,
other
schemas
right,
so
an
array
of
other
schemas
if
you're
referencing,
like
yeah
videos
and
images,
and
whatever
else
might
be
there,
I
guess
I
haven't
yeah,
I
don't
know
how
it
would
be
constructed
to
most
like
most
accurately
reflect
what
else
is
like
in
this
nft.
If
that
makes
sense
like
how
do
you
reference
like
the
video
file
or
if
it's
an
image
that
comes
with
video
like?
E
F
G
F
I
think
so
yeah.
I
think
it's
a
great
question,
because,
because,
if
you
sort
of
take
the
people,
every
day's
example,
which
was
five
thousand
like
five
thousand
works
of
art,
is,
is
that
one
is
that
one
file
could
could
that
actually
reference
it
like
everything
but
yeah,
like
I
don't
know
if
it's
an
interesting
question,
whether
we
want
to
introduce
like
constraint
here
or
leave
that
flexibility.
C
Live
yeah,
keep
it
simple
and
flatten
it,
because
otherwise,
I
think
like
yeah,
I'm
just
thinking
through
like
even
how
you
would
index
it.
It
would
seem
like
it
would
introduce
some
complexity
on
like
okay.
Is
this
a
one?
Is
this
a
single
metadata
file,
referencing
one
asset,
or
is
it
one
referencing
a
bunch?
E
D
I
think
keeping
the
kind
of
default
standard
thing
very,
very
simple
and
saying
like
this
is
a
picture.
You
know
here's
a
couple
sides
of
the
picture.
That's
fine!
You
know
we're
not
excluding
the
option
to
say.
Oh,
I
want
some
weird
fancy
kind
of
artistic
through
code.
You
know
self-referential,
nft,
you're,
like
cool,
you
can
go,
make
your
own
subgraph
for
that.
If
you
want
and
you
can
go,
you
know
signal
on
that.
D
If
that's
really
a
thing
you're
into,
but
we
want
the
standard
to
be
something
that
is
like
low
effort
and
can
be
kind
of
programmed
into
various
markets
and
just
say:
okay,
yeah
click.
This
button,
you
know,
give
us
three
images
and
then
we
can
generate
all
the
kind
of
metadata
necessary
and
it's
really
easy
to
use.
I
think
you
know
the
99
use
case,
but
we
still
leave
the
option
open
for
okay.
You
want
to
go,
be
weird,
fine,
but
that's
going
to
be
more
work.
C
G
Yeah,
the
spec
on
that's
pretty
open,
like
you
can
look
at
hask's,
math
or
hash
masks
is
one
example
where
you
have
these
like
different
figures,
and
then
those
figures
have
different
attributes
or
they
have
different
collections
of
items
around
them.
But
it's
largely
just
these
arrays
of
like
key
value
pairs
and
then,
ideally,
you
have
a
count
of
how
many
total
nfts
have
that
trait
within
a
contract,
and
then
you
can
get
like
five
percent
have
this,
which
give
it
some
value.
C
G
D
E
I
would
err
on
the
side
of
like
the
bass
schema,
having
almost
nothing
that's
optional,
because
I
think
then,
like
everything
can
be
optional.
If,
like
one
or
two
things,
so
I
would
say
that,
like
maybe
a
base,
schema
of
an
image
has
a
subset
of
these
things
like
what
we
attribute
is
like
being
mandatory
and
like
you
can't
do
anything
without
these
things
and
then
yeah.
Maybe
there
could
be
a
composed
version,
which
is
like
more
of
a
yeah
like
trait
image
or,
like
you
know,
whatever.
E
You
would
call
that
thing,
which
would
be
a
separate
schema,
but
it
would
essentially
inherit
or
be
composed
with
the
base
schema
and
then
one
that
enhances
it
with
traits
and
attributes
and
that
kind
of
subset
schema
yeah.
And
then
maybe
you
know
going
back
to
the
the
referencing
one.
Maybe
there
could
be
a
like
a
referencing
set
of
schemas
right
where
it's
like
the
base.
One
can
be
composed
with
other
subset
or
compositions
of
other
different
ones.
C
Yeah,
actually,
sam,
if
you
scrolled
down,
I
forgot
who
it
was,
but
I
think
what
we
can
do
is
maybe
drive
towards
like
the
actual
graph
schema
here
so
like
I
think
someone
has
created
the
interface
generic
metadata,
and
I
think
this
is
based
off
what
you
had
on
above
this
tab
and
basically
it's
just
like.
We
can
just
figure
out
okay,
what
goes
into
that
interface
and
what
goes
into
you
know
specific
media
types.
C
C
C
I
think
we're
adding
the
creator
creator
date
created
date,
which
I
actually
actually
think
those
can
probably
live
on
the
token
and
not
the
metadata,
but
open
a
discussion
on
that,
then
mime
type
definitely
should
be
in
the
metadata,
and
I
don't
know
I
don't
remember
what
the
original
ur
url
is
supposed
to
reference,
but
I
think
things
missing
here
is
definitely
like
traits
and
attributes,
probably
something
that
we
can.
We
can
add
into
here.
C
A
F
B
Yep
so
then
I
had
a
quick
question.
I'm
not
sure
if
that's
to
be
included
in
the
metadata
or
not,
but
like
a
thumbnail
picture
like
open
cpi
is
doing,
which
is
really
cool
because,
like
because
things
like
nfcs
are
mostly
videos
right
and
it
takes
such
a
long
time
to
load
because
it's
heavy
files
and
so
openc
like
they,
I
think,
on
their
api.
I'm
not
sure
if
it's
automatic
from
them
or
if
people
can
upload
thumbnail
images.
But
they
do
that
and
it's
it's.
B
A
E
H
Yeah,
I
had
a
comment.
It
was
not
about
video
format,
I'm
sorry.
It
was
more
about
what
to
discuss
with
traits
just
previously
on
the
and
the
openc
standard,
and
I
think
trades
goes
much
further
than
just
collectibles
and,
like
you
could
use
a
trade
to
say
that
this
character
has
a
sword,
but
you
could
also
use
straight
as
just
a
key
value
sword
saying
this
key.
Has
this
value
and
the
advantage
of
traits
as
they
are
used
that
you
can
see,
is
that
it's
extremely
generic?
H
You
can
use
any
keys
and
any
values
you
want
that
are
relevant
to
to
your
asset.
Basically-
and
this
makes
me
think
that
here
you
are
thinking
about
specifying
the
type
depending
on
what
the
asset
is,
for
example,
adding
or
not
adding
a
resolution
field,
and
I
think
resolution
is
definitely
what
I
would
call
a
trait.
C
A
C
I
think
I
think
it's
both
like
what
alex
mentioned
for
a
thumbnail
like
that
kind
of
while
you're
loading
you
load,
that
like
image
first
and
then
I
think
for
for
us,
like
we
use
different
qualities
on
different
surfaces
like
we
have
these
cards
right,
they'll
use,
maybe
slightly
lower
quality,
and
then
the
full
artwork
page
is
like
a
larger
one.
But
I
think
what
adrian's
mentioning
is
like
basically
leveraging
this
as
a
generic
way
to
like
have
all
any
anything
that
is
not.
That
is
non-standard.
C
We
can
kind
of
stuff
into
here
right,
so
the
trick.
Maybe
full
resolution
is
like
trait
type
resolution
low
and
then
there's
a
value.
The
only
thing
we
would
have
to
figure
out
is
typing.
I
imagine
the
value
you
can
default
to
like
string
and
then
there's
one
more
field
inside
the
attribute.
That's
like
the
the
type
like
it'd
be
like
the
the
typing
for
for
the
value.
C
A
What
would
be
the
guideline
for
when
something
becomes
an
attribute?
I
guess
I
guess
the
point
is
that
it's
optional
and
different
nfts
would
want
to
implement
it
differently.
Lp's
I
mean
it
sounds
like
the
reason
that
you
kind
of
put
resolutions
at
a
higher
level
is
because
you
feel
like
it
really
should
just
be
a
standard
that
every
nft
adopts,
because
this
is
something
that
kind
of
like,
regardless
of
what
type
of
nft
it
is.
A
C
Yeah,
I
think
that's
the
that
was
that's
the
original
thinking,
at
least,
but
I'm
open
to
exploring
what
it
would
look
like
in
here.
I
think,
then
you
would
just
have
to
standardize
like
the
key,
the
key
like
how
do
you,
how
do
you?
How
do
you
describe
what
what
thumbnails
are
or
like
what
resolution
gets
passed
in.
H
Well,
I
mean
like
I
mean
I
agree
with
you
on
on
that,
and
I
would
even
go
further
to
that.
Maybe
even
the
compulsory
entries,
like
creators
could
even
betray
one
reason.
My
first
idea
is
that
it's
it's
backward
compatibility
with
openc.
I
mean
it
might
not
be
a
real
argument,
but
at
least
like
what
exists
right
now
would
be
compatible
out
of
the
box,
and
I
think
this
is.
This
is
a
good
one.
H
Also,
the
thing
is
that
obviously
keys
will
have
to
be
standardized
for
some
keys,
and
the
idea
is
that
the
this
set
of
keys
is
something
that
will
be
partly
standard,
partly
non-standard,
and
this
standard
can
grow
with
time.
If
we
realize
that
at
some
point
we
need
an
additional
field,
it's
very
easy
to
say:
hey
the
json
type,
doesn't
change,
it
stays
the
same
interface.
H
However,
what
does
change
is
that,
in
this
set
of
key,
we
add
an
additional
standard
entry
in
this
set
of
keys,
and
basically
this
this
divides
the
standard
into
two
parts,
and
the
part
that
is
about
parsing
remains
the
same.
Even
though
we
can
extend
the
type
about
key
definition
to
stand
out
about,
kill
fishing.
A
I
I
don't
know
if
I
buy
it,
you
know,
I,
I
think
that
you
know
the
the
schema
is
going
to
be
best
when
it's
really
semantic,
and
I
think
that
kind
of,
like
you
know
the
philosophy
behind
the
graph
and
like
the
schemas,
is
like
you
want
to
have
rich
metadata.
You
want
it
to
be
available
in
the
schema,
you
know
and
it's
structured
data,
and
I
think
that
you
know
one.
A
I'm
not
sure
that,
like
backwards,
compatibility
with
other
apis
should
necessarily
be
a
design
goal,
because
I
feel
like
ultimately
like
there
is
a
translation
process.
You
know
there
is
like
an
etl,
and
so
I
think
it's
okay,
that
it
ends
up
being
different,
and-
and
so
you
know
philosophically
it
feels
to
me
like
the
more
we
can
create.
A
You
know
structured
data
that
creates
a
convenient
api,
that
that
is
preferable
and
to
me,
this
type
of
pattern
should
be
specifically
when
the
structure
of
the
metadata
is
unknowable
right,
because
I
feel
like
there
are
times
where
it's
just
like
truly
dynamic,
and
then
you
basically
the
schema
itself,
needs
to
basically
say
hey.
This
is
dynamic,
but
if
that's
not
the
case,
then
I
think
using
you
know,
structure
and
schemas
is
the
right
tool.
H
One
very
quick
thing
is
when
I
was
thinking
about
backward
compatibility.
I
was
not
thinking
for
some
graph
users
of
developers.
I
was
more
thinking
about
nft
developers,
basically
someone
that
has
an
nft
that
has
structured
metadata.
They
may
want
this
metadata
to
be
readable
by
the
subgraph
and
by
openc.
This
is
the
people
that
would
that
would
benefit.
From
this
background
compatibility.
H
A
Yeah,
so
so
here
here
I
guess
we
we
maybe
separate
the
standard
at
the
contract
level
in
the
subgraph
level,
right
where
I
think
it.
It
would
be
fine
to
have
like
metadata
that
I
guess
like
you're
saying
if
you
want
to
be
compatible
with
openc,
which
of
course
they're
a
large
consumer,
and
maybe
that
is
a
reason
to
structure
the
on-chain
metadata
a
certain
way.
But
I
guess
that
doesn't
mean
that
it
needs
to
be
the
same
schema
for
the
metadata
in
the
subgraph.
C
I
do
think
I
think,
regardless,
I
think
there
there
probably
is
value
in
having
like
subgraph
entities
for
these
attributes,
so
you
could
index
them
for
older
nfts.
It's
just.
I
think
the
question
is
like
whether
or
not
you
pull
things
like
resolution
top
level
or
try
to
stick
it
into
into
this
into
this
like
way
of
doing
it.
So
I
I
think
it's
like
these.
C
These
attributes
should
probably
be
indexable
like
you
should
be
able
to
parse
like
metadata,
and
then
you
should
be
able
to
have
like
on
on
the
like.
The
metadata
entity
you
can
have
like
here
are
the
attributes
and
there's
an
array
right,
but
then
I
think
things
the
the
question
here
is
more
just
like:
okay
for
thumbnails
and
resolutions.
Does
that
belong
in
here
or
is
it
top
level?
And
we
like
basically
say
everybody
should
declare
like
what
your
thumbnail
is
and
what
your
resolutions
are.
A
Yeah,
I
I
tend
towards
that
direction,
but
we
can,
you
know,
carry
on
the
conversation,
maybe
in
the
in
the
google
doc.
If
people
want
to
share
more
comments
there
and
maybe
over
time
we
find
better
places
for
for
discussion
for
these
breakout
things.
But,
okay,
I'm
curious
to
just
go
back
to
the
video
thing,
because
I
feel
like
that's
something
that
a
lot
of
people
are
are
going
to
be
dealing
with.
So
sam
were
were
there
any
more
learnings,
then,
basically
on
an
improvement
to
using
mp4s.
E
Chrome
is
like
starting
to
handle
this
pretty
good
in
terms
of
like
they
actually
lazy
load
videos
past
the
kind
of
scroll
point,
but
it
is
browser-specific
at
the
moment
and
if
you
want
to
start
lazy
loading
in
other
browsers
that
don't
support
that
natively
or
if
you
don't
lazy,
load,
you'll
start
to
like
you'll
start
to
see
all
the
kind
of
like
telltale
signs
of
high
memory
usage.
Like
the
fans
will
spin
up,
everything
will
start
to
creak
a
little
bit.
E
So
what
a
lot
of
the
industry
is
moving
towards
is
streaming
so
you're,
essentially
streaming
a
static
file.
You're
not
streaming
like
a
you,
know,
televised
vision
or
anything
like
that,
but
it
is
essentially
a
looping
video,
and
that
is
a
lot
more
kind
of
like
memory
efficient
in
the
browser,
and
it
allows
you
to
have
many
more
kind
of
like
videos
playing
in
like
in
one
kind
of
viewport
at
a
single
time.
There's
a
couple
of
main
things
to
that.
There's
hls,
which
is
one
format
and
dash
which
is
another
format.
E
E
It's
essentially
kind
of
like
moving
to
a
point
where
you
are
like
streaming
chunks
of
data
in
a
much
more
kind
of
like
performant
fashion.
One
thing
that
we
that
you
still
have
to
then
deal
with
is
like
what
is
the
infrastructure
that
backs
that,
like
it's,
it's
obviously
very
easy
to
just
pull
an
mp4
file
directly
from
a
cdn,
because
it's
just
a
file
that
you're
dumping
in
it
or
from
ipfs
for
that
matter,
but
pulling
eight.
E
The
kind
of
like
the
m,
the
hls
formats,
which
are
actually
kind
of
split
out
in
a
very
different
format,
called
like
a
thing.
It's
like
a
manifest
file
that
has
the
chunks
and
each
chunk
contains
an
array
of
different
qualities,
and
that
is
determined
by
the
browser
and
the
using
some
heuristics
in
your
browser
based
on
my
internet,
speed,
computer
speed,
etc.
E
A
Yeah
really
fascinating,
so
hls
stands
for
http
live
streaming,
that's
correct!
Yeah,
and
I
am
I
am
curious
about.
You
know
how
we
could
add
support
for
something
like
this
in
the
graph.
You
know,
I
feel,
like
the
graph
does
kind
of
have
the
opportunity
to
be
this
kind
of
like
edge
cache
as
well
right.
A
It's
like
indexing
and
caching
already
for,
like
you,
know
the
data
that
you're
querying
and
and
no
reason
why
a
graph
node
you
know
wouldn't
be
able
to
like
serve
this
up,
and
I
I
wonder
it
sounds
like
so.
Hls
is
its
own
protocol,
but
or
when
you
say
it's
like
supported
natively
in
safari,
the
same
way
that,
like
http
or
websockets,
like
it's
like
a
top-level
protocol
and
then
the
the
polyfills
over.
Do
you
know
if
it's
like
over
websockets
or
something.
E
So
the
essentially
what
what
happens
is
yeah
so
so
far
hls
is
actually
created
by
apple.
It's
like
a
standard
that
they
created
and
have
like
open
opened
up
to
us.
You
know,
given
like
a
permissive
license.
Dash
is
a
separate
kind
of
format
that
is
as
well
kind
of
like
probably
much
more
open
and
was
created
kind
of
separately
outside
of
like
a
single
company
but
yeah.
Essentially,
it
acts
as
a
different
protocol,
and
all
that
happens
all
that's
happening
with
the
polyfill.
E
Is
it's
just
a
small
library
that
essentially
kind
of
like
understands
the
the
m3u8
file
format
and
just
understands
how
to
kind
of
pass
it?
So
it's
it's
still
just
pulling
it
over
like
https,
but
it
understands
how
to
actually
pass
it,
whereas
safari
obviously
has
that
passing
built
into
the
browser.
A
E
Yeah
we
at
foundation
use
hls
streaming.
That's
how
we
kind
of
like
pull
in
our
various
video
files
to
display
them.
I
think
yeah.
We,
we
kind
of
like
to
my
point
like
we.
We
realized
that
lots
of
videos
playing
in
our
cards
like
our
artworks
page,
where
there's
a
high
density
of
videos
all
playing
at
once.
E
We
saw
that
there's
a
lot
of
kind
of
heavy
load
that
was
being
put
on
the
browsers
and
people
were
starting
to
notice
that,
like
you,
know,
fans
spinning
up
and
it's
like
not
not
a
great
experience
for
them.
So
we
looked
into
other
things
and
streaming
definitely
seemed
to
like
be
a
better
way
of
handling
that
it
gives
you
a
much
better.
E
You
can
control.
You
have
some
control
in
like
what
quality
is
served
to
the
end
user,
so
you
can
say
like
use.
One
of
the
lower
manifests,
maybe
for
like
small
fight,
you
know.
Small
viewing
sizes,
where
maybe
kind
of
like
speed
over
quality,
is
more
important
to
you,
but
you
can
also
the
browser
itself
will
kind
of
determine
whether
it
should
which
kind
of
quality
version
it
should
be
using
and
for
us,
like,
we
obviously
want
you
know
foundation.
We
want
it
to
be
the
best.
E
We
want
it
to
be
treated
like
a
gallery
right,
so
you
expect
it
to
be
seen
like
you
were
visiting
a
gallery
and
viewing
a
piece
of
art
in
the
reel.
So
we
want
the
fidelity,
the
fidelity
to
be
as
accurate
as
possible
and
closely
representing
that
and
so
yeah
we're
doing
a
lot
of
work,
working
with
like
looking
at
different
providers
and
different
kind
of
ways
of
providing
like
the
best
quality
and
making
sure
that
that
kind
of
ends
up
to
our
browsers.
But
it's.
E
A
And
I
can
say
I
think
that
the
foundation
gallery
experience
is
like
the
smoothest
of
like
any
nft
gallery.
I've
seen
so,
I
feel,
like
y'all,
have
done
a
really
great
job
with
this.
Do
you
take
those
chunks
and
upload
it
to
ipfs?
I
guess
for
whatever
this
encoding
is
for
for
for
these
files
or
like
at
that
point.
If,
if
you
have
to
use
a
service
for
hls,
I
do
you
have
to
just
kind
of
like
point
to
their,
I
guess
urls.
E
Yeah,
so
we're
doing
it
so
that
when
when
the
kind
of
original
asset
is
uploaded,
we
obviously
store
that
original
asset
in
its
kind
of
original
format
on
ipfs,
so
that
it's
forever
decentralized
and,
like
you
know,
kept
there.
But
then
we
take
a
copy
of
that
and
transcode
it
into
an
hls
format,
and
that
is
essentially
what
gets
served
immediately
to
the
end
user
when
they're
visiting
our
pages.
But
you
can
go
and
view
the
original
source
file.
If
you
want
to.
A
C
Yeah,
I
think
the
way
our
mental
model
has
been
like.
We
make
a
distinction
between
like
what's
canonical
and
unchained
and
that's
kind
of
like
what
people
are
trading
and
and
collecting,
and
then
I
think
the
the
rendering
layer
right
now
is
is
centralized,
which
I
think
is
it
seems
like
is
the
same
across
the
board.
I
think
the
world
I
would
love
to
get
us
to
is
like,
for
example,
like
live.
Pier
is
a
decentralized
like
video
infrastructure.
C
I
would
love
to
get
to
a
world
where,
like
we
can,
we
can
also
decentralize
the
rendering
side,
but
right
now
it's
just
like
there's
there's
like
not
decentralized
bills,
people
are
paying,
and
you
know
like
there's
a
decent
or
dirt,
there's
centralized
bills.
People
are
paying
and
centralized
services,
people
are
using
for
rendering,
and
so
I
think
it's
tough
to
put
that
on
chain
right
now
and
put
that
on
on
some
graphs.
A
B
Yeah
and
then
I
feel
like
also
like
very
quickly
yeah,
maybe
on
another
call,
or
maybe
that's
not
useful,
related
to
the
graph.
But
nft
royalties
is
a
very
big
deal
and
I
think
once
you
know
that
this
shortened
bubble
of
studying
art
is
popping,
which
probably
will
in
the
next
few
weeks
or
is
already.
I
think
I
feel
like
royalties
is
really
important
and
I'm
not
sure
if
there's
anything,
the
graph
can
do
to
support
those.
But
like
it's
a
thing
that
we're
thinking
about
a
lot
at
straight
line.
B
Yeah
like,
for
instance,
I
think
on
zora
right
now.
The
creator
of
fee
is
only
to
the
creator
and
we
are
thinking
of
other
ways
to
give
the
royalties
than
the
creator.
Maybe
like
a
pool
that,
like
you
know,
fans
of
the
creator
could
benefit
from,
or
things
like
this
and
so
yeah.
That's
like
more
like
a
political
level
rather
than
like
the
curing,
but
anyway,
just
like.
C
I
think
if
we
do
so,
I
think
if
we
do
a
good
enough
job
of
standardizing
the
way
the
sale
events
are
emitted
and
indexed
and
the
way
the
fee
events
are
emitted
and
indexed,
then
I
think
downstream,
like
consumers
can
construct
whatever
you
know
like
whatever
additional
patterns
they
want.
So,
like
the
show
times
the
up
shots
like
like,
if
there's
a
way
to
report
like
these
are
sales
that
happen.
These
are
fees
that
happen,
and
then
you
guys
can
you
guys
can
build.
On
top
of
that.
G
Yeah
right
right
now,
so
our
contract
doesn't
support
that
use
case,
but
the
api
for
reading
fees
that
open
c
suggested-
and
I
think
variable
originally
put
out
there-
is
flexible
for
that.
So
it
takes
it
returns.
A
array
of
addresses
and
array
of
basis
points
to
send
each
of
those
addresses
so
for
a
use
case
like
what
you're
talking
about.