►
From YouTube: NFT Subgraph Community Call #3
Description
The third NFT Subgraph Community Call took place March 11th.
Join the community and learn more on Discord:
The Graph: https://thegraph.com/discord
The Graph NFTs: https://discord.com/invite/EdZE6EmVKC
A
Hello,
hello,
hello,
welcome
to
the
third
nft
subgraph
community
call,
so
we've
had
yeah
two
really
productive
calls
already,
and
we've
got
a
few
new
people
on
the
call
today.
So
it's
been
a
nice
kind
of
mix
of
folks
cycling
in
and
out
every
week
curious,
if,
if
any
of
the
the
folks
this
week
want
to
just
share
a
little
bit
about
what
they're
building
just
so
we
can
see.
You
know
what
is
kind
of
happening
in
in
the.
B
B
C
Cool,
I
can
jump
in
so
hi,
everyone
yeah,
it's
the
first
time,
I'm
joined
the
call
my
name's
sam
I've
built,
I
kind
of
actually
just
announced
today,
I'm
joining
foundation
full-time
as
of
next
week,
so
I'll
kind
of
be
now
full
time
in
space
which
is
exciting.
For
me,
I've
built
a
bunch
of
other
little
kind
of
side
projects
terminal
is
one
that
obviously
uses
subgraph
foundation
subgraph
to
show
data
I
built
and
there's
a
bunch
of
other
tools.
C
D
Cool
yeah,
sam
sam's
underselling
himself,
but
the
reason
why
I
think
he's
going
to
provide
really
good
insight
into
the
metadata
is
because
he
built
among
many
other
tools,
one
that
helps
any
website
embed
at
any.
I
think
721
for
now
and
then
1155
moving
forward
as
well,
but
and
it
works
with
any
like
standardized
contract
and
makes
it
just
like
one.
I
think
it's
like
one
or
two
lines:
you
drop
it
down
to
your
website
and
you
embed
it
in
nft
and
so
in
the
process
of
doing
that.
C
A
F
I
can
introduce
myself
sorry
hi,
everybody,
I'm
eg.
I
work
on
infira,
which
does
blockchain
infrastructure
apis.
We
don't
do
anything
specific
to
nfts
or
subgraphs
at
the
moment,
but
we've
been
involved
with
a
lot
of
standardization
for
the
json
rpc
api.
Some
some
work
with
go
ethereum's,
graphql,
api,
spec,
and
so
we're
also
interested
in
like
how
how
data's
indexed
and
standards
around
that
so
just
wanted
to
get
involved
and
see.
If
we
could
help
with
anything.
B
We're
selling
nfts,
basically
streaming
money
to
social
costs
at
the
same
time
and
basically
we're
creating
a
protocol,
a
multi-gallery
system,
and
you
can
think
about
it
like
a
meta
gallery
or
metadow,
where
you
can
have
sub-dials
inside
the
inside
the
protocol
that
we're
creating
and
yeah.
I'm
just
excited
to
be
to
be
part
of
this
call.
A
A
So
if
you
don't
have
an
invite
to
this
air
table
just
reach
out
in
the
telegram
or
in
the
discord
and
and
we'll
get
you
added
here
so
so
we
can
collab.
I
think
it's
about
30-40
people
that
have
creator
access
to
this
now.
So
we
added
a
few
of
these
sub
graphs
on
the
call
last
week,
and
some
of
these
are
complete.
A
A
Otherwise,
you
know
in
progress
or
maybe
I
still
think
we
should
find
a
better
name
for
this
unclaimed,
but
kind
of
basically,
I
guess
it
would
be
to
do.
We
can
kind
of
track
that
and
then,
if
somebody
wants
to
take
ownership
of
you
know,
hey
I'll,
go
ahead
and
you
know
build
the
subgraph
and
just
put
yourself
as
the
owner
and
and
that
way
we
can.
We've
got
a
place
to
track
all
this
stuff.
A
Then
last
week
we
spent
some
time
discussing
standards
and
you
know
standards
can
really
apply
both
at
the
smart
contract
level
and
at
the
subgraph
level
right.
So
you
know
on
ethereum,
there's
the
erc,
you
know
standards
and
you
know
it
could
be
that
maybe
some
of
these
things
should
go
through
a
sort
of
erc
standard,
but
then
for
sub
graphs
we
can
also
standardize
and-
and
that
makes
it
easier
to
compose
different
subgraphs
together.
A
A
A
So
last
week
we
assigned
some
ownerships
for
some
of
these
areas
for
standardization
and
today,
we'll
go
through
and
we'll
have
people
discuss
their
proposals
for
these.
You
know
schema
standards,
and
we
can
have
some
open
discussion
about
that.
They
can
share.
You
know
why
they
think
you
know
a
a
given
design
is
the
right
one
and
and
we
can
have
open
discussion
and
then
the
output
of
this
should
be
a
set
of
grc's.
A
D
A
couple
couple
things
to
note
here:
I
know
a
lot
of
people
have
immutable
contracts
so,
like
I
think
this
is
really
just
like
a
standard
update
on
the
graph.
Basically,
the
people's
contracts
can
stay
the
same,
but
the
way
we
index
it.
I
think
we
can
start
standardizing
there
and
return
this
field
and
I
think
it
should
be
required.
D
It
could
be
zero
if
if
people
want
it
to
be
like
mt,
but
I
do
think
it's
a
field
that
it
could
be
either
zero
or
message
under
but
like
it
should
be
a
field
that
makes
it
really
easy
for
people
to
know
like
who.
Who
is
the
creator
of
this
nft
and
I
think
some
some
some
additional
discussion
points
here
is.
I
know
people
have
talked
about
like
fee
splitting
and
potentially
returning
like
multiple
addresses.
D
My
hot
take
here
is
like
that
can
happen
upstream,
like
multi-sigs,
and
so
I
would
keep
this
a
single
address
like
every
nft
is
always
created
by
one
reversal,
one
address
as
the
token
creator
and
then
if
people
are
wanting
to
form
dowels
that
meant
nfts
or
figure
out
how
to
like
do
collabs
via
smart
contracts,
they
can.
They
can
take
that
upstream
and
I
have
like
multi-stick
handle
that.
D
Yeah,
that's
a
good
point.
I
think
the
the
pseudo
code
I
put
here
is
solidity,
but
in
the
subgraph
world
I
do
think
it's
probably
going
to
be
an
entity
rather
than
like
a
straight
up
address.
Don't
have
a
strong
opinion
right
now
on
whether
it's
like
we
have
creators,
and
then
you
have
subsets
of
that.
There
are
accounts,
but
I
think
we
once
we
hash
that
out,
I'm
happy
to
use
either
there.
A
Yeah
one
thing
to
you
know,
keep
in
mind
there.
I
guess,
as
we're
talking
about
subgraph
composition,
is
you
know
we
are
planning
to
to
have
basically
an
ethereum
network
subgraph
that
indexes
you
know
a
lot
of
the
kind
of
you
know.
Raw
blockchain
data
from
ethereum,
including
you
know,
blocks
transactions,
accounts,
etc,
and
so
once
you
have
composition
that
makes
this
kind
of
thing.
G
D
Yeah,
I
don't
know,
I
don't
know
if
anybody
from
nifty's
here
and
I
don't
know
what
the
implementation
looks
like,
but
I
imagine
like
somewhere
in
that
stack.
There
is
an
address
so,
like
my
my
prompt
here
would
be
to
like
at
the
sub
graph
layer
when
you're
indexing
indexing
that
you
would
that
you'd
go
all
the
way
to
the
address
and
then
index
that,
rather
than
returning
the
string.
A
A
D
D
D
So
openc
has
a
standard
at
the
contract
layer
and
then
I
think
wearable
also
honors
this
right
now
and
so
there's
there's
essentially
two
functions
at
the
contract
layer
where
you
can
get
the
recipients
and
then
you
can
get
the
fee
amounts
and
bips,
and
so
both
of
those
return,
arrays
and
the
cool
thing
is.
It
allows
a
lot
of
flexibility.
D
If
you
want
to
you,
can
honor
each
other's
like
you?
Can
each
marketplace
can
honor
each
other's
fees
as
well,
because
that
array
can
include
both
the
creator
and
the
marketplace
fee.
So
there's
there's
good
things
there,
but
in
some
other
ways
I
think
it
might
also
be
like
overkill
and
might
be
too
complicated,
and
so
the
alternative
that
I
I
I'm
proposing
here
is
also
just
like
a
very
simple
field.
D
That's
like
get
creator
and
fee,
so
you
get
a
token
give
it
a
token
id
just
give
you
the
address
and
then
and
then
just
the
amount
that
should
be
paid
out.
Obviously,
both
the
whatever
we
choose
we
need
to
translate
to
into
like
graph
entities,
but
I
think
we
can
at
least
start
thinking
about,
like
what
approach
makes
sense,
and
I
would
open
this
up
to.
G
I
was
gonna
say
I
think
this
is.
This
is
an
interesting
one,
because
I
think
this
seems
this
obviously
pushing
for
a
standard
on
on
chain,
which
I
think
it
would
be
great
but,
like
I
think
people
are
gonna,
do
their
own
thing
as
well.
So
I
guess
the
question
is
whether,
like
like
you
said
when
it
comes
to
the
graph
entities,
whether
we
have
a
bit
more
of
a
like
polymorphic,
like
approach
that
could
take
and
but
and
then
that's
maybe
actually
interesting
for
people
wearing
sparkle.
G
A
Yeah,
so
it's
it's
an
interesting
question
of
you
know:
people
are
going
to
have
different
types
of
contracts,
and
so
you
know
I
guess
the
subgraphs
can
kind
of
deal
with
that
fact.
You
know,
assuming
that
you
know
maybe
not
everybody's
going
to
adhere
to
the
same
on-chain
standard,
but
you
know
what
what
what
do
we
think
would
be
the
advantages
of
like
trying
to
get
everybody
to
use
the
same
kind
of
standard
for
their
contracts.
G
D
The
danger
here
is
like
if
we
go
with
this
convention,
like
the
fees
just
stack
up
right
because,
like
I
think,
if
say,
one
platform
wants
to
honor
another's
fees,
but
then
they're
charging
their
own,
like
the
buyer,
just
gets
like
fee
on
top
of
fee
on
top
of
fee.
So
if
we
do
want
to
go
that
route,
my
proposal
would
probably
be
like
there's
a
like
issuer.
D
A
D
I
think
it's
got
to
be
both
because,
like
issuers
of
nfts
want
to
make
sure
that
the
creator
gets
paid,
you
know
the
secondary
fees
and
that's
a
big
sell
for
the
creators
and
then
for
marketplaces.
I
think
people
do
want
to
generally
like
honor
that
as
well
and
so
on
doing
it
in
a
way
that
it
that
makes
sense
for
them
as
a
business,
I
think,
is
important.
A
B
A
A
D
D
H
Maybe
it
would
be
a
first
to
rather
than
standardized
function,
standardized
events
and
we
just
expect
an
event
to
be
emitted
with
the
creator
or
something
like
that,
and
that
way
we
don't
have
to
store
the
creator
on
chain
which
cost
over
20
000
gas.
But
there
would
be
a
standard
even
that
we
can
catch
in
the.
D
Graph
yeah,
I
think
I
think
that
makes
sense.
I
think
figure
out.
The
events
will
have
implications
of
what
the
schema
looks
like
on
the
graph
anyway,
so
we
can
start
there
down
for
that.
I
do
think
there's
my
optic.
I
do
think
there's
value
in
having
the
creator
on
change,
so
the
contracts
can
talk
to
each
other,
but
that's
a
separate
conversation.
D
B
D
F
A
H
Okay,
sometimes
so
in
my
sub
graphs,
there
is
an
event
interface
and
this
event
interface
says
that
you
should
have
a
reference
to
a
block
number
a
transaction
number
and
that
kind
of
stuff,
and
then
every
time
I
register
an
event
such
as
a
transfer
and
an
approval
it
inherits
from
from
transfer.
However,
sometimes
I
build
more
complex
graph
where
there
are
like
well
at
wallet
related
events,
so
you've
got
a
bunch
of
events
that
all
have
a
wallet
field
inside
them
and
then
in
the
wallet
entity.
H
H
A
A
A
A
F
So
here's
maybe
a
rough
sketch
for
some
things.
We
could
do
so
on
this.
You
could
maybe
have
a
contract
entity
and
then
the
contract
entity
would
house
nfts
at
these
kind
of
contract,
token
id
tuples,
and
then
off
of
that
you
could
have
different
events
linking
off
the
nfts
and
if
you
want,
we
could
have
an
account
linking
to
an
nft
and
then
on
the
account
have
a
creator
fee.
F
F
D
F
F
What
I
think
also
is
really
important
down.
The
road
is,
instead
of
just
tracking
transfers,
to
track
the
amounts
that
are
associated
with
the
transfers.
If
we
can
so
we
get
that
purchase
history
graph,
otherwise,
a
lot
of
times
all
you
really
care
about
is
the
last
transfer
which
you
just
get
off
the
contract,
that's
the
owner
of.
But
if
you
have
the
prices
along
the
way,
then
you
can
get
a
cool
picture
of
the
transfers.
D
Yeah,
I
think
we
talked
about
this
in
the
last
call.
Where
you
can,
you
can
go
to
the
most
primitive
layer
and
like
each
sale.
Essentially
all
you
need
is
like
who
it
came
from
like
who
sold
it,
who
bought
it?
What
the
currency
is,
you
could
do
zero
for
eth
and
then
what
the
amount
is,
which
I
think
is
sufficient
for
almost
everybody
and
then
if
people
want
to
layer
on
top
like
their
graph
can
have
additional
fields
that
are
not
like
exclusive
and
that's
okay,.
D
D
I
think
that
one's
probably
more
controversial
in
some
ways-
and
I
don't
know
that
even
if
you
have
it,
people
would
honor
it.
So
I
think
creator
fee
is
probably
the
most
important
one,
and
we
start
with
that,
and
then
I
think
it
will
probably
be
more
contentious
if
there's
platforms
here
on
whether
or
not
they
want
to
honor
each
other.
As
I
get
shooter
fees
it
could
be,
we
can
make
it
an
optional
field
right,
but,
like
creator
feel
that
would
make
like
required.
A
D
A
Okay
and
then
here
we've
got
metadata
and
then
colon
metadata,
so
metadata
is
its
own
kind
of
entity,
which
I
guess
dovetails
maybe
nicely
to
the
next
one
that
we're
having
sam
think
about.
Is
that
also?
You
know
how
you're
thinking
about
that?
We
kind
of
brought
this
up
for
the
question
last
week
of
whether
you
know
metadata
is
just
its
own
entity
and
or
if
it's
just
kind
of
you
know
just
put
the
fields
directly
on
the
nft
or
what
the
best
approach
is
there.
C
C
E
C
Cool
so
yeah,
like
I
a
bit
of
background
like
when
I
was
working
building
out
nfte.app.
Obviously
I
was
interacting
and
it's
great
to
have
eg
on
the
call,
because
I'm
using
infuria
in
the
background
to
basically
pull
data
directly
from
the
blockchain,
mostly
because
not
everything
has
a
subgraph
associated
with
it.
C
So
it's
obviously
pretty
tricky,
especially
when
you're
trying
to
like
make
sure
it's
as
open
as
possible,
and
one
of
the
issues
I
found
was
obviously
like
you
know,
depending
on
which
platform
you're
talking
to
and
which
platform
you
kind
of
want
to
fetch.
Data
on
everyone
has
slightly
obviously
different
standards.
C
It's
become
pretty
apparent
that,
like
the
721
standard,
while
obviously
extremely
popular,
like
the
metadata
that
the
metadata
the
standard
that
kind
of
comes
baked
into
it,
is
starting
to
kind
of
like
we're,
starting
to
see
like
bits
where
it's
potentially
not
as
not
as
extensible
or
not
as
kind
of
like
full
features
as
we
wanted,
or
maybe
not
even
full
feature.
That's
the
right
word,
but
extensible.
C
C
But,
as
I
see
it,
there's
there
could
be
a
metadata
schema,
uri
and
names
obviously
still
up
in
the
air,
and
that
would
resolve
to
just
a
json
file,
a
json
schema
file,
and
inside
of
that
we
have
just
a
standard.
Json
schema
following
all
of
the
various
conventions
that
have
been
laid
out
inside
of
like
json
schema
and
all
the
data
that
we'd
we'd
expect
from
that.
C
This
means
that,
like
it's,
essentially
becomes
kind
of
introspective,
we
can
like
pull
the
the
schema
first,
we
can
run
it
through
figure
out
exactly
what
we're
going
to
expect
when
we
kind
of
dive
into
the
token
uri
and
then
once
we
do
that,
we
can
then
pull
out
the
data
that
we're
expecting
safely
and
with
types
essentially
or
like
known
types
that
we
can
get
out
of
it.
I
threw
together
some
extremely
the
way
that
I
kind
of
imagined
it
being
is.
A
Yeah,
absolutely
so
you
know,
sub
graph.
Mappings
are
really
flexible
in.
You
know
how
you
process
the
data,
so
you
know
there's
their
existing
tools.
I
mean
you're
you're.
You
have
to
write
that
logic
in
assembly
script
right,
which
is
a
typescript
that
compiles
to
wasm.
There
are
some
utilities
that
are
available
that
are
written
in
assembly
script.
You
don't
necessarily
get
like
the
full
kind
of
typescript.
A
You
know
npm
ecosystem,
since
a
lot
of
those
different
libraries
don't
compile
to
you,
know,
assembly
script
but
or
or
to
wasm,
but
we
could
look
at
like
what
specific
kind
of
adjacent
parsing
tools
you
need
and
and
and
see
just
kind
of
how
we
can
make
that
easy
to
do.
But
that's
all
things
that
you
should
definitely
be
able
to
do
in
in
the
mappings.
H
A
Yeah,
so
you
definitely
should
be
able
to
do
this,
and-
and
I
think
that's
I
mean
that's-
that's
the
idea
behind
the
mappings
right
is,
you
know
just
getting
a
single
data.
Uri
is
pretty
inflexible
and,
and
you
want
to
be
able
to
like
you,
know,
query
and
filter
on
these
specific
fields.
So
you
want
to
really
you
know,
parse
as
much
of
that
data
as
possible
and
store
it
natively
as
entities,
so
that
you
can
kind
of
you
know,
query
them.
However,
you
want.
A
A
C
Yeah,
I
hadn't
quite
thought
about
how
I
yeah
I
guess.
Basically
the
schema
would
have
a
url
and
that
url
would
in
the
same
way
that
I
think
zoro
does
it
currently.
The
url
essentially
can
be
like
converted
into
a
hash
that
is
like
that
is
always
the
same
for
that
particular
common
common
type.
So
you
can
just
verify
like.
Oh,
if
it
matches
its
hash,
then
it's
an
image
schema
and
we
can
expect
this,
and
maybe
you
can
pull
down
the
schema
remotely
from
somewhere
but
yeah.
C
C
I
imagine
there'll
be
ones
for
images,
videos
and
then
I
imagine
there
could
be
you
know
you
could
potentially
have
like
platform
specific
ones
or
marketplace
specific
ones
depending
on,
if
you're
creating
a
brand
new
one,
maybe
you're,
building
one
nft
for,
like
you,
know,
law
contracts
or
something
that
has
a
certain
amount
of
metadata
that
needs
to
be
captured.
You
could
kind
of
have
a
text,
one
there's
the
basis
and
build
on
top
from
that.
A
B
A
Oh
yeah,
so
that's
cool
actually
sebastian
not
sure
if,
if
you'll
be
able
to
join
us
next
week,
but
I
guess
we're
getting
close
to
the
end
of
the
the
hour
here.
So
maybe
we
can
just
kind
of
jump
to
some
some
next
steps
here.
So
this
looks
really
great
and
I
think
I'd
love
it
if
we
could
put
this
in
a
place
where
other
people
can
review
and
kind
of,
provide
comments
on
these
fields.
A
A
Awesome
thanks
yeah,
so
if
we
just
look
at
the
standards
that
we
had
already
kind
of
lined
up
here,
so
today
we're
able
to
talk
about
the
fee
standards,
metadata
and
creator,
I
think
we
still
want
to
discuss
kind
of
marketplace,
and
you
know
we
we
haven't.
Quite
I
found
owners
for
these
were
standards
that
were
proposed.
Does
anybody
have
anything
that
they
would
kind
of
like
add
to
the
list
here
of
things
that
would
be
worth
discussing
for
next
week?.
G
Go,
I
think
one
thing
I've
been
thinking
about.
It
might
be
a
bit
left,
but
I
feel
that
maybe
like
wider
than
energy
is
just
sort
of
handling
like
multiple
versions
or
like
or
like
upgrades
of
a
given
contract
or
a
protocol
or
whatever,
and
currently
those
things
I
think
live
in
separate
subgraphs
generally,
but
it
kind
of
comes
into
the
composability
thing
of.
If
you
like,
how
do
you
combine
version
one
of
a
protocol
with
version
two
of
a
protocol?
G
So
if
you've
got
immutability
or
you
don't
have
upgradability
on
in
the
solidity
specifically
for
nifty
we're
thinking
like?
Could
we
actually
just
merge
them
into
two
like
the
two,
like
versions
into
one
sub
graph,
I'm
just
looking
at
different
contracts
that
kind
of
kept
track
of
which
version
things
were
coming
from?
But
I
don't
know
if
that's
a
problem
that
other
people
thought
about.
A
Yeah,
I
could
see
that
as
being
something
that
you
know
it
would
help
to
have
standard
ways
of
dealing
with
versions
and
in
an
ideal
world.
I
guess
the
subgraph
would
maybe
abstract
you
a
bit
from
that,
because
you
could
have
you
know,
contracts
going
through
multiple
versions,
but
then
kind
of
they
would
just
get
mapped
to
the
same
kind
of
graphql
schema,
and
you
know
we
have.
A
You
know,
support
for
for
actually
not
live
yet,
but
we're
working
on
support
for
versions
which
makes
a
lot
more
sense
in
the
decentralized
network
where
you've
got
these
id's
yeah.
What
I
mean
oh
and
I
just
muted
mandy
there,
so
I
think
it
is
worth
exploring.
We
could
talk
about.
What
that
looks
like
here
is
that
something
you
would
want
to
take
on.
E
Yeah
we're
we're
mostly
interested
in
the
the
price
action
around
this
stuff.
One
thing
I'd
be
curious
to
hear
people's
opinions
on
is
if
it
makes
sense
to
track
price
information
at
the
kind
of
contract
like
per
nfc
contract,
as
well
as
at
the
marketplace
level,
essentially
aggregating.
All
these
marketplace
activities
in
each
nft
contract.
We
touched
it
a
little
bit
earlier
with
the
kind
of
amounts
accompanying
transfers,
but
I'd
be
curious
if
that's
of
interest
or,
if
just
tracking,
all
marketplaces
and
getting
nft
prices
that
way
makes.
E
Yeah
I
like
we
can
track
all
of
the
nfts
within
a
marketplace,
but
also
I
can
just
point
to
the
the
crypto
punks
sub
graph
and
track
all
of
the
activity
that
happens
across
any
marketplaces.
That
subgraph
is
tracking
and
do
that
on
a
kind
of
per
nft
level
or
basis
limiting
the
the
kind
of
number
of
idiosyncrasies
that
have
to
be
kind
of
added
on
to
schemas
to
just
the
kind
of
contracts
themselves
that
nfc
contracts
themselves
as
opposed
to
changes
to
kind
of
marketplace,
structures
and
interactions.
If
that
makes
sense,.
A
A
Okay,
cool,
so
next
thing
just
I
wanted
to
share
really
quickly
and
we've
just
got
like
a
minute.
Left
is
brandon.
Just
posted
he's,
one
of
our
co-founders
research
lead
this
forum
post
describing
the
grc
process,
so
we
announced
today
we
just
published
a
blog
post
describing
how
we're
using
radical
for
our
governance
at
the
graph
and
and
so
when
people
have
like
gips,
which
are
graph
improvement,
proposals
or
grc's,
which
are
these
kind
of
like
standards,
application
level
standards.
A
This
is
you
know
how
we,
you
know,
publish
these
grc's
using
radical
and,
and
then
the
the
process
is
basically,
you
know
once
there's
a
grc
on
radical.
We
create
a
forum
post,
so
we
can
have
discussion
in
the
forum.
We've
had
gips
go
through
this
process
where
there
were
like
hundreds
of
comments
and
like
lively
debate
here
and
then
you
know,
this
can
be
a
way
that
we
kind
of
track
things
through
the
process
and
eventually
end
up
with
the
standard.
A
So
at
this
point
I
think
you
know
we're
kind
of
in
the
working
group
stage
trying
to
get
some
broad
level
consensus,
but
I
think
it
would
be
really
awesome
if,
at
the
end
of
this,
we
ended
up
with
some
grc's
that
kind
of
go
through
the
governance
process
and
actually
end
up.
Getting
kind
of
you
know,
voted
on
and
approved,
and
you
know
be,
would
be
a
really
cool
output
of
this,
but
great,
I
think,
that's
a
good
place
to
end
for
today.
A
So
you
know
we
were
able
to
make
a
lot
of
progress
going
over
some
of
these
proposals.
I
think
giving
people
time
to
you
know,
review
them
after
the
fact
would
be
really
useful.
So,
let's
find
a
way
to
just
share
those
things
out
so
that
maybe
we
can
get
them
added
like
to
the
forum
where
people
can
kind
of
add
comments
and
discussion
and,
and
then
we'll
reconvene
next
week
to
go
over
the
next
set
of
standards
and
and
try
to
converge
on
some
of
these
things.