►
Description
Compute + IPFS - presented by @evgenyponomarev at IPFS þing 2022 - Building Apps on IPFS - https://2022.ipfs-thing.io
A
I'll
be
quite
short,
with
my
talk,
the
the
whole
idea
that
you
know
there
is
a
huge
amount
of
of
approaches
in
terms
of
compute
on
top
of
decentralized
data,
and
I
think
what
we
put
most
attention
to
is.
A
We
started
from
this
like
okay,
we
have
ipfs
as
a
great
decentralization
for
data,
and
the
first
idea
is
now
we
don't
need
any
backends
like
we
don't
need
clouds
anymore
right,
like
we
can
build
everything
on
front-end,
but
then
we
have
all
this
complexity
on
the
front
end
and
we
basically
start
thinking.
Okay.
A
What
can
we
really
move
somewhere
to
performance
nodes
on
the
back
end
and
make
sure
that
you
know
we
have
data
indexing,
caching
and
some
apis
and
stuff,
because
we
cannot
really
have
enough
performance
to
have
decent
ux
on
the
front
end,
and
we
were
thinking
a
lot
about
this
topic,
and
the
whole
idea
here
is
to
have
the
as
universal
as
possible,
runtime
that
potentially
like
as
cool
as
lamb
does
and
like
automatically
scalable.
A
So
you
can
just
put
any
code
there
and
like
it's
magically
works
and
you
don't
need
to
think
about
it
and
it
can
work
on
any
device
so
and
also
like
it's
open
from
the
nodes
perspective.
So
like
it's
the
same
as
anyone
can
run
the
ipfs
node,
anyone
can
should
be
run.
Fluence
node,
who
would
do
this
computation,
and
I
know
I
have
like
these
slides.
A
I
have
here-
they
are
like
quite
high
level
and
pretty
obvious
stuff,
but
we
kind
of
think
about
a
lot
of
this
platform
risk
and
the
composability
of
software
in
general,
like
a
web
2
problem.
If
I
have
api
and-
and
it
runs
on
some
server
and
probably
like
the
data-
probably
sits
also
in
centralized
database,
but
even
if
it
doesn't
sit
in
centralized
database,
someone
still
runs
api
on
some
server.
A
A
It's
kind
of
like
this,
this
slides
from
from
blockchain
context,
but
like
a
lot
of
companies
in
blockchain
space
right
now
they
take
this
open
database
of
blockchain
data
and
index
it
and
and
kind
of
convert
it
into
some
custom,
queryable
databases
and
package
it
as
apis
like
nft
apis
like
openc,
like
some
wallet
apis
and
stuff
like
that,
and
then
other
people,
like
they
kind
of
try
to
bring
other
people
to
build
on
top
of
their
http
web
to
apis,
to
have
better
products
for
users
and
the
problem
is
like.
A
The
data
is
decentralized.
It's
there
it's
on
the
blockchain
nodes,
but
this
this
apis
are
centralized
and
no
one
can
like
rehost
them
or
like
rerun
them
like,
and
and
basically
we
get
back
to
at
this
layer
we
get
back
to
web
to
world.
A
We
don't
we
don't
solve
the
the
platform
risk
from
this
perspective,
so
we
are
trying
to
kind
of
solve
this
issue
at
the
highest
level
and
we
think
that
there
is
a
like
there
should
be
a
network
that
just
allows
you
to
deploy
any
computation
run
it
and
to
have
like.
If
you
need
verification
for
the
computation,
you
should
be
able
to
do
it.
If
you
don't
need,
you
should
be
able
to
avoid
it.
A
So
it's
sort
of
like
a
hybrid
trust
model
for
the
computation,
and
it
should
be
like
much
more
relaxed
than
you
have
than
constraints
you
have
on
chain.
So
this
sound
like
you,
can
build
anything
on
that
for
sure
yeah.
We
want
to
enable
web
to
use
cases.
We
want
to
bring
web
2
use
cases
to
web
3
as
well,
but
what's
important
here
is
we
end
up
having
kind
of
three
things
we
have
the
development
toolset,
which
is
very
specific.
A
In
our
case,
I
I'll
talk
about
it,
so
we
have
the
network
of
nodes
who
anyone
can
can
join
and
and
run
fluence
node
and
like
execute
this.
Whatever
created
with
this
development
stack-
and
there
is
like
the
whole
economics
around
that-
like
incentives
for
for
nodes
to
participate
and
stuff
like
that,
so
two
core
components
of
it
of
the
development
stack
is
the
web
assembly
runtime,
which
is
works
like
sort
of
instead
of
docker.
A
Instead
of
docker,
we
run
everything
in
web
assembly
and
the
reason
to
have
web
assembly
is
not
just
because
you
can
run
it
on
any
device.
But
you
know
if
you
are
the
running
node
and
you
allow
anyone
to
send
a
docker
container
to
you
with
their
program
and
you're
going
to
be
like
the
hosting
provider
like
you
would
need
to
create
additional.
A
You
know
constraints
for
these
docker
containers
not
to
break
your
system
not
to
break
your
machine
and
wasm
has
much
better
resolution,
so
you
can
just
have
it
out
of
the
box
and
it's
kind
of
like
super
easy
to
become
the
hosting
provider.
At
this
sense
and
like
we,
we
have
our
own
runtime,
it's
based
on
wasmar,
it's
pretty
cool.
It
supports,
like
whatever
webassembly
standards
exist.
A
We
we
have
mike
here
but
he's
he
left
now,
but
he
probably
gonna
talk
about
this
on
friday,
if
you're
interested
at
ipfs
and
wasm
track
and
the
second.
The
second
thing
is
aqua
that
we're
also
going
to
have
the
track
about
this
tomorrow.
A
It's
a
language
that,
basically,
you
use
to
implement
the
control
flow
of
your
application.
So
when
you
build
staff
on
fluence,
you
have
the
wasm
modules
as
a
sort
of
docker
like
as
a
microservices
sitting
on
different
nodes,
wherever
you
what
you
deploy
them
and
you
have
the
orchestration
like
business
logic.
On
top
of
these
wasm
containers
implemented
in
aqua
and-
and
you
know
some
some
simple
stupid
analogy
with
web
to
cloud
that
I
have
is
like
you
can
think
of
marine-
is
sort
of
like
lambda
functions.
A
Aqua
is
sort
of
like
workflows
on
top
of
lambda
functions,
but
aqua
is
much
more
performant.
It's
like
not
just
some
jsons
or
configuration
but
like
the
whole
programming
language
that
abstracts
out
a
lot
of
pure
connectivity
and
and
things
like
that-
and
it
looks
like
very
simple,
so
you
like,
if
you
want
to
do
some
map,
reduce
or
like
pluralization,
it's
just
like
few
lines
of
code
and
yeah.
A
Admittedly,
I
think
mitri
showed
this
yesterday
and
what
is
cool
here
is
that
for
basically
every
request
that
happens
on
network,
like
user
clicks,
a
button,
the
aqua
vm
creates
sort
of
you
know
short-living
sub-network
that
executes
this
request.
So,
like
all
these
nodes,
can,
you
know
know
can
discover
each
other
can
know
about.
Each
other.
A
Can
work
together
can
send
like
the
some
function
like
get
price
executed
on
onenote,
and
then
the
results
send
to
to
the
nodes
that
that
calculates
the
average
and
after
the
you
know,
this
script
is
executed,
so
request
ends
to
in
the
second
device.
This
subnetwork
is
is
not
exist
anymore,
but
you
can
also
create
the
you
can
use
aqua
to
program
the
long
living
subnetworks.
If
you
need
the
sub
network
to
exist
for
long
period
of
time
and
like
run
some
scheduled
execution,
so
you
can
also
do
this.
A
So
it's
kind
of
very
similar
to
what
you
have
in
the
cloud
where
you
have
you
know
cloud
functions,
they're
triggered
by
events.
They
read
data
from
some
place.
They
write
data
into
another
place,
but
this
here
you
can
also
manage
the
workflow
of
the
execution,
the
topology
of
the
execution
in
terms
of
network
and
in
the
cloud
you
just
don't
see
it,
you
don't
know
how
it
all
works
inside
they
just
it
works
like
a
black
box,
so
yeah
again
like
some
pictures.
A
So
traditionally
you
have
this
centralized
gateway
that
manages
everything
and
kind
of
reroutes
requests
to
different
microservices
or
orchestrates
business
logic.
Here
you
can
like
really
decouple
business
logic
to
different
nodes
and
yeah.
So
so
this
is
fluence
pure
and
we
mainly
try
to
focus
on
on
compute
and
not
touch.
Data
like
every
fluent
sphere
by
default
comes
with
ipfs
node,
so
you
have
like
native
access
to
ipfs
data,
but
potentially
you
can
plug
anything
like
any
data
source.
A
So
you
can
read
from
any
data
source,
however,
actually
I
I
spoken
to
some
protocol
labs
folks
and
there's
idea
that
you
know
every
day
like
any
data
should
live
in
ipfs,
so
we
we
should
always
read
from
ipfs.
Even
if
it's
like
a
blockchain
data,
it
should
be
first
dumped
into
ipfs
so
like
it
should
be
like
cid,
right
and
and
then
like
by
cid
use
influence
node
by
cidu.
A
You
should
be
able
to
retrieve
any
data,
and
you
know,
do
some
stuff
on
it
and
put
back
to
ipfs
so
like
you
have
inputs
and
outputs
all
as
cids
and
it's
totally
doable,
and
this
is
a
pretty
cool
concept,
but
like
right
now
by
default,
so
you
can
just
plug
any
data
and
yeah.
A
We
have
rust
implementation,
javascript
implementation,
they
a
little
bit
different,
but
almost
the
same
and
yeah
and
and
the
we
have
a
few
more
components
of
it,
because
when
we,
when
we
think
of
of
you,
know
using
this
to
implement
just
re-implement
something
similar
to
traditional
back-ends,
we
started
having
problems
that
we
didn't
have
in
centralized
setup
like
you
know,
nodes,
reputation
and
stuff
like
how.
How
should
I
select
nodes?
Where
should
I
deploy
my
web
assembly
code?
A
If
I,
if
I
don't
know
them
like
if
they
all
the
same
for
me,
because
I
don't
know
any
of
them,
that's
why
we
have,
for
example,
this
trust
graph
thing
which
is
sort
of
web
of
trust
solution.
So
it's
it's
a
distributed
database
of
trust
relationships
between
nodes
on
the
network.
A
So
now,
if
I
run
the
code
like
the
function,
I
should
be
able
to
select
nodes
that
I
trust
the
most
and
and
deploy
it
there
and
execute
there,
because,
because
they're
more
trusted
and
the
graph
there
is,
it
means
that
I
can
basically
query.
A
If
I
you
know,
I
trust
protocol
apps,
and
I
know
that
protocol
apps
run
some
nodes.
There
are
trust
entries
on
the
network
from
protocol
apps
to
particular
node
instances,
so
I
can
discover
these
nodes
and
see
that
I
transitively
trust
can
trust
them,
because
I
trust
this
protocol
up
authority,
but
I
can
subjectively
decide
whichever
authorities,
I
trust.
A
A
A
So
regarding
aqua.
Basically,
because
we
are,
we
are
sort
of
decoupling.
The
control
flow
from
the
execution
and
wasm
aqua
becomes
the
language
to
create
distributed
algorithms,
so
we
can
create,
like
potentially
anything
like
better
kadamlia
like
a
different.
You
know
modifications
of
kadamlia
consensus
notifications
like
whatever,
like
any
any
distributed
algorithms-
and
this
is
what
we
kind
of
we
see
like
for
ipvs.
In
particular,
you
can
just
use
aqua
to
implement
and
re-implement
ipfs
like
parts
of
ipfs
like
basically
slices
of
ipfs.
A
We
can
potentially
be
able
to
create
something
like
bitswap
on
aqua
or
like
something
like
content,
routing
or
indexing
and
stuff
like
like
that,
so
we
kind
of
like
pitching
it,
because
we
believe
that
you
can
in
what
you
can
implement
this
algorithm
once
and
then
reuse
across
different
implementations
in
different
languages
like
go,
ipfs,
rasta,
pfs
like
and
so
on,
and
so
forth,
yeah
and
a
little
bit
on
on
computational
verification.
As
I
said,
the
whole
idea
was
that
you
know
we
are
not.
A
We
don't
want
to
create
a
decentralized
network
that
can
compute
stuff
and
we
don't
want
to
force
the
consensus
there
right,
but
if
it's
decentralized
and
anyone
can
join,
anyone
can
provide
any
fake
results
to
computations
like
how
do
you
deal
with
so
there
are
basically
only
several
ways
to
deal
with
it
like
first,
you
should
trust
node
and
then
for
this
to
select
the
most
trusted
node.
We
have
trust
graph.
A
Second,
you
can
apply
consensus
partially
to
a
piece
of
computation
that,
where
you
really
really
need
consensus-
and
you
can-
you
know-
write
the
consensus
algorithm
in
aqua
and
apply
it
to
the
the
wasm
where
you
want
to
have
consensus
like
basically,
you
can
implement
something
very
simpler,
like
collecting
signatures
for
combination
result
or
you
can
have
something
more
complex
like
tender,
mint
or
something,
and
the
third
thing
is
basically
some
kind
of
ziki
proofs,
but
they
they
really
really
depend
on
the
use
case.
They
it's
not
really.
A
I
don't
know
if
it's,
if
it's
possible
at
all,
to
have
ziki
proof
for
arbitrary
computation,
that
you
would
be
able
to
create
and
verify
at
a
reasonable
amount
of
time,
but
we
don't
have
them
yet
we
probably
gonna,
have
it
oh
and
also
there
is
a
force
way.
Some
people
like
to
use
te
like
trusted,
compute
environments,
and
you
should
be
able
to
discover
nodes
that
provide
it
or
like
run
fluence
with
support
of
td.
A
But
the
problem,
my
personal
concern
about
that
is
that
like
intel's
jax
was
hacked
a
few
times
and
there
was
like
a
silent
attacks
on
it,
so
people
created
fake
keys,
so
they
could
have
like
really
access
to
the
computation
that
happens
because
they
didn't
have
the
dt
they
they
pretended
to
have
it
so
yeah,
and
you
know
the
network
is,
is
heterogeneous.
Basically
every
fluid
zone
is
different.
A
Every
fluency
node
has
different
amount
of
wasm,
can
execute
different
amount
of
wasms,
so
you
can
imagine
the
marketplace
of
of
services
or
kind
of
back
ends
of
applications
or
like
a
pieces
of
back
ends
of
applications.
A
Yeah,
and
I
think
the
rest
is,
is
less
important,
but
one
cool
thing
here
is
because,
like
imagine
that
we
run
backends
of
applications
in
such
a
network-
and
we
talked
in
initially
like
in
the
beginning
about
api
kind
of
dependency
and
platform
risk,
so
here
the
same
way
as
in
blockchain,
because
the
author
of
the
code
doesn't
runs
the
code
on
the
network,
like
the
the
hosting
provider
and
the
author
of
the
code
are
two
different
people
or
companies.
A
Now
you
can,
you
know,
have
the
sort
of
demand-driven
availability
of
the
back-end
components.
So
if
I
am
as
a
application
developer,
I
create
the
new
version
of
the
application
and
it's
you
know
goes
against
users,
freedom
or
users,
privacy
and
users.
Don't
like
it.
A
The
hosts
and
providers
may
just
not
update
to
it,
so
they
basically
can
have
your
application
back-end
forked
into
two
versions
that
would
exist
at
the
same
time
and
like
theoretically,
users
can
choose
whatever
version
they
use.
It's
a
lot
more
complexity,
but
the
the
idea
here
is
same
as
on
the
blockchain.
You
can
once
you
deployed
stuff,
it's
there
like
forever.
A
If
you
do
it
properly
and
then
you
basically
deploy
every
time
you
deploy
the
new
version
of
your
smart
contract
and
they
coexist
and
users
decide
which
is
better
yeah
and
the
economics
is
not
yet
there
so
not
going
to
talk
about
this,
and
you
can
check
out
the
network
our
documentation
and
come
to
our
sessions
tomorrow.
A
Fair
to
say
that,
right
now
you
and
it's
interesting
that
you
are
essentially
treating
ipfs
just
as
a
file
system
for
now
yeah
yeah
for
now
well,
a
little
bit
more.
So
it's
a
kind
of
file
system,
but
also,
for
example,
we
use
ipfs
natively
to
deploy
the
wasms
to
remote
nodes.
So,
like
you
know,
yeah,
so,
like
you,
you
upload
it.
A
You
always
upload
it
by
default
to
ipfs
and
then
the
remote
node
retrieves
it
by
by
cd
yeah
yeah,
exactly
exactly
yeah,
and
you
can
say
that
this
is
like
sort
of
functional
address
function,
addressability,
but
it's
it's
a
complex,
also
question
yeah
awesome!
Thank
you.
Okay!
Thank
you.