►
From YouTube: GraphSync with Hannah Howard
Description
Join us for Filecoin Liftoff Week, an action-packed series of talks, workshops, and panels curated by the web3 community to celebrate the Filecoin mainnet launch and chart the network’s future. https://liftoff.filecoin.io/
Events take place all week, October 19-23, 2020. #FilecoinLiftoff
For more information on Filecoin
- visit the project website: https://filecoin.io/
- or follow Filecoin on Twitter: https://twitter.com/Filecoin
Get Filecoin community news and announcements in your inbox, monthly: http://eepurl.com/gbfn1n
A
Welcome
to
this
talk,
I'm
just
who
I
am
my
name
is
hold
on.
Let
me
just
make
sure
it's
working
okay,
cool.
B
A
So
my
name
is
hannah
howard,
I'm
the
primary
author
of
the
grassland
protocol.
You
can
find
me
on
the
internet
at
tech
girl,
wonder
I
use
she
her
pronouns
and
I
work
for
an
organization
called
carbon.
Five
carbon
fives
product
development
agency
we've
been
involved
in
the
development
of
file
points
since
almost
the
very
beginning
we're
one
of
the
sort
of
like
long
time,
partners
with
protocol
labs
and
I've
been
working
on
ipfs
graph,
sync
filecoin
for
over
a
couple
years.
A
Now
this
talk
is,
is
gonna,
be
super
improv
a
little
bit.
I
put
this
together
right
before
you
know
it
was
sort
of
last
minute,
so
bear
with
me
we're
gonna
do
our
best,
let's
dive
in
cool
okay.
Let's
talk
about
graph
sync,
so
graph
sync
is
a
protocol
to
synchronize
merkle,
dag
graphs
across
piers,
which
probably
means
very
little
to
anyone
who
doesn't
know
the
deep
tech
glitters.
So
let's
find
a
different
definition
for
grossing.
A
So
I
would
say
graph:
sync
is
the
thing
that
gets
your
data
from
one
place
to
another
in
file
coin.
Everyone
understands
that.
So
I'm
gonna
go
with
that.
As
as
my
working
definition
and
then
I'll
talk
to
you
about
how
it
actually
works
and
where
that
other
definition
comes
from
cool,
so
let's
talk
about
the
filecoin
environment
and
how
data
transfer
and
how
we
need
to
move
data
around
in
filecoin,
the
filecoin
environment
has
some
pretty
interesting
characteristics.
A
One
is
that
essentially,
no
one,
I'm
calling
them
peers,
but
no
one
involved
in
filepoint
trusts
each
other
right.
Anyone
who
can
participate
in
the
file
point
network
is
potentially
someone
who
is
a
malicious
actor
for
the
most
part.
People
are
untrusted.
That
means
that
when
I
receive
a
request
for
data,
unless
we
have
some
other
mechanism
for
verifying,
we
don't
trust
that
the
person
who's
making
the
request
is
is
actually
acting.
A
Acting
in
good
faith,
they
may
be
trying
to
request
lots
of
data
for
the
purpose
of
just
slowing
my
computer
down
and
or
basically
causing
me
to
run
out
of
memory.
Also,
if
I
am
requesting
data,
would
I
get
back
by
default?
I
can't
trust.
I
have
no
way
of
knowing
whether
the
data
that
I
am
getting
back
is
the
the
right
data.
Unless
I
have
some
way.
A
You
know
with
mathematica
with
you
know
our.
A
Rely
on
trust,
I
I
cannot
trust
it
so,
and
then
the
and
so
our
goal
is
that
we
want
to
be
able
to
do
these
data
transfers
in
a
way
that
minimizes
the
effects
of
malicious
behavior.
So
a
key
aspect
of
that
is
that.
A
As
we
transfer
data
from
one
place
another,
we
need
to
be
able
to
verify
that
data
and
we
need
to
be
able
to
verify
it
incrementally.
So
we
don't
want
to.
We
want
to
know
that
we're
getting
the
right
data,
we
want
to
be
able
to
know
it
every
step
of
the
process.
So,
if
we're
transferring
gigabytes
of
data,
we
need
to
be
able
to
know
that
at
one
gigabyte,
we've
already
gotten
the
correct
first
gigabyte
and
then
the
correct
second,
the
correct
third,
so
that
we.
A
Find
out,
it
was
all
just
garbage.
The
other
thing
is
that
we
would
like
to
wait.
We
would
like
to
that
for
this
transfer,
despite
these
properties,
to
be
fast,
ideally
as
fast
as
a
transfer
over
traditional
http
or
faster.
Ideally,
in
some
cases,
though,
in
the
case
of
filepoint,
we're
usually
just
moving
from
one
pair
to
another,
so
it's
it's
essentially
pretty
similar
to
an
http
setup.
One
thing
that's
going
to
be
key,
for
that
is.
A
We
would
like
to
not
gate
that
transfer
around
round
trips
between
the
client
and
between
the
requester
and
the
responder
we
want
to
be.
We
want
the
responder
to
be
able
to
send
data
without
waiting
for
the
client
to
acknowledge
that
they
verified
the
correct
data.
So
what
is
that?
So?
What
is
it
that
we're
transferring
here?
So
basically,
the
key
to
doing
incremental
data
transfer
is
to
transfer
it
with
a
data
structure.
A
We
call
a
merkle
dag
now
these
data
structures,
a
merkle
dag,
is
a
is
a
really
common
data
structure
in
all
those
sort
of
protocols.
Protocol
software-
you
you
may,
if
you've
used
ipfs,
you
have
probably
worked
with
merkel.
Dags
merkel,
that
what
so
what
a
merkle
dag
is
is.
Let's
say
I
have
a
giant
chunk
of
data
right
now.
A
I
could
all
arguably
I
could
take
that
entire
data
hash
it
and
then
basically
say
send
me
all
the
data
and
verify
that
the
hash
that
I
get
matches
the
hash
you
told
me
would
be
the
data
would
have-
and
that's
that's
a
simple
way
of
doing
it.
A
But
if
we
wanted
to
break
up
lots
and
lots
of
data,
a
merkel
dag
is
essentially
a
series
of
blocks
of
data,
each
of
which
have
a
hash
where
the
root
block
has
links
to
additional
blocks
and
then
and
those
links
are
the
hash
of
those
blocks.
So
you
can
imagine
in
this
diagram,
you
have
a
root
block
and
it
has
some
sort
of
hash.
I'm
putting
these
like
q
m
hashes,
because
those
are
usually
the
what
hashes
often
look
like
in
in
ipfs
and
filecoin.
A
We
refer
to
these
as
cids
or
content
identifiers.
They
are
essentially
a
mathematical
hash,
plus
some
additional
data
and
and
you
you
would
imagine
this
root
block
you
can
see
inside
somewhere
inside
the
data.
For
the
block,
we
have
the
hashes
of
the
blocks
that
it
links
to.
So
here
you
have
a
link
to
this
block,
and
here
you
have
a
link
to
this
block
and
they
each
have
their
hash,
and
then
they
have
links
to
other
blocks
right.
So
this
is.
A
This
is
essentially
a
way
of
breaking
up
a
giant
piece
of
data
into
smaller
bits
of
data
where
at
any
given
level,
we
can
verify
that
we
have
the
right
data
and
any
other,
and
we
know
how
to
get
the
next
bit
of
the
right
data.
So
that's
a
miracle
bag.
What's
in
what
does
the
actual
inside
of
these
blocks?
Look
like,
so
it
could
look
like
anything
technically,
but
the
actual
structure
that
we
use
for
for
file
point
is
something
called
ipld,
which
is
essentially
a
distributed.
A
Data
format.
There's
a
talk,
I
think,
on
the
main
track
later
today,
where
you
can
learn
a
lot
more
about
ipld,
but
essentially
it
is
a
format
for
distributed
data,
the
short
form
the
you
can
imagine
that
what
it
looks
like
inside
of
a
single
block
is,
you
might
have
a
series
of
nodes
inside
of
a
block
where
each
node
is
a
type
of
data
right.
You
might
have
an.
A
Might
have
a
map
node,
which
is
like
you
know,
analogous
to
you,
know
a
map
or
or
hash
table
or
or
just
like
a
javascript.
B
A
A
Node
is
essentially
a
link
to
another
block
of
data,
so
the
short
form
that
I
use
for
describing
ipld
is
distributed,
json,
which
is
a
super
simplification
of
what
it
actually
is
because
ipld
one
of
its
explicit
goals
is
to
not
be
tied
to
a
serialization
format.
It
could
be
serialized
as
json.
It
could
be
serialized
as
something
like
a
seabor,
which
is
the
common
binary
object
representation.
A
We
also
use
protobufs
for
it,
but
the
way-
but
it's
very
easy
for
me,
as
a
human
to
think
about
it
or
a
human
programmer
to
think
about
it
as
json
with
links
in
it.
So
you
can
imagine
this
is
a
json
representation
of
what
I
showed
you
in
the
past
diagram,
and-
and
so
you
know-
and
so
here
it's
basically
it
looks
like
json,
but
we
have
this
one
special
type,
which
is
this
link.
A
This
link
type
where
we
actually
have
a
link
to
another
block,
and
with
that
addition,
we
can
essentially
build
a
distributed
data
structure.
So
so,
essentially
our
our
challenge
is:
how
do
we
replicate
a
merkle
dag
of
ipl
date
data
over
the
network?
Right
now
you
can
imagine
if
we
were
doing
traditional
http,
we
could
probably
throw
out
all
these
data
structures
and
we
could
throw
out.
We
throw
out
the
need
to
verify
incrementally
and
we
could
rely
on
essentially.
A
Of
verifying
authenticity
or
essentially,
we
could
trust
that
you
know
as
long
as
we
can
verify
that
the
ssl
certificate
you
know
for
cnn.com
is
valid
and
we
trust
cnn,
for
whatever
reason,
we
can
trust
that
the
data
they're
sending
is
correct
and
we
can
simply
send
all
the
data
across
and
then
display
it.
We
probably
don't
even
verify
it
and
often
you
know
when
you're
downloading
files
for
it
from
the
internet.
A
Unless
they,
you
know,
unless
it's
a
security,
conscious
site,
they
won't
even
give
you
a
content,
a
cryptographic
hash
of
what
the
data
you're
downloading
is
so
that
you
can
verify
it.
You
just
like
you
know,
download
a
program
and
open
it,
which
seems
extremely
extremely
risky,
but
in
any
case,
that's
that's
essentially
what
you're
doing
in
http.
A
So
we
developed
ways
over
the
course
of
the
development
of
ibs
to
transfer
this
kind
of
data
in
a
trustless
environment
and
the
original
solution
we
have.
Is
this
protocol
called
bitswap?
Sorry
bitswap
is
essentially
the
basic
way
it
works.
Is
you
request
a
a
single
block
from
another
peer?
A
You
request
a
one
block
starting
at
the
root,
and
when-
and
you
say
I
want
the-
I
want
the
block
with
this
cryptographic
hash
and
then,
when
somebody
sends
you
back
that
block,
you
can
look
at
that
block,
run
a
hash
against
it
and
verify
that
the
hashes
match.
You
now
know
that
that
block
is
valid
and
therefore
the
hashes
to
other
blocks
inside
that
block
are
the
hashes
to
the
remaining
data.
A
So
you
can
imagine
we
would
make
a
request
for
a
top
block
for
the
root
block
and
then
once
we've
done
that
we
could
traverse
down
to
one
of
the
links
in
the
block
and
request
that
block
we
get
the
data
back.
We
can
verify
it
again
and
then
once
we
get
that
black
we'll
know
the
links
to
the
to
the
next
child
blocks
and
we
could
get,
we
could
essentially
proceed
that
way.
You
know
block
by
block
all
the
way
to
the
end
of
until
we've
got
an
entire
graph
of
data.
A
Now
this
is
the
the
the
challenge
with
this
is
in
order
for
me
to
to
request
the
any
blocks
after
root.
I
have
to
get
the
first
block
and
then,
in
order
to
request
any
blocks
after
that,
I
have
to
get
the
next
block,
so
you
have
a
whole
series
of
round
trips
that
happen
where
I
can't
request
parts
of
the
data
until
I
have
some
of
the
initial
bits
of
data,
so
that
is
that's
a
potential
big
speed
slowdown.
A
Now
we
have
some
ways
of
speeding
that
up,
because
bitswap
is
very
parallelized,
so
what
we
can
do
is
once
we
get
the
first
block.
We
can
make
the
the
next
two
request
the
next
blocks
from
two
different
peers.
At
the
same
time,
we
can
do
all
this
stuff
to
massively
parallelize
it,
and
if
we
have
a
data
structure,
that's
like
a
tree
structure
for
our
dad.
A
This
actually
works
relatively
well,
because
you
know
as
long
as
as
long
as
the
tree
is
wide
and
not
too
deep,
we're
going
to
actually
be
able
to
utilize
the
parallelized
requests
really
well
and
get
those
and
get
that
data
back
quickly.
Now
the
downside
is,
if
we
had
a
structure,
that's
very
deep
and
very
narrow,
the
actual
most
extreme
example.
This
is
something
like
the
blockchain,
where
each
block
only
points
to
one
parent
block
and.
A
To
get
them,
you
would
have
to
do
essentially
end
round
trips
for
nr
and
blocks,
it's
very,
not
ideal,
so
essentially
so
so
what
we
need
is
a
way
to
express
what
we
want
from
a
block
and
its
children
child
blocks.
That
is
that
doesn't
require
us
to
know
the
hash
of
every
single
block
in
the
tree
right.
A
What
I
want
to
be
able
to
tell
a
person
that
I'm
requesting
data
from
I
want
to
say
I
want
this
block
and
I
want
all
the
children
underneath
it
and
all
I
want
all
their
children's
children
and
I
want
all
their
children's
children
right
or
I
might
say
I
want
to
request
this
block
and
I
want
only
the
first
child
of
its
of
or
I
want,
the
child
link
that
has
this
name,
and
then
from
that.
A
I
want
the
child
link
that
has
this
name,
and
this
name,
and
this
name
you
can
imagine
if
a
merkle
dad
represented
a
directory
tree,
we
might
request
it
in
such
a
way
where
we
were
essentially
each
link
was
a
subdirectory
all
the
way
down
to
a
root
note.
So
we
have
a
language
for
expressing
this
kind
of
a
query
and
it's
called
an
ipld
selector.
These
are
this
is
sort
of
just
a
diagram.
There's
there's
a
whole
series
of
different
selectors.
A
You
can
do
in
ipld,
but
the
short
version
is
it's
query:
language
for
merkel,
dag
graphs.
It's
a
way
of
expressing
a
query
against
the
merkel
data
graph
that
will
that,
based
on
the
merkle,
dag,
will
will
return
a
predictable
result.
It's
similar.
B
A
A
So,
given
all
that,
let's
revisit
our
our
statement,
so
graphsync
is
a
protocol
to
synchronize
graphs
across
periods
and
what
graphsync
allows
me
to
do
is
it
allows
me
to
send
a
root
hash
to
another
peer
for
a
graph
that
I'm
interested
in
and
to
send
with
it
a
selector
which
expresses
all
or
part
of
the
the
subgraph
below
that
root
that
I
am
interested
in
and
then
to
have
the
other
peers.
A
Send
me
all
that
data
back
one
thing,
so
I
think
the
easiest
way
to
think
of
a
gr
of
grass
sync
is.
It
is
essentially
an
ipld
selector
traversal.
It's
like
running
a
query
against
if
we
think
of
like
the
merkle
dag
is
like
its
own
like
database,
we're
running
a
query
against
a
merkle
database,
but
that
database
lives
on
another
peer
against
a
networked
data
store
right.
So
I
always
say
the
groundsync
is
an
ipld
selector
traversal,
backed
by
a
network
store.
A
So
that
was
a
lot
another.
Just
a
couple.
Other
constraints
to
know
about
grassland,
grassland
was
originally
developed
for
ipfs
and
then
has
been
moved
into
file
coin
and
actually
seen
most
of
its
development
in
file,
but
because
it
also
is
intended
to
work
in
ipfs.
We
have
to
work
with,
like
some
additional
constraints,
in
addition
appears
not
trusted
and
requesters
not
trusted.
We
any
peer
on
the
network
is
a
requester
and
a
responder.
It's
not
like
a
a
client
server
environment.
Anyone
can
serve
grassland
requests.
A
Anyone
can
receive
grassland
requests.
We
may
have
to
serve
multiple
requests
at
once,
so
we're
trying
to
optimize
we're
trying
to
build
an
implementation
that
optimizes
for
handling
multiple
requests.
And,
oh
sorry,
I
apologize
I'm
trying
to
think
there's
anything
else.
Basically,
just
that
you
know
it
is
a
generalized
protocol
for
moving
this
stuff
around,
so
it
can
operate
in
it's
intended
to
operate
in
all
kinds
of
environments,
and
so
we
have
true
all
the
concerns
that
would
come
from
ipfs
ddos.
A
You
know
making
sure
that
we
balance
requests
between
peers
all
those
types
of
things
and
that
those
are
all
concerns
that
are
implementation
level.
Concerns
as
opposed
to
protocol
level
concerns,
but
at
least
the
go
implementation
takes
into
account
all
of
these
things,
cool
wow.
A
That
was
like
a
mouthful,
so
I
want
to
look
at
the
grassland
protocol
first
and
then
look
at
a
little
bit
of
the
architecture
of
grass
think
and
then
look
at
a
little
bit
of
the
file
coin,
specific
questions,
but
I
want
to
just
before
that.
I
just
want
to
make
sure
I
don't
know
how
do
I
get
to.
I
don't
know
if
we
have
any
questions,
I
can't
for
some
reason.
I
can't
see
the
q
a
so
oh
no,
there
is
no
q
a
for
this!
Oh
wait!
A
Is
all
100
totally
comprehensible
to
all
of
you?
I
love
that
because
you're
all
geniuses,
because
I
don't
understand
any
of
it
anyway,
so
let's
go
in
to
let's
look
at
the
grassy
protocol,
so
that's
gonna
be
kind
of
the
end
of
my
slide
deck,
so
I'm
gonna
just
be
showing
you
some
bits
from
code
and
and
other
sort
of
like
online
documents
going
forward.
So
let's
look
at,
I
wanna
just
look
briefly
at
the
browsing
protocol
itself.
This
is
this.
A
Here
we
go,
let's
see,
let's
look
at
this.
Okay,
I'm
going
to
skip
all
these
and
just
get
to
the
the
protocol.
Grassland
is
currently
a
protobuf
based
protocol,
which
is
probably
going
to
change
it
sometime
in
the
near
future.
We're
trying
to
move
things
to
see
seabor,
but
for
the
moment
it's
a
protobuf
so
on
the
grassing
protocol
two,
essentially
it
is
a
live
pdp
protocol,
two
peers,
connect,
overlapped,
p2p
and
then
connect
on
the
sort
of
like
grass
sink
and
set
up
a
stream.
A
That's
set
up
for
the
grassing
protocol
and
they
send
messages
back
and
forth
that
look
like
this.
A
message
contains
a
question
about
selectors,
okay,
cool.
So
a
graphic
message
contains
these
fields.
It
contains
a
set
of
requests,
it
contains
a
set
of
responses
and
it
contains
a
set
of
blocks.
Importantly,
each
message
can
can
contain
multiple
requests,
multiple
responses
and
blocks
that
are
tied
to
one
or
more
responses
this.
Actually,
this
full
complete
request
list.
A
That
makes
me
anxious,
because
this
is
no
longer
super
well
used.
So
I'm
just
looking
at
this
and
seeing
things
where
I'm
like:
oh
wow,
we
should
probably
remove
that
in
any
case,
so
you
have
request
responses
and
data.
A
request.
Content
consists
of
a
request.
Id
a
root.
A
root
is
a
cid,
a
selector,
a
selector
is
an
ipld
selector,
it's
encoded
as
seabor
bytes.
A
In
the
context
of
in
the
context
of
graph
sync,
the
requests
have
priority
and
then
there's
two
special
types
of
requests:
there's
a
cancel
request,
which
means
what
you
might
think
and
an
update
request,
which
means
which
is
a
way
of
expressing
essentially
some
kind
of
update
to
the
existing
request.
A
Importantly,
both
the
request
and
the
response
have
a
have
a
set
of
extensions
potential
that
should
be
that
may
or
may
not
be
present
on
the
request,
and
this
is
really
important,
because
graphsync
is
designed
to
be
an
extensible
protocol
and
we
use
this
extensively
in
file
point
essentially
as
a
way
to
you
can
layer
on
side
protocols
into
the
graph
sync
request
process,
and
this
allows
you
to
do
a
lot
of
really
cool
stuff
like
it's
almost
like.
A
You
can
think
of
these
as
like
being
either
your
ssl
extensions.
Maybe
like
your
tls
extensions,
maybe
even
like
cookies.
It's
a
way
to
like
you
can
do
authentication
with
this.
You
can
do
you
can.
Essentially
you
know
in
retrieval.
We
exchange
payments
through
these
extend
extensions.
It's
pretty
cool
a
response
is
really
simple.
A
response
has
a
has
the
request
idea
of
what
it's
responding
to
and
it
has
a
status.
Now
there
is
one
extension
that
is
in
the
response,
which
is
mandatory.
A
Sorry,
that's
a
side
effect
of
the
of
the
process
of
building
it,
and
then
you
essentially
have
a
series
of
blocks
blocks
are
essentially
a
cid
prefix
and
then
the
data
you
verify
these
blocks
by
by
essentially
taking
the
data
and
hashing
them
so
that
you
can
so
you
only
get
to
see
id
of
these
blocks
from
the
data
itself.
You
don't
want
to
transmit
that
independently
or
you
would
need
to
check
it
to
verify
that
the
blocks
are
in
fact
what
they
are.
A
So
this
just
allows
us
to
construct
the
correct
cid
from
the
blocks.
That's
what
this
prefix
does
and
that's
basically,
the
the
the
the
whole
of
it
one
key
other
element
in
the
protocol.
Is
I'm
gonna
go
sorry
about
this?
I'm
gonna
go
back
here.
Seven
minutes
wow.
This
is
real,
quick
one
key
element
in
the
protocol.
This
is
that
must
have
extension
that
I
mentioned,
unfortunately,
which
is
this
response
metadata,
which
will
be
encoded
in
the
response.
It
will
essentially
say
for
this
response
to
this
request.
A
Id
here
are
the
links
that
I
have
traversed,
and
it
will
tell
you
and
with
that
you
will
include
it
will
include
two
two
additional
things
it
will
include.
It
will
sorry
it
will
include
one
additional
thing.
One
is,
and
it's
essentially
whether
or
not
I
had
the
block
in
this
traversal
one
scenario
that
can
definitely
happen
is
I
can
express
a
selector
to
a
remote
peer.
A
They
can
start
at
the
root
and
start
performing
the
query
and
find
that
they
are
missing
one
of
the
blocks
in
the
process
of
the
query.
This
is
particularly
an
issue
in
the
ipfs
environment
in
the
file
point
environment
generally,
you're
you're,
the
one
for
like
storing
you're,
the
one
who's
like
storing
the
data
that
you
that
you
want
to
store,
and
so
you
tend
to
have
all
of
it,
but
in
any
case
it's
important
particularly
for
security
reasons,
so
that
is
essentially
the
protocol.
Now
the
key
thing
that
we
need
to
so.
A
Briefly
about
the
architecture
I'm
going
to
move
over
to
the
grass
and
the
go
grassland
repository
and
something
here
we
go.
These
docks
these
documents
in
the
this
is
the
go
grass
sync
repository.
It
does
have
a
document
folder
and
it
has
an
architecture
document.
Some
of
this
architecture
is
a
little
out
of
date.
A
I
need
to
update
it
in
which
I
will
in
the
near
future,
but
the
basics
are
pretty
and
pretty
I
don't
know
accurate
and
the
key
thing
to
understand
so
so
yeah
so
graphs
go
grass.
Sync
has
a
you,
know:
top-level
interface
and
a
requester
implementation,
a
responder
implementation
and
a
message
layer
for
sending
messages.
A
In
order
for
us
to
create
a
do.
A
round
trip
request,
a
requester
needs
to
essentially
encode
and
send
the
request
to
the
responder.
The
responder
needs
to
receive
the
request
and
perform
an
ipld
selector
query
based
off
of
it.
The
responder
needs
to
load
those
blocks
as
they're
performing
the
selector
query,
load
the
blocks
from
local
storage,
and
then
it
needs
to
encode
and
send
blocks
traversed
and
metadata
about
the
traversal
to
the
requester.
Now
here's
the
key
step.
A
A
We
also
run
a
selector
query
on
the
incoming
data
to
verify
that
it
is
the
right
data,
so
we
know
the
root
on
the
on
the
requester
side,
so
we
can
start
with
that
root
and
perform
a
selector
query,
as
data
comes
in
against
it
to
verify
that
it
is
the
correct
data
and
it's
important
importantly,
we
do
not
save
data.
That
is
not
that
does
not
match
the
selector
query.
A
Once
we
get
once
we
do
verify
it,
we
need
to
store
those
blocks
and
then
we
need
to
return
the
the
nodes
to
the
caller.
So
those
are
those
are
essentially
that's
like
the
overall
sequence
of
events
and
again,
I'm
like
putting
all
this
commentary
in
here
about
how
I
think
of
a
graphic
request
as
an
ipld
selector
query
that
happens
locally.
That
happens
to
be
backed
by
a
data
store.
That's
on
the
network.
A
A
This
gives
you
like
a
I'm,
probably
going
to
not
go
too
deep
into
the
architecture
here.
Essentially,
this
gives
you
like
all
of
the
step-by-step
of
like,
what's
going.
On
importantly,
we
want
to.
A
We
want
to
make
sure
that
as
we're
processing,
multiple
incoming
requests
and
sending,
and
and
also
responding,
responding
to
requests
making
outgoing
requests
that
we
have
a
mechanism
that
we
essentially
balance
our
workloads
so
that
we
don't
get
overwhelmed
and,
oh,
my
goodness,
it's
2
12
27,
so
I'm
going
to
probably
wrap
this
up
so
that
we
can
get
a
few
couple
questions
in
before
the
end.
I
just
want
to
talk
about
one
other
feature
just
so
you
know
before
we
do
a
q,
a
which
is
the
grasssync.
A
The
gograss
sync
implementation
has
a
number
of
additional
hooks
that
are
used
for
you
to
hook
in
with
extensions,
so
that
you
can
perform
additional
computation
on
incoming
requests.
For
example,
we
have
we
have
like
an
incoming
request
hook.
Sorry,
this
is
the
wrong
thing.
We
have
an
incoming
request
hook,
which
allows
you
to
look
at
an
incoming
request
and
res
accept
or
reject
them
based
off
of
additional
information
in
the
extensions
we
have
an
outgoing
block
hook,
which
allows
you
to
like
pause
requests
as
blocks
go
out.
A
We
have
an
incoming.
We
have
essentially
hooks
for
everything,
so
with
all
that
you
can
build
lots
and
lots
of
protocols
on
top
of
that
and
that's
what
we
do
for
data
transfer
in
both
storage
and
retrieval
and
file
coin
anyway,
that's
I
have
two
minutes.
I'm
going
to
go
with
a
dean's
question.
I
have
a
question
about
selector
and
implementation
level
details
I'll
figure
a
way
yes
go
for
it.
Unmute
yourself,
I'm
gonna,
stop
screen
sharing.
B
Okay,
basically,
I
wanted
to
get
a
better
understanding
of
like
what
types
of
selectors
we
have
or
we
can
use
and
how
we
can
then
use
those
to
then
create
like
multi
multi-user
queries
right.
So
we
can
start
using
graph
sync
to
query
multiple
peers
for
data.
A
Sure
yeah
we
so
to
be
clear.
We
currently
do
not.
We
generally
do
not
use
the
gograss
sync
implementation
for
multipure
queers
queries
at
the
moment,
because
in
filecoin
we're
primarily
transferring
data
from
one
person
to
another.
However,
that
is
an
intended
goal
of
the
of
the
software
and
the
facilities.
We
have
the
the
sort
of
selectors
that
we
have
right
now
we
have
a
like.
A
If
I
can,
we
have
field
selectors,
we
have
a
array,
selectors,
meaning.
I
want
these
elements
of
an
array.
I
want
these
named
fields
of
a
of
a
map.
We
have
a
recursive
selectors
which
are
really
key,
which
is
essentially
I
want
you
to
perform
the
selection.
Then
I
want
you
to
keep
doing
it
again
until
a
condition
is
met
and
that
is
used
for
stuff
like
doing
a
whole,
dag
traversal,
meaning
like
I
want
you
at
each
level.
A
I
want
you
to
explore
all
the
fields
and
then
traverse
all
the
fields,
and
then
I
want
you
to
do
it
again
until
you
get
to
you
know
a
certain
depth.
Now
we
there
are
certain
selectors
that
we
that
we
have,
which
are
we
there's
certain
things
that
we
might
use
like.
We
could
use
a
field
index,
so
I
can
we
to
do
some
really
primitive
requests.
Splitting
like
I
want.
A
You
know
you
to
give
me
the
first
field
and
all
the
children
under
and
you
to
give
me
the
second
field
and
all
the
children
under
it.
That's
not
gonna,
be
very
good
for
balancing
to
balance
we're
gonna
probably
have
to
do
some
updating
of
requests
in
the
middle,
because
we
we
don't
really
know
the
shape
of
the
graph
ahead
of
time.
A
The
other
question:
that's
a
little
complicated
is
figuring
out
how
to
split
up
or
whether
we
want
to
split
up
a
request
at
the
selector
level
or
the
block
level,
because
grassland
works
with
blocks.
We
could
easily
build
an
extension
that
says
I
want
you
to.
You
know,
count
blocks
by
five
and
only
send
me.
A
You
know
the
ones
where
the
block
count
mods
by
one
and
then
like
to
the
next
person
and
give
me
a
block
count
that
mods
by
two
and
mods
by
three,
and
they
essentially
make
the
same
selector
query
to
all
the
peers,
but
they
each
send
back
different
blocks,
and
then
you
verify
it.
Obviously
that
has
its
own
problems,
because
if
one
peer
is
more
is
not
sending
you
the
right
data
that
breaks
it
for
everyone,
it's
there's
a
number
of
different
things
that
we
could
do.
A
The
query
change
the
query
and
say:
hey,
listen,
you
know,
I
don't
need
you
to
send
me
this
part
of
it.
You
know
those
types
of
things.
It's
that
stuff
is
all
a
little
bit
of
a
frontier.
That's
probably
one
of
the
next
main
areas
for
development
in
grouse.