►
From YouTube: Move the Bytes Working Group Meeting 7
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
Hello:
everybody
Welcome
to
meeting
seven
of
the
white
working
group.
It
is
February
15
2023,
my
bad.
How
long
has
that
been
there?
However?
Anyways
cool
thanks
for
joining
everybody
today
is
gonna,
be
a
fun
one.
A
We
actually
get
to
change
up
this
sort
of
format
for
the
meeting
we've
been
having
presentations
for
our
last
six
meetings
and
then
we
had
a
kick
off
at
the
beginning,
which
was
not
recorded,
but
today
we
are
going
to
do
a
recap
of
the
protocols
that
we've
seen
to
date,
try
to
understand
and
compare
and
contrast
them
and
start
to.
B
A
Structure
this
as
a
group
discussion
to
talk
about
next
steps
and
what
we
might
do
from
this,
because
this
was
Bill
largely
a
requests
on
behalf
of
the
group,
as
we've
been
working,
saying,
hey
it's
time
to
step
back
and
sort
of
take
stock
of
where
we're
at
and
a
Dean
did
some
great
work
actually
Gathering
up
all
of
the
different
protocols
and
we're
going
to
go
through
this
a
little
bit.
But
because
this
is
really
hard
to
read.
A
I
figured
I
would
first
take
a
stab
at
just
summarizing
some
of
the
protocols
that
we've
heard
from
so
far
that
have
actually
presented
in
Prior
meetings
in
a
quick
review
and
then
we'll
sort
of
open
up
the
floor,
and
ideally
that'll
just
become
a
nice
starting
point
for
conversations
about
what
we're
going
to
do
next.
A
So
here's
a
copy
paste
of
that
fancy
table
which
some
of
it
may
have
actually
yeah
Hannah.
Thank
you
for
filling
in
this
out.
It
is
not
up
to
date
on
here,
but
just
to
like
get
a
quick
look
at
this
we've.
There
are
some
that
are
already
implemented
in
here,
so
we've
been
swapping
graph,
sync
The
Usual
Suspects.
We've
also
got
BitTorrent
website
and
get
sort
of
listed
out,
mainly
as
a
sanity
check
and
hey.
You
know
these
are
real
protocols
that
are
in
production.
A
We
also
have
car
mirror
Kraken
sync
Stargate
repeats
of
meta
protocol,
so
I
think
it's
debatable.
Whatever
goes
on
here,
I've
subded
it
and
then
cover
hcp,
which
I
don't
know
enough
about
and
manifest
which
I've
gotten
the
details
about
just
prior
to
this
meeting,
but.
C
A
That
is
worth
looking
at
from
this
is
actually
the
headers
just
understanding
how
we're
comparing
contrasting
some
of
these
the
protocol
type
in
particular.
This
is
like
the
most
engineering
approach
to
this
is
like,
if
you
had
to
do
an
enumeration
of
different
types
of
protocols.
Some
of
these
are
request
response
some
of
these
do
stream
sessions.
Some
of
these
are
message
oriented
or
multi-party.
A
Are
they
stateful
state
is,
in
this
case
kind
of
fuzzy,
whether
it's
client-side
server
side
or
both,
because
it's
dependent
upon
if
it's
just
a
client
answer
or
if
it's
multi-pure
and
server
handle
arbitrary
data.
I
believe
is
that
one
arbitrary
data
structures
right
so
can
we
do
lots
of
different
types
of
requests?
Incremental
verification?
Can
we
talk
about
it
without
downloading
it?
How
much
service
I'd
worked?
If
any,
what
happens
on
the
server
side?
A
Do
we
need
to
modify
dags
in
any
way
to
make
this
work,
or
do
we
need
to
do
any
external
construction
to
make
this
work?
What's
our
basic
unit
requests
does
I
added
a
couple
just
before
this,
which
is
designed?
Is
it
designed
to
paralyze
content
and
what's
its
implementation
status,
which
I
think
is
a
practical
consideration
and
so
just
to
step
through
the
ones
that
we've
heard
from
that
you
can
go
back
and
watch
videos
about?
We
had
four
that
were
largely
presented.
A
D
A
Oh
okay.
Well
then,
we
will
we'll
leave
that
for
for
the
discussion
section,
but
we
have
formally
heard
from
Power
crack
and
sync
Stargate
and
repeat,
and
so
those
are
four
that
you
can
actually
go
back
and
look
at
to
briefly
review.
Those
I
think
it's
worth
the
folks
who
put
together
that
put
in
the
time
to
actually
make
a
presentation
on
those
in
car
mirror.
I've
I've
taken
my
like
tongue-in-cheek
staff
at
a
pitch
for
each
of
these
protocols.
A
The
pitch
from
car
mirror
is
the
team
of
fission
needs
some
mechanism
for
doing
better,
synchronization
right,
and
so
this
is
avoiding
redundant.
Transformers
they're
trying
to
the
use
case
is
a
very
general
one.
It's
almost
exactly
like
what
git
runs
into
where
you
have
a
lot
of
data
already
on
both
sets
of
the
wire
and
you
just
need
to
efficiently
figure
out
what
is
missing
so
that
you
do
a
set
Union,
Across,
The
Wire.
It
has
a
working
prototype.
A
I
have
heard
work
from
the
vision
team
that
they
have
actually
seen
some
signs
of
life
from
it
in
the
last
couple
of
days,
which
is
very
exciting.
The
protocol
is
formatted
is
request,
response,
important
caveat
on
camera
trusted
context.
There's
you
actually
need
to
trust
the
pure,
on
the
other
end,
for
reasons
that
I
will
leave
to
the
fission
presenters,
but
I
understand
that
caveat
I
can
take
the
high
level
for
Crockett's
sake:
hey,
let's
repair
a
little
fetch.
A
A
So
the
idea
that
you
may
have
a
sparse
population
of
the
bits
that
are
needed,
the
real
magic
of
krakensig,
is
applying
the
bitfield
trick
to
graphs,
which
requires
a
lot
of
massaging
to
make
that
function,
to
make
it
both
deterministic
and
to
deal
with
the
common
case
where
you
actually
cannot
construct
the
graph,
because
you
can't
complete
the
deterministic
reversal
of
that
graph
to
turn
it
into
a
field.
A
Is
oriented
around
streams,
good
stuff,
Stargate
Hannah,
presented
pldr
HTTP
is
great.
We
should
use
it
and
that's
like
what
I
think
the
sort
of
thing
that
makes
that
radical
and
exciting
is.
We
should
use
it
to
like
actually
internally
move
data
around
I
think
this.
A
You
know
a
lot
of
us
have
come
from
this
world
of
well,
there's
going
to
be
the
way
that
the
P2P
nodes
talk
and
there's
going
to
be
the
way
that,
like
Gateway
and
external
systems,
talk-
and
let's
not
do
that-
let's
just
use
HTTP,
because
it's
great
the
idea
I
think
the
general
use
case
is
like
hey.
It's
designed
a
protocol,
they
could
replace
bid
swap
it's
there.
It
hasn't
working
prototype.
It's
request
response
good
next
and
last,
but
okay,
now
I,
don't
want
to
move
stuff.
Around
rabid
was
I.
A
Think
the
highest
level
of
repeat
is
just
like
hey.
Why
I'd
be
best?
Why
don't
you
do
parallel
fencing?
This
is
ridiculous.
You're,
a
pure
pure
protocol.
You
should
be
able
to
do
paralyzed
fetching
the
exciting
things
about
rapid
are
moving
a
lot
of
this
complexity
at
the
end
of
the
client
side.
So
you
actually
have
the
client
do
a
lot
of
the
coordination
of
parallelized
fetch,
so
that
is
easier
to
deploy
into
circuit
systems.
A
When
you
just
improve
the
clients,
you
have
to
ask
less
about
other
notes,
which
is
really
great
and
it
has
a
working
prototype
and
that
working
prototype
has
shown
really
great
throughput
numbers
as
draw
code
demoed
last
week.
It's
also
its
approach.
It's
also
a
meta
protocol.
So
the
idea,
here
being
that
you
could
use
different
data
transports
to
actually
do
the
the
actual
moving
of
stuff
over
the
wire
and
repeats
sort
of
like
contribution
is,
we
could
do
a
make.
A
A
meta
structure
that
composes
and
supercharges
that
actual
touching,
which
I
think
is
neat,
also
makes
it
a
little
harder
to
slot
into
some
of
these
things.
But
it's
also
I
think
really
relevant
to
bring
up
as
a
protocol
because
to
sort
of
we're
going
to
open
this
up
to
the
floor
and
just
talk
about
hey.
Where
do
we
go
from
next
and
how
do
we
ideally
open
some
space
for
that's
not
actually
quite
right,
and
how
do
these
two
concepts
link
together
but
stuff
that
we've
talked
about
in
this
working
group?
A
That
I
think
should
help
contextualize
a
discussion
of
where
to
take
this.
We
should
be
also
considering
the
adjacencies
of
the
subsystems
that.
D
A
Working
group
and
they're
they're
talking
about
how
do
we
do
this
better
and
more
efficiently
and
one
of
the
things
that
has
really
showed
up
as
a
recurring
theme
here
with
crack
and
sync
and
Rapid
in
particular,
but
the
carpool
extension
on
car
mirror
that
was
alluded
to.
Is
this
idea
of
hey?
A
We
need
to
get
into
a
situation
where
we
are
able
to
leverage
the
fact
that
we
have
multiple
peers
with
equal
or
similar
caches
of
the
data
that
we
want,
and
so
this
High
leveraging
multiplayer
availability
to
get
a
better
throughput
is
a
really
important
aspect.
But
we've
also
seen
from
the
measurements
team
that
the
ibms
network
right
now
has
of
this
very
significant
bias
to
having
a
single
Provider
from
the
vast
majority
of
cids
and
so
I.
Think.
A
That's
not
just
a
Content
writing
conversation,
but,
like
also
is
that
is
there
something
about
the
network
I'm
about
to
understand
there
as
we
build
these
protocols
that
are
trying
to
take
advantage
of
a
context
where
we,
you
really
see
the
big
pickups
when
multiple
peers
have
the
data
and
you
could
get
into
a
situation
where
you'd
know
that
and
then
maybe
the
last
before
sort
of
like
trans
over
the
other
thing.
A
I'd
ask
us
all
to
consider
is
when
we
convene
this
working
group,
we
had
some
original
use
cases
and
requests
that
I
went
back
and
sort
of
pulled
up
just
to
sort
of
remind
us
of.
In
the
beginning
of
this
conversation,
we
said
we
should
prioritize
point
to
point
for
that
very
observation
that
the
vast
majority
of
cities
in
the
advertise
Network
are
provided
by
single
peer.
We
said
hcp
support
was
a
hard
requirement
and
that
came
from
numerous
parties
in
the
in
the
ecosystem.
A
Support
was
implied
by
the
it
must
support
HTTP,
and
so,
if
we
do
think
about
it,
you
just
need
to
be
able
to
support
both
in
a
lot
of
ways.
We
had
numerous
requests
to
minimize
dag
interactions,
so
the
actual
amount
that
we
touched.
The
tag
I
think
now
that
we've
heard
so
many
of
these
presentations.
We
are
starting
to
refine
that
view
in
this
group.
As
asking
the
question
of
what
state
requirements
do
you
have
to
place
on
a
data
transfer
protocol
when
you
have
to
calculate
so,
you
have
to
calculate
per
request.
A
How
long
do
you
have
to
hang
on
to
it?
For
is
how
does
that
overhead
scale?
Is
it
with
the
size
of
the
graph?
You
have
to
touch
the
graph
to
calculate
it
right,
I
think
it's
like
the
way
that
that
conversation
has
evolved.
We
said
it
needs
us
back
in
a
reference
implementation
to
be
considered
for
use.
That's
I
think
we've
seen
a
lot
of
working
prototypes
and
I.
Think
that's
one.
One
of
the
things
that
I'm
hoping
to
talk
about
today
is
like
getting
from
working
prototypes
to
actionable
stuff.
A
We've
said
it
needs
to
be
implementable
in
JavaScript.
So
far
aside
from
some
bit
twiddling
stuff
in
krakensync,
that
I
think
we
would
still
be
fine
with
everything
we've
seen
has
been
implementable
on
JavaScript
and
even
that
it
totally
did
some
pretty
sure
we
can
get
away
with
it
needs
to
be
instrumented.
In
the
beginning.
We
said
it
needed
to
be
instrumented
with
test
ground,
I.
Think
I've.
A
So
with
that
I'm
hoping
today
can
be
far
more
discussion,
oriented
and
just
sort
of
like
talk
about
where
we
go
from
here,
we've
seen
some
great
protocols
we've
seen
working
code.
What
do
we
do
next?
It's
over
there
I
just
want
to
open
up
the
floor.
Does
anybody
have
any
comments
on
that
initial
couple?
Minutes
Preamble?
What
I'm
gonna
do.
C
Yeah
I
have
like
a
very
quick
follow-up
to
to
this
summary
table.
There
was
like
item
about
cars
over
HTTP
and
we
also
discussed
rapid,
but
there's
like
a
small
detail,
which
I
feel
is
worth
mentioning
that
both
in
both
cases,
we
don't
talk
about
cars
alone,
there's
always
a
way
to
fetch
a
single
block,
and
that's
how
you
get
you.
You
remove
ipld
dependency
entirely
that
whatever
we
do,
there
should
always
be
a
way
for
me
to
just
fetch
blocks.
C
I
want
I
will
pay
penalty
of
performance,
maybe
or
maybe
I'll
get
better
performance
by
running
my
own.
The
serialization
formats
right,
but
we
always
should
have
that
escape
hatch
of
having
ability
to
fetch
a
specific
blocks
without
having
to
get
the
entire
dog
and
that's
how
rapid,
even
like
rapid
fetches
initial
block,
it
does
not
go
with
a
car
overhead
for
a
single
block,
request,
I,
believe
that's
how
public
gateways
work
today,
you
can
fetch
a
single
block.
You
can
also
fetch
entire
dog
as
a
car.
D
Yeah
as
part
of
part
of
why
I
I,
I
started
trying
to
put
the
table
together
and
to
try
and
like
get
get
people
to
to
help
like
figure
out
what
the
columns
and
whatever
were
here,
is
to
to
be
like
what
is
the?
D
What
are
some
of
the
properties
of
these
protocols
that,
like
we
care
about
and
what
are
some
of
the
things
that
are
like
kind
of
who
cares,
and
we
all
know,
they're
kind
of
who
cares,
but
I
feel
like
it's
important
within
this
group
to
like,
say
that
out
loud
so
like
if
I
make
a
request
response,
protocol
and
I,
do
it
over
live
P2P
and
like
TCP
and
mplex
or
I?
Do
it
over
HTTP
like
the
amount
of
effort
it
would
take?
D
D
If
you
don't
like
the
fact
that
the
way
the
BitTorrent
protocol
works
is
using,
like
you
know,
UTP
or
something
you
could
do
it,
you
could
do
similar
things
in
other
ways
right,
like
that's,
not
the
interesting
part,
and
then
aside
from
that,
there's
a
bunch
of
things
that
we
kind
of
like
gloss
over
as
not
interesting,
but
the
fact
that
we
don't
have
some
group
thought
or
progress
or
agreement
on
them,
causes
problems
like
all
of
these
things
in
which
the
unit
of
request
is
I
want
to
graph
instead
of
I
want
to
block,
which
is
most
of
them,
because
the
I
want
to
minimize
graph
interactions
tends
to
look
at
I
want
to
graph
how
am
I
going
to
describe
a
graph
and
everyone
hates
every
way
we
describe
a
graph
so,
like
I,
think
we
need
to
make
progress
there,
like
those
sorts
of,
like
other
things,
I
I,
think
I
dumped
for
yeah.
D
You
know
I,
think
I've
done
for
in
in
the
chat
today
when
Brendan
was
asking
me
about
about
the
Manifest
stuff
and
I
was
like
there's
these
other
random
things,
the
transport.
How
do
I
want
to
deal
with
headers?
How
big
can
they
be?
Can
I
shove,
Bloom
filters
on
them
and
do
whatever
I
want
like?
D
D
D
Those
are
like
things
that
seem
to
apply
like
basically
across
all
of
these
protocols,
and
maybe
we
all
have
very
different
opinions
on
them
or
like.
Maybe
we
don't,
but
just
by
the
fact
that
they're
all
like
implementation
details
that
are
not
interesting,
we
don't
end
up
like
converging
on
on
a
set
of
Concepts.
B
Okay,
I
guess
I
would
kind
of
wanna
throw
a
little
bit
of
a
curveball
into
a
very
non-technical
aspect
of
this,
which
is
that,
like
like
one
the
question
for
me,
the
one
question
for
me
is
like:
can
we
develop
a
protocol
to
the
point
of
production
as
a
group
that
operates
across
a
number
of
companies.
B
We,
like
the
the
thing
we
haven't
actually
got
to
is
the
thing
we
said
what
is
currently
our
new
deliverable,
which
is
a
test
bet
or
not
a
test
bed
a
set
of
test
cases
right
for,
like
all
those
things,
are
things
that
emerge
like
when
you
have
dedicated
work
time
like
I,
don't
know
how
many
people
in
this
group
have
like
dedicated
work
time.
I,
don't
like
you
know,
and
I
I
I.
B
Of
test,
you
know
beds
for
my
production
code,
but
like
that's
because
I
know,
I
get
eight
hours
a
day
to
do
that,
and
you
know
when
I'm
like
working
it
when
I'm
doing
a
couple
extra
free
time,
hours,
I'm,
not
gonna,
be
like
Oh
I'm
going
to
spend
my
time,
writing
really
fancy.
You
know
test
cases
and
metrics
and
like
I,
mean
I,
know
you
and
yes,
it's
very
important
totally.
It
is
the
most
important
thing.
Arguably,
but
it's
just
not
the
thing
you
want
to
work
on
in
your
free
time.
B
A
Thank
you
Hannah
for
centering
this
on
something
I
think
I.
Think
that
what
do
you
have
a
thought?
Berkeley,
no
I,
don't
know.
Do
you
immediately?
A
Okay,
yeah
to
so
this
I
think
this
was
the
sort
of
core
question
to
this
group
right
and
one
of
the
things
that's
been
exciting,
I
like
to
sort
of
positive
an
approach
that
I
think
fits
with
what
people
are
already
doing.
A
Their
idea-
and
you
know
in
in
another
world,
you
have
an
allegory
for
that
which
is
we
wrote,
a
white
paper
and
we
have
an
implementation
and
we-
and
we
have
a
sort
of
theory
on
how
this
why
this
thing
is
great
and
why
more
people
should
know
about
this
research,
all
right
and
so
I'd
like
to
argue
that
what
we've
been
doing
for
the
last
couple
of
months
is
actually
research.
But
what
we
now
need
to
do
is
turn
to
that
exact.
A
Practical
question
that
you
have
Hannah
of
like
okay,
we
we
know,
we've
learned
some
things.
How
do
we
compose
what
we've
learned
into
the
best
expression
of
something
that
would
become
start
to
approach
us
back
right
and
and
the
reason
I
wanna,
I
wanna
inject
the
idea
of
a
spec,
or
at
least
a
document,
is
to
force
exactly
what
you're
saying
Hannah
of
like?
How
do
you
build
a
thing
across
numerous
organizations?
The
answer
is
a
spec.
The
only
way
that
it
works
is
a
spec.
A
You
can't
do
this
with
like,
like
where
we've
seen
it
we've
seen
this
run.
We've
run
into
this
problem,
a
bunch
trying
to
write
implementations
based
off
of
the
pattern
where
you
go.
Implementation
spec
cross
compatible
implementation,
it's
really
hard
because
you
always
end
up
in
this
pattern
where
they
cross
compatible.
The
original
reference
implementation
gets
way
far
ahead
of
the
spec
and
the
motivation
to
maintain
the
spec
is
low,
and
if
you
you.
A
This
group
sits
together.
This
is
okay.
Can
we
like
compose
some
of
these
things
together
in
a
meaningful
way?
Maybe
we
can
actually
do
this
scary
thing,
which
is
group,
writing
and
actually
put
together
some
of
these
Concepts?
Not
all
these
concepts
are
going
to
make
it
onto
the
I'll
like
make
it
through
the
cutting
floor.
But
can
you
actually
write
some
opposition
protocols
and
say
this
is
how
we
think
we
would
replace
bit
swap
as
a
group
and
like
do
a
recommendation
and
that's
maybe
that's
an
abstract
spec?
A
A
Don't
even
think
this
needs
to
be
one
protocol,
but
it
needs
to
be
some
effort
on
behalf
of
this
group
to
coalesce
and
I
think
the
best
way
to
do
that
is
with
writing,
because
we
can't
we
can't
change
the
laws
of
gravity
that
state
that
everybody
here
has
assigned
work
and
can't
stop
what
they're
doing
and
say.
I
will
take
one
for
the
team
and
be
the
implementer
of
the
thing
different.
A
D
Yeah,
the
film
feature:
that's
actually
useful.
If
you
manage
to
disable
the
thing
or
if
you
physically
pick
up
your
hand
and
it
does
it
for
you,
the
yeah
I
think
I,
agree.
I
agree
with
most
of
that
with
like,
with
the
caveat
that.
D
Doing
the
writing,
without
making
sure
that
we
have
enough
people
dedicated
to
like
being
able
to
build
implement
the
thing
leads
to
like
rough
stuff,
so
I
feel,
for
example,
an
example.
This
is
like
the
like
the
the
proposal
for
like
a
bit
salt,
1.3
Improvement
that
basically
handles
a
whole
bunch
of
stuff
around
like
auth
and
other,
like
random
edge
cases
that
have
been
biting
at
like
the
bit
swap
wire
protocol
without
some
of
the
things
that
are
really
annoying
just
the
things
that
are
really
easy
to
fix,
modifying
the
protobufs.
D
You
know
like
new
protocol
stuff,
no,
like
new.
You
know
stream
protocol
IDs
and
whatever,
and
that
was
useful
like
it
made.
You
know,
I
got
a
bunch
of
good
feedback
from
various
people
who
are
interested
parties,
but
then,
like
sort
of
push
came
to
shove
and
I
felt
like
I
was
helping
orchestrate
this,
but
I
was
like
Kubo,
which
is
the
thing
I
am
like.
I
I
at
the
time
was
able
to
spend
most
of
my
time.
D
D
Let's
let
me
help
coordinate
the
spec
work,
at
which
point
the
thing
was
like
well,
but
I
mean
if
Kubo
is
not
doing
it,
I
don't
really
want
to
do
it,
and
that
was
like
that
felt
rough
and
so
I
feel
like
the
spec
writing
helps
because
it
helps
us
coalesce
on
ideas
like
which
things
are
important
for
when
we
get
to
build,
but
in
order
for
people
to
like
feel
like
the
time
has
really
gone
somewhere.
There
needs
to
be
some
level
of
commitment
to
like.
D
If
this
thing
starts
to
materialize,
it
will
exist
inside
of
some
deployed
code,
at
least
until
we
find
out
that
it
turns
out.
This
whole
idea
was
crazy
and
we
got
to
shut
it
down.
You
know,
but
like
we
tried
as
I,
you
know,
and
that
means
maybe
going
to
wherever
we
are
and
making
sure
we
can
earmark
some
amount
of
time
once
the
writing
is
far
enough
along.
B
Yeah,
this
is
just
a
clarifying
question
like
so
then
this
group
it'd
sort
of
be
like
almost
like
a
tc39
process
where
we
like
agree
on
a
spec
and
the
people
or
the
implementers
and
various
implementations
are
like.
Oh
yeah
we'll
go
Implement
that
or
if
they
think
it's
not
gonna
work
they're
like
no,
that's
a
terrible
idea
and
I
don't
want
to
do
it.
Here's
why
I
just
want
to
make
sure
I
understand
the
concept.
A
Yeah
like
like,
where
are
we
going
with
all
this
and
and
I
think
Dean's
asking
the
same
question
yeah
right
in
my
mind,
you
know
I'd,
even
I
I
personally
want
to
back
away
even
from
the
like.
Is
it
going
to
get
implemented
like
just?
Can
we
clench
some
of
these
ideas
together
right,
let
with
like
it
needs
to
support
basic
block
requests
so
like
a
cool
layer
that,
in
this
is
an
escape
patch,
it's
got
to
happen.
A
I
think
repeat:
has
this
wonderful
Insight
that,
like
hey,
we
can
cram
a
ton
of
stuff
on
the
client
side
and
that's
going
to
help
us
a
whole
bunch,
okay,
cool!
Can
we
put
that
in
Hannah's
coming
in
and
saying
guys
HTTP
doesn't
suck
like?
Can
we
just
like
do
this?
Can
we
at
least
map
this
on
HP,
semantics
and
and
if
it's
going
to
be
a
request
response?
A
Why
not
just
use
HTTP
right
like
start
to
see
some
of
these
things
and
post
together,
I,
don't
know
if
we
actually
get
to
the
writing
of
protocol
a
bit
but
like
maybe
all
it
exists
to
do,
is
just
to
get
this
group
sort
of
trying
to
think
as
a
group
instead
of
present
as
individuals
and
I,
don't
know
what
comes
out
the
other
side
of
it
and
I
don't
want
to
make
any
promises.
They're,
like
yeah,
we're
totally
gonna
like
come
up
with
something
great.
That's
super
implementable.
A
Who
knows
this
is
research.
You
know
like
maybe
it's
just
a
matter
of
like
trying
to
piece
some
of
these
pieces
together
and
like
we're
on
the
rail.
This
is
the
kind
of
group
that
can
be
thermally,
nerd
sniped
into
like
well
that
hits
something
and
I
want
to
influence
this
in
a
way
so
I
just
like
took
that
and
sort
of
like
went
a
little
bit
off
the
sweet
prototype
neat
and
then
maybe
we
can
pile
onto
that
right,
like
I,
don't
know,
but.
A
C
Ahead,
yeah,
yeah
kind
of
like
kind
of
like
wrote,
an
essay
there,
but
long
story
short
is
like
I
agree
that
specs
don't
work
if
you
write
specs
for
a
single
use
case
or
for
a
single
stakeholder,
and
that
just
leads
to
frustration
and
and
some
prior
art
there
is
like
spec
things
work
because
we
have
web
platform
and
if
you
look
how
things
like
what
working
group
or
w3c
thing
before
that
worked,
you
had
multiple
stakeholders
pulling
in
different
directions
and
then
you
distill
to
the
most
useful
thing
to
the
majority
of
stakeholders.
C
No
one
is
happy,
but
you
end
up
with
something
that's
mostly
in
interoperable,
and
then
you
create
a
compliance
test
to
shame
people
into
obedience,
implementation,
wise,
that's
my
take,
and
you
know
we
have
web
platform
tests.
We
have
things
like
htmls,
where
I
can
and
JS
spec
and
sure
it's
never,
no
one
implements
100,
but
no
one
uses
80
of
it.
So
in
practice
most
people
don't
even
know
two
browsers
diverge
in
ridiculous
places,
because
those
are
like
edge
cases.
C
Low
level
engineer
will
bolt
on
on
top
of
so
I
feel,
focusing
on
what
are
the
most
prevalent
use
cases
for
like
retrieving
data.
The
retrieving
content
address
data
today,
I
I
have
my
opinion.
I'd
say
like
well:
websites
are
pretty
popular
I've
heard
and
how
website
looks
like
well,
it's
a
directory
with
index.html
and
maybe
some
things
every
browser
sends
requests
for
five
icon.
You
already
have
like
three
things
that
you
can
think.
Oh,
how
do
I
optimize
the
initial
round
trip
right?
C
Oh,
if
I
fetch
car
over
hdp,
how
would
I
save
literally
two
round
trips
on
every
request
on
every
website
load?
That's
it's
called
cache
right.
It's
not
difficult
to
reason
about
things
if
you
start
from
end
user
instead
of
low
engineering
approach
right
sure
and
then
like
you,
because
you
will
run
into
your
own
traps.
You
have
oh
I.
Have
this
back
end
I!
Have
this
those
storage
criteria?
I
need
to
hit
those
latency
things?
C
You
forgot
that
the
real
people
will
be
using
your
things
and
instead,
if
you
focus
on
making
sure
that,
like
the
80
of
people,
will
avoid
those
round
trips
sure
it
won't
be,
maybe
like
the
most
performant
thing,
but
across
entire
ecosystem
you
will
save
like
a
ton
of
time.
Probably
energy-
and
you
know
that's
I
I'd,
say
like
you
first
focus
on
what
are
the
use
cases
we
want
to
accommodate
for
because
sure,
like
let's
say
you
have,
you
are
like
storage
provider
and
you
don't.
C
You
won't
be
serving
website
requests
directly
right,
but
you
will
have
someone
in
front
of
you
who
will
be
asked
for
that
index.
Fav,
icon
whatever,
and
then
you
that
you
that
thing
in
the
middle
will
have
to
translate
that
to
request
to
you.
Do
we
need
to
have
like
multiple
protocols
and
pay
cost
of
translation
layer
on
every
hop
I'd
say
that's
more
or
less
Echo,
system-wise
question
and
I
I
know
some
people.
People
are
smiling
because
that's
literally
what
we
are
currently
trying
to
solve.
C
So
it's
pretty
fresh
on
my
mind,
but
I
see
I
I
feel
it's
like
the
people
outside
of
this
group
working
with
content.
Other
address
data
hit
the
same
questions
right.
So
that's
like
my
like
I
think
to
wrap
it
up.
I'd
say
like
think
about
and
end
user
types
of
requests
and
how
can
we
like
them
optimize
and
things
end
to
end
to
minimize
round
trips.
D
Building
off
of
that,
I
think
like
just
very
briefly,
I
think
this
is
also
how
we
like
make
ipld
kind
of
the
right
amount
of
ipld
I
feel
like
we've
seen
like
the
the
the
kind
of
pendulum
swing
back
and
forth
of,
like
you
know,
I
like
blocks
I,
don't
like
graphs
I
like
links,
but
I,
don't
like
I,
don't
like
named
links
or
I,
don't
like
other
sorts
of
multi-block
data
structures
and
you're
like
oh,
but
I
have
these,
but
I
need
multi-block
data
structures
because,
like
I,
want
to
logically
represent
them
as
like
a
big
directory
or
a
big
map
or
a
big
list,
or
something
and
you're
like
oh
well.
D
How
do
I
do
that
and
you
sort
of
like
go
back
and
forth
of
like
I,
want
all
I
want
some
of
this
I
want
none
of
this
and
I
think
this.
The
areas
where
which
hurt
the
most
right
now
are
the
ones
where
you're
like.
Did
this
really
come
from
an
end
user
request?
You
know
probably
only
sticks
out
the
most
and
ipld
is
like
floats
like
nobody
wants.
Nobody
wanted
floats
and
content
address
data
nobody's
using
floats
and
content
address
data.
Why
are
we
talking
about
it
in
the
context
of
content?
D
Address
data
right
it
just
sort
of
left
there
on
the
specs
is
like
we
said
floats,
but
we
didn't
really
mean
it
because
it
didn't
it
didn't
come
from
an
end
user,
right
and
so
I
think.
That's
that's
like
I
feel
like
that.
That's
the
way
that
you
sort
of
iterate
towards
like
the
what's
the
small.
How
do
we
grow
the
set
of
things
we
can
get
enough
people
on
board
with
that?
We
bother
implementing
it.
A
Yeah
I
think
and
Hannah's
got
a
point
from
Chad
like
are
we
you
know
enumerating
experiments
might
be
the
wrong
direction
instead
of
thinking
this,
this
Ladle
getting
us
centered
around
this
use
case
and
I
would
I
would
add
to
that
a
prioritization
of
a
set
of
use
cases
right
like
can
this
group
first
agree
on
hey
if
we
enumerate
concrete,
like
real
world
user
stories
and
I,
like
the
emphasis
on
like
touching
a
web
page.
A
You
know
like
this
is
like
things
that
don't
require
deep
knowledge
of
hashlink
data
structures
to
like
actually
talk
about,
because
there's
some
other
ones
right
like
you
getting
lots
of
like
getting
a
movie
to
lots
of
people
fast
right.
That's
where
you
acknowledge
and
you
have
like
the
sub
graph.
You
know
practicing
side
of
things
and
that's
that's
another
use
case.
Are
we
how.
A
Prioritize
those
against
each
other's
like
Visions,
need
for
like
hey,
we
just
we
need
to
duplicate
transmission
over
the
wire
as
much
as
possible,
like
we
have
heard
these
use
cases
presented
and
I
think
kind
of
you're
just
to
try
and
refine
your
comment
from
chat
like
I
think
about
an
incredible
starting
before
before
we
dive
into
like
academic
writing.
A
It's
just
like
just
enumerating
a
set
of
use
cases
and
trying
to
have
a
discussion
around
that
in
the
same
way
that
a
Dean
you
built
this
table
comparing
protocols
and
we
built
a
table-
that's
stack
nice
use
case
I,
think
that,
and
we
already
have
a
bunch
of
writing
from
that.
That's
the
first
thing
that
we
asked
for
the
kickoff
of
this
working
group
hi.
Why
are
you
here?
A
B
And
also
like
I
mean
it
would
be
really
helpful
to
hear
in
depth
from
like
a
couple
of
folks.
I
mean
like
I,
want
to
hear.
Dag
house
just
ran
for
45
minutes
about
why
we
should
never
use
dags
in
our
dag
house,
like
so
that
you
know
like
that
type
of
thing,
I
feel
like
that's.
What
will
make
us
understand
like
why?
Why
are
you
doing
it
this
way,
so
yeah.
D
I
I
would
I
would
sort
of
counter
that
a
little
bit
which
is
like
you
cannot
make
anyone
come
to
the
room
so
like
some
of
the
pinning
surface
API
pending
service,
API
issues
stem
from
the
fact
that,
like
there
weren't
enough
people
in
the
room-
and
there
were
like
there
were
conferences
that
people
went
to
and
they
talked
about
it,
and
then
it
came
time
to
write
the
spec
and
like
not
enough,
people
showed
up
in
the
room
and
so
like
it
doesn't
really
matter.
D
B
D
A
A
lot
of
data
transfer
tell
us
where
it
hurts,
because
with
the
data
transfer,
better
team
and
like
listening
to
them
and
making
sure
that
to
your
point
of
Dean,
one
of
the
worst
things
you
can
do
is
compose
the
design
document
without
that
feedback
in
front
of
you
right.
But
ideally
we
can
learn
from
that
mistake
here
and
say:
okay,
no,
it
is
actually
incumbent
upon
us.
Okay,
maybe
doesn't
show
up
to
this
calls,
that's
okay,
they
watch
them,
they
know
about
them.
We
can
get
them.
A
This
is
possible
right
and
so
like
if
we
I
think,
but
I
think
this
could
be
done
in
parallel.
I
think
we
I
see
no
reason
why
we
couldn't
boast
it's
validated
to
work
on
in
writing
a
set
of
use
cases
and
try
to
launch
together
some
of
the
existing
proposals
and
see
like
there's,
no
reason
that
they
can't
both
be
it
happening
very
well
right
and
like
say:
hey
can.
A
Putting
those
things
in
a
conversation
makes
it
really
interesting
and
where
you
can
actually
say
Hey,
you
know,
we've
all
agreed
that
this
use
case
is
the
one
that
needs
to
be
served
more.
So
that's
that
should
help
settle
disputes
over
how
something
works
or
doesn't
work
or
needs
to
be
implemented
or
doesn't
need
to
be
implemented
right.
A
Yeah
Daniel,
you
have
you
had
a
comment
from
the
chat.
Do
you
want
to
just
read
it
out
for
the
record
I
think
it's
a
good
comment.
Yeah.
E
I
feel
like
as
someone
who
hasn't
been
sort
of
heavily
involved
in
implementing
transfer
protocols,
but
it's
been
with
ipfs
for
long
enough
to
know
that
there's
problems
that
are
established
and
there's
also
very
much
a
culture
of
experimentation.
E
I
think
I
I
sense
that
just
coming
from
the
outside
we've
sort
of
spent,
as
you
said
right
this
phase
of
doing
research
trying
to
diverge
as
much
as
possible
and
explore
like
a
breadth
of
of
possibilities
in
improving
the
protocols.
The
transfer
protocol
in
ipfs
and
maybe
coming
up
with
some
metrics
I.
Think
now
is
actually
a
good
time
for
us
to
converge,
because
our
efforts
were
only
be
successful
if
they're
concentrated
our
resources.
E
Our
time
in
our
attention,
I
think,
as
Dean
pointed
out
really
nicely
in
the
beginning,
we're
limited
and
so
I
I
converging
is
really
the
the
only
way
to
to
move
forward,
and,
worse
is
better
just
in
the
sense
of
like
trying
to
keep
things
simple,
not
trying
to
invent
a
request
response
protocol
trying
to
you
know,
build
on
something
like
HTTP
and
I
mean,
even
if
we
look
at
gateways,
which
is
how
most
users
actually
get
exposed
to
ipfs
I
have
the
sense
that
it's
like
we've
done
all
of
this
work
in
the
background
to
make
that
more
efficient
and
then
slowly
build
up
more
of
the
ipfs
and
content
addressing
functionality
to
the
Gateway
with
you
know,
verified
responses
and
whatnot,
and
so
that's
becoming
more
and
more
of
a
bottom-up
adoption.
E
Legitimate
path
for
doing
mostly
retrieval
writable
gateways
might
be
the
sort
of
you
know,
standardized
way
for
ingestion
and
then
that's
also
another
HTTP
interface
and
I.
Don't
know
I've
seen
monitoring,
Martin's
work
on
on.
You
know
lip
P2P
on
top
of
HTTP
and
there
seems
to
be
an
agreement
that
HTTP
is
a
good
foundation
to
do
a
lot
of
this
stuff
on.
E
A
A
A
Totally
semantics
aside,
this
feels
like
so
this
to
me.
This
feels
like
a
call
to
action
right
like
can.
We
actually
set
a
very
modest
goal
of
doing
something
as
a
group
in
a
two-week
time
frame
right
and
so
like
we
have
a
meeting
in
two
weeks.
I
don't
want
to
get
up
here
and
be
like
hey.
Here's
a
slide
stack,
there's
nothing
in
it.
A
So
should
we
start
by
saying
hey
we're
going
to
try
and
take
a
crack
at
these
two
documents
and
see
if
we
can
punch
something
together
and
turn
this
into
a
little
bit
more
of
a
working
session
in
two
weeks,
but
ideally
have
something
that
is
meaningfully
media
to
actually
keep
folks,
believing
that
hey
there's
something
Worth
showing
up
for
how
do
we
feel
on
that?
Can
I
take
the
temperature
of
the
room?
A
Can
we
can
we
agree
that
at
some
point,
Brenda's
gonna
nudge,
you
in
the
movement
by
its
working
group
Channel,
because
you
were
so
bold
as
to
join
this
call
and
see
if
you
can
give
input
or
possible
stuff
onto
a
notion
document
like
and
does
that
feel
like
it
comports
with
your
original
question,.
B
E
A
Table
that
that
has
use
cases,
your
invitation
is
to
very
so
much
that
they
approached
that
I
think
a
Dean
has
put
forward
for
the
protocol
and
immigration
side.
Can
you
add,
maybe
you
add,
a
column,
header
and
say:
hey
I'm,
going
to
try
and
like
look
at
these
use
cases
through
this
lens,
or
can
you
add
a
use
case
to
that
and
say
like
Hey,
we're
missing
this
well
and
then?
Finally,
can
we,
as
a
group
in
two
weeks,
talk
about
how
we
would
prioritize
those
the
second
document
being?
A
Basically
start
to
smash
them
all
together,
I,
don't
even
think
it
needs
to
like
come
into
like
this
is
going
to
be
the
one
particular
rules
of
all.
Maybe
it's
just
like
this
group
is
trying
to
write
a
book
report
on
on
the
things
that
we
see
to
date
and
and
try
to
identify
places
where
we
can
duplicate.
A
B
A
I
think
it's
just
whatever
you
have
okay,
I
will
I,
will
stub
out
the
documents
and
start
to
throw
in
some
of
these
cases
based
on
this
conversation,
and
if
you
can
throw
somatic
right,
if
you
can't
you
can't
this
is
this
is
at
will
right,
like
people
are
here
as
they
want
to
be,
and
so
all.
B
Of
the
all
the
protocol
Labs
people
on
this
caller
now
involved
in
a.
E
D
Yeah
Brandon
there
will
probably
be
in
a
a
soon
ipfs
implementer
sync.
Once
anyone
can
get
once
we
can
get
our
ducks
in
a
row
which
we're
we're
trying
some
things
around
cars
and
gateways
and
stuff
to
basically
be
like
hey.
What,
if
you
wanted
like
something
more
practical?
What
if
you
wanted
something
a
little
more
precise
than
like
you
know,
a
block
or
in
everything
because
range.
D
D
Like
a
range
request
or
like
whatever,
like
I
mean,
but
this
is
part
of
the
everyone
hates
every
graph,
descript
description,
syntax
business
so
like
we'll
put
that
off,
we'll
see
what
people
think
we
have
another
one
of
these,
which
is
everyone.
Everyone
seems
to
like
cars
and
likes
HTTP
and
neglects
the
fact
that
you
cannot
in
fact
send
a
car
over
HTTP
in
a
streaming
fashion
and
know
that
it
completed
successfully.
D
D
But
it's
part
of
this
I
mean
it's
part
of
this
business,
though
right
gateways
are
sort
of
one
thing
where
we
know
we
can
like
put
up
an
ipip,
and
there
are
multiple
stakeholders
involved
in
building
and
running
gateways
that
you
can
see
if
people
throw
tomatoes
at
you-
and
this
is
a
bad
idea
and
don't
do
it
right
or
at
least
don't
do
it
as
a
it's
not
like.
You
can
say
you're
doing
it,
but
no
I
don't
want
this
thing
as
part
of
the
spec.
D
D
Right
I
think.
That's
part,
part
of
the
reason
why
people
want
to
do
are
like
some
of
like
the
HTTP
and
the
Gateway
stuff
is
because,
like
they,
they
know
where
which
bucket,
to
put
it
in.
It's
like,
if
you
didn't
feel
like
making
like
an
800th
repo,
but
you
didn't
know
where
to
put
your
miscellaneous
project
and
you're
like
yeah
I'll,
just
leave
it
on
my
I'll
just
leave
it
on
my
desktop
because
I
don't
know
where
to
put
this
thing,
you
know
so,
there's
like
the
gateways
are
like
a
place.
D
D
C
No
I
was
about
to
say
more
or
less
a
more
precise
description
of
what
he
was
speaking
about,
but
we
have
the
meeting
next
week
and
it's
going
to
be
good
enough.
A
Cool,
so
that's
the
IP
address
implementers
working
group
call.
That
is
another
call
that
it
happens,
cool
all
right,
so
I'm
gonna
take
a
step.
These
two
doctors,
I'm
gonna,
set
them
up.
I'm,
gonna,
post
them
in
the
channel
and
I
would
love
it.
If
folks
could
try
and
throw
some
stuff
on,
there
sounds
like
there's
a.
A
Stick
it
to
the
top
of
the
list
and
fight
about
whether
it
should
be
at
the
top
of
the
list.
It's
about
the
as
far
as
the
impact
of
this
conversation
affects
this
group's
agenda
as
far
as
I'm
concerned,
but
like
maybe
this
is
a
great
moment
to
augment
and
inflight
engineering
effort
with
a
couple
of
small
graceful
touches
in
a
way
that
may
make
it
more
generally
applicable,
I,
don't
know
we
will
have
to
wait
in
deep
suspense
for
whatever's
going
on
here,
but
cool.
A
Once
going
twice,
okay,
my
closing
time
I'm,
excited
I,
think
assigning
a
little
bit
of
group
work
to
this.
This
group
is
the
right
way
to
go
and
we'll
and
we'll
see
if
we
can
actually
go
hey.
These
are
all
the
cool
things
these
people
have
done
in
parallel
and
now
I
actually
have
a
conversation
about
doing
something
in
series.