►
From YouTube: RETMKT Builders - Markets Vision
Description
Hannah gives us her vision of the market from the Retrieval Market Builders Mini-Summit in April 2021.
A
This
section
is
going
to
be
essentially
laying
out
a
grand
vision,
oh
well,
sorry,
sort
of
an
overall
vision
for
where
the
retrieval
market
and
just
to
to
to
start
off.
I
want
to
do
a
quick
is
before
we
before
we
jump
in.
I
want
to
do
a
quick
review
of
sort
of
like
our
goals
for
the
file
coin,
retrieval
market
in
2021
and
I'm
kind
of
referencing
juan
slides
from
yesterday.
A
So
as
a
reminder,
we
would
like
to
build
the
first
production
version
of
the
filecoin
retrieval
market
and
concretely
what
that
means
is
that
we
want
data
to
be
retrievable
in
some
second
time.
We
want
there
to
be
over
a
thousand
people
involved,
potentially
as
retrieval
miners
and
they're
running
at
least
10
000
nodes
on
the
network.
A
A
A
You
may
have
heard
us
say
golden
path.
A
couple
times
essentially
means
like
the
ability
to
store
and
retrieve
data
very
smoothly,
so
that
you
know,
anyone
who
wants
to
store
data
is
very
successful
in
doing
so,
and
that
anyone
who
wants
to
retrieve
data
is
is
able
to
do
so,
ideally
sometimes
without
lotus
at
all.
So
so
so
that's
that's
what
most
of
those
changes
are
aimed
towards
that,
but
a
content
delivery
network
actually
goes
beyond
storage
miners.
A
We
said
that
we
said
that
the
storage
miners
are
really
just
the
core
and
they
don't
cover
the
edges
of
a
content
delivery
network.
There's
gonna
be
a
lot
more
that
we
have
to
build
to
to
get
there.
So
this
talk
is
mostly
about
laying
out
a
plan
to
build
this
market,
and
we
know
we're
gonna
be
doing
decentralized
development.
All
of
you
are
doing
amazing
work
separately,
but
also
together,
and
so
we
have
quite
a
quite
a
ways
to
go
in
just
in
just
a
year.
A
So
how
do
we
get
from
where
we
are
to
where
we
want
to
go?
So
I'm
going
to
be
laying
out
an
overview
of
what
I
see
is
the
components
of
a
decentralized
retrieval
market
that
functions
as
a
content
delivery
network,
and
we
we
know
we
all
want
to
build
like
these
small,
reusable
components
that
can
be
used
by
other
teams
right.
A
But
to
do
that,
we
have
to
have
some
conceptual
alignment
on
what
the
different
components
are
right
and
that's
the
main
goal
of
my
talk,
something
as
a
sort
of
stretch
goal
for
today.
I
would
love
it
if
we
can
start
to
agree
on
how
we,
what
the
names
of
these
components
are
and
how
we
talk
about
them
right.
A
Well
with
it-
and
I
I
that's
gonna-
be
a
process,
I'm
gonna
throw
out
some
stuff
today,
but
it's
mostly
to
you
know
as
strong
and
stuff
for
on
which
to
get
a
lot
of
feedback,
and
I
also
expect
that
those
the
the
the
apis
will
mostly
emerge
from
actual
implementations
as
they
like
come
into
being.
And
you
know,
the
really
good
stuff
will
probably
have
the
most
influence.
C
A
Yeah,
so
that
that's
kind
of
the
the
overview
and
goals
for
this
talk
and
yeah,
let's
get
going
so
this
talk
is
mostly
gonna,
be
based
around
this
thing.
That's
called
the
file
coin,
retrieval
specification
about
a
month
ago,
I
spent
a
bunch
of
time
looking
at
a
lot
of
the
projects
you
guys
were
working
on,
and
I
also
spent
a
lot
of
time
talking
to
go
to
juan
about
his
goals
for
the
retrieval
market
and
doing.
A
Thinking
ahead
about,
what's
still
needed,
for
the
retrieval
market
to
operate
is
the
cdn,
and
I
came
up
with
this
document
that,
like
essentially
outlay
outlines
a
rough
road
map
for
what
the
thing
we're
building
is
and
how
we
get
there.
I'm
gonna,
I'm
gonna,
be
spending
a
bunch
of
time
reviewing
this
at
the
time
I
created
it,
I
called
it
the
file
coin,
retrieval
specification
and,
and
now
I'm
I'm
not
I'm
not
so
sure
that
was
the
best
name,
because
I.
E
A
A
Kind
of
top-down
imposition
it's
more
of
a
conceptual
framework.
The
way
I
would
describe
it
the
way
I
would
describe
it,
maybe
from
pl's
perspective,
and
I
don't
want
to
be
too
authoritative-
is
it
like
this
is
what
we
think
generally
a
retrieval
market's
gonna
look
like
and
when
we
build
our
own
when
we
build
stuff
ourselves,
it's
probably
gonna
fit
somewhere
in
this
in
this
framework,
and
but
that's
that
doesn't
mean
you
have
to
build
things
only
within
this
framework.
D
A
Sure
some
of
you
might
have
ideas
that
we
haven't
even
thought
of,
and
you
can
do
that.
You
can
build
those,
but
you
should,
but
if
you
build
components
that
are
part
of
this
and
you
build
them
well,
you're
really
setting
yourself
up
for
the
best
chance
to
like
see
those
get
heavy
usage
in
the
eventual
of
file
coin
retrieval
market,
so
that
that's
that's
the
way
it
the
way
I'm
presenting
it.
A
We're
pretty
that
you
know
we're
pretty
sure
needs
to
get
built
very
soon
in
order
to
unlock
other
things
and
then
there's
v1,
which
is
the
one
you're
out.
This
is
the
2020
goal,
and
this
is
where
we
are
shooting
for,
like
the
basics
of
a
content,
delivery
network,
there's
also.
Lastly,
a
v2
milestone
where
I'm
just
like,
where
mostly
there's
like
notes
on
things
that
you
could
do
in
the
future,
to
make
it
even
more
awesome.
A
So
yeah,
that's
the
that's
the
basic
layout
here
this
this
overview
page
lays
things
out
and
if
you
want
to
see
actually
all
of
the
pieces
of
the
roadmap
are
gathered
on
this
other
page
called
detailed
roadmap.
I
I
will
say
that
this
roadmap
probably
needs
a
review.
It's
already
changed
a
little
bit,
but
it's
just
to
kind
of
help.
You
get
get
a
sense
of
what
we're
doing.
So.
What
is
the
retrieval
market
right?
A
I'm
gonna
sort
of
go
from
like
highest
level
to
lowest
level
in
how
we
talk
about
this
so
at
the
highest
level
of
the
at
the
highest
level.
The
retrieval
market
is
a
bunch
of
people
and
organizations
who
who
want
to
do
something
right
they
want
to.
They
want
to
interact
with
this
market
and
accomplish
some
goal,
whether
it's
to
serve
content
and
make
money
serving
content
or
get
content,
or
you
know,
or
they
want
to
help
other.
D
A
Find
content
right
so
our
highest
level
is
our.
Is
our
sort
of
actual
participants
right
humans
with
intense
right,
we'll
call
the
the
different
intents
they
might
have
we'll
call
them
roles
right,
specific
things
they
want
to
do,
and
I've
kind
of
identified
five
different
roles.
The
the
participants
in
the
retrieval
market
are
gonna.
Do
there's,
there's
a
retrieval
client,
that's
the
person
who
just
wants
to
get
data
right,
there's
the
retrieval
miner
or
retrieval
provider.
A
This
is
the
person
who
is
serving
data,
so
these
are
ones
that
are
pretty
familiar.
I've
identified,
someone
called
a
marketplace
provider,
and
this
is
mostly
the
someone
someone
who's
going
to
be
helping.
Other
people
discover
other
people
and
discover
other
participants
in
this
network
right,
so
they're
going
to
be
helping
them
find
content
they're
going
to
be
helping
them.
A
Look
at
the
reputation
of
different
minors
and
they're,
also,
eventually,
maybe
going
to
be
helping
miners
get
paid
by
other
people
to
serve
it
to
clients
right
that
actually
gets
to
our
next
role,
which
is
the
content
distributor.
Now.
This
is
something
that
does
not
exist,
but
is
almost
surely
going
to
need
to
exist
within
the
eventual
retrieval
market.
A
This
is
the
person
who
has
content
that
they
would
like
to
make
available
to
someone
else
and
they're
willing
to
pay
a
retrieval
miner
to
make
it
available
and
actually
cover
the
cost
of
that
person.
Downloading
that
that
data
and
then
the
last
person
is,
is
the
person
who
who
handles
payments.
I
call
that
the
the
payment
provider-
this
is
essentially
in
whatever
mechanism
they
they
offer.
They
are,
they
are
facilitating
payments
between
different
parties
right
now.
This
doesn't
really
exist
as
any
kind
of
an
organizational
like
entity.
C
A
Those
are
the
high
level
components
and
then,
within
that
sorry,
the
high
level
roles
I
apologize
and
then
within
that
each
role,
you're
you're
in
order
to
perform
these
roles
like
a
participant
is
gonna.
They
usually
are
gonna,
have
one
role,
but
they
might
have
multiple
and
they're
gonna
run
machines
on
the
network.
Right,
they're
gonna
be
running
nodes,
and
these
are
all
essentially
with
p2p
hosts
and
then,
within
that,
each
each
role
is
there.
A
I've
defined
a
bunch
of
individual
components
that
perform
one
function
in
the
network
and
each
role
is
probably
going
to
have
a
typical
composition
of
different
components
right.
So,
if
I
am
a
retrieval
client,
I'm
going
to
need
to
run.
You
know
these
three
components
most
likely
locally
in
my
own
hardware
and
I'm
going
to
need
to
interact
with
these
other
roles
on
the
network
and
they're
going
to
be
running
their
own
they're,
going
to
be
running
a
specific
set
of
components
right.
A
Speaks
to
the
like
the
ongoing
this
ongoing
theme
of
like
decomposition
right,
like
that,
like
you,
have
to
run
less
and
less
to
participate
in
the
way
that
you
want
right,
and
you
only
run
the
stuff
that
you
need
and
and
and
so
that
so
so
that
brings
us
to
the
sort
of
lowest
level.
So
what's
a
component
right,
so
there's
a,
but
I'm
gonna
actually
walk
through
these
one
by
one
but
they're
they
are.
They
are
individual
components
that
rod
the
that
do.
A
One
thing
you
can
general
they're
the
basic
building
blocks
right
and
they
generally
run
in
a
single
process
on
a
single
node
in
the
network,
and
they
do
not
have
to
run
in
the
same
process.
You
know
every
component
while
it
depends
on
other
components.
Okay
should
be
able
to
run
in
its
own
process
and
communicate
across
process
boundaries
as
needed
right,
and
this
is
sort
of
like
part
of
the
design,
to
allow
a
lot
of
composability
again.
A
These
are
just
mostly
recommendations
and
not
necessarily
things
that
everyone
has
to
agree
on.
But
but
you
know,
I
think
it
it.
It
would
be.
You
know
it's
useful
to
strive
towards
this
right,
notably
not
all
most
of
the
components
in
a
real
retrieval
market
network
do
not
actually
necessarily
have
to
be
tied
to
filepoint
in
any
way
right.
When
you
look
at
the
when
I
go
through
these
you'll
see,
there's
really
only
essentially
three
that
have
any
reference
to
the
filecoin
network,
and
even
then
it's
you
know.
A
A
An
api
specification
for
each
component
again.
These
are
mostly
strong,
like
strawman
proposals,
and
I
define
them
with
golang,
but
they
roughly
follow
the
same
json
api
format
that
lotus
uses
for
its
api.
So
the
translation
to
it
like
a
json
rfpc
api
should
be
pretty
straightforward,
cool.
Okay,
that
was
a
mouthful.
I'm
gonna,
I'm
gonna
start
digging
in
now
cool,
so
the
first.
The
first
component
is
a
mechanism
for
transporting
data.
A
You
can
you
can
think
of
the
primary
example
of
this
currently
as
as
grassy
in
the
in
the
current
sort
of
file
coin
setup,
a
transport
specifically
the
the
where
the
place
this
interface
appears
in
current
software
is
a
transport
in
interface
inside
of
the
data
transfer,
software
that
essentially
abstracts
the
underlying
transport
and
while
graph
sync
is
our
current
one.
There's
there's
an
opportunity
to
potentially
build
like
a
a
much
simpler
protocol.
That's
like
that's
close
to
http.
A
This
is
something
that
we
are
looking
into
in
our
own
software.
It's
tricky
because
you
need
to
be
able
to
verify
data
as
it
comes
in
for
most
cases
but
yeah,
but
that,
but
but
you
could
potentially
have
multiple
transports,
and
we
also
talked
about
yesterday
the
possibility
of
bit
swap
or
mixing
grass
and
bit
swap
so
you
can
think
of
the
transport.
A
A
You
is
you're
most
familiar
with
it,
as
essentially
the
retrieval
market
software
and
go
fill
markets,
but
I
think
exchange
is
probably
a
better
description
because
we
could
potentially
have
multiple
exchange
protocols,
not
just
the
one
that
is
in
in
retrieval
markets,
and
the
basic
goal
of
the
exchange
protocol
of
an
exchange
module
is
to
facilitate
a
fair
exchange
of
payment
for
data
right
now.
The
the
this
the
this
is
obviously
a
complicated
problem
and
fair
exchange.
A
You
know,
there's
a
number
of
solutions,
not
all
none
of
them
are
perfect.
That
can
include
stuff
like
sorry.
It
could
include
stuff
like
having
third
parties
involved.
It
can
include.
We
can
include
what
we
do
now,
which
is
essentially
just
a
form
of
optimistic,
fair
exchange,
and
it
essentially
just
the
exchanges
are,
is-
is
responsible
for
making
sure
both
parties
fulfill
their
obligation.
A
However,
that's
implemented
and
again,
if
you
look
at
the
interface
here,
you're
going
to
see
stuff
that
looks
pretty
similar
to
parts
of
go
fill
markets.
There's
a
few
changes
to
kind
of
facilitate
the
idea
that
it
might
be
operating
in
a
separate
process,
because
that
might
be
important
and
and
yeah
that's
what
the
the
exchange
mechanism
does.
Exchange
in
turn
needs
to
communicate
with
some
form
of
payment,
and
that's
what
this
payment
channel.
A
Calling
it
for
now
but
payment
channel
manager
now
this
is
this-
is
really
based
off
of
the
early
stuff,
but
I
know
that
a
lot
needs
to
change
right,
because
eventually,
a
payment
channel
manager
is
that
it
is
ideally
actually
a
running
an
entire
website.
That
is
doing
some
kind
of
like
hub
and
spoke
type
type
payments
right.
A
In
order
to
do
this
is
going
to
need
to
talk
to
wallets
for
each
party
right
so
again
we're
seeing
pretty
common
components,
so
the
common
things
that
exist
already,
this
one's
based
off
of
lotus
and
and
then
in
order
to
do
all
this
there's
a
component
to
interact
with
the
file
point
chain
right
now.
This
is
this
is
a
essentially
just
an
abstraction
of
what
we
call
the
lotus
light
api,
which
is
just
the
parts
of
lotus
that
interact
directly
with
the
chain.
So
that
covers
all
the
stuff.
A
We
know
we
most
of
this
is
really
you
know,
well-known
stuff,
I'm
going
to
start
getting
into
some
of
the
new
the
newer
things
that
are
that
get
into
a
lot
of
the
projects
that
you
all
are
building.
So
we
have.
The
one
that
we've
started
to
talk
about
is
some
kind
of
a
content,
routing
interface
right.
So
we
know
we
need
to.
A
A
That's
in
that's
that's
sort
of
like
already
in
ipfs,
but
I've
sort
of
started
to
add
others,
and
the
the
assumption
is
that
this
would
be
built
off
of
the
the
smart
records
that
that
guitar
game
to
talk
about
yesterday,
eventually
and
in
the
me,
and-
and
we
want
to
make
sure
that
speaking
of
what
will
was
just
just
covering
that
it
speaks
to
both.
You
know
that
it
can
speak
to
multiple
types
of
content,
routing
systems,
whether
it's
the
dht
or
indexers
or
whatnot
cool.
A
A
Okay
and
then
the
last
two
components
have
to
do
with
the
idea
of
people
who
want
to
actually
pay
to
distribute
content
and
again
you'll
see
on
each
of
these
pages,
there's
a
little
bit
of
a
there's,
a
confidence
level
right
and
and
like
it's
basically
me
saying.
I
think
this
is
this
is
I
know,
vaguely
what
this
looks
like,
and
it
mostly
has
to
do
with
whether
the
software
is
built
right,
and
I
I
describe
this
concept
of
a
content
bid
index.
A
A
There's
not
store
to
to
serve
it
to
retrieve
it,
because
it's
not
provable
storage
in
the
same
way
that
that
the
that
storage
mining
is
and
then
I
had
this
notion
of
a
content,
distribution,
api
and
a
distribution
component,
and
what
this
would
do
would
be
to
facilitate
essentially
the
it
would
be.
It
would
sit
on
top
of
data
transfer
and
it
would
negotiate
the
distribution
of
content
from
a
content.
Distributor.
A
Someone
who
wanted
to
to
serve
con
to
have
content
served
up
to
a
retrieval
miner
or
someone
who
would
actually
do
the
serving
and
there's
an
api
here,
that's
quite
similar
to
the
exchange
protocol
and
then
the
the
last
step
of
the
exchange
will
actually
be
probably
a
little
bit
complicated
because
we're
going
to
need
to
have
a
transfer
from
miner
to
client,
while
an
exchange
actually
facilitates
a
payment
from
distributor
to
to
minor.
But
I
think
that,
but
these
are
sort
of
like
this
is
going
to
be
an
important
functionality.
A
A
Gonna
look
like
in
terms
of
software,
and
then
you
know
over
the
course
of
the
next
year,
probably
the
one
that
is
well,
you
heard
a
little
bit
of
about
what
we're
doing
with
lotus,
which
will
probably
make
a
big
be
the
initial
changes
that
lead
towards
the
that
matter.
For
folks
who
are
doing
mining
now,
eventually,
what
we're
probably
going
to
do.
A
What
we
would
like
is
that
people
should
be
able
to
be
operated
as
retrieval
miners
without
operating
as
storage
miners,
because,
obviously,
storage
mining
is,
is
a
big
bar
to
get
over,
and
you
know
we'll
see
what
that
looks
like
the
prob
by
breaking
up
parts
of
lotus,
we're
sort
of
setting
up
the
the
the
beginnings
of
that.
It
was
interesting
to
hear
that
maybe
estuary
is
a
potential
retriever,
retrieval
minor.
You
know
piece
of
software
there's.
F
D
F
H
A
This
isn't
like
super
mapped
out,
it
might
be.
The
ipfs
is
itself
potentially
a
retrieval
minor
or
go.
Ipfs
is
potentially
a
retrieval
minor
for
the
retrieval
client.
We
have
kind
of
a
much
more
detailed
plan.
Our
goal
is
most
likely
to
make
go
ipfs
a
retrieval
client
at
some
point
in
in
the
future,
and
there's
there's
a
bunch
of
steps
to
get
there,
and
I
want
to
just
briefly
jump
back
over
to
this
presentation.
A
This
will
go
forward.
Yes,
we're
gonna
have
to
do
some
re-architecting
of
ipfs
in
order
for
it
to
be
able
to
retrieve.
This
is
like
my
napkin
math
arc
re-architecture.
So
please
don't
hold
me
to
it.
Also,
like
I
don't
wanna
like
present
this
to
something
this,
like
hotdog
free
architecture,
without
running
it
by
a
team,
who's
sort
of
like
the
main
person.
A
But
you
know
what
we're
right
now,
our
ipfs
does
most
of
its
operations
directly
through
bitswap
bitswap
manages
a
whole
lot
in
ipfs
and,
among
other,
like
it
fetches
content,
but
it
also
like
tracks
peers
like
as
you're
trying
to
like
fetch
if
you're
fetching
a
dag
of
content.
It
tracks
like
what
are
the
peers
that
responded
for
other
parts
of
that
dag
it's
responsible
for
that,
it's
responsible
for
for
going
out
to
the
dht,
it's
responsible
for
providing
cid's
to
the
dht.
A
You
know
ipfs
bit
swap
type
retrieval
or
if
we're
gonna
go
over
to
and
try
to
do
a
file
coin,
retrieval
with
data
transfer
and
most
likely
graphic.
Initially,
we
are
most
likely
going
to
start
focused
on
very
much
focused
on
free
retrievals.
We
are
not
going
to
attempt
to
do
paid
retrievals
in
our
first
run,
because,
among
other
things
we
are
most
likely.
A
You
can
imagine
a
little
exchange
module
somewhere
over
to
the
left
of
data
transfer
of
operating
across
a
process
boundary
and
and
managing
the
actual
payment
part
and
yeah.
And
so
then
you
get
you
just
get
a
few
different
other
changes.
You
know
we're
gonna
again
we're
gonna
have
to
move
the
tracking
appears
out
from
under
bit
swap
and
we're
most
likely
going
to
need
to
move
the
providing.
I
would
probably
move
it
all
the
way
up
to
the
like
top
level
of
ipfs.
A
So
this
is
some
stuff
that
that
we
don't
this.
Is
it's
not
necessarily
going
to
look
like
this,
but
it
is
something
we
are.
We're
definitely
going
to
be
looking
at,
because
one
of
our
directions
is
to
you
know,
probably
have
go
ipfs
be
a
retrieval
client,
especially
for
free
retrievals,
initially
so
yeah.
So
those
are
all
the
different
things
I
am
not
going
to
get
too
deep
into
I'm
trying
to
think.
If
I
should
go
too
deep
into
some
of
these
other
things
again,
like
you.
A
The
goal
for
payment
providers
on
this
network
is
to
slowly
evolve
to
be
actual
payment
providers
who
manage
like
hub
and
spoke
payment,
channel
systems
or
something
else
we
don't
know
and
then
our
goal
for
and
then
the
idea
is
that,
for,
like,
I
grouped
like
the
idea
of
reputational
index
the
idea
of
like
a
content,
routing
index
and
potentially
this
bit
index
into
a
single
person.
It
may
not
be
a
single
person
that
might
be
multiple
people,
but
yeah.
A
H
Thank
you
so
much
so
yeah.
What's
what's
like
new
content
here
we
have
a
question
on
chat
and
given
that
we
all
get
a
little
bit
of
extra
time
for
this
specific
q
a
then
you
will
take
that
question
and
then
open
up
the
room
for
people
to
just
raise
hands
and
do
like
a
live
discussion
rather
than
a
direct
q.
A
so
the
question
is:
is
your
retrieval
client
that
knows
in
the
network
or
a
library
that
an
application
could
study
statically
linked
to.
A
I
had
been
known
like
my
in
order
to
operate
as
a
retrieval
client,
you
need
to
be
running
a
lift
p2p
node
when
I
say
node
I
for
me,
node
means
a
lib
p2p
node
as
and
you
have
a
network
address,
so
in
that
sense
it
is
definitely
a
node.
Now
it
could
be
running
within
go
ipfs,
which
is
obviously
its
own
application,
or
we
could
get
to
the
point
where
it's
a
standalone
library
that
other
people
could
integrate.
I
know
for
myself.
A
A
I
think
the
initial
goal
is
just
to
just
to
get
it
to
ipfs,
which
is
like
its
own
challenge,
and
we
definitely
want
to
be
able
to
interoperate
between
you
know
these,
like
free,
retrieval
and
free
file,
current
retrieval
and
ipfs,
so
that
in
and
of
itself
is
a
big
challenge
to
figure
out,
and
so
it's
good
we're
probably
going
to
spend
some
time
on
that.
I
know
that,
though,
also
like
that
you
know.
H
A
Yeah,
it
says:
is
this
framework
compatible
with
coordinated
w3dt
golden
path
designs?
That
is
the
intent.
I
do
not
believe
there
is
anything
in
there
that
is,
that
is
that
is
operating
differently
and
I've
mostly
synced
up
the
names
they're
they're.
They
originally
were
some
other
names
yeah,
but
so
the
the
the
golden
path
is
is
again
like
focused
on
retrieval
from
storage,
miners
and
and
the
ev.
A
Much
of
that
specification
actually
matches
the
things
that
we
want
to
do
in
order
to
support
golden
path,
and
that's
at
least
from
the
at
least
from
the
standpoint
of
protocol
labs.
That's
that's
probably
the
first
thing
we're
going
to
be
working
on,
including
ipfs
as
a
retrieval
client
is
currently
sort
of
part
of
the
designs
for
you.
D
Know
like
I'm
just
like
asking
like
a
super
practical
question,
because
I'm
not
liking
the
flow
of
the
non-resnet
lab
world,
but
basically
like
the
golden
path
is
like
this,
like
high
architecture,
sort
of
high
level
architecture,
design
of
all
the
software
components,
and
you
have
like
specific
interface
designs.
So
I'm
basically,
I
was
wondering
if
essentially,
these
interfaces
are
going
to
be
the
interfaces
in
the
boxes
of
the
golden
path,
components.
A
Yeah,
I
wouldn't
I
wouldn't
necessarily
say
they
will
be
those
exact
interfaces
again.
The
interfaces
are
looking
pretty
far
forward
and
like
I
would
not
live
by
them.
Yet
there
they
are.
You
know,
like
the
the
you'll,
see
on
the
pages,
for
the
components
that
they
have
a
sort
of
state.
So,
like
there's
one,
that's
called
you
know
the
one
that's
file
coin
chain.
A
A
small
part
of
lotus,
and-
and
so
I
don't
see
that
being
potentially,
that
changing
much
now,
how
you
call
that
might
change
because,
like
that
that
currently,
that
interface
is
part
of
a
monolithic,
node,
lotus,
node
and
that
may
be
split
out
and
that's
actually
already
split
somewhere,
because
that
interface
is
the
part,
is
part
of
the
lotus
apis
and
some
that's
in
so-called
lotus
light,
which
is
this
version
of
lotus.
That
does
not
actually
sync
the
chain,
but
talks
to
another
node
that
does
so
yeah
yeah.
A
I
mean
I
was
mostly
those
interfaces.
The
one
thing
that
is
true
about
them
is
that
they
do
talk
to
each
other
and
they
are
compilable.
But
I
am
also
not
like
you
know
under
the
illusion
that
I
that
that
you
know
off
the
off,
like
you
know,
just
pulling
stuff
out
of
thin
air
that
they're
the
right
ones
exactly
yeah.
A
Yeah
for
sure
well
so
so
up
to
paid
up
to
just
to
be
just
as
a
starting
piece
up
to
paid
retrieval
up
to
the
point
where
you're
paying
you're
still
within
a
single
note
in
process.
But
but
I
totally
sorry
I
should
rewind
and
just
say
I
totally
kind
of
agree
with
your
point.
There's
like
a
larger
question
about
like
how
does
ipfs
become
more
composable
or
pluggable.
A
No,
there
is
a
plug-in
api
which
obviously
you're
quite
aware
of
because
you
guys
are
working
with
it,
but
I
I
I
think
it
would
be
interesting
to
I
don't
know
to.
We
have
not
done
any
kind
of
like
an
ipfs
architecture.
Audit.
I
think
in
some
time
at
pl,
and
we
may
need
to
take
a
look
at
that
before
we
start
messing
around
with
the
guts.
A
G
To
include
a
just
a
quick
note
here
around
english
sure,
because
I
think
it's
really
important
given
kind
of
how
the
filecoin
software
ended
up
developing
in
order
to
ship
last
year
and
so
on.
All
kinds
of
important
connectivity
layers
were
and
because
the
software
approach
was
just
different,
it
ended
up
building
pieces
of
software
that
didn't
talk
to
other
parts
of
the
system
as
as
well
as
as
we
could
so.
G
We
ended
up
with
like
an
accidental
division
between
say,
like
the
falcon
software
stack
and
the
like
say,
go
ipfs
and
js
ipfs
versions
of
the
world.
So
I
think
what
most
people
have
been
calling
fpfs
here.
I
think
people
are
meaning
go
ipfs
specifically
like
the
software
distribution.
The
ipfs
system
is
is
as
like
a
larger
scale
thing
you
can
you
should
we
should
be
thinking
about
it
as
some
network
oriented
way
to
distribute
ipld
data,
and
so,
like?
G
That's
super
general
right,
but
like
that
that
is
sort
of
what
ipfs
is
about,
and
so
that
means
things
like
lotus.
Node
is
an
ipfs
node.
It
just
doesn't
talk
to
go
ipfs
as
well
as
it
should,
and
so
what
we're
going
to
do
about
this
kind
of
help
reduce
the
confusion.
Hey
we're
going
to
rename
go
rpfs
and
jsps
and
give
those
implementations
names
other
than
ipfs,
so
that
when
people
say
ipfs,
they
don't
specifically
just
mean
go
ipfs.
G
All
of
these
should
have
very
simple
interface
layers
that
they
can
where
they
can
talk
to
each
other
very,
very
smoothly.
So
the
ideas
of
pulling
a
bunch
of
this,
this
thinking
into
the
go,
ipfs
implementation
and
sounds
great.
I
think
it
depends.
One
of
the
important
constraints
in
those
implementations
is
that
they
remain
kind
of
like
payment
neutral
to
some
extent,
and
so
there
might
be.
There
might
be
constraints
there
around
saying,
hey.
G
There
should
be
one
distribution
of
of
this
that
doesn't
require
paying
through
through
through
some
particular
market.
However,
in
any
place
where
there
are
vouchers
or
things
like
that,
then
they
would
work
just
fine
right
and
so
for
most
of
the
retrieval
most
of
the
cdn
style
use
cases.
The
publishers
are
going
to
be
paying
the
the
bandwidth
costs
and
they're
going
to
be
kind
of
giving
vouchers
or
something
like
claimable
batteries
or
some
way
of
of
of
accessing
the
data
to
to
the
end
user.
G
So,
like
the
the
the
retrieval
nodes
like
the
actual
browser,
their
tool,
clients
right,
the
actual
browsers
or
web
pages,
and
so
on
and
those
can
be
just
js
ipfs
notes.
Potentially,
it's
not
not
really
clear
that
they
can't
be,
and
so
it's
like
this
kind
of
a
bulbable
layer
of
just
getting
into
just
the
concrete
interface
points
that
need
to
that.
We
need
in
order
to
kind
of
move
around
a
lot
of
this
data,
find
this
data
and
so
on.
G
I
don't
know
that,
like
by
the
way,
give
me
feedback
on
chat
if,
like
this
was
confusing,
I'm
I'm
very
happy
to
go
and
record
a
a
topic
where
I
go
in
detail
into
kind
of
how
we're
gonna
all
this
renaming
of
the
implementations
and
so
on.
We're
also
gonna
name
the
dhd.
So
it's
very
clear
like
when
something
is
in
the
current
iphone
chd.
What
does
that
mean?
That
has
a
name,
so
it's
easy
to
think
about
like
the
different
content,
distribution
layers.
F
Yeah,
it
was
mostly
just
saying
that
I
think
that
separating
out,
like
you
know,
clarifying
like
that,
ipfs
is,
is
sort
of
a
more
generic
thing
than
god.
Kfs
helps,
but
there's
a
deeper
level
of
like
extensibility
and
and
and
like
shared
understanding
of
what
people
are
talking
about
when
they
say
something
like
supports
ipfs,
which
is
a
suspected
term
that,
if
we
wanted
people
to
move
away
from,
would
be
quite
hard
right
like
it's.
G
Like
what
do
you
mean
when
you
say
supports
http
right,
like
you?
Like
you,
don't
mean
you
run
the
binary
that
that
was
used
in
the
90s
or,
and
you
don't
mean
apache,
you
don't
mean
nginx,
you
mean
there's
a
specific
protocol
layer
where
you
have
this
request,
reply
model
and,
like
you,
speak
html
and
you
have
like
the
headers,
and
so
that's.
F
I
I
guess
I
was
trying
to
like.
Maybe
a
more
concrete,
like
example,
is
you
know
brave,
says
that,
like
they
have
their
their,
you
know
you
can
find
things
by
typing
an
ipfest
colon,
slash
a
thing
and
right
now
it's
using
this
ips
public
dht
to
find
stuff.
But
now
I
want
to
add
support
for
you
know,
for
what
mile
is
doing
or
for
what
pegasus
is
doing
right.
F
G
Yeah
exactly
exactly
so.
This
is
what
making
good
content,
routing
interfaces
and
apis
means
and
we're
going
to
solve
this
problem.
Well,
once
we
have
three
or
four
different
content,
routing
systems
that
need
to
play
together
and
a
tool
does
not
should
not
have
to
learn
four
different
clients
and
users
should
never
have
to
worry
about
those
or
usually,
you
should
never
have
to
to
worry
about
where
it's
coming
from.
I
Maybe
in
that
multicodec
gets
to
point
to
the
data
of
the
wasp
module
of
the
way
to
interpret
it,
and
so
there's
some
things
where
things
can
then
load
in
ways,
and
you
can
imagine
that
also,
for
you
know
additional
protocols
for
how
okay,
how
do
I
actually
then
go
and
get
this
thing
that
needs
payment?
Can
I
you
know
have
some
way
to
learn
enough
to
make
the
request
to
the
dap
so
that
the
provider
can
do
its
payment
channel
thing
that
it
needs
in
some
extensive
way.
I
If
it's
not
something
where
I
need
to
actually
pay
myself,
because
once
I've
got
a
wallet,
that
probably
is
some
other
piece
of
software.
I
have
to
be
thinking
about
meaningfully,
but
if
it's
offloading
to
a
cdn,
there
may
well
be
a
way
that
that
can
all
just
sort
of
happen
automatically
in
an
extensive
way.
A
Yeah
I
just
want
to
by
the
way
I
want
to
identify
that
I
sort
of
made
the
bold
claim
that
we
were
for
sure
going
to
be
changing.
Do
ipfs
itself
in
my
talk,
and
so
that
may
have
created
confusion
and
it
sounds.
You
know,
there's
a
possibility
that
this
will
be
within.
You
know.
I
think
that
that
what
we
want
to
do
is
make
sure
that,
if
you're
running
an
ipfs
client
whatever,
that
is
that
you
can
retrieve
from
both
ipfs
and
filecoin.
H
C
I
know
this
for
now
it's
up
to
client,
so
he
has
to
store
data
twice
and
agree
with
multiple
miners
like
for
two,
for
example,
but
but
if
I'm
as
a
client-
and
I
want
to
store
data,
this
is
like
a
first
question
for
me
like
I
want
someone
something
with
trustworthy.
Like
did
you
consider
doing
this
data
redundancy
and
resilience
based
of
cig
parts
like
pieces
instead
of
like
doing
the
parts
of
files
and
the
responsibility
of
the
client,
so
I
don't
want
to
think
about
it.
C
I
just
want
to
store
it
in
like
a
red
array
and
forget
about
it.
So
this
is
like
a
looks
to
me
like
a
feature
of
a
system
like
maybe
one
of
the
most
important
one.
So
I
don't
have
to
worry
about
how
many
miners
do
I
talk
to
and
it's
I
I
don't
want
to
be
responsible.
If
I
choose
run
miners,
I
just
want
to
store
data
and
forget,
and
maybe
you
will
cut
it
into
pieces
and
give
cids
to
the
pieces
and
distribute
it
across
multiple
miners
and.
C
A
G
Cases
right
like
if
and
there's
all
kinds
of
utility
that
comes
from
content,
addressing
and
and
like
the
whole
mdn
world
and
and
content-centric
networking
world
has
tons
of
very
good
solutions
for
a
bunch
of
very
interesting
problems
around
moving
content
that
all
become,
or
a
lot
of
them
become
possible
to
use.
Once
you
can
make
these
network
layers
extensible
and
you
have
a
a
uniform
way
of
relating
the
pieces
of
data
and
and
knowing
how
to
how
to
find
them.
G
B
H
F
B
B
My
my
thought
is
my
vision
is
that
it
would
be
great
if
we
could
get
to
the
point
where
we
could
have
this
library
say
running
on
ios
on
android
in
the
browser
wherever
you
like,
and
you
can
decide
to
drop
your
readme.txt
file
in
and
then
get
it
back,
and
so
it
can
do
the
storage.
It
can
do
the
wallet
for
the
payment
and
it
can
locate
the
data.
B
So
I
I
guess,
I'm
not
directly
having
questions
here,
but
I'm
just
sort
of
saying
that
that's
where
I'm
sitting
at
the
moment
is
just
thinking
through
exactly
how
it
relates
and
how
this
architecture
relates
to
the
architecture
that
I've
been
thinking
about,
that
we
could
move
forward
with
which
should
hopefully
help
anyone
store.
You
know
just
with
a
little
client
library,
that's
sitting
in
an
ios
app
or
you
know,.
A
Yeah
I
mean
so
so.
Actually
it's
a
great
it's
a
great
question.
I'm
totally
happy
to
try
to
take
this
question
from
other
folks,
but
like
from
what
I
know
of
your
of
your
stuff,
like
I
would
see
like
your
incentivized
dht.
That
to
me
is
a
form
of
that's
going
to
fit
in
the
content,
routing
piece
right
and
I
believe
your
gateways
are
now.
B
A
F
G
There's
a
very
big
difference:
the
difference
is
discovery
is
a
process
of
passively
finding
things
like
peer
discovery,
you're
in
a
network.
You
don't
know
who's
around.
You
suddenly
find
peers.
You
have
you
weren't
looking
for
them,
maybe
you
were
looking
for
other
people,
but
you
just
passively
find
peers
in
content-centric
networking
content
discovery
is
like
you
will
possibly
find
content.
Content
will
passively
be
pushed
to
you.
G
Maybe
you
were
interested,
maybe
you
weren't,
but
you're,
finding
the
content
and
a
lot
of
algorithms
and
protocols,
leverage
that
passive
diffusion
of
content
to
then
disrupt
like
to
get
to
like
really
good
solutions,
even
when
nodes
weren't
interested
in
it.
So
then
routing
is
a
separate
problem,
which
is,
I
specifically
want
to
go
for
a
specific
thing.
I
want
to
find
a
peer,
or
I
want
to
find
a
piece
of
content.
G
What
do
I
need
to
do
to
find
this
thing
that
I'm
interested
in
specifically,
and
so,
like
those
two
problems,
end
up
right
now?
Our
interfaces
don't
really
do
much
with
content
discovery.
We
basically
just
have
pure
discovery
peer
routing
and
content
routing,
but
all
the
content,
centric
networking
world
has
tons
of
interesting
diffusion,
oriented
protocols
that
do
the
proper
content
discovery
thing,
and
so
so
I
would
like
yeah.
Sorry.
Storage
interrupt
is
just
like
that.
A
Routing
now
you
mentioned,
like
the
gateways,
might
also
have
like
a
some
kind
of
a
cache
of
the
data,
and
you
might,
I
don't
know
if
your
your
intent
is
to
like
ask
the
gateway
and
then
ask
the
miner
directly
or
to
actually
have
the
gateway
proxy,
the
request
to
the
miner
and
then
send
it
all
back
and
or
respond
through
the
local
cache
if
they
have
it.
If
that's
the
case,
I
would
I
would
describe
it
as
also
operating
kind
of
as
a
retrieval
miner
and
that's
okay.