►
From YouTube: Move The Bytes Working Group Meeting 5
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
A
It's
January,
18th
yay,
really
really
nice
clean
agenda
today,
just
a
couple
of
bits
of
housekeeping
and
then
Hannah
Howard
is
going
to
give
us
a
talk
about
a
data
transfer
protocol
Hannah
I
believe
yes,
thumbs
up
very
excited
to
hear
that
and
then
we'll
just
move
an
open
discussion
which
20
minutes
to
the
top
of
the
hour.
However
long
it
goes
and
we'll
cap
it
off
from
there
housekeeping
is
really
light.
We
have
our
new
purpose,
we're
here
to
present
research,
compare
measurements
and
recommend
improvements.
A
I
have
some
notable
reading
a
weird
position
of
plugging
our
own
content,
but
I
think
this
is
relevant
to
this
group.
This
paper
came
out.
It
was
recommended
by
Brooke
on
range-based,
set
reconciliation,
I
thought
rather
than
try
to
like
take
a
slot
in
this
meeting
and
talk
about
it.
I
made
a
YouTube
video
about
it,
so
you
can
just
watch
that
in
your.
A
A
But
if
you
have
some
recommended
reading
for
next
week,
if
you
want
to
post
something
or
for
next
meeting,
it'd
be
great
to
to
have
it
for
our
agenda
in
terms
of
where
we're
at
in
time,
we
are
on
our
meeting
our
fifth
meeting,
which,
on
our
old
timeline,
was
sort
of
going
to
be
this
design
phase,
and
then
we
were
going
to
move
and
switch
gears
into
a
more
focused
implementation
phase.
I'm
going
to
shift
that
to
a
discussion
in
the
move.
A
The
lights
working
group
chat
about
this
select
metrics
conversation
where
we
talked
a
little
bit
about
trying
to
make
our
protocols
at
least
comparable
I
know
of
a
number
of
groups
that
are
working
on
protocols
and
so
for
I'm,
going
to
try
and
kick
off
an
async
discussion
around
what
metrics
each
of
those
groups
either
will
want
to
collect
or
will
collect,
and
ideally
we
can
normalize
on
the
names
of
those
metrics
and
have
some
of
those
figures
presentable
and
discussable
in
the
following
meetings,
and
ideally,
this
whole
group
can
start
to
shift
gears
just
a
little
bit
towards
hey.
A
These
are
implementations
that
are
starting
to
emerge.
These
are
their
characteristics,
we're
hearing
more
and
more
threats
of
Demos
in
some
of
our
talks,
great
I
think
it's
a
great
sort
of
shift
to
encourage
and
facilitate
of
us
turning
towards
actual
code
and
seeing
hey.
How
does
that
work?
How
does
that
compare?
How
does
this
Stack
Up
in
given
scenarios?
The
other
thing
I
want
to
discuss
with
others,
is
choosing
test
data
sets
or
pieces
of
data
that
we
can
all
agree
upon.
A
I
think,
internally,
at
number
zero
we've
been
playing
a
lot
with
as
an
example,
the
qix
Wikipedia
backups
has
a
great
test
of
just
like
both
a
lot
of
content
and
sub
selections
within
that
content
for
data
transfer
protocol
I
think
there
are
others,
and
it
would
be
great,
as
this
group
to
sort
of
Identify
some
of
those
like
dative
test
fixtures.
So
I'd
like
to
kick
off
discussions
about
those
two
things.
A
Beyond
that,
it's
kind
of
all
we
had
so
Hannah
I
know
we
were
talking
a
little
bit
how
you
might
have
a
little
bit
of
vamping
time
to
polish
up
your
talk,
but
this
I
instead
I
will
give
a
lovely
warm
introduction
for
Hannah
to
give
an
extra
couple
of
seconds.
Hannah
has
been
working
on
two
different
protocols
for
some
time
and
has
led
numerous
tracks
at
our
conferences
and
meetups.
A
Around
data
transfer
demanded
because
she
worked
on
and
implemented
graph
sync,
which
is
one
of
the
biggie
protocols
in
filecoin
and
kind
of
exists
in
ipfs,
is
also
the
fastest
performing
protocol
behind
TCP
that
we
have
based
on
our
measurements,
so
I'm
very
excited
to
hear
what
Hannah
has
to
say
and
with
that
I'll
turn
it
over
to
you
Anna.
Hopefully,
that
gave
you
an
extra
30
seconds
to
collect
your
thoughts.
Hey.
B
Yeah,
no,
it's
it's
cool!
Mostly
I
collected
my
screen
Windows,
but
I'm
going
to
go
ahead
and
get
started.
C
B
Cool,
can
you
all
see
that
groovy,
okay,
here
to
talk
about
a
vertical
called
Stargate,
but
also
it's
a
protocol?
I've
I've,
been
working
on
and
and
and
even
have
a
demo
of
today,
but
mostly
I
started.
B
Writing
it
to
try
to
like
think
a
thing
through
some
interesting
issues
with
regard
to
data
transfer
and
I
will
caveat
this
ahead
of
time
that
I'm
not
going
to
be
introducing
any
exciting
new
algorithm
for
the
most
part,
because
I
am
not
an
algorithmee
researchy
type
of
person,
I'm
more
of
a
like,
let's
think
through
this
like
problem
and
try
to
break
it
down
in
different
ways
and
think
and
try
to
realize
some
cool
stuff
so
anyway
yeah
this
is.
B
This
is
the
title
of
this
of
this
presentation?
Bringing
the
90s
back
to
web3
I
mean
part
of
that
is
because
one
of
the
things
that
I'm
building
on
is
trying
to
look
at
what
has
already
worked
in
the
web
too,
and
why
does
it
work
so
anyway,
let's
get
started
so
I
have
one
rule
that
when
I
get
presentations
and
I
broke
it,
which
is
never
ship
code
for
a
presentation.
B
It
is
the
worst
idea
possible
because
it
is
impossible
to
put
the
code
down
until
it's
done
and
then
the
presentation
may
or
may
not
be
there.
So
yeah,
that's
fun
whatever.
Let's
go,
let's
go
ahead
and
do
this
all
right,
so
somebody
suggested
to
this
group
that,
rather
than
build
another
lib
P2P,
we
should
build
something
that
speaks
over
HTTP
and
I
was
like
I
was
like
I
will
answer.
B
The
call
I
have
worked
on
some
data
transfer
protocols,
but
but
but
I
think
I
could
do
better
than
last
time
simpler
than
last
time,
so
I
thought
I
would
try
again.
Oh
can
you
all
even
see
that?
Oh,
it's
supposed
to
say,
okay
but
I,
don't
know
what
happened
to
it.
Oh,
my
God
yeah
all
right,
well,
cool.
What
if
and
I
started
off
and
I
was
like
all
right.
Let
me
design
a
protocol
from
scratch
for
HTTP
and
I.
B
Will
you
know
come
up
with
the
way
to
do
it
and
I
started
digging
into
it
and
I
realized
that
someone
had
already
written
one?
It's
called
the
gateway,
and
it
is
the
most
widely
used
data
transfer
protocol
in
ipfs
and
I
thought
to
myself.
That's
interesting.
Why
aren't
we
using
that
for
so
many
things
and
there's
a
couple
things
that
I
could
see
that
were
missing?
B
If
you
dig
into
the
gateway
code,
you
will
see
that
it
does
support
car
files,
but
if
you
give
it
a
sid
plus
a
path,
you
will
get
back
a
car
file
that
lacks
these
SIDS
in
between
the
root
and
your
end
thing
at
the
end
of
the
path.
So
it
won't
be
verifiable.
So
that's
a
that's
a
little
bit
of
a
bummer.
It
doesn't
have
much
information,
sorry,
not
much
information.
B
It
doesn't
have
a
the
tools
to
transmit
data
for
someone
who
might
want
to
make
a
multi-peer
request
and
similarly
it
doesn't
have.
It
doesn't
really
have
queries
that
you
would
want
to
make
for
a
multi-peer
request.
B
In
many
cases
you
you
could
use
it
like
if
you're,
if
you're
getting
a
directory
that
might
work
work
well
for
multi-pier
but
like
if
you
were
getting
a
video
file
like
it's,
not
super
obvious
how
to
get
a
verifiable
like
range
request
into
a
big
giant,
Unix
FS
file,
and
it's
not
possible
in
the
Gateway.
You
can
get
a
raw
file
with
a
range
request,
but
that
won't
be
verifiable.
B
So
anyway,
I
was
like
okay.
Well,
that's
that's
cool!
What?
If
I
dig
into
this
and
so
yeah
I'm
gonna,
introduce
this
protocol
that
I
wrote,
called
Stargate
and
all
Stargate
is,
is
basically
a
new
format,
response
format
for
Gateway
queries,
plus
a
few
other
things,
and
at
this
point
in
the
presentation,
I'm
actually
going
to
switch
over
to
the
initial
Specky
thing
that
I
wrote
for
Stargate
and
yeah.
So
basically
here's
here's
the
deal,
here's!
What
Stargate
is?
B
It
defines
a
new
response,
mime
type
response
format
for
a
Gateway.
It's
just
it's
just
a
car
format
with
a
little
extra
on
it.
So
the
response
format
is
still
a
car.
It
just
has
some
other
things
in
it,
and
then
it
defines
some
additional
query
parameters
for
for
doing
different
kinds
of
queries
that
you
might
not
be
able
to
do
with
the
Gateway
currently
yeah.
So
let's
look
at
the
format.
So,
basically
start
you,
you
give
it
the
you
give
it
a
normal,
Gateway
query.
B
This
is
taken
directly
from
the
Gateway
pathing
spec
and
you
will
get
back
a
car
file.
It
will
have
your
root
sit
as
the
car
is
the
roots
in
the
car.
However,
the
first
Sid
after
the
car
header
is
going
to
be
a
Stargate
message
and
here's
a
Stargate
message
all
it's
it's
a
pretty
simple
type
of
message:
it.
It
simply
has
one
of
two
possibilities:
it's
either
a
path
or
a
dag
and
what
you'll
have
is.
Basically
the
first
message
will?
B
Oh,
if
you
have
path
segments
will
be
a
path,
method
message
and
then
in
a
path
method.
Message:
sorry
about
this
I'm.
Also
like
super
tired
I'm
doing
this.
Each
you're
gonna
have
a
list
of
segments
that
the
the
path
message
covers
and
then
you're
gonna
have
a
list
of
metadata
about
blocks
and
the
blocks
are
basically
just
SIDS
plus
a
status.
The
important
ones
are
like
I,
didn't
send
it
with
this
request
and
I
I
did
send
it.
B
That's
present
I'm
actually
missing
it,
which
is
useful
for
you
know
if
you
want
to
do
partial,
and
this
is
a
duplicate
which
means
that
you're
not
going
to
see
you're
not
going
to
see
this
or
anything
below
it
in
the
response,
and
so
basically
what
you
you're
going
to
read
your
target
path
message
and
then
immediately
following
that
message,
there
will
be
all
of
the
blocks
that
were
marked
that
were
listed
as
block
present
right
in
that
message
now
and
then
now
so
you're
going
to
read
the
message
and
then
you're
going
to
go
ahead
and
read
all
the
blocks,
and
then
you
and
then
at
the
end,
you're
going
to
look
for
another
Stargate
message
right
now.
B
The
next
message
could
be
another
yeah.
What's
up?
Oh
no
unmute
issue.
The
the
next
message
could
be
another
path
message
or
it
could
be
the
beginning
of
a
dad.
Each
path
message
is
basically
covers
some
or
all
of
the
portion
of
the
of
the
of
the
path,
and
you
know
to
switch
to
Dag
messages
when
you've
gotten
to
the
end
of
your
past
segments
by
combining
all
the
ones
you
Traverse
so
far.
So
then
you
get
a
dag
message
and
a
dag
message
is
is
probably
even
simpler
than
the
path
message.
B
It
is
simply
an
ordering
which
right
now
has
two
values:
bread,
first
and
depth
first
and
a
list
of
blocks
again
with
the
metadata
and
that's
pretty
much
that's
the
entirety
of
the
protocol.
For
the
dad
part,
you
can
have
one
or
more
dag
messages
followed
by
the
block
sequence
and
it's
the
same
algorithm.
B
You
just
read
as
many
blocks
as
you
need
to
to
get
to
the
to
get
all
the
present
ones
in
in
the
in
the
Stargate
message,
and
then
you
look
for
another
Stargate
message,
and
so
this
so
actually,
whether
or
not
you
can
actually
send.
B
If
you
have
a
path
query
with
like
you
know,
and
then
a
dag
at
the
end,
you
can
send
Just
One
path,
message
followed
by
all
the
blocks
in
the
path
and
then
one
dag
message
followed
by
all
the
blocks
in
the
dag
or
you
can
send
multiple
and
actually
the
there's,
there's
not
a
decision
made
in
the
protocol
itself
about
how
that
will
be
broken
up.
However,
it
will
be
specified
in
what
we're
calling
what
I'm
calling
the
application
protocol
that
you're
using
and
I'll
get
into
what
that
is
in
a
minute.
B
So
yeah,
that's
pretty
much
all
it
is
in
terms
of
the
in
terms
of
the
protocol,
and
essentially
this
allows
you
to
stream
back
a
car
file
I'm
using
car
files,
because
it's
something
that
everyone
knows
there's
some
hiccups
around
here-
that
you
know
pluses
and
minuses.
Among
other
things,
car
files
have
SIDS
in
them,
and
so
I
am
like
hashing
the
Stargate
messages,
they're
very
small,
so
I
don't
expect
them
to
take
a
while,
but
probably
not
the
most
efficient
thing.
B
I'm
still
I've
gone
back
and
forth
about
whether
I
should
be
using
cars
but
car
everybody
loves
a
car
and
there's
lots
of
tooling
out
there.
So
I
thought
I
would
go
ahead
with
it
and
that's
the
protocol
so
and
that's
all
there
there's
that's
all
there
is
to
it.
I
want
to
talk
about
why
we
should
use
hdb
yeah
sure,
but
there
will
be
questions
at
the
end.
I
promise
I
promise
a
double
promise.
B
Why
would
we
use
HTTP
so
there's
a
couple
things
that
I've
dug
in
that
there's
there's
sort
of
the
stuff
that
people
know
everybody
you
know
HTTP
is
incredibly
widely
deployed.
It's
very
easy.
It's
good
with
web
browsers
all
that
stuff.
But
if
you
go
back
to
http,
there's
there's
another
there's
a
couple.
B
If
you
go
back
to
like
the
design
of
HTTP,
like
my
first,
my
first
like
programming
Supervisor
was
like
a
devotee
of
a
guy
named
Roy
Fielding,
who
like
came
up
with
HTTP
1.1,
and
this
principle
called
rest,
which
was
like
this
set
of
tools
for
building
an
incredibly
widely
distributed
system
and
so
HTTP.
B
That's
part
of
the
reason
hdb
works
is
because
of
its
design
is
built
to
support
lots
of
caching
and
getting
things
from
anyone,
and
the
URL
provides
like
a
really
good
is
essentially
your
cash
key,
and-
and
this
is
actually
an
interesting
property
that
we
we
really
haven't,
thought
about
taking
advantage
of.
But
a
URL
is
actually
a
great
constraint
for
a
selector
right.
D
B
Can't
fit
it
in
a
URL,
then
maybe
you
have
too
complicated
a
language
and
I
don't
mean
a
selector,
but
it's
a
query
constraint
for
any
kind
of
a
query
right
and
if
you
look
at
URLs
over
time,
people
have
built
complex,
highly
Dynamic
applications,
Unix
FS,
the
application,
we're
sort
of
building
with
ipfs.
B
It's
almost
like
the
web
1.0
right,
and
they
did
that
fine
with
URLs
and
and
then
but
but
you
think
about
like
Web
2.0
is
all
these
Dynamic
applications
that
were
built
with
just
URLs
as
they're
sort
of
like
go-to
and-
and
it
makes
for
this.
This
really
interesting
like
mechanism
for
caching,
which
makes
the
system
easy
to
distribute,
and
we
we
should
have
a
really
good
Advantage
here,
because
we
should
have
true
highly
cachable
content
because
of
the
nature
of
content
addressing,
and
we
haven't
really
always
had
that
yet.
B
But
I
think
it's
an
interesting
constraint
and
the
URL
is
a
really
interesting
way
to
limit
what
you
can
do
and
it's
so
and
you
know
we
often
go
back
and
forth
about
like
what
kinds
of
queries
should
we
support?
Should
we
support
pathing?
Should
we
support
something
more
complex,
like
selectors
and
I,
think
that
the
rule
that
I
would
put
forward
from
having
looked
at
the
Gateway
spec,
because
actually
the
Gateway
people
have
been
like
that?
B
The
folks
who
built
the
Gateway
have
been
building
this
out
for
a
while
is
if
it
can't
fit
in
a
URL.
Maybe
you
haven't
done
it
right
anyway?
So
that's
just
a
sidebar
yeah.
So
that's
that
okay,
good
properties
of
HTTP,
let's
see
what
else
I
have
another
question.
So
this
is
something
that
came
up
for
me.
What
is
the
slash
ipfs
in
a
Gateway
request
mean.
B
So
if
you
go,
if
you
actually
dig
into
the
ipld
docs
on
ADLs,
there's
a
section
where
they're
like
well,
an
ADL
is
like
the
Slash
ipfs
and
the
Gateway.
That's
actually
like
kind
of
an
ADL.
It's
a
Unix
FS
ADL
for
pathing
into
Unix,
fs
and
I'm.
Like
that's
cool,
that's
interesting,
but
then
I
was
like
okay.
B
Let's
talk
about
what
an
ADL
is
and
I
had
this
fascinating
conversation
with
the
dean
a
couple
days
ago,
where
we
came
to
a
disagreement
about
like
where
the
bounds
of
an
ADL
was
or
not
a
disagreement,
a
different.
We
have
different
ideas,
so
show
of
hands
who
thinks
a
Hamp
is
an
ADL.
B
Adl
is
an
advanced
data
layout.
Would
you
call
it
a
Hamp,
an
ADL
all
right,
somebody
raised
their
hand
yay
all
right,
yeah,
who
knows
okay
ADL
by
the
way,
stands
for
Advanced
Data
layout,
which
provides
a
different
lens
from
which
to
view
data.
Okay,
I
think
the
Hampton
ADL
is
like
Camp
is
like
the
canonical
ADL.
Actually
right,
it's
like
very
clear.
B
You,
like
all
you
want,
is
a
map
and
you
want
to
represent
it
as
a
you
know,
you
want
to
be
able
to
interact
with
it
like
a
regular
old
map,
but
underneath
it's
this
multi-block
structure,
you
know
that
you
know
comes.
That
represents
a
complex
and
mutable
way
of
creating
of
representing
a
very
large
I.
Don't
know
map
in
memory,
I
don't
know,
there's
a
whole
top
enhance
from
ipfs
Camp
I
encourage
you
to
go,
see
it
all
right,
but
here's
another
question
is
UNIX
FS
an
ADL
right,
so
here's
a
so.
B
B
It's
okay,
open
question:
you
don't
have
to
raise
your
hand
or
not,
but
I
found
this
I.
So
this
starts
to
get
pretty
interesting,
because
it's
not
just
a
data
structure
here
over
multiple
blocks.
It's
like
a
whole
file
system
right.
It's
like
it
is
a
data
structure
which
is
like
the
directory,
which
actually
also
has
a
Hamp
in
it
for
one
form
of
the
directories.
And
then
you
have
the
and
you
know,
and
then
you've
got
files
at
the
end
of
those
directories
and
it
all
links
up
together
right
all
right.
B
There
are
hamps
and
all
kinds
of
things
inside
of
inside
a
file
coin.
Right,
like
there's
all
kinds
of
those
things,
there's
there's
very
complex
data
structures,
but
it
all
links
together.
Okay-
and
so
there's
like
this
thing
about
levels
of
ADLs,
it's
not
well-defined.
This
part
of
ipld
is
not
well
defined.
Okay.
B
What
do
you
call
this
like
thing
when
you
put
everything
together
right,
I
started,
calling
it
an
application
right,
because
it's
kind
of
like
what
you're
doing
with
ipfs
or
I
mean
ipfs
I
guess
is
a
app
it's
a
protocol.
It's
not
an
application.
I
was
like
and
then
I
was
like.
Well,
let
me
rewind
and
think
about
what
it
was
like
when
I
used
to
build
things
for
web
2
and
I
built
things.
B
I
build
applications
for
web
2,
and
when,
when
you
started
to
build
an
application
for
web
2,
you
would
start
by
building
something
called
a
domain
model
right.
A
domain
model
is
basically
thinking
through
the
structure
of
the
of
the
the
type
of
thing
you're
trying
to
build
and
figuring
out
all
the
entities
within
it
and
then
figuring
out
how
they
relate
to
each
other
right
and
you
actually
in
web
2.
B
You
could
be
you
know
if
you
build
a
web
2
app,
you
have
this
complex
domain
model,
and
then
you
have
these
endpoints
that
can
do
all
kinds
of
crazy
searches
into
your
domain
based
just
off
of
pathing
right
and
this
isn't
just
static
files.
This
is
like
usually
talking
to
a
database
so
anyway.
So
this
is
something
I've
been
really
interested
in
and
I
would
put
forward
a
a
claim
which
is
ultimately
the
thing
that
is
really
interesting
and
really
enables
powerful
queries
is
a
whole
domain
model
right.
B
The
reason
that
the
Gateway
is
widely
used
is
because
it
has
like
you
can,
because
it
understands
all
of
unixfs.
You
can
just
do
this
little
path,
and
then
you
get
what
feels
like
the
most
powerful
thing
in
you
know:
query
that
we
do
in
ipfs,
which
is
web
1.0.
Let's
look
into
directories
and
files
right.
We
still
haven't
gone
past
that
so
this
is
so
this
is,
but
but
it's
it's
still
like
this
is
useful
right.
B
If
you
have
a
domain
model
that-
and
you
have
complex
understanding
of
what's
going
on,
you
can
do
complex
queries
with
not
a
lot
of
information
anyway.
Selectors
could
be
out
of
their
own
domain
model.
Maybe
just
ipld
itself
is
a
domain
model.
I,
don't
know
it's
it's
an
interesting
question,
but
I
I,
I,
I
I,
think
it's
worth
considering
and
I
actually
have
gone
taken.
The
Liberty,
probably
this
is
the
most
controversial
part
of
this
this
out
this.
B
This
proposal,
which
is
I,
am
considering
the
slash
ipfs
part
of
the
Stargate
protocol
to
be
the
Unix
FS
application
or
Unix
FS
domain
model.
Further
ones
could
be
added
at
a
later
point
right
on
and
you
can
you
could
build
it
and
the
the
goal
he
and
and
theoretically
this
might
solve
some
of
our
like
one
more
protocols.
Well,
maybe
what
you
need
to
do
is
build
build
the
ability
to
put
in
applications
and
transmit
them
around
and
plus
we
have
wasm
and
you
can
just
you
know,
transmit
around
applications.
B
Super
easy,
barely
an
inconvenience
It'll
like
you
know,
and
you
just
distribute
them
widely,
and
anyone
can
figure
it
out
so
that'll
one
day
all
work
and
then
in
any
case,
in
the
meantime,
it's
it's
more
food
for
thought
cool.
Let
me
see
where
I
am
in
this
presentation.
Yeah.
Oh,
oh
I
want
to
talk
about
one
more
thing.
B
There's
this
this
statement,
I've
heard
a
few
times
like
that,
like
dag
traversal,
is
considered
harmful,
and
this
is
this
is
coming
from
like
some
folks
who
are
building
the
most
scalable
largest
ipfs
implementations
in
existence
right
and
I.
Think
that's
interesting
right
like
why
are
the
people
who
are
scaling
up
ipfs,
saying
that
traversal
is
considered
harmful
right?
What's
the?
Why
here?
Well,
my
proposal
is
the
dad
traversal
is
not
scalable
in
its
current
form.
Right.
B
Let's
talk
about
what
Dad
traversal
means:
I
start
with
a
sid
I
load
the
block
from
disk
I
deserialize.
It
I.
Look
into
it
find
some
relevant,
related
links
and
SIDS.
Then
I
go
ahead
and
like
go
through
each
one
of
them
load
their
block
deserialize.
It
probably
doing
this
all
one
one
at
a
time
right
in
the
best
case
scenario,
I
have
some
parallelism
and
I
repeat
the
process
ad.
C
B
And
something
that's
been
interesting
to
me:
yeah,
you
just
keep
recursing
recursing
until
you
have
no
more
states
to
Traverse,
could
we
do
better
right?
So
this
is
something
that's
been
fascinating
to
me
for
a
while.
I
was
like.
Why
can't
we
answer
the
question?
What
that,
what's
what
SIDS
are
in
my
dad,
without
having
to
read
through
every
block
and
I,
think
and
and
sort
of
to
me?
B
The
answer
to
this
is
you
need
some
kind
of
metadata
information
about
the
dags
and
I
started
started
off
thinking
about
how
can
we
build
a
general
case,
like
you
know,
metadata
data
store
for
ipld
that
can
answer.
Ipld
queries
quickly
and
I
came
to
the
conclusion
that
is
too
hard.
B
Maybe
somebody
will
do
it
and
maybe
somebody
was
smarter
than
me
will
do
it,
but
the
problem
is
like
trying
to
answer
General
case
queries
about
ipld
without
looking
at
the
blocks
you
get
into
a
lot
of
hard
problems
like
you
know,
like
R2
nodes
in
an
arbitrary
directed
async
with
Dad
connected
like
that's,
like
not
super
easy
to
answer
in
some
like
01
type
time.
B
So
I
was
like
what,
if
but
but
if
you,
if
you,
if
you
limit
that
metadata
or
you
make
it
specific
to
a
domain
like
Unix
FS,
you
can
actually
answer
almost
all
of
the
queries
cool.
So
I
think
this
is
actually
the
point
where
I
wanna
I
think
I'm
going
to
switch
over
to
a
demo,
actually
yeah,
let's,
let's
switch
over
to
demo
again.
This
part
is
a
little
out
of
order.
B
I
just
want
to
show
you
the
thing
works
and
then
I
will
show
you
some
some
things
about
how
it
does
it:
okay,
cool,
so
I'm
gonna
go
to
terminal.
This
will
definitely
be
the
part
where
I
hope
for
the
best,
all
right
so
there's
this
is
this
is
my
command
line?
I
am
going
to
start
off.
B
B
B
Part
of
the
reason
it
goes
fast
is
because
it's
all
done
with
the
file
store
abstraction,
which
basically
allows
you
to
write
block
stores
that
aren't
really
block
stores,
but
really
just
references
to
existing
files
on
your
system,
cool,
so
I
did
that
and
I
got
a
root,
Sid
I'm,
actually
gonna
do
one
other
thing,
because
almost
all
the
files
in
this
directory
are
basically
very,
very
small
and
so
I
am
going
to
import
one
other
thing
which
is
I'm
going
to
import
a
little
video.
B
Great
okay,
so
now
I
have
two
SIDS
and
now
I'm
going
to
start
my
started.
Server.
I
could
have
started
this
before,
but
whatever
all
right,
I'm
starting
my
Stargate
server.
All
right,
you
have
a
port
now.
I
have
not
finished
the
client.
So
this
part
of
the
demo,
it's
gonna,
be
a
little
bit
of
a
bummer.
Well,
it's
not
going
to
be
that
much
of
a
bummer,
because
I
figured
out.
You
can
show
that
it's
working
without
all
that,
so
we'll
see
all
right.
Let's,
let's
do
a
thing
all
right!
B
So
first,
let's
just
try
to
get
the
root
of
this.
The
root
directory
of
my
code,
repo
here.
So
let's
go
ahead
and
we're
going
to
do
it
with
a
really
fancy
program
called
yeah.
There
we
go.
This
is
this:
is
the
curl
program?
I,
don't
know
if
you
all
have
used
it
before,
but
it's
it
I
hear
that
it
can
get
you
some
things.
B
B
I
know
Ctrl
a
and
control
e,
and
that's
about
it.
Okay,
so
cool
I'm
gonna
put
this
sit
in
here
and
you
can
see
that
we
got
a
200
response
and
we
did
download
the
the
the
file
looks
like
it
was
177k,
probably
because
it's
got
a
bunch
of
Sids
in
it
and
actually
that's
bigger
than
I
would
have
thought
but
whatevs
and
then
to
prove
that
this
is
actually
working.
I
will
do
a
pathing
request
and.
B
Go
to
a
mod
here!
Being
the
oh
wait,
that's
the
download
speed!
Sorry,
the
transferred
is
only
four
thousand
eight
eighty
one
bytes
for
the
top
level
directory
for
four
thousand
for
the
for
the
the
go
mod,
oh
because
there
actually
aren't
that
many
bytes
in
the
top
level.
There.
B
B
Okay,
yeah
and
you
can
see
that
I
got
a
404
not
found
and
I
got
a
404
and
I
found
over
here
and
saying
that
there
was
no
file
or
folder
named
cheese,
okay,
cool
and
so
then
I'm
going
to
go
ahead
and
do
a
couple.
Other
I'm
gonna
do
something
else
which
is
I'm
gonna,
go
ahead
and
try
to
download
something.
That's
in
a
nested
directory.
So
let's
see
package.
What
do
we
got
here?
Package,
slash
types,
I,
think:
that's
a
file.
D
B
There
we
go
another
200
and
we
got
that
to
download
cool
yay
all
right
so
now,
I
want
to
show
you
some
cool
things
about
about
some
cool
things
you
can
do
with
Unix
FS
files
with
with
this
protocol
thing
that
I
wrote.
So
let's
get
our
other
Sid
and
I,
of
course
failed
to
copy
paste
it,
and
let's
try
this
okay,
so
now
I'm
going
to
download
this
video
file,
I'm,
actually
going
to
add
a
parameter
at
the
end
called
leaves
right.
B
B
Maybe
I
might
switch
those
defaults,
because
people
expect
the
whole
thing
to
come
back,
but
you
can
see
I
transferred,
10
megabytes
if
I
go
ahead
and
take
off
this
now,
I
transferred
4K
and
I
think
this
is
a
really
key
thing,
but
in
that
4K
is
all
the
sits
for
all
of
the
other,
all
the
leaves
they're
just
not
the
content.
I
think
this
is
a
a
thing
that
we
could
be
that
particularly
for
Unix
FS
like
to
me.
That's
an
obvious
way
to
deal
with
file.
B
B
So
that's
a
thing
and
then
I
want
to
show
you
one
other
thing
I'm
going
to
put
my
leaves
back
on,
but
then
I'm
also
going
to
do
another
thing
which
is
I'm
going
to
go
ahead
and
say:
bytes
equals,
let's
say
one,
but
it's
got
ten
thousand
to
three
million
I.
Don't
know
I'm
just
making
up
right
now
is
that
six
zeros
I
think
so,
let's
see
no,
oh,
no
200.
Okay,
writing
failure.
Writing
did
I
spell
it
wrong.
Probably
did
oh
I
did
this
right
beforehand
and
then
I
broke
it.
B
Oh,
oh
I,
now
I,
remember,
I,
didn't
stargate's,
not
broken.
I
forgot
that
and
characters
are
escaped
in.
So
you
can
see
here.
I
transferred
three
total
megabytes,
that's
a
little
less
than
then
a
little
more
than
this,
and
that's
because
it
has
to
transfer
in
Block
amounts,
but
you
can
see
that
there's
a
unit,
you
know
a
query.
That's
really
useful
for
Unix
FS
is
give
me
a
byte
range.
Now
you
can't
really
use
a
HTTP
range
request.
I
mean
you
could
use
the
range
header
to
do
this.
B
The
reason
you
don't
want
to
is
the
range
header
has
a
very
specific
meaning.
The
only
proxy
supported
meaning
for
the
range
header
is
a
byte
range
of
the
actual
response
and
it
doesn't
start.
It
still
supports
that
as
well.
But,
like
the
thing,
that's
useful
for,
like
verifiable
data,
is
actual
range
of
the
underlying
Unix
FS,
but
giving
you
the
whole
car.
So
this
is
a
you
know.
Another
thing
that's
that's
kind
of
useful
to
do
and
and
like
my
thought
is
like
so
those
are
the
parameters.
B
I
came
up
with
for
Unix
FS,
just
off
the
top
of
my
head.
You
could
come
up
with
lots
of
other
ones
right
and
presumably
every
application
would
have
to
have
a
spec
that
would
describe
what
does
it
support?
How
does
it
work?
How
does
it
Chunk
Up
messages
all
that
stuff
cool
I
want
to
show
you
guys
just
a
couple
things
about
the
code
and
that
and
and
the
first
thing
I
want
to
show.
B
You
is
my
sort
of
like
solution
to
how
to
how
to
query
Unix
FS
quickly
and
the
short
version
is
again:
I
fell
back
on
web
2
and
built
an
SQL
database
that
tracks
everything
that
you
care
about
for,
for
you
know,
except
best
data
right.
B
This
is
I,
haven't
even
tried
the
performance
optimize
this,
but
basically
what
you've
got
in
here
is:
okay,
I'll
show
you
the
schema.
It's
like.
Basically,
you've
got
a
concept
of
directory
links
which
are
just
like
a
link
between
a
root
Sid
and
like
another
Sid
in
the
directory.
B
This
is,
this
is
actually
an
interesting,
complicated
thing
because
you
want
to
support
both
hamps
and
non-amps
and
amps
have
like
each
each
link
to
the
file
is,
is
like
each
subpath
has
one
link,
but
in
in
regular
directories,
but
enhance
each
subpath
has
multiple
SIDS,
so
I
sort
of
to
build
that
thing.
B
That'll
assemble
this
and
then
for
file
links
you
basically
I
I
built
a
thing
that
cover
that
essentially
stores
the
important
information
that
you
get
out
of
the
Unix
FS
header
about
the
file
itself
and
a
lot
of
this
stuff
is
in
the
Block.
It's
just
that
it's
just
not
saved
and
easily
queryable,
and
this
is
how
you
can
do
these
byte
range
queries.
I
have
another
table,
that's
just
like
things
that
are
roots
in
Unix
FS
like
so.
B
The
concept
of
a
root
in
Unix
FS
is
interesting,
because
a
Unix
FS
block
is
not
inherently
a
root,
and
this
isn't
it
right.
So
this
is
an
interesting
and
it's
not
always
obvious,
either
which
whether
it's
a
root
or
not
like
both
for
Unix
FS
files
and
for
and
for
Hamp
directories,
there's
a
bunch
of
intermediate
nodes
that
just
looking
at
them
on
their
own.
B
You
can't
tell
if
they're,
if
they're
roots
or
not
so
anyway,
and
then
I
wrote
a
bunch
of
utilities,
basically
to
Traverse
cnxfs
and
like
find
all
this
stuff,
and
what,
when
you
look
at
the
actual
way,
this
whole?
Let
me
pull
this
up.
I'm
gonna
show
you
the
import
command
and
what
it's
doing,
by
the
way,
with
the
roots,
you'll
notice.
There's
this
metadata
thing
there's
an
interesting
question
around
like
like
I'm,
not
answering.
B
Our
data
is
stored
in
giant
pieces
which
are
like
separate
car
files,
and
so
I
wanted
to
make
sure
that
my
thing
would
be
useful
for
a
file
coin
type
storage,
because
that
might
make
my
team
want
to
actually
use
it
one
day.
So
this
just
metadata
in
the
case
of
filecoin
actually
would
just
point
to
like
a
piece
Sid
or
a
car
file,
or
something
that
the
things
you
would
need
to
do
that
if
I
look
at
the
actual
import
command,
what
I
am
doing
is
I
am
I'm.
B
Essentially
you
know,
reading
in
the
car
file,
yeah
all
right,
I'm
reading
the
I'm
reading
the
directory
in
writing
out
the
whole
car
files,
all
the
things
that
are
in
that
directory,
it's
a
recursive
walk
through
the
directory
and
I'm,
actually
not
trying
to
build
a
database
at
that
time,
because
I
wanted
to
get
to
a
flat
car
file
and
then
reassemble
it
by
scanning
the
car
file.
Again.
B
So
in
any
case,
so
yeah
so
I
read
the
whole
thing
and
then
I
initialize
this
store
and
then
I
import
it
and
the
import
process
looks
like
a
essentially
reading.
All
the
SIDS
in
the
in
the
in
the
store
and
running
this
program
called
discover,
Roots,
which
reads
through
blocks,
and
basically
you
know
if
if
they
happen
to
be
in
raw
format
or
in
protobuf
format
and
then
like
if
they're,
when
you
read
in
the
protobuf
ones
and
deserialize
them,
then
you
like
read
that
they're
Unix
FS.
B
Then
you
start
putting
them
in
this
list.
And
then
you
have
this
system
for,
like
tracking,
like
which
ones
are
Roots
by
like
initially
assuming
everything's
a
root
and
then
finding
at
it's
not
when
another
unit,
except
has
block
points
to
it
and
then
once
you've
got
the
roots,
then
you
re,
you
add
all
the
intelligence
by
scanning
again
through
the
the
files.
It's
probably
not
the
most
efficient
thing,
but
it
is
something
you
could
run
on
an
existing
Block
store
without
any
big
changes,
which
is
felt
important
to
me,
anyways.
B
That's
how
that
does
that
and
then,
when
you
actually
make
a
request,
I
want
to
just
show
you
the
like
the
concept
of
like
basically
like
the
concept
of
how
you
would
respond
to
a
query
right.
I
have
this
concept
of
a
resolver
I
mean
this
is
actually
kind
of
a
steal
from
yet
another
web
2
thing
which
is
graphql.
If
you
look
at
how
you're
supposed
to
implement
graphql
servers,
almost
everything
in
them
requires
you
to
build
a
thing
that
says.
B
Given
this
query
resolve
it
for
me,
and
so
with
the
with
the
way
the
app
resolver
works
you
it
essentially
starts
with
it.
The
first
thing
you
have
to
do
is
resolve
the
route,
and
when
you
resolve
the
root
you
actually
return,
The
Block
store
you're
going
to
use.
This
could
be.
B
This
is
an
ipld
link
system,
which
is
just
the
IPL
DFI
Block
store,
and
then
you
get
back
and
then
you
get
a
path
resolver
and
then
and
then
the
path
resolver
can
do
one
of
two
things
again
and
try
to
resolve
all
the
path
segments
I
mean
when
you
resolve
you
get
back
a
path
message:
you
get
back
the
path
segment,
you
get
back
the
remaining
path
segments
and
then
you
get
another
path.
B
Resolver
or
you
can
convert
to
a
query
resolver,
which
basically
means
resolve
the
rest
of
the
DAC
and
then
I've
got
a
thing
that
can
just
block
this.
You
know,
then
I
have
code,
That'll,
Walk,
This
and,
like
you
know,
build
the
response
based
off
of
that
and
the
query
resolver
just
sends
like
dag
messages
back
so
an
interesting
thing
about
this
is
that
none
of
these
resolvers
are
reading
block
stores.
There's
no
read
of
The
Block
store,
that's
why
it
returns
this
ipld
link
system.
B
So
this
is
all
if
you
look
at
the
Unix
FS
implementation
that
I've
built
it's
all
using
this
database
as
the
thing
that
you
know
like
reads
out.
All
of
this
information
right,
so
this
is
like
all
the
this
is
like
the
Unix
FS
store
it
can
like
do
a
Dura
LS,
a
dirt
path,
a
durafile
all
file
byte
range,
a
root
Sid.
B
It
doesn't
really
matter
these
are
these
are
the
things
anyway
so
yeah,
so
that
is
all
done
without
ever
looking
at
the
Block
store,
and
then
you
have
the
actual
car
rider,
which
is
not
optimized
right
now,
but
it's
like
not
very
complicated.
It
has
the
link
system,
it
gets
the
messages,
it
reads
them
out
of
the
Block
store
and
writes
them
and
I
figure.
It
can
be
like
you
know,
super
pipeline
optimized
at
some
point,
and
the
idea
here
is
that
you
know
like.
B
Basically,
this
thing
is
a
separate
responsibility
and
it's
never
deserializing
blocks.
So
that's
kind
of
the
basic
idea
and
again,
like
I,
built
I,
think
the
way
this
resolver
is
built
it
could
like
you
know
you
could
support
other
things.
If
you
wanted
to
build
a
file
coin,
one
you
could
build
it.
I
might
try
to
do
that.
B
One
day,
if
I'm
I
acquire
about
a
thousand
hours
of
random
free
time,
so
yeah,
but
you
could
I,
think
I,
don't
know
we'll
find
out
again
it's
all
built
around
the
structure
of
URLs
and
how
you
might
want
to
resolve
things
in
in
in
different
applications.
Now,
if
you,
if
you
actually
sorry
I'm
going
to
rewind
for
two.
B
Yeah
and
if
we
built
this
and
if
we
build
it
all
the
way
out
and
it's
super
awesome-
I
can
do
everything
with
web
2,
then
we
can
go
to
the
next
level
and
start
building
like
an
actual
selector
graphql
type
interface.
Maybe
we
should
start
put
that
at
the
end,
rather
than
at
the
beginning,
so
yeah.
That's
the
basic
idea,
I'm
trying
to
think.
If
I
have
anything
else,
I
apologize,
I'm,
just
sort
of
like
scanning
slides
from
I've
covered
everything
yeah.
So
that's
the
deal.
B
The
code
is
available
or
well
yeah.
No,
it
is
available.
I.
Think
it's
I'll,
send
the
I'll
I'll
send
more
information
after
this,
but
let
me
see
where's
the
chat,
the
chats
by
the
way,
there's
there's
there's
like
a
little
like
I.
Don't
know
if,
if
dig
is
on
the
call,
but
if
he
is
I
I
may
or
may
not
have
like
taken
some
ideas
for
me.
So
I
want
to
give
credit
because
he
was
like
he
was
like.
B
Let's
just
do
a
good,
you
know
path
and
dag.
Underneath,
oh
by
the
way.
Another
thing
that's
great
about
paths
and
dads:
is
you?
Don't
have
like
duplicate
logic
is
really
straightforward.
One
of
the
worst
problems
with
selectors
is
figuring
out
how
to
arbitrarily
tell
if
you
need
to
Traverse
something
again.
You
don't
have
to
do
that
as
much
with
an
all
selector
or
pass
selector.
If
past
selector
never
has
a
duplicate
and
and
all
selector,
you
can
always
assume
that
you
don't
need
to
Traverse
it
again
hold
on
one.
B
Second,
let
me
let
me
just
send
the
URL
I'm
gonna
put
it
into
here,
because
I
can't
remember
what
it
is.
Okay,
I
have
no
idea
how
long
I've
talked
for
and
I
apologize.
If
it's
been
on
the
super
long
side,
it
is
in
the
ipfs
repo
which
I
can
move
it
to
my
own
I
didn't
like
know.
Apparently,
I
still
have
some
level
of
admin
access
which
allowed
me
so
not
admin.
B
Access
I
have
like
what
I'm
on
my
like
the
go,
go
core
team
still
from
like
2018,
so
that's
why
it's
there
and
here
I,
can
send
you
the
protocols
back.
This
is
all
like
super
Rock,
So
apologies
anyway.
There
you
go.
A
It
cool,
do
you
mind,
mixing
screenshot
and
we
can
go
to
some
questions.
C
A
Dean
I'll
go
first,
his
are
generally
better
I'll.
Ask
good
questions.
A
E
Okay,
so
I
I,
like
I,
like
it
I,
think
that's
the
the
gist
I
I
just
wanted
in.
In
the
meantime,
I
was
like
they're
taking
notes
because
we
were
looking
at
this
already,
but
the
I
think
the
Hana
just
bridged
the
Gap
by
introducing
the
concept
of
like
application
of
ipfs
like
and
like
making
a
king
xfs
domain
specific
and
but
that,
like
the
prefix,
slash,
ipfs
defines
the
domain
more
or
less
provisionally
with
that
and
lives
and
by
its
parameters
are
really
really
useful.
E
Something
we
did
not
consider
before,
but
I
see
now
how
they
they
are
useful.
We
had
the
discussions
about
that,
but
you
don't
always
know
the
depth
of
the
dog,
so
the
leaves
Flex
is
really
useful.
I
dropped
some
notes
on
on
the
issue
about
like
car
export
with
selectors.
E
When
we
quickly
realize
we
don't
want
selectors.
So
there's
like
a
huge
I.
Think,
there's
like
a
huge
alignment
in
what
it's
like
at
the
inner
direction.
We
want
it
and
I
feel
we
from
the
Kuba
perspective
and
other
implementations
that
already
Implement,
let's
say,
block
and
car
on
gateways.
It
would
be
easy
to
extend
I
feel
the
only
you
know.
They're,
like
the
only
questions
are
around
like
error.
Hunting,
the
content
type
and
accept
headers
are
often
ignored.
E
So,
even
though
the
dedicated
content
type
is
nice
gateways
will
often
just
return
you
bytes
without
saying
I,
don't
know
what
it
is.
I
will
just
give
you
HTML.
So
those
are
a
quick,
quick
notes.
I,
like
I,
think,
like
from
the
perspective
on
my
mobile
web
browsers,
which
do
not
want
to
run
fully
peer-to-peer
only
P2P
stack.
It's
also
like
really
nice,
especially
the
byte
range
one.
The
ordering
and
the
duplicates
are
open
questions,
but
that's
the
kind
of
like
high
level
that
time
online
on
the
direction.
A
C
Okay,
cool
yeah,
I
guess
a
few
things
so
I
I
as
little
said
also
also
a
fan,
I
I
think,
like
I,
tried
putting
together
like
a
a
matrix
of
like
some
of
the
protocols
that
we
have
already
and
what's
going
on
all
the
request
response
protocols
you
want
to
use
like
HTTP
or
like
carrier,
pigeon
or
TCP
like
who
cares
and
HTTP
has
proxy.
It
has
like
caching
and
stuff
by
cloudflare
and
Amazon
so
yeah.
C
Do
it
I
think
the
there's
there's
like
a
little
there's
like
a
few
awkward
things
about,
like
choosing
like
slash
ipfs,
to
mean
Unix
FS,
based
on
some
things
that
people
have
done
in
the
last
year
and
a
half
that
they
were
not
supposed
to
do
According
to
some
people
or
not
other
people
that
have
made
it
like?
C
Not
a
Unix
FS
thing
for
the
people
like
Brendan,
who
are
going
like
this
I'll,
give
like
a
brief
tldr,
which
is
there
may
or
may
not
be
a
bunch
of
nfts
that
you
can
do
slash
ipfs
Seaboard
object,
slash
Foo,
which
is
a
unixfs
file.
C
That
aside,
at
the
moment,
you
know
I
like
the
like
the
bytes
and
the
and
bites
and
leaves
I,
don't
know
if
there's
other
things
that
we
we
need,
particularly
around
directories
and
like
what
level
of
access
people
need
to
directories,
but
basically
URI
URLs
good,
getting
something
that
is
like
usable
enough
as
a
graph
descriptor
that
people
can
work
with
it.
Also
good,
because
at
the
moment
everybody
hates
all
of
them
right.
Current
current
ipfs,
not
good
enough
I,
don't
have
byte
ranges
and
such
selectors
I
hate
them.
C
They're
too
complicated,
I'm,
ignoring
everything
except
for
blocks.
It
doesn't
work
because
I
have
hands
so
like
finding.
That
feels
like
one
of
the
key
pieces
is
like
just
getting
that
descriptor
thing
we
can
align
on
I
guess.
Maybe
a
question
is
like
an
or
a
comment
is
like
awkward
thing
about.
Car
files
is
like
and
streaming
them
is
I
I,
don't
know
when
they've
terminated,
which
basically
is
what
little
was
I,
think
part
of
what
I
was
getting
out
with
error
handling.
C
So
if
you
go
to
today
and
you
do
ippest.io
and
get
a
car
and
then
it
dies
in
The,
Middle,
there's
no
way
to
know
unless
you
go
and
validate
the
car,
whether
that
closing
was
accidental
or
not
or
as
the
result
of
an
internal
error
or
a
Comcast
error.
It
just
kind
of
happens.
B
B
The
header
comes
first
followed
by
the
rest
of
the
response,
so
it
means
you
have
to
kind
of
like
decide
ahead
of
time,
whether
you're
going
to
succeed
or
fail
or
like,
and
why
right
and
I
actually
so
what
I'm
doing
at
the
moment
is
probably
super,
not
up,
probably
not
the
right
solution,
but
it's
a
solution
is
I'm,
actually
writing
the
car
file
to
a
file
and
then
just
streaming
the
file
and
but,
and
you
know,
and
then
you
send
the
now-
your
connection
could
still
go
down,
but
that
is
like
more
of
it.
B
I
think
that
is
expected,
Behavior,
that's
more
how
HTTP
is
expected
to
work.
It
also
I
mean
for
what
it's
worth.
It
enables
range
requests
if
we're
using
the
header
range.
If
you
care
about
that
and
then
but
then
but
yeah
like
the
interesting
thing,
is
that
yeah
and
then
you
can
decide
and
give
the
generally
the
the
yeah
right.
It.
B
Streaming
errors,
it's
a
bummer.
So
but
that's
that's
the
thing
that
I
did
for
the
time
being,
just
to
make
it
work
with
HTTP
but
yeah.
It's
not
probably
optimal,
then
again
hard
disk
reads
or
cheat.
Maybe
well.
C
C
B
Was
partly
going
towards
like
that's
a
totally
yeah,
no
I
was
like.
Why
don't
I
have
this
problem
in
graphing,
because
grasslink
is
a
series
of
messages
right,
so
it
can
just
change
it
at
any
time.
Versus
HTTP
is
a
request
and
response,
and
you
generally
expect
to
get
one
response
back
now.
I
guess
you
can't
really
do
a
server
I
heard
you
could
do
a
server
push,
but
then
I,
Googled
it
and
apparently
server
push
is
dead
like.
D
So
if
I
were
to
solve
this
I
would
like
add
message
so
you're
using
already
I,
think
your
messages
into
the
car
fire
and
you
could
do
the
same
thing
with
different
messages
like
instead
of
having
a
network
artists
that
you
find
a
network
on
the
streaming.
You
add
some
special
cids
that
indicate
oh
actually,
I'm
I'm
done
I'm,
not
finished.
That
I
cannot
see.
This
should
have
any
alarm
or
another.
One
would
be
right
now.
The
cop
fight
is
expected
to
terminate
when
the
body
terminates,
but
because
HTTP
one
is
awesome.
D
Sometimes
the
body
terminate
and
you
don't
actually
know
if
that's
on
purpose
or
not,
it
can
be
for
multiple
reasons.
So
you
could.
We
could
say,
let's
say
we
add,
like
a
magic
empty
elements,
so
you
make
it
like
a
zipper
block
and
a
zero
CID,
and
you
add
that
to
the
final
and
like
let's
say
now,
we
can
decide
that.
Oh,
this
is
the
end
of
a
car
fire.
That
would
be
a
pretty
small
change
to
the
cafe
spec
but
seems
like
a.
C
D
A
At
Hannah,
I
I
appreciate
I,
really
appreciate
you
calling
attention
to
the
construction
of
an
index
as
a
means
of
bypassing
the
expense
of
the
store
and
and
pointing
to
it
as
a
required
ingredient
of
a
data
transfer
protocol.
A
We
have
this
in
our
own,
have
had
it
from
day
one
where
we
just
have
an
index
of
everything
and
don't
touch
blocks,
and
it's
all
of
our
stuff
is
built
as
a
prere
with
that
as
a
prerequisite
in
mind,
and
so
you
I'm
delighted
to
see
that,
like
common
substrate
just
to
specifically
touch
on
this,
but
because
you
have
that
index,
if
the
car
file
or
whatever
transport
mechanism
you
use
is
specific
enough,
you
could
theoretically
know
your
bite
length
based
on
your
query
beforehand.
Right.
A
A
Maybe,
and
then
you
get
your
fancy
streaming
stuff
but
like
you'd,
have
to
be
damn
sure
that
it's
gonna
be
good
accounting
but,
like
we
have
unit
tests
for
that,
but
I
want
to
go
in
somewhere
else.
Some
other
direction,
specifically
the
question
about
how
you've,
really
what
you've
seems
like
you've
really
wrestled
with
is
the
is
the
connection
between
the
protocol
and
the
application.
A
Space
and
you've
made
a
pretty
declarative
statement
and
said:
if
we,
if
we,
if
we
poke
up
into
application
space
and
and
say
this,
is
how
we're
going
to
constrain
the
system
such
that
we
can
more
meaningfully
talk
about
it
and
I
think
that
I
thought
your
ADL
like
existentialism,
was
a
really
great
way
of
getting
to
that,
and
so
I
think
the
natural
question
that
begs
is
really
about
iplt
and
and
what?
A
How
would
you
now,
when
I
say,
IPL
day,
specifically
applications
that
don't
obey
the
unixfs
sort
of
Universe
of
tools
and
and
I?
And
if
I
understand
correctly,
your
protocol
is
implying
that
not
even
playing
you
said
it
right.
We
would
have
other
extensions
that
would
have
other
applications,
which
would
require
us
to
be
able
to
write
other
plug
other
mechanisms
for
people
to
write
different
things
that
aren't
non-unix
investors
is
that
right.
B
Yes,
so
I
would
argue
that
the
arbitrary
ipld
is
itself.
Arguably,
like
the
arbitrary
ipld
stack
AKA,
you
know
data
model
codex
like
what's
it
called
you
know,
schemas
and
ADLs
is
itself
an
application.
It's
I
like
like
there's
a
proposal
for
a
slash
ipld
on
the
Gateway
as
a
as
like
a
root
and
I
think
that's
worth
supporting
and
building
out
right
like,
and
we
could
totally
build
that
out
and
like
there's
some
fascinating
things,
they're
doing
with
like
the
past
segments
to
Signal
ADLs
and
all
that
I.
B
C
B
Makes
the
web
3
and
the
content
address
data
you're,
not
what
three
I
the
content
address
web
take
off
is
when
you
can
build
cool
stuff
with
it
and
in
my
mind,
people
are
going
to
want
to
write,
simpler
queries
and
more
optimized
queries,
because
when
you
know
a
lot
about
the
data
model,
you
can
do
a
lot
right.
B
C
Yeah,
so
this
is
I,
guess
just
the
like,
I'll
say
the
thing
that
lives
in
the
middle.
So
once
you
get
one
of
the
difficulties
with
this,
it's
just
like
it's
just
IPL
these
stuff
in
general,
with
like
the
I,
get
to
write
arbitrary
code
for
my
application,
whether
it's
a
codec
or
an
ADL
or
I,
guess,
maybe
a
hash,
but
we'll
ignore
the
hashes
and
pray
you
use
a
normal
one.
C
C
So
if
we
assume
that
that's
not
what's
happening,
then
you
still
need
a
way
to
deal
with,
like
the
the
blockish
side
of
things
right,
the
like
it
sucks
I
wish
that
you
know
webtree.storage
supported
a
Dean
fancy
ADL,
but
they
don't.
They
just
support
unixfs,
so
I'll
get
my
stuff
from
them.
C
It'll
just
be
slower,
and
when
we
do
that,
if
you
have
like
a
block
protocol,
that's
like
one
block
deciding
what
we
want
to
do
about
we'll
call
it
granularity
of
caching
right,
you
can
do
one
block
at
a
time
with
like
CID
block,
block,
block,
block
block
or
I,
can
group
them
together
and
ask
for
more
stuff
and
I
I.
Think
like
that,
probably
it's
like
there's
that
boundary
between
like
oh,
we
have
an
HTTP
protocol
for
single
block.
We
have
a
bit
swappy
thing
with
lots
of
blocks.
C
B
Just
just
yeah
so
I
actually
originally
intended
to
write
a
companion
like
multi-block
request
protocol
and
then
I
realized
that
building
an
entire
new
protocol
outside
of
my
regular
day.
Job
was
probably
a
little
bit
ambitious
and
so,
but
like
like
I,
had
some
ideas
on
this
front
like
the
caching
thing
is
really
tough
with
multi-block
right
like
because,
like
you
can't
really
like
once
you
have
a
combination
of
Sids
like
I'm
gonna
cash
them.
Arguably
I
guess
you
could
you
could
hash
them
together
and
then
you
get
a
hash
key.
B
It
just
wouldn't
be
a
very
useful
one
right
like
because
well,
unless
somebody
asks
for
the
exact
same
set
of
blocks,
it
wouldn't
be
useful.
The
so
my
thought
was
on
that
front:
Maybe
punt
on
cashing
I,
don't
know
like
and
but
and
then,
but
then
it
was
like.
Oh
well.
What
could
we
do
there
because
there's
a
lot
of
questions
about
what
we
transmit
and
my
thought
was
okay,
so
you
get
this
response
back
and
you
now
know
all
the
SIDS
you
care
about.
B
Theoretically,
I,
don't
know,
and
so
my
thought
was
at
that
point.
You
actually
would
be
an
entry
if
you
really
wanted
to
get
fancy
you
could
like
take
all
the
SIDS.
You
want
split
them
up
among
you
know
the
ten
five
peers
that
you
know
have
this
thing.
Hopefully
you
know
that
at
that
point
and
you
could
build
like
five
Bloom
filters
of
like
which
suits
I
actually
want,
and
the
nice
thing
about
doing
it.
B
That
way
is
that
I
believe
the
property
of
Bloom
filters
works
Works
in
that
direction,
where
you'll
get
a
little
extra
data
rather
than
a
little
under
data,
so
it
would
be
a
single
request.
I
somebody
with
Bloom
filtering
knowledge.
It
will
have
to
like
check
me
on
that,
but
I
believe
if
you
say
I
want
these
SIDS
expresses
a
bloom
filter.
B
You
could
also
do
like
a
bitmap
or
you
know
any
of
those
ideas
that
people
have
been
throwing
around
so
but
I
I
sort
of
like
said
well
block
multi-block
block
protocol
well,
first
of
all,
there's
a
bit
swap
available
for
a
lot
of
people
and
then,
second
of
all,
like
you
know,
like
there's
a
a
HTTP
block
protocol.
It's
not
particularly
powerful,
but
you
know
whatever
and
then
lastly,
there's
like
you
could
build
one
and
it.
B
C
B
Before
we
shut
down,
I
just
want
to
say
one
thing,
which
is
that
so
I
in
terms
of
like
what
I'm
prepared
to
do
on
this
protocol
that
I've
just
built
I'm
gonna
clean
clean
it
up
a
little
bit.
Add
a
few
more
tests.
Maybe
do
some
measurements
but
I'm
not
going
to
keep
developing
yeah.
I,
know.
I,
know
measurements
I
that,
like
like
I
had
so
many
conceptual
things
to
figure
out.
First
I
was
like
I
know
that
I
would
yeah.
B
Actually
it
was
all
going
to
get
done
before
before
this
presentation
and
yet
somehow
not
possible
anyway.
I
am
going
to
so
yeah
I'm
gonna
maybe
get
do
that,
but
then,
if
I
can
but
I
actually
am
not
going
to
be
the
one
to
keep
developing
this.
So
it'll
really
be
up
to
this
group
to
figure
out.
If
you
want
to
pick
up
and
do
something
with
it,
maybe
there's
some
useful
stuff
yeah.
So
there
you
go.