►
From YouTube: Fluence EthDenver Workshop
Description
00:00 Intro
0:50 What is Fluence?
1:05 Peer-to-peer. The next generation of internet computing (Web1.0, Web2.0, Web 3.0)
6:42 Decentralize everything with p2p network. Storage, Identity,Networking,Computing
10:27 Decentralized computing
12:30 Fluence overview
13:33 Fluence in a nutshell. P2P network diagram
19:40 What is Aqua?
22:25 Foundations: The Particle. Process explanation
26:23 Tooling In A Nutshell
26:42 Main reference node. Rust SDK
30:00 JS implementation. Fluence JS
31:52 What is Aqua?
32:35 Aqua. Diagram and code
38:20 Code demo
45:30 Q&A
54:10 Code demo
1:06:57 Fluence+IPFS
1:07:03 Fluence+ Ceramic
1:07:39 Additional Building Blocks
1:08:08 Bounties
1:09:35 Links
https://fluence.network/
https://twitter.com/fluence_project
https://github.com/fluencelabs/aqua
https://github.com/fluencelabs/aquavm
https://github.com/fluencelabs/marine/tree/master/examples/greeting
https://fluencenetwork.notion.site/fluencenetwork/Fluence-Developer-Community-Calls-2733beddb3ff4e4986c4fcc830fc796d
https://github.com/fluencelabs/marine-rs-sdk
https://t.me/fluencedev
https://discord.com/invite/5qSnPZKh7u
Speaker Bernhard Borges
Fluence Bounties at ETHDenver https://www.ethdenver.com/bounties/fluence-labs
Fluence Hacker Guide https://www.notion.so/fluencenetwork/How-to-hack-on-Fluence-97e20ba47ef04df2bfd0c234ee90537d
Apply to participate https://www.ethdenver.com/apply
The deadline for submissions is March 20, 2022
A
All
right
welcome
everybody.
Welcome
to
east
denver
22,
it's
gonna
be
great
online
and
offline.
It's
gonna
be
interesting
to
see,
but
I
know
the
in
person.
Turnout
is
supposed
to
be
huge
and
I
hope
the
virtual
one
as
well
as
well
as
part
of
east
denver.
We
have
a
great
great
hackathon
going
on
and
fluence
is
one
of
the
sponsors
with
an
additional
fifteen
thousand
dollars
in
bounties,
and
today
we
gonna
go
through
a
workshop
to
help
you
monetize
those
rewards
into
your
own
wallet.
A
A
A
So
if
you
go
back
actually
you
could
go
into
the
pre-web
era.
You
had
mainframes
that
actually
already
had
built-in
shared
capability
resource
management
terminals
were
attached
directly
to
the
mainframe
or
on
private
networks.
Throughout
a
building,
for
example,
and
as
we
moved
into
the
internet
era,
we
got
mainframes,
get
smaller,
cheaper
and
desktop
scale.
A
The
downside
of
that
development
was
on
multiple
fronts.
One
you
had
to
maintain
an
entire
department
that
did
nothing
but
basically
manage
operate
and
provide
infrastructure
and
demand
was
applied
fundamentally
a
zombie.
So
if
you
had
an
oracle
database
and
it
needed
an
oracle
administrator
which
believe
it
or
not
in
the
1990s
and
2000s
was
the
highest
paid,
the
I.t
job,
you
could
have
it
didn't
matter
how
many
people
actually
were
using
the
oracle
database.
A
You
were
stuck
hiring
at
least
one
person
same
for
hardware,
hard
disks,
cpu
ram,
so
with
the
advances
on
the
internet,
bigger
bandwidth,
more
availability,
more
endpoints,
fiber,
coaxial
and
and
networking
within
not
just
the
big
cities,
but
some
of
the
suburbs
and
eventually,
hopefully
rural
you
could
make
a
new
value
proposition
and
the
value
proposition
basically
was
to
to
virtualize
it
departments
into
the.
What
is
now
called
the
cloud
and
you
have
the
amazons,
the
googles
and
the
microsoft's
of
the
world.
A
A
A
And
while
it's
easy
to
enter
into
a
cloud
provider
stack,
it's
very,
very
difficult
to
exit
it,
so
their
exit
barriers
are
very,
very
high
and
it's
actually
very
difficult
to
attain
failover
availability
by
spreading
across
the
major
cloud
providers.
It's
it's
not
entirely
easy,
so
you
can't
just
take
your
amazon
rds,
for
example,
and
share
it
for
availability
or
failover
across
google
or
azure
without
any
major
problems.
A
I
think,
like
five
ten
years
ago,
amazon
was
really
really
good
at
providing
five
nines,
and
if
you
look
at
the
outages
that
some
of
them
are
direct
and
some
of
them
are
indirect
through
dns
related
issues
targeting
particularly
the
major
three
cloud
providers.
Availability
has
gone
down
significantly.
It's
it's!
It's
it's
starting
to
be
a
significant
problem
for
our
cloud
customers
on
top
of
it
through
the
business
agreements
we
have
with
those
providers.
I
mean
those
are
private
businesses.
A
So
what's
the
solution,
the
solution
to
centralized
provisioning
of
virtualized
environments
and
infrastructure
is
period-appear,
and
web
3.0
through
the
early
guns
in
blockchain,
demonstrated
that
very
effectively
that
with
peer-to-peer
you
can
massively
decentralize.
You
can
in
include,
if
you
want
trustlessness
in
your
in
your
business
logic
you
don't
have
to,
but
you
can
and
you
get
a
very,
very
nice
availability
and
failover
model,
not
necessarily
scaling
modeling
the
blockchain
side,
but
definitely
availability
and
failover.
A
However,
if
you
look
at
the
naps
model,
for
example,
or
even
the
use
of
lib
of
peer-to-peer
in
most
blockchains,
those
are
the
applications
so
napster.
The
data
sharing
was
the
application.
You
couldn't
just
go
and
host
an
a
decentralized
database
on
app
store.
It
just
wasn't
set
up
for
that
and
same
in
blockchain.
A
A
Avoid
send
or
or
improve
censorship
resistance
in
all
those
models,
including
the
access
to
business
logic
on
the
blockchain
node,
for
example,
you
use
ip
addresses.
Fundamentally,
that's
your
you
use
location
addressability
to
access
your
resources,
and
that
is
the
main
sticking
point
in
terms
of
censorship
and
moderation.
You
can,
you
can
tie
it
to
ip
addresses
and
that's
how
you
can
shut
down
entire
subsets
of
the
internet
through
very
clever
dns
manipulations
in
in
the
new
peer-to-peer
networks.
A
However,
that's
not
as
easily
accomplished
for
the
reason
that
a
peer
id,
which
is
the
address
address
of
a
node
in
the
network,
is
independent
of
the
ip
address,
so
the
peer
id
in
lib
p2p
networks
like
we
like
fluence
uses.
It
is
the
hash
of
the
public
key
of
the
of
the
node
provider
of
the
node.
If
you
want
and
it's
independent
from
the
ip
address
so
within
reason,
it
still
needs
to
be
discoverable
and
the
change
of
information
has
to
be
able
to
permeate
through
the
network.
B
A
So
going
back
to
the
gap
in
the
offerings
in
p2p
networks,
decentralized,
p2p
networks
is
on
the
compute
side,
and
this
is
where
fluence
comes
in.
So
if
you
look
decentralized
computing
today,
you
have
smart
contracts,
you
have
decentralized
hardware,
marketplaces
and
what's
missing
in
our
opinion
and
this,
what
we're
providing
is
general
purpose
peer-to-peer
computing.
So
any
computation,
as
I
said
like
an
in
napster,
for
example,
you
couldn't
just
post
or
or
deploy
some
application
on
app
store.
It
had
to
be
data
sharing.
That
was
it.
A
There
was
no
other
way
to
do
it
and
we
wanted
permissionless.
So
anybody
can
join
the
network
open
and
as
long
as
your
node
is
capable
to
interact
with
the
other
nodes
in
the
network,
you
can
join
it's
it's.
It's
that's
exactly
what
we
want
and
we
want
our
function.
Our
services
function,
addressable
that
goes
back
to
the
censorship
resistance.
A
The
way
you
address
a
service
or
function,
you
can
think
of
a
service
at
the
low
level
as
a
as
a
lambda
function.
For
example,
it's
not
my
ip
address,
it's
done
by
pid
and
service
id.
So
most
simplistically.
You
can
imagine
this
table
where
you
have
the
peer
id.
That's
where
you're
routed
in
your
application
in
your
workflow
and
then
on
that
peer,
some
looking
app
happens
and
you
find
the
service
id
which
now
gives
you
your
service,
your
function.
A
Basically
and
then,
within
the
namespace
of
that
service,
you
can
execute
any
one
of
the
called
functions
and
that's
entirely
bypasses
the
ip
issue
and
dns
type
censorship,
and
we
wanted
to
kick
it
up,
one
more
notch
and
we
wanted
a
universal
runtime.
So
we
wanted
to
have
a
high
degree
of
portability
for
service
and
application
developers,
and
for
that
we
use
webassembly.
A
There
aren't
all
right,
then,
let's
dig
in
so,
as
I
said,
fluence
is
a
decentralized
provides,
decentralized
compute.
So
as
a
developer
just
to
to
set
the
stage
you
are
required
to
quote
unquote,
bring
your
own
store,
your
storage.
It
could
be
if
you,
if
you
stick
with
the
web
3
paradigm
and
you
want
to
be
centralized
peer-to-peer,
obviously,
protocols,
labs,
ipfs
and
the
foghorn
any
of
the
really
cool
building
applications
that
are
building
on
them,
like
ceramic
textile,
etc,
are
all
perfectly
good
candidates
to
to
work
on
that.
A
You
can
also
decentralize
actually
some
of
your
rdbs's
or
no
sql
databases,
but
it's
going
to
take
a
little
more
effort,
and
so
we
have
this
protocol
and,
according
to
we
also
have
a
network.
As
I
said,
the
network
is
open,
so
we
bootstrap
the
network,
but
it's
not
our
network.
Anybody
can
join.
Anybody
can
leave
at
any
given
time,
and
there
is
no
centralization
in
this
in
this
entire.
A
Look
at
the
green
round
things
here
as
a
peer
clients,
for
example,
it
could
be
a
browser,
iot
device
edge
device
doesn't
really
matter
just
think
of
it
as
a
thin
client,
and
then
the
blue
parts
are
nodes
in
the
fluence
peer-to-peer
network.
As
again
as
I
said
before,
it's
an
open,
permissionless
protocol.
So
it's
not
fluence's
network.
It's
just
we're
bootstrapping
and
facilitating
it
at
this
point,
and
then
we
got
a
few
outside
networks.
A
A
You
could
have
many
many
peers
that
are
not
publicly
accessible.
It
could
be
behind
a
nat,
they
could
be
whitelisted
whatever
the
relay
would
be
in
front
of
those
where
in
front
of
course,
is
topologically
speaking
not
entirely
correct,
but
you
think
of
it
physically
in
front
of
those
private
nodes,
and
that's
where
you
get
the
access.
A
You
also
need
a
relay
for
a
browser,
for
example,
not
all
clients
or
for
most
clients,
they're,
not
fully
connected
full-time
connected
to
the
network,
and
that's
where
you
want
the
relay
other
than
that
a
relay
hack
can
provide
the
same
functionality
as
any
other
node
in
the
network
or
peer
in
a
network,
so
it
can
host
webassembly
services
and
you
can
call
them
and
execute
them.
It
just
also
helps
you
to
access
otherwise
non-accessible
nodes.
A
So
if
you
I
don't
know,
let's
just
look
at
our
workflow
here
and
you
can
think
of
you
have
a.
I
don't
know
a
document,
a
document
you
want
to
spell
check
and
you
want
to
check
for
markup
to
inject
emojis.
So
our
service
here
would
be
the
the
spell
checker
and
our
service
here
would
be
the
emoji
injector
and
when
this
all
is
done,
we
want
to
deliver
that
end.
Result
that
spell
check
and
emoji
upgraded
injected
document
to
the
client
down
here.
A
So
sorry,
this
could
be
a
browser
up
here
and
we
type
in
our
document
and
then
we
specify
with
aqua,
which
is
our
programming
language,
we'll
get
to
this
in
a
minute
and
what
to
do
so?
We
get
the
document
we
find
a
relay.
Now
we
find
our
spelling
service
from
our
spelling
service.
We
go
to
our
emoji
injector
and
we
may
not
have
written
that
injector
code
entirely
or
that
spell
checking
code.
It
could
have
been
an
already
existing
api
microservices
which
we
could
wrap
into
the
fluence
service.
So
this
is
critical.
A
All
the
your
investment
in
existing
code
and
and
apis
doesn't
have
to
be
thrown
out.
At
this
point
you
could
just
write
an
adapter
and
then
wrap
whatever
you
have
and
bring
it
back
into
the
network.
So
there
is,
there
is
a
nice
nice
continuum
that
allows
you
to
to
reuse
what
you
have
and
improve
on
what
you
want
and
for
certain
new
services
particular
ones
that
are
web
3.
That
should
be
web
3
compliant.
A
You
should
start
writing.
New
services
in
webassembly
spell
check
emoji
injector,
which
could
be
all
calling
from
there,
and
then
you
finally
deliver
the
document.
We
could
do
this
sequentially,
like
I
just
pointed
out,
or
we
could
do
this
in
parallel.
So
if,
if
our
emoji
injector
literally
is
independent
of
a
spell
checker,
which
may
or
may
not
be
the
case
depending
on
how
bad
we
are
with
our
punctuation
and
in
our
punctuation.
A
Colons
and
plus
sign
misspellings.
Then
you
probably
want
to
have
the
injector
sequentially.
If
not,
you
can
just
go
in
parallel.
You
could
call
that
service
and
that
service
in
peril
then
converge
it,
which
is
one
of
the
advantages
in
aqua,
because
we
have
eventual
consistency
and
data
comes
out
the
way
it's
supposed
to
be,
even
if
it's
done
in
parallel,
and
then
we
deliver
it
to
that
peer
down
here.
A
So
when
you
look
at
that,
of
course-
and
I
mentioned
earlier-
we
don't
use
rest
and
points.
We
don't
use
json
rpc.
How
do
you
actually
your
your
application
to
call
these
services?
How
do
you
get
there?
How
do
you
do
that?
And
for
that
use,
aqua
aqua
is
a
high
level
program
language
we
designed
particularly
for
this
purpose.
It's
very
high
level,
so
you
really
don't
have
to
dig
down
into
the
lib
p2p
stack
at
all
and
basically
the
workflow
you
specify,
tells.
A
Tells
subsequent
chunks
of
how
to
execute-
and
this
happens
in
the
following
way,
we'll
get
into
this
a
little
more
detail,
but
we
basically
compile
aqua
into
an
intermediate
representation.
You
can
think
of
it
as
bytecode.
It's
not
bytecode,
but
it's
actually
like,
but
that's
what's
being
executed,
and
then
you,
basically
in
each
node,
executes
whatever
segment
of
that
compiled
aqua
code
necessary
to
move
to
the
next
service.
To
move
to
the
end,
we'll
dig
down
that
in
more
detail.
A
Are
we
executing
a
service
on
this
particular
peer?
If
so,
find
that
service
find
the
web
assembly
modules
now
push
them
into
with
the
data
to
the
marine
runtime,
execute
that
bring
the
data
back
update
the
state
changes
and
move
to
the
next
peer,
where
you
have
a
service
to
execute
and
or
finalize
your
execution
of
the
workflow,
and
that
model
enables
some
really
really
cool
things
that
you
basically
get
free,
including
obviously
peer-to-peer
applications,
but
also
serial
trust
applications.
A
If
you
look
at
the
trends
in
in
I.t
management
and
risk
management,
zero
trust
frameworks
are
critical
in
securing
your
your
I.t
assets
these
days
and
you
get
this
free
of
charge,
basically
as
part
of
the
programming
model
with
fluence
in
aqua.
And
of
course
you
get
this.
This
really
really
vast
application
collaboration,
composition,
capability
over
peer-to-peer
networks
and
where
it
gets
interesting,
is
that
he
actually
can
use
aqua
not
just
to
program
the
network
itself
and
the
composition
of
services
deployed
onto
the
network,
but
actually
third-party
networks
like
ipfs.
This
is
an
example.
A
So
I
showed
you
I
tc
a
little
bit
with
with
function,
addressability
versus
location,
addressability
versus
content,
addressability
and
how
acquisitive
magically
pushes
things
through
and
without
getting
into
too
much
detail.
I
want
to
give
you
like
one
of
the
foundations.
One
of
the
foundations
for
all
this
to
work
is
called
the
particle
you
can
think
of
it
as
smart
packet
and
basically
what's
happening
is
that
we
create
a
data
structure
that
combines
data.
A
What
has
been
done
would
work
within
work,
error,
logs
et
cetera,
et
cetera,
and,
if
you
think
of
it
from
like
it's
actually
it's
it's
it's
it's
quite
fascinating
in
a
certain
extent,
is
if
you
look
at
it
from
a
browser
perspective,
so
you
gather
all
your
data.
You
write
your
document.
You
now
get
it
ready
to
processed
it
on
on
the
network.
A
So,
in
the
background
you
have
aqua,
you
have
your
workflow
ready
and
you
get
your
data
that
populates
your
workflow
and
then
you
literally
create
this
sort
of
genesis
particle.
This
genesis,
smart
packet
and
you
fling
it
onto
the
network
where
flinging
literally
means
you
like
you
pop
it
to
the
first
relay.
If
you
use
a
browser
and
then
that
browser
sorts
out,
if
where
the
services
are
that
need
to
be
the
next
services,
the
spell
check
services,
for
example,
routes
to
the
pier
helps
the
route
to
the
pier.
A
Then
the
av
aim
kicks.
In
again
we
have
the
service
now,
which
webassembly
modules
do
we
need
to
do
the
spell
check.
Now
we
do
the
state
change
on
the
document.
If
there
is
any
and
on
and
on
it
goes
so
you
get
this
data
push
model
which
is
totally
totally
different
than
what
you
have
in
client
server
models
right,
the
client
server
model.
You
would
send
out
the
request.
You
get
the
response
back
to
your
client,
you
may
or
may
not
do
something
with
it
other
than
apply
like
routing
logic.
A
Go
to
the
next
api.
Do
your
emoji
injection
get
it
back
and
then
you
send
it
to
the
final
destination.
So
that's
a
lot
of
capabilities
required
from
a
research
perspective.
Bandwidth
compute
on
your
on
your
client,
which
influence
doesn't
happen
with
this
push
model.
The
the
data
never
comes
back,
you
can.
You
can
generate
some
informational
data
that
goes
back
to
the
client,
but
you
don't
have
to
so.
Your
clients
can
be
super
super
thin.
A
I
mean
a
browser
actually
has
a
fat
client
as
far
as
I'm
concerned
from
a
requirements
perspective
and
you
can
go
really
to
edge
computing
devices
and
iot
devices
that
have
very
very
little
resources
and
fully
utilize
the
network
and
that's
extremely
powerful
and
actually,
in
my
opinion,
probably
the
first
time
it's
really
really
possible
to
do
something
meaningful
within
clients.
The
way
it's
been
advertised
in
web
2
and
never
been
materialized.
C
C
A
Cool
all
right,
so
nuts
and
bolts,
what's
the
tooling
we're
providing
so
we
have
the
protocol.
We
went
through
some
of
the
aspects
of
the
protocol.
We
have
the
network,
we
run
some
of
the
aspects
of
the
network.
Where,
again
we
don't
own
the
network,
we
just
bootstrap
and
bootstrap
it,
and
we
have
the
tooling
now
we're
going
to
the
tooling
in
detail
our
ref,
our
main
reference
node
is
a
rust
node,
it's
built
on
lib,
p2p
and
rust,
and
we
have
a
rust
sdk
that
allows
developers
like
yourself
to
create
webassembly
modules.
A
But
you
then
can
link
them
through
basically
a
json
document
specifying
how
modules
should
be
linked
into
a
service
and
you
deploy,
deploy
these
modules
onto
the
network
and
you
link
them
and
then
you
get
a
unique
service
id
which,
in
combination
with
the
prd
gives,
gets
you
to
get
you
towards
function.
Addressability
and
those
webassembly
modules
then
run
on
the
marine
runtime.
A
So
for
those
of
you
afraid
of
rust,
we're
in
web
assembly
webassembly
is
single
threaded
and
we
do
passing
by
values.
So
if
you
know
typescript,
the
part
of
russ,
you
know
are
literally
the
first
four
chapters
in
the
rust
book
because
we
have
no
lifetimes,
we
have
no
generics.
We
have
no
concurrency.
A
All
that
is
not
part
of
the
rust
programming
model
for
web
assembly,
so
don't
be
afraid
over
us.
Really
don't
if
you
know
the
typescript,
especially
typescript
you,
you
are
fine
and
there's,
like
I
don't
know,
there's
like
a
little
more
than
two
handfuls
of
types
in
wazi32
and
it's
it's
really.
If
you
know
javascript
typescript,
you
have
no
problem
doing
this
and,
as
part
of
the
development
environment,
we
actually
provide
an
extension
of
the
rust
native
testing
unit
and
integration
test
to
include
webassembly
modules.
A
So
this
is
actually
really
really
cool
and
usually
you
in
any
target
in
compile
targets.
You
know
linux,
whatever
unix
64.
you,
you
write
your
tests
and
then
you
test
it
on
the
code.
You
just
written
and
that's
very,
very
cool
because
that's
the
application
web
assembly,
however,
is
very,
very
different,
and
our
deployment
model
and
our
construction
model
for
a
service
out
of
webassembly
module
is
very,
very
different.
A
So
you
actually
catch
bugs
and
problems
within
the
modules,
not
just
the
code
level,
so
pre-compiled
versus
post
compile
and
the
construction
and
linking
of
this
module,
which
is
super
super
helpful,
and
we
also
provide
you
as
part
of
tooling
with
a
local
version
of
the
marine
vm,
which
is
basically
wrapped
into
apple,
and
you
can
interact
with
each
one
of
your
modules
locally.
That's
so
before
you
even
deploy
them.
A
We
also
have
a
javascript
implementation.
It's
called
fluence.js.
It
provides
fundamentally
everything
necessary
to
create
a
peer
to
connect
to
the
network
as
a
relay
node.
So
you
can
use
this
to
any
in
the
browser
or
as
a
standalone,
node.js
api
app,
not
api
app,
and
it
includes
a
an
aqua
virtual
machine
instance,
but
not
a
marine
neon
runtime.
Yet
so
it's
it.
You
can't
deploy
webassembly
modules
onto
a
fluence.js
client.
A
If
you
need
to
use
the
browser
as
a
client,
then
this
is
obviously
your
tool
kit
to
go.
If
you
want
to
create
your
own
node
for
a
variety
of
reasons,
and
you
don't
want
it
to
be
a
rust
node,
then
this
also
works
were
one
of
the
the
use
cases
or
patterns.
If
you
will,
where
fluency
has
it
is,
is
really
helpful
for
a
client
is
for
signing
services
signing
as
in
transaction
signing
for
blockchain,
for
example,
erp
712
documents.
A
The
exposed
interfaces
from
your
fluence.js
node.js
app
are
fully
programmable
by
aqua.
Again,
that's
I
mean
that's
the
whole
trick
of
fluence.js.
It
basically
provides
you
with
the
various
bindings
and
runtime
requirements
for
your
js
services
to
protect
actually
typescript
to
be
fully
programmable
with
aqua
aqua
itself.
Aqua
is
a
few
things.
It's
a
it's
a
high-level
language.
A
It's
a
compiler.
It
leads
to
an
intermediate
representation.
We
call
it
air
aqua
intermediate
representation
and
it
actually
includes
a
command
line
interface
that
actually
that
allows
you
that
wraps
a
few
things,
including
fluency
s,
that
allows
you
to
actually
have
a
command
line
single
shot.
If
you
will
a
peer
client
to
deploy
services
to
the
network
to
run
services
on
the
network,
and
it's
a
great
little
tool
to
you
know
play
around
on
the
command
line
now.
Finally,
aqua,
let's
dig
into
aqua
a
little
bit.
A
A
Let's
call
it
the
greeting
service,
it's
a
fancy,
hello
world
that
takes
two
parameters:
a
string
and
a
boolean,
and
so
the
string
could
be
east
denver
and
the
boon
could
be
true
or
false.
So
if
the
string
is
denver
and
the
boolean
is
true,
the
return
string
would
be
hello,
east
denver.
If
the
balloon
is
fall
false
and
we
still
have
east
denver,
the
return
string
would
be
goodbye
each
dimmer.
Something
like
that.
A
That's
it
so
here
we
that
service
is
out
there,
it's
written
in
webassembly,
and
when
we
deployed
it
we
knew
the
prd
and
we
get
back
the
unique
service
id.
So
we
can
turn
this
binding.
This
interface
with
that
function
into
a
binding
down
here,
I'll
get
to
it
in
a
minute,
and
now
we
want
to
do
something
with
the
service.
A
So
this,
basically
is
you
can
look
at
it
as
your
api
right
in
in
solidity
or
in
many
other
instances,
that's
the
api,
and
now
we
create
actually
an
actual
function
and
that
function
we
call
it
greeting.
It
takes
a
string
parameter,
we
call
name
which
actually
corresponds
to
this.
We
take
a
boolean,
we
name
it
greet
and
it
corresponds
to
this.
We
take
a
node
which
is
a
string
which
is
our
peer
id,
basically,
the
peer
id
of
the
node.
A
We
now
bind
that
interface
to
that
service
id
we
basically
instantiate
it,
and
now
we
call
that
service.
So
that's
our
namespace.
This
is
our
function.
This
is
our
parameters
here
and
here
going
right
there
and
then
we
get
result
back
and
then
we
return
result
back
to
the
client
and
if
you
look
in
the
little
diagram
up
there,
this
is
basically
what's
happening.
So
the
actual
node
could
be
like
two
three
nodes
down
quote
down
the
road:
basically
not
the
road,
but
the
the
binary
tree.
A
A
This
genesis
particle,
if
you
recall,
and
you
compile
this
aqua.
This
is
the
the
programming
component
we
were
talking
about
and
then
you
know
all
the
metadata
and
you
fling
it
out
to
this
relay
node,
which
is
here
from
there.
We
figure
out
where
our
node
is.
If
it's
a
direct
hit
it's
great,
and
now
we
actually
call
that
binding.
We
instantiate
it.
We
run
on
marine
vm.
A
We
run
our
our
webassembly
module
with
those
data
points
execute
it
and
then
we
return
the
results
by
relay
back
to
the
client
peer
and
if
you
never
had
to
do
this
at
the
at
the
middle
level,
this
kind
of
programming
peer-to-peer
program
at
the
node
level.
It's
you
don't
know
how
much
pain
you're
being
saved
anyway.
The
point
is
this
is
a
very,
very
readable
language.
A
It's
a
very,
very
special
purpose
language,
so
it's
not
very
complicated
and-
and
it's
really
all
about
just
specifying
the
workflow,
which
is
an
association
of
how
you
want
the
data,
the
state
change
to
happen
across
functions
or
services,
and
that's
it
so
there's
a
little
bit
more
to
it,
but
we've
got
great
documentation
for
it
in
our
aqua
book
and
we'll
dig
into
it
a
little
bit
later.
When
I
go
through
a
few
more
examples
which
is
basically
right
now,
okay,
so
before
we
go
into
the
code
demo
and
review
any
questions.
A
B
A
B
A
A
All
right
here
we
go
so
in
previously,
I
told
you,
you
write
your
web
assembly
right
and
then
you
deploy
it
to
the
network,
and
then
you
can
call
it
and
use
aqua
to
do
something,
really
cool
or
something
super
cool,
or
something
exceptionally
cool
with
it.
Whichever
way,
whichever
way
it
goes,
and
here
we
wrote
a
service,
and
basically
this
is
a
very
simple
service,
as
I
said
you
can
think
of
it
as
the
services
in
terms
of
lambda,
for
example.
A
A
Okay
and
that's
all
there
is
to
it-
and
this
is
this-
is
your
marine
marked
up
russ
code?
As
you
can
see
a
few
I
mean,
as
if
you
look
at
function,
signature
return,
you're
in
the
rest
is
called
destruct
in
javascript.
It's
on
interface
doesn't
really
matter.
It's
you
shouldn't
have
any
any
problems
making
this
work
for
you
rust
webassembly,
for
that
is,
and
we
compile
that
service
and.
A
So
we
could
do
this
from
our
from
our
laptop
every
time
or
we
can
get
really
really
cool
and
we
deploy
it
to
ipfs.
So
this
is
what
we're
doing
now.
So
we've
we
provide
fluence,
provides
out-of-the-box
full
support
for
ipfs,
which
basically
means
that
we're
running
ipfs
nodes
as
a
sidecar
to
influence
peers
and
each
of
the
sidecars
actually
has
a
ipfs
multi
address,
which
is
which
we
have
right
here.
A
Okay,
so
now
I'm
getting
a
little
lazy
using
the
ipfs
desktop
and
in
order
to
interact
properly
with
the
with
ipfs
influence,
we
want
to
hit
that
particular
sidecar
ipfs
here
associated
with
that
fluence
appear.
We
just
selected
out
of
the
possibilities
provided
to
us,
which
is
one
out
of
whatever
is
on
the
network,
basically
and
relay
capable,
and
so
now
we're
going
here
and
voila.
A
A
A
A
A
A
A
The
sidecar
hasn't
changed
right.
We
use
the
same
one
and
we
use
the
that
particular
content
id
and
now
we
calculated
the
style
the
the
size
of
that
file
on
using
the
fluent
servers,
and
this
is
really
really
cool
so
just
to
before
we
go
to
code.
So,
basically,
what
happens?
Is
we
put
some
stuff
some
files
onto
ipfs,
one
of
those
files
actually
was
the
webassembly
module.
We
would
like
to
turn
into
a
service.
A
Just
any
old
file
domain
file,
this
one
we
also
drag
it
to
for
convenience
purposes
on
that
same
sidecar,
ipfs
node
used
that
content
identifier
and
again
used
aqua,
then
to
to
com
to
utilize
that
previously
deployed
webassembly
module
service
to
calculate
the
results,
return
result
and
bring
it
here,
so
this
sounds
really
really
complicated
right.
This
is
like
you
figure,
there's
a
whole
bunch
of
nuts
and
bolts
and
a
lot
of
programming
to
be
done.
Well,
let's
see,
if
that's
the
case,.
A
Yes,
yes,
you
can,
you
can
so
fundamentally,
okay,
so
webassembly
modules
or
webassembly,
I
t
particular
web
assembly.
It
modules
for
cura
for
security
purposes
are
extremely
sandbox
right.
You
don't
have
sockets,
you
don't
have
you
don't
have
any
access
to
the
host?
Fundamentally,
what
we've
done
is
we
built
a
security
model
that
allows
the
webassembly
module
to
quote
unquote
punch
through,
if
permission
correctly,
into
the
host
resources,
which
includes
access
to
http
transport,
for
example
like
curl
and
or
the
local
file
system
in
memory?
A
A
So
if
you
want
posterity
and
decentralization
and
censorship
resistant
on
your
on
your
modules
on
your
webassembly
modules
themselves,
you
probably
would
be
looking
more
at
ipfs,
then
github
as
sort
of
the
host
of
the
the
file
itself,
but
through
the
local
file
sharing
and
access
to
local
file
system
and
http
like
curl,
you
can,
you
can
bring
in
you.
Can
calculate
file
sizes
from
anywhere
and
the
service
the
web
assembly
module?
We
wrote
the
web
assembly
module
itself.
The
service
doesn't
care
where
it
comes
from
right.
A
In
this
particular
I
mean
we
could.
We
could
have
used
the
buffer,
but
we
just
used
the
file
path
and
the
way
we
implemented
the
the
ipfsi
car
is.
Basically,
we
allocated
space
on
the
peer
file
system
and
we
call
it
the
volt
the
file
vault,
which
you,
which
then
transfers
to
and
from
ipfs
from
that
particular
location
of
the
file
system,
and
then
the
web
assembly
module
interacts
with
the
peer
file
system,
which
is
that
particular
file
path.
A
B
B
C
A
Okay,
so
in
general,
when
we
talk
about
on-chain
and
off-chain,
unchain
is
on
the
blockchain.
It's
it's
part
of
the
the
blockchain
model.
Processing
model
and
off
chain
is
not
so
in
this
particular
example.
With
the
file
size,
calculation
unchained
doesn't
come
into
play
at
all
it.
It's
not
relevant.
C
A
A
A
A
From
the
security,
so
the
security
model
is
totally
different
off
chain
for
for
fluence
than
it
is
on
chain.
So
in
the
blockchain,
the
security
comes
through
through
the
mining
and
the
re-running
on
basically
of
creating
the
longest
longest
chain,
where
every
node
reruns
the
computation
of
every
other
node
right.
B
A
There
is
no
quote-unquote
consensus,
so
you
don't
rerun
that
at
least
not
out
of
the
box,
the
file
calculation
50
times
or
100
times
or
whatever
the
number
of
peers
are
in
the
network
and
then
come
to
consensus.
You
know
quote-unquote,
what's
the
longest
data
chain
for
file
size
for
that
particular
computation,
that's
not
what
happens.
However.
A
Well,
every
time
on
the
ingress
and
egress
of
of
state
change,
there
are
signatures
being
applied
and
those
signatures
are
verifiable
and
they
eliminate
a
lot
of
issues,
including
man
in
the
middle
attacks,
eclipse
attacks
and
a
few
other
things,
and
all
of
this
is
sort
of
quote.
You
can't
access
it
directly,
but
this
is
all
abstracted
away
from
from
you
with
with
aqua.
This
is
why
it's
it's
a
very
high
level
language
did
I
answer
your
question
on
that.
One.
A
Let's
go
to
aqua,
as
I
said
when
I
explained
what's
going
on,
we
have
our
webassembly
module,
we
put
it
onto
ipfs
from
ipfs.
We
then
get
it
onto
any
one
node
we
determine,
and
then
we
execute
that
that
service
against
some
file
any
file
to
calculate
the
file
size
as
it
sounds
complicated.
But
what
does
it
look
at
aqua?
It
looks
it's
super
simple.
A
In
our
web
interface,
the
the
cid
which
remember
we
got
from
here
for
our
module
right.
What's
that
and
the
ipfs
multi-adder
address,
which
is
what
we
also
got
from
here,
which
is
the
side
card
to
the
fluence
node
in
that
particular
example,
and
then
we
make
room
for
basically
a
callback.
We
call
an
error,
but
that's
basically
a
callback
to
the
client
just
in
case
something
goes
wrong
and
what
we
want
once
we
deploy
our
webassembly
module
as
a
service.
A
A
A
We
execute
an
ipfs
get
call.
That
is
what
we
call
a
built-in
service.
We
basically
wrote
wrappers
around
ipfs
api
that
you
can
use
totally
like
part
within
aqua.
As
I
said
so
seamlessly
I
go
from
fluence
into
into
ipfs
peer-to-peer
back
to
fluent
utterly
seamless
and
because
we
wrote
those
wrappers
for
you
in
this
particular
instance,
so
we
basically
get
the
result
back
and
if
the
result
is
so,
this
is
a
structure
or
an
interface.
A
Whichever
you
want
to
look
at
it,
I'm
a
raster
if
you're
a
javascript
or
it's
an
interface,
it
means
it's
direct
and
then,
if
that's
successful,
we
now
call
the
add
module
aqua
function,
which
is
up
here
and
basically,
what
that
does
is.
Basically,
you
have
a
name
which
is
string
of
the
file
and
the
path,
and
now
we
also
have
another
service
here
which
basically
get
creates
the
configuration
that
turns
the
module
modules
into
a
service
and
then
basically
add
the
module
from
the
vault.
A
Remember
I
told
you
the
allocated
local
file
path
for
ipfs.
We
call
vault.
This
is
this
is
also
part
of
all
the
wrappers.
We
wrote
are
available
for
you
and
you
get
back
a
module
hash,
that's
basically
it
and
once
we
get
the
module
hash,
we
calculate
what's
called
the
blueprint
id
a
blueprint.
Id
is
basically
a
hashes,
the
hash
of
all
the
webassembly
modules,
making
up
the
service
and
simplistically
speaking-
and
this
is
here-
we
can
do
this
with
aqua
and
again.
A
Those
are
all
built-in
functions
available
for
you,
so
you
don't
have
to
do
anything
other
than
provide
the
the
sequencing
of
how
you
want
to
calculate
the
blueprint
and
use
the
module
hash
as
an
input,
because
we
only
had
one
module.
So
there
is
nothing
fancy
going
on
and
I
don't
know
we'll
just
go
through
the
procedure
here
and
we
end
up
with
a
blueprint
id
once
we
have
the
blueprint
id.
We
turn
that
into
a
service
id.
So
basically
what
happens?
A
Now
you
associate
a
unique
id
with
the
blueprint
id
so
which
is
a
uid4
actually,
so
this
is
important
because
you
might
may
want
to
have
multiple
instances
of
that
service
running
on
the
same
pier
or
on
any
other
peer,
and
we
want
uniqueness
in
the
addressability,
even
though
the
underlying
blueprint
id
is
always
the
same
for
this
particular
constellation
of
of
the
service
based
on
the
configuration
file
and
those
modules,
and
that
that's
what's
happening
here.
If
that
doesn't
work,
we
use
that
error
function.
A
Remember
up
here
this
callback
and
we
do
this
as
a
code
routine.
So
it
reports
back
to
the
browser
interface.
Listen,
this
didn't
work.
This
was
a
failure.
This
is
the
report
and
then
we
return
the
service
id
here.
The
service
id
is
prefixed
by
a
question
mark
which
actually
means
it's
optional
and
that's
all
it
took
to
deploy
the
service.
A
B
A
20
lines
of
code,
okay
in
aqua
to
basically
take
any
webassembly
module
from
ipfs
and
deploy
it
as
a
unique
service
to
any
peer
id
peer
in
the
network.
That's
accessible,
aka
everything,
that's
all!
There's
to
it,
and
this.
This
is
basically
all
your
network
programming.
You
don't
have
to
ever
touch
anything
at
the
low
level.
So
we
truly
believe
that
aqua,
if
you're
into
creating
peer-to-peer
application,
web3
applications
highly
decentralized
aqua
is,
is
really
gonna,
be
a
go-to
tool
and
it
is
it
is.
A
A
We
want
a
result
and
then,
if
we
want
to
actually
write
the
result
somewhere,
we
write
it
and
if
you
remember
these
data
interfaces,
these
data
structs
and
those
functions
calculate
the
file
size
and
write.
The
file
size
fully
correspond
to
the
exposed
functions
from
our
aqua
right.
Here
we
go,
this
was
the
size
result
which
was
the
same
thing
right,
and
this
is
file
size
and
write.
Result
was
this
and
this
is
a
write
file.
So
where
was
I?
Where
was
I?
Where
did
it
go.
A
And
we
actually
get
those
we
can
export
those
structures
and
and
interfaces
directly
from
the
services
with
the
marine
sdk
tool.
So
you
can
pipe
it
straight
from
from
the
wasm
into
into
your
your
aqua
file.
So
you
don't
have
to
retype
all
this
stuff
and
again
so
file
size.
You
should
have
the
file
path,
the
string
and
then
you
get
the
result.
A
A
Here
we
go
and
we
want
to
get
the
file
size
right.
So
again
we
need
a
relay
our
cid,
which
remember
was
this
one
here,
not
this
one.
This
was
the
module.
This
was
the
file
we
were
going
to
process
this.
We
get
the
service
id
which
we
got
from.
You
know
which
we
got
from
here
and
same
rpid,
and
then
we
have
again
a
couple
of
logging
or
co-routine
functions,
callbacks,
basically
here
and
here
and
optionally.
It's
our
ipfs
put
result
right
and
the
ipfs,
and
that
was
the
structure
up
there.
A
So
again,
basically,
what
we're
doing
we're
creating
a
results
variable
of
that
structure,
which
is
what
we
call
a
stream
and
then
you
basically
create
this
interface
binding
for
the
processing
for
the
process
file
structure
to
that
particular
service
id,
and
then
you
just
go
through
it
like
we
did
before
that,
particularly
blah
blah
blah.
You
get
the
file,
then,
if
get
success,
start
processing
it
right.
If
we
can
calculate
the
sales
size,
we
report
it
back
in
the
background
through
the
co
routine
into
the
web
browser
like
which
was
done
here
and.
A
Then
we
do
some
some
some
other
processing
by
uploading
the
file
to
the
right
path.
If
that's
that's
just
the
way
it's
set
up
here
and
alternatively,
we
just
keep
piping
back
our
errors
that
something
didn't
work
and
that's
it.
So
again,
we
basically
with
you
know-
I
mean
it's
it's
formatted
and
all
that,
but
with
10
lines,
12
lines,
you
basically
compose
the
entire
ipfs
2
fluence
file,
size
calculation,
service
and,
of
course,
you
could
use
this.
A
You
know
for
as
part
of
a
much
other
service,
many
many
more
services
in
terms
of
where
you
can
compose
this
into
a
much
much
more
important
workflow.
So,
for
example,
in
our
original
example,
when
I
said
you
have
the
document,
you
spell
check
it,
you
did
the
emoji
injection,
we
could
actually
add
a
file
size
calculation,
and
this
this
part
would
be
exactly
there
now,
since
we
probably
would
mess
with
things
with
with
the
spell
checker
there.
A
Basically,
you
remove
a
service,
and
I
think
we
have
it
here,
so
we
clean
up
ourselves,
so
this
actually
moves
the
web
assembly
module
and
all
associated
files
from
that
particular
peer.
We
click
that
and
it's
gone,
and
that
took
what
three
lines
to
do
it,
which
again,
if
you've
ever
done
peer-to-peer
programming
at
the
middle
level.
This
is
super
super
cool.
C
A
Okay,
one
second,
let
me
just
like
power
through
three,
more
slides
so
which
hopefully
will
help
you
too.
So
we
just
showed
you
the
the
fluence
in
ipfs
integration
right.
So
we
don't
have
to
do
that
anymore.
We
also
have
one
with
ceramic,
which
builds
on
top
of
ipfs,
and
basically
I
don't
know
if
you're
familiar
with
ceramic
ceramic
allows
you
to
build
basically
associate
a
longer
running,
it's
basically
a
nosql
stream.
A
If
you
will-
and
it
basically
allows
you
to
create
a
permanent
content
identifier,
if
you
will
and
then
apply
changes
to
it
with
pointless
linking
individual
cids.
So
it's
very,
very
cool
actually,
and
it
also
has
a
blockchain
component
and
it's
it's
really
really
nice.
We
have
additional
building
blocks
around
near
and
eip
712,
and
then
we
have
a
whole
bunch
of
examples
listed
up
here
and
we
also
have
community
examples
from
previous
hackathons
they're.
A
C
B
D
C
C
Currently,
I
don't
have
any
use
cases
to
think
towards
other
than
this
storage
sharing
the
storage
thing,
but
even
then
it
is
needed.
Even
google
is
providing
only
the
for
free,
they
are
providing
only
a
little.
You
will
not
be
able
to
upload
your
any
of
your
mp4
or
mp3
anything.
You
will
not
do
only
just
the
documents
and
one
drive
you
need
to
do
you
have
you
should
have
a
subscriptions,
then
only
you'll
be
able
to
have
a
data
for
one
terabyte.
C
A
Good
well
and
I'll
give
you
I
mean
we
have
discord,
we
have
telegram,
we
get,
I
mean
you
can
set
the
cleanly
meetings
with
the
team.
If
you,
if
you
need
to,
if
you
need
any
help,
I
mean
this.
Isn't
this?
Isn't
this
isn't
like
school?
We
want
you
to
succeed,
we
want
you
to
do
well
and
we'll
do
anything
we
can
to
to
to.
You
know
help
you
succeed
in
in
that
hackathon.