►
From YouTube: Panel Discussion - Adin, Dietrich, b5 & Boris Mann
Description
In this May 2022 IPFS implementations workshop, we heard a number of first-hand accounts from builders & thinkers working on and with IPFS, taking stock of the current implementation story, and imagining what’s possible through shared effort on a protocol with such broad applicability.
A
But
I
think
that
one
of
the
interesting
themes
that
seems
to
be
coming
up
in
a
few
places
here
is
spanning
the
gap
of
ipfs
as
a
mental
model,
which
feels
like
both
like
a
macro
and
a
micro
thing
move
and
aggregate.
They
were
sort
of
talking
a
bunch
about
how
just
abstracting
over
multiple
pdp
technologies
can
make
it
easier
to
sort
of
just
get
people
over
that
home
carson
make
it
easier
for
people
to
fail
faster.
A
This
idea
that
hey
can
we
can,
we
have
more
people
come
and
iterate
make
their
way
over
see
what
works,
who
it
doesn't
and
then
dietrich.
This
comment:
don't
go
full
ipfs
and
introduce
people
slowly,
I
think,
was
a
pretty
phenomenal
like
strategy
for
actually
crossing
this
divide,
boris
flipping
it
to
you.
What
do
you
think?
How
is
is
that
the
right
way
to
interpret
what
we've
been
hearing?
How
would
you
take
that
from
there.
B
B
And
then
we
slipped
down
the
slope
that
carson
had
to
slip
down
and
we
found
ourselves
having
to
invent
a
decentralized
auth
protocol,
good
news,
much
like
the
web
two
days
when
we
had
to
invent
oauth
because
it
turned
out
that
putting
passwords
into
arbitrary
third-party
clients
or
having
to
figure
out
how
to
extract
an
ipfs
node
key
and
put
it
things
actually
has
generated
lots
of
stuff
and
in
fact,
we've
gotten
lots
of
adoptions
around
that.
B
And
it's
it's
going
lots
of
interesting
places
with
that
with
ucan
carson,
also
called
into
the
thing
that
I'm
gonna
write
a
post
that
says,
ipfs
is
one
the
dot
dot
dot
here
is
kind
of
like
oh
now
we
have
a
lot
of
work
to
do
so
and
I
think
a
lot
of
the
other
things
in
here.
What
has
won
is
content
addressing
and
hashes
and
the
concept
of
self-verifying
data,
and
even
that
that
mental
model
is
just
kind
of
barely
there,
how
you
get
to
it.
B
The
vast
majority
of
people
fetch
these
things
through
ipfs
gateways,
the
vast
majority
of
people
fetch
them
through
ipfs.io
as
a
gateway,
and
we
can
see
that
some
of
those
what
some
of
those
problems
are
without
fission,
attempting
to
build
an
entire
application
model
on
top
of
ipfs.
We
don't
get
to
some
of
these
other
things.
We
start
hitting
issues
with
go
ipfs.
B
We
think
we're
dumb
and
we're
like.
Hopefully,
someone
else
is
smart.
We
start
we
finally
take
us,
takes
us
nine
months
to
find
the
right
people
cake
and
why
and
they're
like?
Oh
actually,
we
can
introduce
you
to
all
the
right
people
and
we
start
meeting
with
other
ipfs
implementers,
and
we
realize
everyone
has
the
same
problems
and
that
in
some
ways
a
central
ipfs.io
has
been
papering
over
some
of
these
things
for
a
while
and
yeah.
B
So
I
think,
there's
a
lot
of
stretch
around
a
lot
of
these
things,
but
now
I
mean
one
thing
that
hasn't
come
up
that
I
want
to
focus
on
is
in
fact,
some
of
the
tensions
of
having
a
large
entity
building
a
lot
of
things
versus
a
model
where
more
things
are
actually
pushed
out
in
different
ways
and
and
a
large
entity
can
do
things
like
do
convening.
B
Do
an
ipfs
camp
have
specs
where
everyone
gathers
and
talks
about
their
use
cases
together
and
then
goes
off
to
their
implementations.
I've
spent
a
lot
of
time
in
the
ethereum
community.
Some
of
the
things
were
mentioned
earlier
are
incorrect
and
have
in
fact
failed.
There
aren't
a
lot
of
ethereum
node
implementations
like
there
are,
but
only
one
is
fully
funded
with
infinite
runway
by
the
ethereum
foundation.
B
This
has
been
fixed
with
eth2
clients
in
interesting
ways
and
there's
an
argument
to
be
made
that
some
of
the
really
hard
parts
and
I'd
look
at
something
like
ipfs
mobile
libraries.
We
should
not
build
those
more
than
once
go.
Mobile
is
probably
the
not
right
the
base
for
that
really
hardcore
low-level
performance.
Libraries
that
actually
tackle
the
challenges
on
mobile
that
get
built
once
so.
That's.
B
B
There
should
be
a
bazillion
implementations
of
that
because
that's
the
layer
that
has
fully
won
and
is
quite
easy
to
read
and
write
in
in
different
ways.
So
I'd
say
that
we
need
to
keep
choosing
that
convene,
have
a
more
open,
tint
migrate,
some
things
out
of
individuals,
orgs
into
more
of
of
community
style
things
and
then
look
for
models
to
actually
just
adopt
more
people
in.
We
want
more
people
at
the
table.
We
want
to
know.
Don't
worry
we're
like
all
learning
together.
That's
my
opener.
C
There's
all
these
different
groups
that
we
work
with,
and
a
lot
of
this
is
us
going
to
those
groups
and
we
rock
up
with
a
single
implementation.
It's
designed
with
a
specific
set
of
assumptions
in
the
single
operating
environment.
So
you'll
see
the
requirements
and
it's
even
though
it
seems
flexible
and
it
seems
like
a
tool
kit
for
wp
applications.
It
ends
up
being
a
pretty
big
barrier
more,
I
think
more
more
diversity
in
our
ecosystem
is
going
to
make
it
stronger
and
really
increase.
C
I
think
you
know
like
the
to
the
the
vector
of
choose
of
choice
there,
and
I
think
choosability
is
one
of
the
things
like
I
think
boris.
This
is
really
it's
really
nuanced.
Right
like
we
want
a
lot
of
choice,
but
not
too
much
choice
and
that's
really
hard
balance
to
strike.
We've
seen
that
in
in
the
web
platform
choices
we've
seen
that
in
javascript
world
for
sure
where
the
explosion
of
choice
has
led
to
incredible.
C
Right
like
it's,
so
it's
really
hard
bounce
to
strike,
but
I
think
when
you're
talking
about
deep
platform,
integration
like
something
like
native
ios
support
or
native
android
sport
for
sure
but
yeah.
I
think
that
doing
that
once
and
letting
people
wrap
it
the
way
that
that
it
works
with
the
higher
level
obstruction.
Great
one
of
the
things
that
I
for
for
me
that
I
think
and
I'd
love
to
hear
from
a
dean
on
this.
It's
really
a
question
perfect
for
you,
a
lot
of
what
we're
talking
about
is
kind
of
like
this.
C
This
there's
a
veneer
like
the
the
far
the
furthest
out
abstractions
on
top
of
this
protocol,
not
necessarily
the
core
implementation,
and
I
can
I
could
go.
You
know
talk
about
all
the
challenges
that
we've
had
with
different
groups
and
different
people
and
how
hard
it
is
to
get
ipvs
into
weird
places.
D
D
We
have
talked
for
a
long
time
about
like
ipfs
more
broadly,
and
it
has
been
said
repeatedly
over
a
long
time
like
ipfs
not
equals,
and
you
know
I
guess
I'm
giving
away
my
whole
talk,
which
comes
after
this,
but,
like
we've
been
you
know,
a
lot
of
like
ipvs
not
equals
like
ipvs
public
dht
does
not
equal
bitswaff
does
not
equal
tcp
or
emplex
or
whatever
it
does
not
equal
those
things.
D
D
You
know
an
example
of
this
is
you
know,
pure,
like
having
authentication
to
some
degree
and
for
for
bitswap
people
have
asked.
How
do
we
do
this
and
for
a
long
time
was
like
well
already
in
the
protocol?
You
can
do
this
based
on
peer
ids.
D
We
can
change
the
protocol,
so
you
can
make
it
do
other
things,
but
right
now
it
works
with
peer,
ids
and
they'd
be
like,
but
like
there's,
no
api
in
go
bit
swap
and
go.
Ipfs
doesn't
have
a
flag.
That's
like
dash
dash
ipfs
ad
dash
dash
for
brenden
right,
there's
no
flag
there.
So
like
does
it
work,
and
yet,
like
someone
who
joined
like
you
know,
the
community
put
this
thing
together
in
like
a
week
or
so
because
they
just
went
and
we're
like
we.
It
was
like.
Oh
yes,
no,
I
believe
you.
D
I
bet
you.
If
I
go
look
at
this
part
of
the
code
base,
I
can
go
change
it
and
that's
just
an
example
of
like
it's
like
there's
like
the
mental
blocks
that
happen
even
before
the
code
blocks,
even
before
the
the
various
gross
code,
things
that
carson
mentioned
and
and
hugo
mentioned,
and
you
know,
etc,
like
even
before
those
there's
like
mental
blocks,
before
you're
willing
to
open
a
code
editor
and
like
see.
D
What's
up,
and
hopefully
I
think,
trying
to
promote
more
implementations
and
make
this
more
like
visible,
will,
will
help
people
get
used
to
the
fact
that,
like
it
gets
to
look
a
little
different,
it
doesn't
all
have
to
look
the
same
way.
A
C
C
In
my
way
and
and
the
you
know
what
native
means,
I
think
is
really
like
in
in
the
question
that
much
asked
earlier,
what
native
what
native
means
is
really
undefined
if
it's
functional
you
know,
is
that
native
enough
oftentimes,
though,
and
I
think
this
is
why
I
can
kind
of
when
I
was
asking
about
the
dht
specifically
like
it-
if
it
is
reliant
on
some
other
external
massive
network,
that
you
don't
control
and
can't
connect
directly
to
and
be
a
first-class
citizen
of
how
functional
can
it
be,
and
I
think
that's
where
we're
playing
all
the
time
like
like
pushing
on
these
barriers
and
and
boris,
is
nodding,
because
just
all
the
challenges
they've
had
trying
to
get
the
stuff
working
at
the
web
platform
in
in
like
the
global
scope
of
a
window,
you
know
in
a
in
one
tab
in
a
browser,
so
we're
in
so
many
ways
we're
pushing
on
the
boundaries
of
of
how
close
can
we
get?
C
What
does
it
mean
to
be
a
first-class
citizen
of
of
that
network
and
have
that
implementation
actually
function,
and
so
in
react
native,
yeah,
yeah
sure?
Yes,
you
can
do
it,
but
if
it
is
not
a
first-class
citizen
of
what
the
dht
is
unclear,
how
native
that
actually
is
how
functional
it's
going
to
be.
B
So
this
is
exactly
it,
so
we
need
to
be
realistic
and
we
have
to
be
pragmatic
about
some
of
these
things
about
which
parts
of
the
ipfs
has
won.
We
start
prosecuting
and
where
we
make
those
trade-offs.
So
as
an
example,
the
very
first
thing
that
we
should
have
is:
should
we
have
a
great
library
for
making
local
car
files
and
uploading
them
to
an
https
endpoint
in
classic
restful
style.
You
are
unblocked
from
doing
that
today.
B
There
probably
need
to
be
some
like
basic
see
it
in
car
libraries
that
are
that
are
shareable,
a
car
file
being
a
way
to
bundle
a
bunch
of
sids
together
in
sort
of
an
offline
way,
and
this
we
want
to
keep
the
integrity
of
ipfs
as
self-authenticating
data.
Oh,
I
can
trust
it
right.
It
was
here
locally.
I
could
push
it
the
fact
that
it
used
an
https
transport
and
used
the
server
to
do
some
other
stuff.
B
One
of
the
things
that
my
team
is
working
on,
something
that
I've
been
calling
the
append
endpoint
that
will
do
for
some
of
this.
You
will
you
will
upload
a
file
and
it
will.
It
will
do
dag
surgery
on
the
server
to
put
it
in
a
particular
location
in
a
directory,
so
fissions
approach,
there's
all
sorts
of
other
stuff
that
we
have.
B
That
is
like
baggage,
so
some
of
you
have
heard
me
rate
rant
about
pinning
before
most
people
who
run
ipfs
at
scale
turn
off
automatic
painting
garbage,
because
it's
a
garbage
collection,
internal
thing
and
it
has
leaked
all
the
way
to
end
users
from
our
work
with
end
users.
What
do
they
care
about?
B
So
for
moves
earlier
thing
of
wanting
to
be
able
to
like
share
stuff
together,
that's
been
on
my
hack
list
that
I
should
write
up
publicly
somewhere,
where,
ideally,
you
can
literally
just
put
a
little
dns
link
somewhere,
where
boris.fission.name
is
something
that
mode
could
put
in
this
little
file
and
all
of
that
sid
would
just
like
stick
around
that's
a
lot
of
stuff.
We're
stacking
on
top
of
things,
and
it
has
zero
to
do
with
the
dht
if
we
want
mobile
clients
to
participate
and
crusade
broadly
and
trust.
B
It
will
be
ugly
it'll,
be
a
hash,
it
won't
be
a
rented
dns
name,
it
won't
support
ipns,
but
at
the
very
least
we
can
keep
human
data
around
in
perpetuity.
If
even
one
person
cares-
or
you
know-
keeps
it
on
a
usb
key
and
plugs
it
in
the
future,
and
that's
where
a
lot
of
us
who
are
working
on
a
bunch
of
other
things
of
all
the
other,
exciting
things
that
ipfs
does
need
to
dial
back
our
stuff
and
be
like.
A
I
think
that's
a
really
great
jump
off
point
because,
as
we've
been
talking
about
this
sort
of
it
makes
me
think
about
the
intersections
between
clients
and
like
what
we
end,
this
spectrum
of
sort
of
thickness
right,
we're
talking
about
a
thin
client,
a
client
server.
You
know
something
in
my
board,
something
that
can
just
hash
and
create
a
car
file
that
is
content
addressed
is
is
is
in
many
ways.
I
see
that
as
a
foundation
of
a
thin
client
sort
of
origin
and
then
participation
in
the
dht.
A
This
question
of
citizenship,
like
is
your
capability
to
be
first
class,
is
like
a
thickening
process.
I
think
on
another
axis.
We
have
this
question
of
like
what
is
the
difference
between
an
application
and
an
implementation
of
ipfs,
and
I'd
like
to
put
that
to
this
group.
Like
do
we
see
a
distinction
there?
Is
that
a
healthy
question?
You
know
dietrich
you're
talking
about
this.
A
This
question
like
we
don't
it
doesn't
have
like
an
application
platform,
but
then
dean
when
we
were
talking
about
sort
of
documenting
the
number
of
different
implementations
of
ipfs.
There
are
a
number
of
projects
listed
on
there
that,
in
my
mind,
sort
of
might
actually
be
classified
as
applications
right,
and
so
I'm
wondering,
if
that's
a
healthy
distinction.
D
D
I
would
put
like
the
thing
that
needs
to
happen
to
some
extent,
which
is
and
again
more
more
giving
away
of
things
for
for
the
next
talk
but
like
if,
if
I'm
just
doing,
content
addressing
right-
and
I
don't
really
care
where
the
data
arrives
from
because
I
can
verify
it-
my
application
is
going
to
have
lots
of,
should
have
lots
of
interesting
ways
in
which
to
get
the
data,
and
maybe
they'll
have
some
standard
ones.
Maybe
there'll
be
some
ones
that
are
specific
to
me.
D
I
I
have
an
application.
My
application
has
like
I
have
a
social
graph
with
like
a
few
people,
and
I'm
gonna
start
checking
with
them
or
we've
agreed
for
something
like
there
are
all
these
extra
mechanisms
that
are
gonna
come
in
that
you
know
an
ipf's
implementation
doesn't
have
to
care
about
right.
You
could
just
be
I'm
just
gonna
use
public
dht.
I
don't
care
that
brendan
probably
has
my
stuff
and
he's
my
friend
nope
or
you
can
decide
to
like
leak.
D
The
apple
the
people
who
built
some
of
the
library
tools
has,
you
know,
gave
me
some
tools
to
work
with,
but,
like
I
know,
what's
best
for
my
users,
I
know
what
I
want
for
them,
and
so
I
think,
like
you
know,
maybe
you
could
decide
like
there
are
library
components
that
are
implementation
e
and
that
you
can
start
to
compose
them,
but
like
at
the
end
of
the
day,
all
of
these
things
should
be,
you
know,
set
you
know,
configurable
to
what
the
application
developer
needs
and
they're
going
to
be
deciding
what
the
ipfs
stuff
looks
like.
B
So
and
again,
the
word
app
here
is
overloaded
in
a
many
many
different
ways
right.
Another
one
of
my
missions
is
to
kill
the
lamp
stack
because
it
is
naturally
centralizing
so
part
of
it
like,
and
it
shouldn't
just
be
that
we
like
take
the
a
out
and
replace
it
with
with
I
the
limp
stack.
Oh
my
god,
that's
so
terrible.
B
Because,
as
dietrich
said,
we
have
new
components,
so
we
can
think
about
this
differently.
You
know,
I
think
there
are
some
dx
goals
right,
so
I
I
would
like
again
I'm
so
very
much
I
so
this
is
some
of
the
stuff
that
we're
driving
towards
is
like.
When
I
say
any
human
should
be
put
a
file
file
on
ipfs
and
like
keep
it
there
forever.
Every
every
human
should
be
able
to
publish
an
app
in
like
sort
of
running
on
the
web
engine.
B
Let's
put
it
that
way
in
a
similar
way.
So
I'd
like
some
protocol
and
implementation
pieces
right,
we
have
ipfs
404
and
then
we
realized
oh
well.
We
we
actually
need
spa
support.
Just
like
netlify
or
vercell
does
so
we
put
someone
on
putting
a
pr
into
go
ipfs
which
we
are
supporting
as
the
main
implementation.
B
That's
out
there
today,
because
we
don't
have
the
resources
to
replace
all
this
ourselves
and
we
want
to
make
it
portable
at
the
protocol
level,
so
working
on
spec
level,
stuff
to
say:
hey,
let's
put
redirects
in
to
the
protocol
directly
again
that
crosses
over.
In
reality,
we
could
have
solved
that
at
the
engine
x,
layer,
people
who
run
ipfs
in
production,
most
of
them
run
nginx
in
front
of
it.
So
this
is
an
application
architecture
of
some
of
these
things.
That
goes
all
the
way
to
ops
and
how
you
put
this
together.
B
We
could
solve
it
at
a
non-spec
non-protocol
while
at
the
engine
x
layer
and
then
immediately
if
someone
accesses
that
ipfs
app
stack
somewhere
else,
because
that's
the
beauty
of
content
addressing
it
will
break
and
not
work
because
it's
not
in
the
protocol,
and
so
we
need
to
be
realistic
about
both
these
things.
You
know
what
you
need
to
put
these
things
together
to
robustly
run
things
in
production
and
also
there
are
some
things
that
we
should
put
in
and
all
of
these
things
have
to
be
displayed
in
such
a
way.
B
That
isn't
like
our
experience.
Coming
in,
we
basically
like
tripped
on
all
the
same
foot
guns
that
everybody
else
did,
but
because
mostly
there's
just
one
big
ipfs.o,
like
team,
that
runs
it
for
with
a
specific
needs.
We
had
to
learn
some
of
that
from
scratch.
So
I
think,
there's
there's
there's
all
these
things
in
all
of
these
different
layers
that
we
actually
need
to
push
the
brownies
of
have
people
figure
some
of
these
other
and
and
give
them
the
tools
so
that
they
can
figure
out
what's
specific
for
their
application.
C
You
know
there's
a
bit
I
removed
from
one
of
my
slides
that
that,
like
backwards,
compatibility
is
the
best
thing
with
http
is
the
best
thing
we
ever
did
for
adoption,
and
it's
also
the
biggest
possible
trap
and
one
of
the
biggest
barriers
towards
people
actually
learning,
ipfs
and
figuring
out
how
to
deploy
it,
build
it
build
on
top
of
it.
What
one
one
challenge,
I
think
you
know
both
boras
you
and
nadine
have
talked
about
kind
of
like
protocol,
configurability
and
extensibility,
and
one
thing
that
ibfs
does.
C
That,
I
think
is
really
interesting.
Is
that
that
we
have
really
strict
layers
really
strict
layer,
adherence
between
the
protocol
layer,
the
network
layer,
the
protocol
layer
and
the
application
layer?
You
really
build
on
top
of
ipfs,
it's
very
rare
that
you
see
somebody
actually
kind
of
reconfiguring
the
protocol
to
do
different
things
and
I
think,
with
http.
C
We
think
that
that's
actually
happening
as
well,
but
http
headers,
actually
like
almost
the
entirety
of
the
accessibility
of
what
we
consider
the
web
application
environment
is
actually
just
the
accessibility
of
the
headers
for
http
and
so
a
lot
of
what
we
consider
application
layer
logic
is
deeply
embedded
in
every
single
message
the
protocol
sends,
and
that
is
with.
I
feel
like
without
acknowledging
how
tightly
integrated
the
http
application
stack.
B
I
mean,
and
the
depths
are
so
dark
here
in
in
in
or
not
dark,
but
deep
in
this,
we
like
like
we
need
to
do
this
talk
this
same
talk
about.
A
B
And
people
are
like:
did
you
deploy
a
planet
scale
structured
database
when
no
one
was
looking,
and
so
my
team
is
thinking
about
some
things
like
autocodex
and
putting
wasm
in
there
and
adding
a
vm
to
ipfs?
B
What,
and
so
I
think
this
is
the
challenge
is
that
we
should
really
be
pushing
people
to
not
go
like
don't
larp
httpd,
but
with
ipfs
right
really
understand
what
we're
using
it
for
and
what's
really
about,
including
being
like
you
know,
what
no,
you
should
just
do
a
rest
api
at
some
sweet,
sweet,
http
right
like
that's
like
you,
you
don't
mean
it's
it's
the
same
sort
of
thing
of
like.
Should
we
sprinkle
a
blockchain
on
it?
B
It's
like
a
lot
of
the
time,
no,
including
the
fact
that
ipfs
has
many
of
the
same
properties
that
a
lot
of
people
look
only
for
for
blockchains
to
oh,
you've
got
merkle
trees
and
you've
got
these
structures
and
it's
immutable,
and
it's
self-verifying
and
and
but
people
are
then
looking
for.
B
Where
are
the
accounts?
Where
are
the
end
user
accounts,
and
so
we're
stuck
actually
between
these
two
things?
We
shouldn't
larp
as
http,
and
we
should
probably
say
that
a
lot
of
things
that
people
want
blockchains
for
are
actually
provided
by
ipfs
and
yeah.
That's
a
lot
of
different
layers
and
audiences
to
surf.
A
But
I
think
that's
a
really
interesting
point
because,
like
while
we're
talking
about
don't
lark
http
we're
also
talking
about
like
wow,
look
how
far
you
can
get
on
just
kind
of
generic
metadata
right
like
the
headers
and
dean
we've
we've
been
talking
a
little
bit
about
in
the
I
profess
implementers
working
group
on
the
ipfs
discord,
which
you
should
join
in
the
middle
of
a
panel
discussion.
Hopefully
this
is
showing
up
on
your
youtube
feed
sure.
But
you
know
metadata
conversations
are
starting
to
surface
right.
A
The
idea
of
adding
attaching
tokens
to
bitswap
as
an
example.
Then
I
think
that
story
feels
like
we're
just
starting
to
crest
into
that,
as
we
sort
of
have
these
conversations
about
building
and
advancing
the
protocol
to
me.
That
strikes
me
as
a
really
interesting
point,
like
we
haven't
actually
formalized
a
conversation
about
like
hey.
A
How
did
you
do
metadata
stuff
and
like
as
someone
who
built
an
application
on
top
of
ipfs
and
use
it
as
a
library
go
ipvs
as
a
library
before
we
were
supposed
to
use
it
as
a
library
there
was.
We
did
a
lot
of
like
construction
of
what
might
have
fit
into
a
metadata
layer
as
a
custom
with
p2p
protocol,
because
that
felt
cool
and
really
like
to
be
blunt
about
it.
But
I
guess
I
should
try
and
turn
this
into
a
question,
and
I
guess
my
question
really
is
like.
A
D
So
one
I'm
gonna
answer
part
of
the
question
and
then
sort
of
answer
something
it's
a
little
bit
related
to
some
stuff
that
came
from
the
last
one.
I
think
this
idea
of
like
what
is
configure.
How
does
configurability
look
like
in
in
ipfs
world
is
it's
sort
of
interesting,
we'll
call
it
like
doing
like
authentication
and
stuff
that
allows
you
to
to
sort
of
pass.
You
know
so
like?
Oh,
you
know,
here's
here's,
the
reason
why
you
should
give
me
data.
D
Are
I
I've
decided
that,
like
you
know,
atp
the
dean
transport
protocol
is
the
best
protocol
and
it
is
the
only
one
that
my
implementation
will
support
and
it
turns
out
that
that's
you
know.
I
can't
I
don't
speak
tcp
or
quick
and
can't
really
talk
to
anybody
else
and
so
data
from
you
know.
People
who
use
my
implementation
may
not
be
usable
from
data.
D
You
know
from
people
who
use
your
implementation
and
then
maybe
somebody
decides
to
build
a
bridge
where
they
like
vacuum,
up
all
the
data
and
they
like
sort
of
bridge
it
over
or
something
and
how
we
help
people
like
navigate
what
that
means
when
you
get
to
like
change
things
so
substantially
like
that,
where
you
can
sort
of,
because
ipfs
does
work
in
offline
environments,
you
can
create
segmented
networks
that
don't
talk
to
each
other
and
in
the
same
way,
that,
like
boris,
is
mentioning
oh,
like
ipfs.io,
like
papers
overall
to
some
extent
one
of
the
ways
in
which
it
does
this
is
it's
like?
D
Oh,
if
it,
if
it
loads
on
ipfs.io,
like
that's,
probably
ipfsc
enough
for
me
right,
and
maybe
that
means
it's
advertising
the
dht
or
maybe
it
means
that
the
folks
who
run
the
ipfs.io
infra
peered,
with
some
appeared
with
some
other
companies
that
didn't
advertise
all
their
data
into
the
dht
and
so
yeah
that
counts
that
counts
good
enough,
too
right
and
figuring
out
how
we
want
to
yeah.
D
I
guess
both
empower
differentiation
and
allow
people
to
build
different
versions
of
this,
but
also
help
people
figure
out
like
what's
going
on
and
how
the
pieces
do
and
don't
fit
together
is
useful.
Maybe
that
looks
a
little
bit
like
the
the
crazy
like.
Can
I
use
it
for
javascript,
where
you
can
find
out
which
browsers
implement
which
wacky
new
javascript
things
today,
or
maybe
it's
or
maybe
it's
other
sorts
of
tooling,
but
I
think
that's
part
of
it.
I.
B
Think
it
absolutely
is-
and
I
think
the
other
half
of
this
is
us,
so
this
is
some
of
the
stuff
of
coming
together
as
a
community.
So
if
you
say,
can
I
use
this?
What
you're
actually
saying
is
you're
seeing
a
centralized
area
where
we
all
come
together
and
we
do
some
interop
testing
and
we
work
stuff
together
and
we
were
like
no,
no
okay,
we're
going
to
get
ibfs.io
to
support,
redirects
and
cloudflare
to
support
redirects
and
pinata
to
support
redirects,
whatever
the
number
is
and
we're
going
to
say.
B
Let's
do
that,
there's
other
questions
about
which
implementations
might
have
redirect
support
turned
on
by
defaults
or
other
things
like
that
right
and
I
think
those
are
where
we
can
make
some
quantum
leaps
in
various
things
and
those
are
some
of
the
things
that
we
can
put
together
as
pushes
as
a
community
while
leaving
the
door
open.
Absolutely
like
hey.
I
wrote
this
custom
gateway
that
does
blah
right,
so
I
posted
some
links
earlier
because
we
run
a
lot
of.
B
We
put
our
file
system
layer
on
top
of
ipfs
the
standard
gateway.
We
use
dag
links
to
point
back
to
previous
versions
and
have
this
neat
structure
that
is
enabled
by
ipfs
and
ipld.
That
is
amazing.
The
standard
gateway
thinks
that
I
have
1.4
petabytes
in
my
file
system
because
it
doesn't
know
if
the
way
that
it
it
just
like
adds
all
the
sim
links
together.
Basically
right
and
that's
one
of
those
things
where
I'm
like
yeah,
I
don't
really
expect
the
standard
gateway
to
you
know
like
I.
B
I
should
put
this
somewhere
and
see
if
anyone
else
has
this
pain
around
sim
links
that
that
we
should
get
around
to
prioritizing
fixing
that-
and
I
think
that's
a
really
great
question:
what
is
the
user
expectation
of
like
a
raw
ipfs
gateway
browser,
so
that
becomes
you
get
that
that
delight
and
discoverability
right
and
in
some
ways
again
it's
going
back
to
and
we
had
saw
a
screenshot
from
juropo
of
of
the
the
like
apache
default
directory
browser
kind
of
thing,
and
I
think
the
flip
side
of
that
is
that
how
do
we?
B
You
know
what
are
the
standards
when
you
look
at
like
a
bittorrent
file,
I
don't
know,
maybe
we
do
like
like
a
crazy
visualization
that
shows
that
it's
everywhere
or
right,
like
we,
we
do
want
more
people
to
think
about
content
addressing
and
do
that
and
we
need
to
in
some
ways
as
a
larger
community
of
ipfs
aligned
and
interested
people,
make
some
strong
goals
of
what
we're
going
to
work
on
together
and
then
commit
to
doing
it,
and
it
can't
be
any
one
org
driving
that.