►
From YouTube: Retrieval Market Spec - A Vision for the Future
Description
B
Hey
everyone,
so
I
want
to
talk
to
you
guys
about
a
little
thing
that
I
worked
on
last
week,
which
I
called
the
retrieval
market
spec.
What
it
is
is
so
it
is
a
specification
for
the
file
coin,
retrieval
market
and
you
might
be
like
well.
We
actually
already
have
a
file
coin,
retrieval
market.
I
know
that
I've,
I
can
personally
say
I've
written
software
on
such
a
thing.
B
But
there's
a
lot
of
pieces
that
that
aren't
there
in
order
to
get
there
and
actually
a
lot
of
people
have
been
working
on
this.
A
lot
of
people
have
come
up
with
a
lot
of
different
ideas.
We've
we've
worked
internally.
We've
worked
with
with
some
external
partners
consensus
who
else
chain
safe
a
number
of
other
folks.
So
many
that
this
this.
The
first
thing
I
did
when
I
was
writing.
B
In
a
year-
and
maybe
afterwards,
so
you
can
think
of
this
as
sort
of
like
a
meta
project
proposal,
it's
not
it's
not
any
team's
work
immediately,
but
several
probably
a
dozen
small
project
proposals
that
emerge
from
from
from
this
so
yeah.
So
this
is
the
retrieval
market
specification.
This
url
is
a
is
a
url.
You
can
all
access.
I
will
share
it
in
there.
B
B
B
B
B
C
B
A
B
Awesome
yay
yeah,
so
you're,
gonna,
you're
gonna,
see
here
at
the
the
front.
You
just
get
a
kind
of
like
a
grand
overview
in
terms
of
the
goals
of
the
of
the
document.
If
you
go
ahead
and
click
on
the
roadmap
yeah
you're
gonna.
So
this
is
just
a
sort
of
like
an
overview
of
the
roadmap
for
the
retrieval
market.
B
The
one-year
milestone
is
to
get
to
a
like
mvp
of
a
web
3
content
delivery
network,
essentially
to
have
all
the
components
in
place,
if
not
the
most
amazing
implementation
of
those
components
so
that
all
the
different
people
who
want
to
participate
in
a
retrieval
market
could
I
want
to
actually,
if
you
wouldn't
mind,
clicking
on
architectural
overview
on
the
left?
Awesome.
Thank
you!
So,
oh
yes,
yeah
at
the
bottom
of
the
roadmap.
It
says
things
are
about
to
get
pretty
technical.
B
B
This
is
I
it's
actually
to
speak
to,
that
is
I've
organized
the
I've
thought
of
the
retrieval
market
is
made
up
of
sort
of
like
high-level
actors,
doing
different
things
that
I
call
roles
which
are
like
the
high-level
functions
of
the
retrieval
market.
So,
for
example,
a
retrieval
client
is
one
role:
a
retrieval
provider,
the
person
who's
providing
data
is
another
rule.
B
If
you
just
want
to
click
on
how
to
read
the
spec
a
couple
things,
though,
if
you
do
read
this-
and
I
encourage
you
all-
you
know
read
it
at
your
leisure-
give
me
feedback.
There
are
there's
a
couple
things
in
each
thing
that
you
might
be
interested
in
they're.
All
the
pages
have
a
status
and
like
some
of
these
pages
were
just
me
like
making
pulling
stuff
out
of
out
of
out
of
my
head,
I
think
I'll
say
where
it's
like.
B
You
know
like
it
whether
it'll
actually
land
there
is
hard
to
say,
but
it
might,
but
you
know,
hopefully
it
will.
There
are
there's
a
bunch
of
code
in
this
spec
and
it
is
compilable
code,
even
though
it
has
no
implementation.
I
am
not
attempting
to
do
a
file
coin.
Spec
and
like
right,
like
you
know
the
the
actual
implementation
inspect
till
we
end
up
with
the
actual
implementation.
B
Just
one
other
so
yeah,
so,
let's
just
briefly:
click
on
the
roles
and
I'll
talk
a
little
bit
about
what
those
rules
are,
because
it
might
be
like
if
those
of
you
guys
have
never
thought
about
like
the
retrieval
market
in
the
long
term.
What
that
might
look
like,
so
you
know
the
two.
The
first
two
rules
you
might
recognize
are
retrieval
client
and
retrieval
might
provider
slash
miner.
B
So
the
person
who
wants
to
fetch
the
data
and
the
person
who's,
giving
you
the
data
to
fetch
those
two
roles
already
exist,
and
they
are
best
expressed
by
a
lotus,
node
and
a
lotus,
minor
node
and
but
then
there's
some
other
rules
which
are
kind
of
like
right.
Now.
Very
primitive
implementations
are
folded
into
running
a
lotus
node,
but
they
will
actually
eventually
be
entirely
separate
people.
One
of
them
that
does
not
exist
at
all
is
the
so-called
content
provider.
In
a
more
like.
B
Our
current
payment
model
is
that
the
miner
serves
data
and
the
person
who
fetches
it
pays
for
it,
but
probably
a
more
likely
model
for
the
the
future.
Is
that
that
much
more
closely
resembles
how
content
cdn
works?
Is
someone
who
wants
content
to
be
available
very
quickly?
Would
pay
a
retrieval
miner
to
provide
it?
So
we
call
that
person
the
content
provider,
that's
the
person
who's
like.
I
have
a
website,
and
I
want
to
make
sure
that
everybody
can
get
to
it
in
a
sub
millisecond
time.
B
So
I'm
going
to
pay
a
bunch
of
people
to
host
my
content
so
that
you
can
get
it
quickly.
Other
people
that
are
in
the
mix
a
payment
provider.
We
have
really
simple
and
really
not
well
developed
components
for
payment
in
retrieval,
as
is,
but
they
actually
are
sufficiently
slow
that
you
know
we
find
ourselves
on
this
file
point
golden
pad
edging
towards
emphasizing
free
retrieval,
because
we
don't
want
to
block
anything
on
chain
operations.
There
are
a
lot
of
ways.
B
We
just
need
to
build
a
more
complex
solution
and
it
probably
means
that
one
person
on
this
network
is
just
someone
who's
processing
payments
and
then
the
last
person
is
a
marketplace.
This.
The
person
who
helps
peop
connect
people
helps
clients,
find
contact,
help
helps
people
who
are
providing
data
advertise,
what
their
content
is
and
advertise,
what
they
charge
for
new
content
and
then
helping
content
providers
find
other
providers
on
the
network.
B
B
I
noticed
that,
like
other
than
a
couple
of
them,
everything
is
not
violent
coin
specific,
but
the
retrieval
market
is
surprisingly
not
biocoin
specific,
and
it
is
possible.
We
could
potentially
run
it
with
a
payment
system
running
other
something
other
than
filepoint.
I
don't
know
if
we'll
ever
do
that,
but
I've
kind
of
like
identified
that
the
other
thing
about,
and
then
I
also
so
then
for
these
components.
B
And
with
what
and
I
I
made
a
couple
modifications
to
the
lotus
spec
just
because
to
lots
of
flexibility,
but
yeah
you'll
see
you
can
see,
there's
a
whole
list
there
below
of
the
different
components.
If
you
click
on
some
of
them,
some
of
them
will
look
really
familiar.
If
you
click
on
like
file
point
chain
right
to
the
left
on
the
yeah.
B
B
We
could
communicate
remotely
and
that's
probably
where
we'll
head
eventually
in
terms
of
like
putting
this
in
ipfs
and
in
fact,
if
you
scroll
down
you'll,
see
for
each
component,
there's
a
roadmap
and
I
believe
the
one
year
one
probably
says
you
should
we
are
going
to
try
to
put
retrieval
in
ipfs
in
some
fashion.
So
anyway,.
B
Supposed
to
give
you
a
real
specific
way
to
get
from
here
to
there.
This
is
like
there's
a
ton
of
stuff
in
here,
and
so
I'm
not
gonna
go
through
the
rest
of
it.
I'm
sure,
I'm
over
time
already,
and
so,
but
I
encourage
you
to
go
check
it
out.
I
don't
know
how
public
this
is
because
I
I
suspect
it's
not
private,
but
it
hasn't
been
reviewed.
B
A
Cool
very
cool,
yes,
this
is
a.
This
is
a
very
exciting
work
and
I'm
I'm
very
glad
to
see
that
you
know
like
long-term
vision
is
still
happening,
because
sometimes
it
can
feel,
at
least
for
me
that
yeah
we're
very
much
focused
on
the
day-to-day,
but
like
stuff
like
this
is
probably
going
to
be
what's
most
important
towards
you
know
the
broader
product
market
fit
mission,
one
question,
so
I
wanted
to
push
a
little
bit
on
the
yeah.
How
much
of
this
is
actually
file?
Coin
specific?
A
B
Yeah
I
mean
so
there.
There
are
the
the
specification
as
written
works
with
the
file
coin
protocol
or
as
specified
by
like
the
the
actors
and
state
machine
today.
A
lot
of
this
is
taking
components
that
are
in
lotus
or
elsewhere
and
breaking
them
out.
I
mean
some
of
them
are
already
broken
out.
Like
you
know,
data
transfer
flow
markets
already
exist
as
independent
repos.
They
don't
exist
very
well
in
their
own
process
boundary.
So
there's
there's
some
interesting
stuff
around
that
and
you'll
see
like.
B
If
you
look
at
the
the
data
transfer
api,
it's
been
modified
so
that
like
it,
would
actually
would
super
well
work
well
over
an
rpc
and-
and
so
it's
probably
gonna
be
happening.
You
know
in
a
bunch
of
different
places
and
there's
a
bunch
of
different
suggestions
for
how
to
assemble
different
components.
One,
for
example,
a
retrieval
provider,
slash
miner
right
now.
The
only
version
of
that
is
a
lotus
storage.
Miner
right.
However,
there
is
no
reason
you
need
to
be.
B
Storing
data
in
you
know,
with
like
storage
deals
in
file
coin,
to
serve
it
for
retrieval,
and
so
one
of
the
big,
the
immediate
tasks.
If
you
look
at
like
the
retrieval
miner
or
retrieval
provider
role,
is
that
like
it's
like
there's
a
suggestion
that
we
could
break
this
out
and
have
it
run
either
just
on
an
ipfs,
node
or
or
something
else?
And
yes,
so
the
answer
to
where
these
things
run
is
like
everywhere,
like
hopefully
a
lot
you
know.
Hopefully
the
retrieval
client
is
not
even
an
ipfs
node.
B
Eventually,
the
retrieval
client
eventually
is
the
web
browser
right.
So,
but
you
know
it's
just
a
question
of
like
part.
This
is
a
part
of
the
goal.
Here
is
to
take
things
and
push
them
into
different,
to
make
them
more
componentized
so
that
we
can
start
to
figure
out
how
to
build
different
solutions
that
aren't
tied
to
a
lotus,
node
and
or
you
know,
I
mean
most
likely
we'll
be
running
a
lotus
light
node
for
for.
A
Cool
yeah,
one
follow-up
question:
sorry
yeah,
it's
a
bit
more
prickly,
but
a
lot
of
this
is
kind
of
like
trying
to
hit
a
similar
piece
of
the
puzzle
as
like
what
the
arg
with
jeremy
jeremy
is
doing
on
estuary
and
so
on.
Is
there?
Is
there
an
overlap
between
them
at
all,
or
is
this
like
two
different
approaches
to
solve
similar
or
different
problems?.
B
Yeah,
that
is
a
super
good
question
to
me,
and
I
do
not
have
a
lot
of
part
of
my
problem
is,
I
do
not
know,
have
a
lot
of
information
about
what
estuary
so
you'll
actually
see.
Estuary
referred
to
here
in
a
couple
things
because,
like
estuary
is
probably
the
best
example
of
a
retrieval
client
that
is
not
a
lotus
node,
however,
does
that
actually
work?
I
would
be
amazed
if
that
works.
Okay,
maybe
not.
B
It's
referenced.
If
you
look
at,
I
think
you
actually
went
by
one
of
them,
but
in
any
case,
oh,
if
you
look
at
the
roles
for
a
retrieval
client,
yeah
yeah
there,
you
go
six
months.
Prototyping
there
you
go.
That
being
said,
I
actually
I
don't
have
a
lot
of
information
about
estuary.
I
don't
feel
like
most
of
us
do.
It
would
be
really
helpful
if
we
could
get
some
of
that,
because
I
don't
want
to
like
overlap
on
work,
but
I
also
can't
plan.
C
Sharing
this
is
awesome
hannah.
This
is
super
super
cool
and
I
think
also
the
the
piece
that
I
love.
The
most
is
kind
of
like
taking
this
giant
giant
evolving
space
and
getting
enough
clarity
so
that
it
can
be
broken
down
into
different
sub-pieces
and
different
milestones,
many
of
which
can
be
done
by
different
groups
in
parallel,
which
I
think
is
phenomenal
and
the
best
way
to
make
progress
here.
B
Is
that
there's
some
like
some
of
these
brainstorm
components
like
you
could
be
totally
handed
to
like
a
dev
grant
who,
like
wants
to
spend
a
whole
year
like
coming
up
with
cool
stuff
around
it,
so
yeah
any
case
yeah?
Hopefully,
hopefully
this
will
get
us
off
the
ground.
Obviously
I
know
we
have
a
million,
a
million
other
things
that
we're
trying
to
try
to
keep
moving
forward
on
at
the
same
time,
so
yeah.