►
From YouTube: Application space in IPFS - @b5 - Building Apps on IPFS
Description
Application space in IPFS - presented by @b5 at IPFS þing 2022 - Building Apps on IPFS - https://2022.ipfs-thing.io
A
So
I
was
supposed
to
talk
about
what
was
I
supposed
to
talk
about:
building
ld
in
french,
no
ipld
and
friends,
right?
Okay,
we'll
get
to
that.
Oh.
A
The
but
brooke
asked
me
in
the
hallway.
I
want
to
know
why
query
failed
and
I
was
like
oh,
I
can
talk
about
that,
and
so
this
is
going
to
be.
I
literally
have
cooked
this
up
in
the
last
hour
very
much
in
the
spirit
of
this
track
to
because
I
think
it's
a
valid
question
and
as
soon
as
she
asks
was
like,
of
course
it's
like
the
perfect
thing
to
talk
about
when
you're
talking
about
building
applications
on
ivfs.
A
I
want
to
say
that
a
lot
this
is
actually
very
quickly
assembled
and,
like
a
lot
of
these
views,
I
very
very
very
much
believe
in
the
strong
views
weekly
held
principle
in
the
sense
that
I'm
going
to
tell
you
a
lot
of
stuff.
That
is
very
off
the
cuff
for
the
purpose
of
getting
some
of
these
conversations
out
into
the
open,
so
that,
ideally,
we
can
have
this
move
into
a
discussion,
but
I
am
I'm
very
at
peace
with
this.
I'm
very
proud
of
query.
I
think
it's
one.
A
So
I'm
not
angry
about
this,
but
I
think
it
is
really
exciting
to
talk
about
what
we
learned
and
as
rick
was
saying
like
it's
just
it's
when
you
actually
get
the
full
honest
truth
when,
when
something
kind
of
hits
its
conclusion,
and
so
just
for
those
who
don't
know,
query
or
qri,
is
or
was
a
dataset
version
control
tool
built
on
top
of
ipfs,
we
got
our
start
archiving
government
data
sets
from
the
environmental
protection
agency
in
2016.,
so
we've
been
building
on
top
of
ipfs
in
late
2016.
A
I
met
a
lot
of
the
members
of
protocol
labs
when
they
were
like
a
team
of
13,
and
it
was
a
really
fun
time
and
have
had
have
had
actually
the
real,
distinct
pleasure
of
working
in
the
secret
system
for
a
long
time.
We
built
query
over
a
number
of
years.
Query
wound
down
in
january
of
this
year,
when
we
for
two
reasons,
and
the
reasons
that
I
gave
publicly
on
on
the
internet
were
one
data
is
not
code
and
two
computing
competing
with
web.
A
Two
companies
on
web3
on
a
web3
stack
is
hard.
That
should
be.
I
can
be
more
direct
than
that
today.
I've
had
a
little
more
distance,
the
in
the
first,
the
top
line.
Here
we
really,
it's
really
important.
I
think,
as
a
founder
to
like
actually
acknowledge
look
at
the
end
of
the
day.
A
The
reason
query
failed
was
we
didn't
achieve
exponential
growth
right
like
we
did
not
build
a
great
startup
that
that
just
like
had
insatiable
demand,
I'm
okay
with
that,
like
I
don't
but
like
I
mean
the
next
point,
which
is
spicy
for
this
room
that
we'll
talk
about
but
like
they
need
to
go
in
that
order
right
we're
talking
about
ipfs,
we
chose
to
use
ipfs,
we
chose
to
be
as
part
of
this
community.
We
chose
to
build
on
top
of
it,
like
those
are
all
choices
that
we
actively
made.
A
So
this
is
not
to
foist
blame
on
anybody
right
and
it's
much
more
about
like
I,
I
sleep
perfectly
well,
knowing
that,
like
hey,
I
went
out
to
build
a
startup,
something
like
95
of
startups
fail.
Something
like
95
of
statistics
are
made
up
on
the
spot,
but,
like
you
know,
I'm
I'm
comfortable
with
that.
A
The
second
point,
though,
is
obviously
gonna,
be
the
thing
that
we're
gonna
focus
on
here,
which
is
ipfs
sold
as
a
bill
of
goods
that
it
could
not
deliver
on,
which
is
in
many
ways,
true-
and
I
want
to
get
into
some
details
on
that.
A
I
think
the
biggest
thing
that
is
actually
better
expressed
in
this
first
point
is
competing
against
web
2
on
web3
stack
is
hard.
This
idea
that
what
actually
happened
in
practice
for
us
was
we
set
out
to
build
a
thing
that
provided
a
benefit
to
a
set
of
real
world
users,
trying
to
do
a
thing
which
was
hey
we
want
to.
A
A
Sometimes
it
takes
you
six
learners
to
learn
six
years
to
learn
a
really
simple
lesson,
but
in
the
past,
in
the
future,
when
we
step
forward
I'm
working
on
a
new
project,
because
I've
spent
six
years
building
on
top
of
ipfs-
and
I
know
what
I
want
out
of
ipfs
like
into
a
t
and
but
along
the
way
we,
the
the
sort
of
way
this
played
out
in
over
the
years
was
we
got
ipvs
to
work
out.
The
first
version
of
query
talked
to
the
ipvs
daemon
via
the
http
api.
A
We
could
not
get
query
peers
to
stay
connected
to
each
other,
so
we
brought
ipfs
the
go
library.
We
wrote
our
software
our
source
code
in,
go.
We
brought
ipfs
in
as
a
library
at
the
time
it
was
never
intended
to
be
a
library,
as
I
understand
it,
some
of
the
ipfs
engineers
were
like.
Why
are
these
people
doing
this?
This
is
not
the
right
way
and
actually
started
bending
to
the
ipfs
as
a
library
use
case
based
on
us
and
others
in
the
ecosystem.
A
Trying
to
do
that,
we
still
had
the
problem
of
like
getting
queer
appearance
connected.
So
we
wrote
our
own
p2p
protocol
to
say:
hey
the
connection
manager
had
just
come
out
when
we
did
this
and
we
said
awesome,
we
will
detect
when
we
connect
to
appear.
We
will
ask
them
if
they
support
the
query
protocol
and
if
they
do,
we
will
add
a
thousand
points
to
their
connection
manager,
value
and
that
will
keep
them
connected,
which
was
like
a
technique
that
oh
great
cases
in
the
room.
A
In
case
you
wrote
that
code,
but
the
and
then
we
got
into
okay.
We
can't
transfer
data
like
we
like.
We.
A
lot
of
our
users
want
git
push
right.
They
want
hey,
make
new
version
of
data,
set,
send
new
version
of
data
set
to
some
other
place,
and
that
needs
to
work
consistently
and
fast
right
and
if
we
think
about
like
an
rsync
style,
particularly
because
query
was
a
version
control
tool,
you
know
that
the
set
of
blocks
that
have
changed
is
not
the
entire
deck.
A
We
do
not
need
to
sync
the
whole
thing
here.
We
should
really
be
saying
something
looks
a
lot
more
like
rsync,
so
we
wrote
in
our
sync
like
protocol
called
dsync,
and
we
basically
took
off
bitswat
and,
like
95
of
all
query.
Dataset
acquisition
was
over
this
dsync
tool
that
just
used
http
and
eventually
car
files
and
manifest
we
put
ipfs
kubo
into
a
desktop
application
and
made
the
desktop
application.
Auto
updating,
because
we
needed
to
ship
updates
to
end
users
fast,
because
we
were
iterating
that
worked
really
well
actually.
A
That
thing
by
default,
put
the
we
decided
to
try
to
figure
out
the
repo
problem,
and
so
we
actually
used
the
ipfs
main
repo
and
then
one
day
folks
jumped
into
our
discord
and
said
people
who
run
both
query
desktop
and
ipfs
companion
are
getting
errors
because
they
can't
open
at
the
same
time,
because
they're
fighting
for
the
repo
lock
and
so
we
went
it,
took
us
seven
months,
eight
months
and
we
moved
we
migrated
out
of
that.
A
So
we
took
the
we
took
and
moved
into
our
own
ipfs
repository
moving
all
the
data
there,
so
the
user's
locked
machine
for
their
experience
would
have
been.
You
can
now
run
both
if
you
want
and
the
data
will
not
cross,
but
you
now
lose.
We
sort
of
felt
like
which
was
being
the
right
citizen
of
an
ipfs
ecosystem.
Do
you
read
from
that?
Canonical
data
store,
or
do
you
create
your
own?
We
were
when
we
were
told
to
create
our
own.
A
It
took
us
eight
months,
and
this
is
what
I
mean
by
competing
with
the
web3
stack
against
web
2..
We
got
smoked
in
the
market
like
again
we're
building
a
product
that
is
supposed
to
serve
customers.
Our
customers
for
those
five
years
are
screaming
at
us.
Access
control
on
data
sets,
and
we
had.
We
were
busy
trying
to
figure
out
how
to
get
data
to
move
from
a
to
b.
We
were
busy
trying
to
figure
out
how
to
do
just
stay
connected
to
each
other.
Please
we
were
trying
to
figure
out
like
okay.
A
I
think
that
the
reason
that
data
sets
there's
no
github
for
data
hasn't
taken
off
is
the
scale
of
costs
for
the
cloud
service
scales
completely
differently,
because
users
are
being
encouraged
to
add
data,
and
so
we
can
use
ipfs
to
compensate
for
that
which
I'm
implicitly
assuming
that
ipfs
has
solved
the
data
availability
problem
which
it
hasn't
and
never
claimed
to,
but
we
at
least
thought
that
we'd
get
a
better
like
transmission
rate,
or
we
could
start
to
offload
some
of
the
traffic
onto
the
network.
We
not
only
did
we
never
get
there.
A
This
is
the
question:
why
did
we
build
on
top
of
ipfs?
What
tangible
benefit
did
we
get
from
using
ipfs
that
we
couldn't
have
gained
without
it?
In
our
view,
we
really
like
we
fully
drink,
drink,
drank,
drunk
drink
still
drink.
The
content
addressing
kool-aid
like
I
think
that
content
addressing
is
a
fundamental
like
primitive,
that
I
want
to
see
proliferate,
and
it
is
one
of
the
reasons
why
I'm
around
here
but
again
stuff.
A
We
had
to
build
ourselves,
like
our
users,
wanted
collaboration
like
there's
this
tool
that
we
looked
at
all
the
time
called
deep
note
and
they
just
killed
us.
They
had
live
jupiter
notebooks
and
we
were
they
just
watched.
It
was
just
like
watching
them
every
six
weeks.
Launching
these
amazing
features,
and
it
was
just
like
oh
man,
that
would
be
cool.
A
And,
like
you
know,
I
I
was
talking
with
dust
mop
who's
here.
We've
worked
together
on
this
project
in
case
you
was
also
here.
We
worked
together
on
this
for
years.
We
wanted
like
concrete
examples
of
stuff
that
we
just
really
wanted.
That
was
like
really
basic
was
like
just
feedback
from
the
data
store,
so
the
user
experience
for
us
was
a
user
would
drop.
Usually
you
know
a
minimum
200
megabyte,
sometimes
10
gigabyte
file
csv
file
over
a
query
desktop,
which
would
be
under
the
hood
ips
ad.
A
We
refactored
our
ad
pipeline
two
or
three
times
to
turn
it
into
a
parallelizable
like
just
transparent
stream
through
to
the
ad
process,
and
so
eventually
we
were
finally
to
the
point.
We
were
just
blocked
on
hashing,
but
like
we
didn't,
we
had
to
build
our
own
progress
bars.
We
had
to
build
our
own
hooks
into
that
to
show
this
is
how
far
you
are
in
the
ingest
process,
which
did
not
come
to
us
for
free
and
so
yeah,
and
so
this
is
it's.
This
all
sounds
really
ranty
but
like.
A
I
think
this
is
we're
talking
about
applications
on
wpfs,
and
so
I
want
to
transition
to
stuff
that
might
sound
spicy,
but
like
we'll
just
we
just
might
as
well
get
into
it.
This
is,
I
think,
a
strong
view
that
we've
arrived
at
and
so
to
be
clear.
I've
dropped
down
a
level.
My
our
goal
with
number
zero
is
to
make
the
next
query
founder
have
a
better
time
like
that's.
A
Why
I'm
here,
and
I
think
one
of
the
things
that
for
us
is
that
I'm
just
gonna
put
this
view
out
here
and
say
like
hey.
What
do
we
think
about
this?
I
don't.
I
don't
know
that.
I
believe
this
yet
but
like
I
want
to
experiment
with
this
viewpoint
and
see
what
you
all
think
about
it.
A
I
think
this
idea
that
just
unix
fs
is
the
killer
app
of
ipfs,
like
the
fact
that
it's
like
a
file
system
is
a
really
solid
abstraction
for
data
layout.
There's
no
block
limit,
you
can
put
a
file
into
unix
fs
and
from
the
user
adding
perspective,
I
can
put
a
10
gig
file
there.
I
can
put
a
32
terabyte
file
on
there.
It's
cool
right.
It's
going
to
work.
I
have
files
and
directories.
It's
a
really
straightforward
way
for
me
to
understand
how
to
lay
out
data.
I
don't
I've.
A
This
is
an
even
stronger
view
from
the
application
space.
I
have
to
be
totally
honest
that
ipld
is
actually
detrimental
application
developer
velocity.
I
think
that
and
the
the
problem
here
is
like
when
viewed
through
the
lens
of
like
I
need
more
users
or
I'm
going
to
die.
We
I
feel
he
provided
us
very
little
benefit
and
actually
like
in
hindsight
it
was
a
total
time
sink
that
I,
as
a
ceo,
was
a
mistake
to
like
invest
time
in
that,
because
it
provided
no
benefits.
A
To
my
end
users
that
yeah,
which
is
to
get
to
the
data
interop
stuff
users
and
data.
Oh
it's
you
being
in
this
in
this
sentence,
is
the
application.
Developer
needs
users
and
data
in
enough
of
those.
B
I
didn't
want
to
let
you
off.
Why
do
you
feel
like
it
was
an
sdk
issue?
Do
you
feel
like
there
was
something
wrong
with
the
schema.
A
A
Yeah,
it
was
the
complexity
of
it
I
think,
and
I'll
I'll
get
into
a
little
more
of
what
I
think
might
be
a
concrete
solution,
but,
like
generally,
it's
just
like
like
what
like
what
am
I
getting
as
an
application
developer
like
what
am
I
actually
concretely
getting?
Am
I
getting
a
like
better
sync?
Am
I
getting
faster
thing
like,
I
think
what
I'm
getting
is?
Do
I
have
let's,
let's
get
even
spicier.
D
A
But
like
no,
but
I
think
the
second
line
right,
the
the
belief
that
we
can
teach
our
applications
to
reverse
application
data
without
human
intervention,
like
is,
is,
I
think,
that's
an
admirable
thing,
but
like
as
an
application
developer.
Actually
I
should
phrase
this
more
specifically
as
someone
running
a
startup
right,
like
as
someone
who's
trying
to
figure
out
a
sustainable
business
like
looking
at
it
through
that
lens,
or
is
it
like
what
is
ipl
to
get
us,
because
we
all
want
interoperable
data?
I.
C
E
C
C
C
A
Yeah,
just
as
a
point
of
comparison
like
we
wrote
when
we
switched
to
this,
like
we
wrote
the
queer
so
query
is
a
data
set
version
control
tool
like
in
theory.
We
should
be
like
the
golden
poster
child
for
linked
data
right
like
it's,
it's
data
catalog
like
you,
should
like.
We
and
we've
really
had
aspirations
of
like.
A
Wouldn't
it
be
amazing
to
be
able
to
have
cells
that
reference
other
cells
inside
of
csv
files
like
what,
if
we
introduce
the
cid
data
types
like
column
type
inside
of
a
csv
file
that
lets
you,
you
know,
connect
very,
very,
very
granularly
to
other
data
sets
and
like
that
was
for
us
was
like
one
of
the
big
draws
of
ipl.
He
was
like.
Oh,
I
think
we're
going
to
need
something
that
looks
like
ipld
for
that.
A
A
That
looks
a
lot
like
package.json
in
the
npm
universe
and
that
contains
a
json
map
of
keys
that
all
whose
values
are
all
cids
and
that's
how
query
works.
It
opens
up
dataset.json
and
deserializes
that
and
it
really
solves
the
issues
where
one
happened
to
deal
with
this
whole
data
molecules
and
crap,
and
also
have
to
deal
with
the
fact
that
tooling
sucks.
But.
A
C
Like
the
right
way,
and
that
would
have
been
sort
of
like
I'll
learn
how
I
believe
to
design
the
data
so
like
it
automatically
trumps
the
data
and
cementing
it.
E
So
I
think
it's
actually
excellently
made
to
make
the
point,
so
the
fishing
team
met.
Query
were
like
this
is
amazing.
This
is
great
and
we're
like
and
through
query.
We
actually
finally
found
connections
into
the
ipfs
ecosystem,
because
we
thought
still
think
we
don't
know
what
we're
doing.
Surely
we
must
be
holding
this
wrong,
it
can't
just
be
the
system,
it
must
be
us
and
then
and
then
brendan's
like
psy.
E
A
E
E
A
Oh,
I
did
do
we
wanted.
Do
you
ever
thought.
B
Conversation
there
is
related,
like
you
said,
or
they'll.
This
ipld
is
detrimental
to
application
developers,
which
may
be
true,
but
I
definitely
think
it's
true.
That's
like
it's
detrimental
to
product
management
like
product
developers.
A
A
A
So
I
think
the
first
thing
to
me
is
like
I
I
don't
I
don't
this
like,
I
sometimes
sort
of
slag
on
ipld
I
in
my
head,
I'm
like.
Finally,
I
feel
like
I'm
arriving
in
a
place
that
it's
a
different
use
case
like
ipd,
is
like
much
more
when
you
there
are
you
just.
There
are
absolutely
requirements
where
you
need
to
traverse
across
linked
data,
and
you
need
really
really
finely
shaped
data
models
like
I
do
not.
A
Yeah-
and
I
think
it
should
be
that's
what
I
and
I
personally
would
like
to
advocate
for
in
my
head-
there's
like
this
non-existent,
but
secondary
product
like
ipdb.
That
is
like
an
iplt
centric
thing
that
is
really
focused
on
more
database
looking
stuff
and
less
file
system
looking
stuff,
but
keeping
our
emphasis
on
the
fastest
and
looking
stuff
for
a
second.
These
are
the
things
that
I
think,
I
would
say
are
like
commonly
occurring
stuff
that
people
want
out
of
the
ecosystem.
A
We
all
need
access
control.
We
all
need
I'm
going
to
talk
to
you
about
arbitrary
metadata
in
a
second
versioning,
not
everybody
needs
but
like
it's
pretty
dope,
it's
good
to
have,
and
we
need
some
type
of
mutability
like
an
aiming
system
that
that
is
robust
and
works.
My
evidence
for
this
chris
and
I
did
not
coordinate
on
this
before
I
took
a
photo
of
his
slide
and
put
it
in
mine.
B
A
Can
we
in
my
head,
like?
I
think
I
think
that
I'm
starting
to
realize
that
there's
some
really
nice
properties
about
unix
fs,
specifically
the
there's
a
link
section
and
there's
a
data
section
in
the
protobuf.
I
think
that's
actually
good
for
a
lot
of
reasons.
The
more
we
talk
about
it
at
number,
zero,
the
more
that
seems
like
a
good
thing.
I
I'm
not
totally
sold
on
this.
A
I
think
that,
like
winifest
is
done
like
has
correctly
identified
these
four
things
that
a
lot
of
people
need
and
like
when
you
say,
access
control.
You
need
encryption
right.
So
that's
like
you
in
our
space.
So
that's
that's.
Just
like
a
substrate
requirement
or
sub
the
requirement
of
that
when
fs
has
arbitrary
metadata
built
into
it,
where
this
has
merging
building
into
it.
A
I
really
strongly
think
that
all
these
things
need
to
be
optional
and
that
some
of
the
challenges
that
we've
been
thinking
about
a
bunch
are
like
when
we
started
trying
to
use.
So
we
wrote
a
semi-functioning
implementation
of
winfs
and
like
intended
to
switch
to
that
for
query
things
that
we
ran
into
were
immediately
like.
Oh,
when
we
started
to
like
write
the
mock
code,
that,
like
quick
query
on
top
of
the
new
winfs
stuff,
was
like.
Oh,
we
got
to
plug
like
application
specific
merge
semantics
into.
A
How
do
we
actually
merge
two
files,
because,
as
soon
as
you
introduce
versioning,
you
get
branching
as
soon
as
you
get
branching,
you
wanna
put
those
things
back
together
and
if
you
wanna
put
those
things
back
together
and
you
just
try
to
let
a
computer
magically,
do
it
for
you.
It's
not
gonna
end
well
for
the
perception
of
the
end
user,
and
so
there
is
like
this
is
really
hard,
and
then
I
do
think
those.
I
think
it
should
be
really
obtainable
like
not
everybody
wants
versioning,
not
everybody
wants
encryption
and
privacy
like.