►
From YouTube: London Hack Week 2018 // Bitswap - Graphsync Improvements & Module Architecture - Erik Ingenito
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
We
know
historically,
which
peers
have
given
us,
which
parts
of
the
dag
that
we're
currently
fetching,
among
other
things,
and
we
can
use
that
information
to
predict
more
intelligently,
which
peers
are
likely
to
have
the
content
we
currently
want
with.
For
instance,
if
we
had
already
gotten
a
sibling
of
a
current
node
from
a
peer,
then
that
peer
is
a
decent
candidate
for
giving
us
the
block
we
currently
want-
and
you
can
imagine
other
things
like
that.
Other
relationships
in
the
deck
that
might
make
appear
likely
to
have
a
block
that
we're
looking
for.
A
So
it's
I
think
that
that
started.
There
was
sort
of
a
general
acceptance
that
okay,
let's
see
where
we
can
build
in
that
kind
of
smarts,
and
there
was
a
notion
that
it
would
be
a
service
consumed
by
bit
swamp.
That
would
be
like
big
swap
says:
hey
I
want
I,
just
got
this
block
from
this
peer.
Do
whatever
you
want
with
it
cache
that
information.
A
A
Also
he's
sort
of
questioned
or
was
there
was
a
an
open
discussion
about
whether
that
is
appropriate,
whether
the
service
that
should
be
consumed
by
this
pot,
whether
it
should
actually
be
a
driver
of,
did
swap
actually
have
smarts
and
just
relayed
a
bit
swap
one
bit
swap
should
be
doing.
Who
bid
swap
should
be
fetching
a
set
of
blocks
from
what
which
peers
and
that's
sort
of
what
a
session
is
in
a
sense,
although
it's
not
factored
that
way,
but
a
session
is
in
essence
a
way
of
telling
bit
swap
which
peers
are
good.
A
A
Stephen
diagram,
a
sort
of
future
world
where
that
involves
other
transports.
I,
don't
know
transports
right
word,
but
other
things
that
are
parallels
have
been
swap
in
essence,
like
brass
sink,
so
a
different
protocol
spoken
for
exchanging
data
between
peers
and
how
we
actually
might
want
to
factor
the
codes
so
that
there
was
proper
coordination
and
until
an
ability
to
make
intelligent
decisions
about
how
to
use
various
transports
for
getting
data
and
right
now,
basically
bit
swap
is
probably
responsible
for
too
much.
A
When
we
have
graph
sync,
we
are
actually
probably
going
to
want
orchestrating
something
that
can
make
intelligent
routing
decisions
between,
should
I
bench
this
from
peers
and
bit
swap
or
should
I
fetch
this
from
peers
using
graphs
Inc
one.
What
protocols
do
they
speak
to?
How
high
quality
are
the
peers?
Three
well
they're,
not
numbered
this
way.
Three.
What
have
we
already
gotten
from
these
peers?
A
So
there's
lots
of
potentially
pretty
complicated
ways
in
which
we
could
rank
peers
and
suggest
that
some
better
than
others
for
fetching
data
from
so
this
is
actually
pretty
different
from
the
way
it
looks.
Currently
I'm
not
gonna,
go
into
too
much
detail.
I
think.
Maybe
some
of
you
who
are
more
familiar
with
the
code
than
I
am
recognize
how
different
it
is
from
the
way
things
currently
work.
A
A
This
was
I
can
talk
briefly
about
the
thing
that's
just
actually
just
above
it,
which
was
this
had
already
been
thought
of
before,
and
there
was
actually
like
divvy
sort
of
showed
what
something
that
had
been
considered
in
the
past,
which
was
more
of
a
fall
through
behavior,
where
graph
sync
was
the
was
the
superior
transport
device
and
that's
meaning
it
a
little
bit.
It's
not
quite
a
transport
device,
but
whatever
you
grab,
sync
was
like
a
better
way
of
getting
data
from
other
peers.
A
Failing
graphs,
inky
would
fall
through
to
the
block
service.
I'm.
Sorry,
you
would
yeah
you'd
fail
through
you'd
fall
through
the
block
service,
which
only
knows
about
blocks.
It
would
potentially
ask
bit
swap
for
data,
and
it
would
be
the
thing
that
also
understood
about
the
repo
and
you
like
how
to
add
files
to
add
blocks
to
the
repo
and
get
blocks
out
of
the
repo.
A
So
I
guess
the
one
thing
Kubo
immediately
was
like
okay,
one
thing
I
don't
like
about
this:
if
you
can't
make
smart
routing
decisions
or
really
smart
routing,
the
students
between
graphs
and
convinced
well,
like
you,
can't,
have
them
running
at
the
same
time
for
a
set
of
blocks,
you
can't
divide
things
up
or
you
can't,
for
instance,
if
you're
on
the
local
network
with
really
awesome
bit
swap
peers,
but
you
have
some
graphs
and
peers
that
are
whatever
far
away
high
latency.
A
You
might
want
to
actually
prioritize
those
bits,
wan
peers
and
talk
to
them
first,
instead
of
using
graphs
of
grassing
to
get
data,
so
that
I
mean
that
is
true.
If
this
is
really
technically
a
fall
through
pattern,
then
that
is
true,
and
so
this
other
the
other
architecture,
definitely
architecture.
The
other
way
of
laying
out
our
responsibilities
definitely
gives
us
an
opportunity
to
to
make
sort
of
higher-level
decisions
about
how
we
want
to
do
stuff,
which
appears
gavage.
It
also
yeah,
the
in
the
details.
A
Things
will
it'll
be
interesting
to
see
how
this
exactly
falls
out.
It
is
interesting
where
the
block
store
lives
in
this
picture
here,
which
I
think
is
good,
but
it's
really
set
it's
very
much
separated
from
from
the
actual
transfer
of
data
between
tears
now.
Can
it
actually
be
that
super
separated?
A
It's
not
it's
a
little
hard
to
know
exactly
how
we're
gonna
plumb
some
of
that
stuff
in
because
in
the
discussion
this
morning,
with
you
sort
of
pointed
out
well,
there's
been
swapped
fetching
and
then
there's
also
bit
swap
serving
that
swap
serving
obviously
needs
to
respond
needs.
Well,
they
don't.
A
They
both
need
somehow
to
get
data
in
and
out
of
the
block
store,
potentially
just
knowing
whether
you
have
blocks
already
as
you
try
to
fetch
blocks
in,
although
that
could
be
a
the
job
of
the
block
service,
but
in
another
case,
when
you're
serving
them
up,
we
don't
know
exactly,
but
maybe
more
also
like.
We
don't
want
to
build
all
of
this
before
we
do.
A
The
thing
that
we
were
setting
out
to
do
in
the
very
first
place,
which
was
make
for
smarter
bid
swap
and
make
better
decisions
in
bit,
swap
so
I
guess
the
idea.
The
idea
is
first
to
break
up
that
swap
a
little
bit
the
way
it
is
right
now,
just
sort
of
the
things
I
think
you
can
think
of
this
sort
of
as
like.
A
What
in
the
dag,
we
would
use
that,
and
we
may
also
have
I
mean
that
is
actually
sort
of
the
session
in
a
sense.
But
it's
like
information
like
a
session
would
be
about
making
decisions
about
what
peers
to
communicate
with
that's
what
all
in
and
that's
the
first
thing
you
would
do
would
presumably
without
doing
all
the
refactoring
and
probably
still
having
block
store
like
bit,
swap
a
little
bit
more
closely
tied
with
friends
right
now.