►
From YouTube: Developer Community Call #22
Description
Welcome to the monthly community call with the Fluence developer community ⚡️
This time we're going to discuss some of the lates updates and the future plans, watch demos of the ETHDenver winner teams and have a Q&A session
Join the call via link: https://us06web.zoom.us/j/82025547767
If you would like to present your project, feel free to reach out to nadia@fluence.one
_________________
Join the community!
Discord 🔹 https://fluence.chat
Telegram 🔹 https://t.me/fluence_project
Follow Fluence!
Twitter 🔹 https://www.twitter.com/fluence_project
Build with Fluence!
Quick Start🔹 https://fluence.dev/docs/build/quick-start/
Tutorials 🔹 https://fluence.dev/docs/build/tutorials/setting-up-your-environment
Docs 🔹 https://fluence.dev/docs/build/introduction
A
A
A
A
A
A
A
A
A
A
A
A
A
C
C
So
so,
basically,
today
we
will
speak
about
our
highlights,
highlights
on
the
progress
from
our
development
team,
so
we'll
have
Alexia
on
the
call
with
us
today.
He
will
tell
us
about
the
new
functionality
we
have
recently
added,
which
is
called
spells
and
workers,
and
you
will
be
able
to
ask
him
questions
about
these
new
cool
features.
We
also
have
eth
Denver
highlights
because
well
we
had
a
really
exciting
participation
there.
C
We
have
also
have
we'll
have
demos
from
the
teams
which
are
building
with
fluence.
We
have
talent,
player
team
with
us
and
you
you
can
ask
them
questions
about
their
experiences,
so
we
also
have
some
checkout
session
and
we
will
have
power
up
distribution
for
this
call.
So
after
this
call,
you
have
a
fancy
pull
up
when
you're
on
your
wallet.
So
let's
start
so
how
are
you
doing?
How
is
your
week?
C
E
E
So
we
introduced
several
new
Concepts
recently,
namely
spells
workers.
Installation
spells
deals
all
that
that's
a
lot,
let's
go
through
them,
one
by
one
and
start
from
the
most
familiar
one
to
some
people
at
least
and
most
I
guess
low
level.
One
and
most
simple
one
so
spells
what
are
the
Spells
spells
are
basically
just
a
way
to
express,
even
when
driven
aqua
like
not
the
aqua
that
you
run
from
the
front
end
but
Aqua
that
reacts
to
some
events
and
like
runs
in
response
to
something
happening
and
also
it's
we.
E
We
had
a
similar
concept.
It
was
called
schedule
scripts,
but
it
was
missing
lots
of
very
useful
things,
one
of
which
is
crucial,
is
state.
It
was
stateless.
Now
spells
are
stateful,
they
have
killer
storage.
So
it's
basically
a
service
that
specifies
what
aqua
to
run,
how
often
to
run
it
on
what
events
to
run
it
right.
Now,
it's
only
by
clock
by
timer,
but
in
the
future
we
will
have
more.
E
That's
kind
of
a
lot
of
things
happening
here,
but
just
to
like
it
mostly
shows
the
rust
peer
architecture
just
to
dive
a
little
bit
deeper
into
how
it
all
works
and
might
work
in
the
future.
Because,
right
now
we
have
like
only
timer
events
that
trigger
different
spells
on
different
times,
but
in
the
future
also
hope
to
have
HTTP
events.
Network
events
and
stuff
like
that.
E
What's
important
here
is
that
spells
are
inside
this.
This
services,
Corner
Services
part,
so
spells,
are
services,
but
with
a
special
property
of
providing
air
script
to
execute
and
raspberry
peer
periodically
looks,
goes
through
all
the
Spells
and
asks
what's
your
script
and
creates
particle
with
that
script
and
sends
that
particle
to
other
peers
or
executes
it
locally,
depending
on
what
is
written
inside
the
aqua
air
script.
E
So,
as
I
said,
basically
just
to
recoup
what
I
said
what's
important
here,
that
I
have
yet
covered
is
that
it's
possible
to
have
cues
in
cable
storage
of
the
Spells,
so
that
kind
of
resembles
the
actor
model,
but
each
spell
can
have
as
many
cues
as
you
want
right
now,
it's
not
limited
in
the
future.
It
will
be
so
yeah
you
can
have
lists
in
the
keyword,
storage
and
that
you,
you
can
push
things
there
and
you
can
pop
things
from
there.
E
So,
like
some
external
things,
like
other
spells
or
your
customer
Aqua
or
whatever
can
push
messages
to
the
cable
storage
and
spell
script,
can
pop
it
from
there
and
like
process
so
basically
an
actor
Q
actor
mailbox.
Where,
like
from
one
side,
messages
are
coming
from
the
other
side,
they're
taken
and
processed
by
the
spell.
E
There
is
a
a
certain
flavor
of
spells
that
just
that
serves
a
certain
like
purpose.
It's
just
an
ordinary
spell,
so
it's
just
a
service
with
some
aqua,
but
it
the
aqua.
There
is
like
special
in
a
sense
that
we've
written
it
to
implement
very
narrow
thing.
It
retrieves
a
list
of
services
and
spells
to
install
from
apfs
and
installs
them
to
the
peer.
Where
installation
spell
runs.
E
So
you
can,
what
you
can
have
is
you
can
like
upload?
You
can
have
a
configuration
like
service
full
service
bar
spell
XYZ.
Whatever
here
is
like
name
of
the
modules
here
are.
My
configs
here
are
Echo
functions
and
all
that
upload.
Those
like
definitions,
does
configuration
files
to
ipfs,
get
the
CID
back
and
from
then
create
an
installation
spell
with
that
CAG
as
an
argument,
and
it
will
automatically
download
a
definition
from
a
PFS
parse.
E
If
you
make
them
human
readable,
usually
people
do
tend
to
do
that.
Services.
It
would
be
possible
to
call
services
by
those
eliases,
so
Elias
namespaces
are
now
inside
those
boxes
as
well.
So,
whatever
like
set
of
services
installation
spell
deploys
no
need
to
know
exact
service
ID
anymore,
you
can
just
refer
to
them
by
aliases
and
if
some
service
has
changed
and
automatically
redeployed,
so
we
say
underlying
service
edible
change.
E
No
one
cares
anymore,
because
everything
is
aliased
and
aliases
are
they
are
inside
inside
that
box
and
they
do
not
conflict
with
other
boxes.
So
that's
great
automatic
deployment
so
those
boxes
they
are
called
workers.
What
are
they?
It's
kind
of
kind
of
dual
Concept
in
the
sense
that
we
tend
to
call
worker
definition,
configuration
of
services
like
service,
Food,
Service
bar
spell
XYZ,
and
so
on
those
modules,
their
configs
aqua
scripts.
All
that
we
before
we
upload
it
to
ipfs.
We
call
that
worker
definition
like
and
we
get
CID
from
that.
E
That
I
was
just
describing
that's
a
distribution
package
side
of
the
thing.
The
other
side
is
when
the
worker
debugs
get
actually
deployed
to
the
peer.
All
the
services,
all
the
Spells
get
deployed,
get
aliased
all
that
that's
a
worker
that
exists
on
the
pier
and,
besides
being
a
unit
of
deployment.
It's
also,
as
I
said
an
alas
namespace,
a
box
for
aliases.
It's
an
isolation
namespace
all
there
are
certain
permissions
on
who
can
create
services
in
that
box
in
that
worker.
E
E
In
the
future
we
will
have
a
separate
Resource
Management
so
that
compute
providers
will
be
able
to
to
limit
how
much
CPU,
how
much
memory,
how
much
distance
on
certain
workers
will
be.
We
will
be
able
to
use,
and
also
some
security
isolation
keys
are
separate,
like
disk
will
is
separate
and
stuff
like
that.
So
it's
an
isolation,
namespace
and
I
think
we
will
figure
out
for
more
ways
to
isolate
things
from
workers
to
workers.
Those
are
isolated
boxes.
E
So
we
recently
introduced
the
concept
of
deals
and
that's
deployment
of
Services
of
workers.
Now
I
can
say
deployment
of
workers
through
a
blockchain,
but
a
very
useful
concept
that
we
had
before
is
direct
hosting
when
you
can
deploy
certain
services
to
certain
peers.
It's
so
that's
where
this
dichotomy,
that's
distinction,
comes
from,
there's
a
concept
of
direct
hosting
where
you
know
which
peers
you
want
to
deploy
to,
and
there
is
a
serverless
hosting
where
you
can
declaratively
declaratively.
E
Say
I
want
this
worker
to
be
deployed
to
this
number
of
peers.
I,
don't
care
who
exactly
they
are
here.
Is
my
money
just
figure
it
out
so
two
different
approaches?
The
direct
hosting
is
very
useful
for
debugging
or
writing
your
own
notes
and
development,
and
it
basically
enhance
all
service
deployment
deployment
model.
It's
not
that
different,
except
that
the
deployment
happens
inside
installation
script.
E
So,
instead
of
calling
a
Server
create
10
times
you
just
upload
worker
definition
to
ipfs
and
then
say:
hey
create
an
installation
spell
with
that
CID
and
it
installs
everything
automatically
and
there
are
logs
and
all
that
and
in
the
serverless
model.
It's
almost
the
same,
except
that,
as
I
said,
you
don't
know
who
will
host
your
services
who
will
host
your
workers.
You
just
send
this
CID
along
some
metadata
like
price
and
desired
number
of
hosts
to
the
blockchain
and
then
the
complete
providers.
E
They
listen
to
the
blockchain
for
events
and
whenever
they
see
that
certain
deal
is
like
makes
economical
sense
to
to
host
on
their
Hardware.
They
do
that
they
download
that
CID
they
create
installation
spell
and
it
goes
the
same
way
as
direct
hosting
goes,
and
then
they
register
themselves
in
service
Discovery
in
in
registry,
for
example.
So
that's
kind
of
a
distinction
that
we
have
it
all
works.
Direct
hosting
Works
is
more
mature
at
the
moment
than
serverless,
for
example.
Right
now
there
is
no
way
to
opt
out
of
the
serverless
deployment.
E
So
whenever
you
run
your
rust
beer
like
Europe,
does
I
know
it
will
host
Services
by
other
people
and
that's
and
not
that
you
not
what
you
want
to
spend
your
CPU
Cycles
on.
Sometimes
sometimes
you
do.
Sometimes
you
don't
want
and
we
will
provide
some
ways
to
opt
out
of
that.
But
right
now
like
it's
all
pretty
exciting
in
the
sense
that
you
just
enter
one
comment
and
then
boom
deploys
to
the
whole
network.
That's
pretty
fun
to
watch.
E
So
all
that
is
integrated
into
The,
Shining
fluency,
light
fresh
and
crispy
direct
hosting
is
there
you
can
do
fluence
workers
deploy
and
after
that
you
can
do
fluence
workers
logs,
and
you
will
get
some
lugs
there
like.
We
will
improve
how
they
look,
how
they
read
and
all
that,
but
you
can
see
the
lags.
That's
to
me
change
debugging
a
lot
because
I
don't
have
to
SSH
to
peers
anymore.
I
can
just
do
frames.
E
E
And
we
have
how
it
like
organized
in
the
fluency
line.
We
have
a
single
yaml
file
for
all
of
that
single
high
level,
one
as
before,
where
you
can
configure
services
like
you
can
have
you.
You
say
where
your
service
lives.
You
can
have
workers
here
default
worker
is
just
a
name.
You
can
name
it
whatever
you
want
by
default,
it's
default
worker
and
you
specify
of
what
services
this
default
worker
consists
and
of
what
spells
this
example
doesn't
demonstrate
spells.
E
But
I
will
show
you
in
a
moment
so,
and
the
next
kind
of
abstraction
is
the
deals
and
you
specify
what
worker
is
in
the
deal.
Only
single
worker
can
be
in
a
deal
and
you
specify
how
many
kind
of
hosts
you
want
there.
So
minimum
you
want
one
host
at
most.
You
want
three
hosts,
that's
the
idea
and
when
you
do
having
this
configuration
file,
you
can
do
fluence
workers
deploy
and
only
the
and
all
the
workers
will
be
deployed,
but
without
deals,
just
workers
will
be
deployed
directly.
E
I
will
show
you
how
that
works.
You
can
specify
hosts
where
to
deploy
the
workers
and
when
you
do
fluence
deals
deploy
the
next
section
comes
into
play
and
it
forms
a
transaction
to
the
blockchain
since
from
metamask
called
that.
With
that
information
that
this
worker
is
inside
that
deal,
please
deploy.
E
Good
and
since
spells
are
a
new
addition
latest
addition
to
fluency
live
and
though
it
all
started
with
them.
Here's
how
like
spell
configuration
file,
looks
so
you
basically
just
specify
from
what
function
you
want
spell
to
call
and
from
what
file
you
wanted
to
take
and
also
how
often
you
want
it
to
run,
and
there
is
also
an
option
to
set
init
arguments
to
that.
E
E
What
what
I
have
here
I
have
a
project
just
a
basic
project
created
with
fluence
service
new
fluent
spell
new,
no,
like
almost
no
customization
I
have
a
certain
service
full
here
that
just
has
a
greeting
function
and
it
takes
name
and
count
and
prints.
Some
string,
like
hello
for
the
third
time
and
also
I,
have
here.
I
have
a
spell.
That's
called
my
spell,
and
it's
like
here,
you
can
see
that
the
buff
is
specified
here
and
worker
consists
of
two
things
of
one
spell
of
one
spell
and
one
service
all
good.
E
E
We'll
see
in
a
moment
why
and
run
it
every
10
seconds
and
stop
doing
so
in
that
much
seconds,
so
the
spell
fun
spell
could
run
any
Aqua
function
as
long
for
for
now
we
have
a
limitation
that
it
takes
only
like
plane
arguments,
not
the
objects,
I
believe,
but
we
will
fix
that
in
the
future.
So
what
here
init
arguments
automatically
go
here?
E
E
No
more
this
you
just
import
service
from
service.aqua,
and
you
just
call
the
function,
and
it's
already
definitions
are
already
there.
You
just
use
it
and
that's
basically
it
that's
how
you
organize
your
spells
in
your
project,
with
direct
hosting
and
for
example,
if
you
want
to
check
out
the
logs,
if
you
want
to
check
out
the
logs
for
the
like,
for
your
spell,
you
can
run
fluence
worker
logs.
It
will
automatically
get
information
from
the
dot
fluids.
E
There
is
a
like
workers,
yaml
containing
information
about
deployed
workers,
and
it
just
it
even
prints
it
here
like
spell
ID
host
ID,
and
then
it
just
prints
the
logs
as
they
were
written
by
the
aqua,
so,
for
example,
hifolics
for
the
zero
of
time.
It's
exactly
what
I
logged
here
like
greeting
I,
do
loggers
and
that's
exactly
what
has
been
logged.
So
we
have
logs
and
also
you
have
like
more
technical
lags
about.
Like
spell
deploying
created
service,
install
spell
created,
subnet
all
that
stuff
and.
B
C
Thank
you
very
much
for
such
detailed
presentation
on
the
Spells.
I
have
a
question
actually,
so
you
said
that
right
now
like
it
only
allows
timer
based
events
and
what
events
are
planned
in
the
future.
So,
for
instance,
will
it
be
able
to
get
some
HTTP
events
or
some
events
like
from
blockchain.
So
what
are
the
plans
for
it.
E
Yeah,
hopefully,
we'll
have
HTTP
events,
so
it's
we
have
like
yeah
design
in
mind
on
how
to
process
HTTP
requests
on
peers
and
send
them
to
spells
so
I
hope
that
will
happen,
and
there
is
a
plan
for
blockchain
events
as
well,
though
right
now
we
have
blockchain
can
integrate
it
on
Services
level,
not
on
the
raspberry
level,
so
I'm
sure.
Maybe
it
will,
it
will
be
kept
there
and
there
will
be
no
blockchain
trigger.
You
will
have
to
do
that
like
through
other
spells.
E
You
can
always
have
a
spell
that
listens
to
blockchain
and
triggers
other
spells
through
mailbox
and
yeah.
There
is
also
a
connection
disconnection
trigger
possible.
For
example,
you
might
care
that
your
users
connect
on
or
disconnect
and
update
their
statuses
if
you're
doing
a
messenger
or
something
like
that,
but
that
needs
some
strict
security
guarantees.
So
no
one
can
spy
on
your
users
or
you
cannot
spy
on
other
users.
So
that's
are
the
plans
but
we're
looking
into
more
possibilities
here.
A
A
This
may
be
short.
Oh
yeah,
so
I
I
I've,
already
got
some
things
working
today,
so
I
did
like
I
I
I
I
did
made
a
deploy
with
the
serverless
option.
I
made
a
deploy
with
the
direct
something
option,
but
with
the
latter
one.
It's
like
a
practical
questions,
even
though
I
changed
things
in
my
fluence
or
and
in
the
washing
file.
It
keeps
saying
that
it's
already
the
deal
already
exists.
So
what
is
sort
of
the
ID
by
which
it
checks?
If
it's
already
exists,.
E
So
a
great
question
I
understand
where
you're
coming
from
so
yeah
we've
right
now,
we've
fluent
still
deploy
with
that
serverless
mode.
We
have
this
hidden
potency
implemented
as
a
hotfix,
because
whenever
you
kind
of
safe
fluence
deal
deploy
after
you
like
the
second
time,
what
it
does
it
just
updates
the
certain
like
updates
the
definition.
So
it
doesn't
recreate
the
deal
it
just
sends
an
update
vendor.
E
A
E
No,
it
does
so
if
it
says
that
it
didn't
do
anything,
then
it
didn't.
Do
anything
I'm
saying
that
you
in
our
experiments
it
it
like
behaved
correctly,
but
you
may
found
the
bag
and
also
what
I'm
saying
is
that
that
only
happens
with
fluence
deal,
deploy,
Prince
deals,
deploy
but
never
happens
with
fluence
workers.
A
F
B
Hey
everyone
happy
to
share
some
some
things
from
if
Denver.
So,
yes,
you
know
at
the
end
of
the
February,
there
was
a
huge
event
in
Denver
and
we
participated
and
we
did
a
lot
of
stuff
there,
so
not
only
the
main
event
with
the
hackathon,
but
also
we
held
our
Summit.
We
have
our
breakfast
and
a
lot
of
workshops.
B
We
have
a
lot
of
like
speaking
slots
and
many
different
events,
so
here's
our
decentralized
Network
Summit,
which
is
a
pretty
big
event,
collecting
like
all
a
lot
of
good
people
from
different
projects,
we're
speaking
about
technology
and
all
the
related
stuff,
so
good,
good
news
that
the
video
from
the
Summit
is
already
out,
which
has
discovered
just
today
when
preparing
this
slide.
So
here
is
the
QR
code
that
you
can
find
going
to
the
whole
summit
video.
B
There
was
like
five
talks,
which
is
pretty
interesting,
so
go
check
it
out
and
we're
gonna
continue
to
do
this
Summit
and
yeah,
probably
in
Austin
we're
going
to
have
the
same
event.
Also.
We
have
lunch
breakfast
and
a
lot
of
workshops
there
so
yeah.
This
is
another
event
with
a
bunch
of
people
yeah,
the
next
one
was
yeah
fvm
hacker
Bay
was
very
good
event
organized
by
filecoin
and
protocol.
Labs
yeah,
like
just
event,
was
dedicated
mostly
two
protocol
Labs,
but
we're
always
happy
to
join
their
event
and
yeah.
Give
a
talk.
B
Workshop
and
yeah
I.
Don't
think
that
we
have
videos
from
those
events,
but
still
was
good
to
participate.
Yeah
and
the
main
is
Denver
event.
We
had
a
talk.
You
can
check
it
out
also
where
how
Tom
speaking
yeah
we
had
a
boost.
There
was
a
lot
of
people
was
more
than
10K
people.
There
was
really
massive
and
yeah.
It
was
a
fact
it's
on
where
we
have
our
next
slide.
Next
slide.
B
Let's,
let's
check
e.
Oh
one
slide
is
missing
for
our
winners
of
the
hackathon.
There
was
a
four
of
them
yeah
here.
Is
it
so
yeah
we
have
five
winners.
The
one
of
them
was
bring
To
Us
by
developer
Dao.
As
you
remember,
during
the
previous
call,
we
presented
you
the
initiative.
So
if
you
want
to
go
to
East
Denver
but
like
maybe
you
don't
have
enough,
you
know
money
to
go
to
to
buy
tickets
and
Etc.
B
F
D
All
right,
let's
start
so
better
PC-
is
the
project
that
we
built
during
Denver
and,
as
you
can
probably
tell
from
the
name,
is
an
RPC
solution,
but
it
is
trying
to
do
a
few
things
better
than
current
RPC
Solutions.
So
let's
have
a
look
at
the
traditional
RPC
solutions
that
are
currently
being
used
by
most
of
the
dubs.
We
just
have
a
regular
adapt
from
10
and
which
is
talking
to
an
RPC
endpoint,
and
usually
this
is
centralized.
So,
for
example,
we
can
think
of
infuria
or
Alchemy
or
quick
node.
D
Basically,
we
are
just
relying
on
them
to
talk
to
to
read
and
write
data
from
the
blockchain,
and
this
is
simple.
It
works,
but
it
has
a
few
problems
and
few
few
improvements
that
can
be
done.
So
what
are
the
problems?
Basically,
by
relying
on
a
singular
and
centralized
provider?
We
have
a
single
point
of
failure.
This
means
that
if
inferior
Alchemy
goes
down
our
front
end
Goes
Down
And,
basically
most
of
our
users
can't
interact
with
our
application,
and
this
is
also
so.
D
This
is
the
real
reliability
problem,
but
we
also
have
censorship
problems
because
being
centralized.
These
providers
can
decide
to
censor
or
also
track
IPS,
which
is
something
that
recently
happened
within
fewer
I
know.
Many
people
were
really
happy
about
it.
So
this
is
basically
the
situation
here.
Yeah
we
have
decentralized
protocols
on
chain
which
is
awesome,
but
then
our
front
ends
are
actually
talking
to
centralized
intermediaries.
So
that
means
that
if
there
are
problems,
99
of
our
users
won't
be
able
to
use
our
protocol,
even
if
it
is
open
and
decentralized.
D
So
how
is
better
RPC
different,
as
we
can
see
from
the
this
image?
Basically
right
now
we're
not
relying
anymore
on
a
single
RPC
provider,
but
on
many
of
them,
so
we
still
have
actually
centralized
providers
under
the
hood,
but
not
a
single
one.
So,
for
example,
we
can
rely
at
the
same
time
on
infuro,
Alchemy
and
quick
node,
and
also
we
are
not
interacting
directly
with
these
providers.
D
So
we
don't
have
to
do
this
all
from
a
single
server
get
away,
but
we
can,
for
example,
call
many
providers
using
different
peers
by
making
this
process
way
more
efficient.
So
the
way
better
PC
works
is
that
for
all
these
providers
that
we
are
using
we're
tracking
a
score
so
basically
a
number
that
defines
how
good
this
provider
has
been
so
far
and
in
order
for
this
number
to
make
sense,
we
need,
of
course,
to
have
some
data
and
try
some
RPC
calls.
D
So
we
have
a
sort
of
training
algorithm,
so
basically
a
process
that
we
followed
to
to
build
this
course
until
the
point
where
they
actually
start
to
make
sense
and
the
algorithm
is
the
following.
So
we,
when
the
RPC,
when
our
Gateway
receives
an
RPC
code,
basically
is
going
to
execute
up
the
same
code
in
parallel
to
all
providers,
and
the
cool
thing
is
that
every
single
peer
is
going
to
call
a
different
provider.
How
we
can
see
like
we
can
see
in
this
picture.
D
Once
we
have
all
the
responses
from
the
providers
we're
going
to
execute
a
program.
So
basically
we're
checking
all
the
responses
and
making
sure
that
at
least
a
certain
number
of
responses
are
the
same
value,
and
this
is
basically
for
making
sure
that
the
response
that
we
got
actually
makes
sense
because,
for
example,
we
call
five
different
providers
and
we
have
five
different
responses.
D
D
We
basically
use
the
following
three
ones,
so
latency,
so
basically
the
fastest
providers
will
get
a
higher
score
and
we're
also
optimizing
a
little
bit
here,
because
since
every
peer
is
calling
a
provider,
we
don't
want
to
to
add
that
same
peer,
always
calling
the
same
provider,
because
then
we
might
have
actually
the
peer
to
be
slower
and
not
the
provider.
So
we
are
also
randomizing
this
part,
then
we
want
the
providers
to
be
aligned
with
the
Quorum.
D
So
basically
we
increase
the
score
of
the
providers,
whose
response
is
the
same
as
the
most
frequent
response,
so
basically
the
most
reliable
ones
and
finally,
either
provider
fails.
We
decrease
the
score
and
yeah.
So
this
is
the
basically
the
training
algorithm
and
the
idea
is
to
do
this
algorithm
quite
a
few
times
so
that
the
scores
that
were
for
our
providers
can
actually
start
to
make
sense.
D
And
after
that
we
can
achieve
what
we
call
an
Optimizer
physical,
which
basically
is
gonna,
get
all
our
providers,
order
them
by
score
and
use
the
better
ones.
So
it's
gonna
use
first,
the
the
provider
with
the
highest
score
to
the
the
RPC
code
that
we
want
to
do
and
in
case
of
failure,
is
going
to
the
it's
going
to
use
the
second,
then
the
third
one
and
so
on.
So
basically
we're
ending
payloaders
so
that,
even
if
the
the
provider
that
we
think
is
the
best
fails,
we
are
still
good.
B
B
C
D
Yeah
so
we
haven't,
we
don't
really
have
an
API
or
something
for
that.
We
didn't
like
save
a
scores,
something
that
like
for
now
is
in
memory.
So
basically,
once
you
start
a
server,
it's
gonna
start
tracking
them,
but
then,
once
you
shut
down
a
server,
you
don't
have
basically
a
discourse
anymore
and
of
course
this
is.
This
is
good
for
a
hackathon
project.
But
of
course
this
wants
to
be
used
in
production.
Then
you
you
need
to
plug
in
a
database
for
tracking
this
course
Etc.
C
D
Yeah,
so
basically,
this
will
take
it
even
to
the
next
level.
We
actually
talked
with
the
Pokemon
guys
at
the
Denver
and
yeah.
Basically,
the
vision
similar.
We
can
we
probably
Aqua.
We
have
more
flexibility,
because
we
are
actually
the
ones
doing
the
algorithms,
so
we
can
decide
how
to
orchestrate
all
the
calls,
but
then,
if
their
actual
goals
are
also
to
Providers
like
plug
Network,
that
is
also
relying
on
many
providers
behind
the
scenes.
That's
even
even
better
for
sure.
A
And
the
super
coolest
thing
would
be
that
I,
don't
think
it's
possible
now,
with
Talk
network,
to
house
to
host
your
own
nodes.
But
if
you
would
house
like
one
of
their
notes
either
booked
or
anchor
in
combination
with
a
a
fluence
note,
then
you
could
relay
it
on
the
on
the
server
itself
without
an
extra
HTTP
call
without
using
the
curl
adapter.
E
B
Thanks
so
much
yeah,
if
we
don't
have
any
more
questions,
we
can
move
forward
with
different
things
regarding
events,
so
yeah
actually
we're
gonna
have
more
this
year,
so
we're
gonna
be
in
Brussels
for
ipfs
being
in
April,
also
in
consensus
in
April
and
compute.
Our
data
in
the
early
May,
so
ECC
berries.com
and
talking
2049,
is
coming
like
summer
and
Autumn
so
actually,
like
I,
think
I'm
gonna
share
more
during
the
next
Community
goals,
but
the
upcoming
is
IP
first
ping.
B
It's
going
to
be
only
developer
related
event,
but
you
still
can
meet
our
developers.
There
feel
free
to
join
the
event.
They
also
have
a
scholarship.
If
you
want
to
join,
feel
free
to
apply.
They
have
a
website
and
everything
there.
Consensus
is
pretty
huge
event,
but,
like
probably
maybe
we
can
I
have
a
chance
to
meet
some
of
you
there
as
well,
and
computer
over
data
is
actually
also
like
developer
oriented
and
super.
B
C
B
Else
we
have
here-
oh
yeah,
so
yeah
for
for
this
community
critical.
We
finally
have
a
poap.
This
is
kind
of
an
nft
is
a
proof
of
attendance,
so
you
can
go
to
your
DM
right
now,
check
the
message
from
myself
and
yeah:
just
click
the
link
fill
out
your
ethereum
address
or
ens,
or
maybe
even
email,
and
try
to
claim
your
Co-op.
This
is
actually
free,
so
yeah
you
didn't
have
to
pay
for
transaction
fee.
C
C
C
A
A
F
F
A
Or
how
can
I?
Maybe
the
question
is:
how
can
if
people
ask
me
about
fluence
and
I,
trying
to
explain
that
you
that
I
can
orchestrate
different
data
flows
between
peers,
that
you
have
a
way
to
sort
of
verify
that
everything's
been
done
correctly
and
that
we
can
trust
the
things
that
we
can
build
on
it?
How
can
I
start
understanding
and
maybe
in
the
future,
explaining
the
the
actual
logic
behind
it.
F
G
G
So
we
have
like
influencer,
you
could
call
service
and
services
a
webassembly
code
and
basically
like
each
webassembly
code,
could
trick
you
yeah
because,
like
or
even
for
an
old
provider,
it's
more
easier
for
Just
For
example
to
return
zero
or
to
return
like
I,
know
some
other
stuff
and
not
to
do
the
computation
itself,
hey,
because
computation
requires
some
Hardware
resources
and
all
the
stuff,
and
the
first
thing
is
to
kinda
protect
against
such
cases.
So
generally,
there
are
only
I
know
three
or
two
main
way
to
protect
in
the
distributed
systems.
G
The
first
one
is
like,
or
what
before
he
went
before,
because
some
of
them
are
kind
of
hybrid
of
others.
So
the
first
one
you
can.
You
can
just
trust
the
service
yeah.
For
example.
You
know
that
some
good
guys
like
serve
this
service
for
you
and
there's
no
reason
just
to
for
like
to
trick
here.
Second
case
is
to
have
a
reputation
based
mechanism.
Is
that
we
want
to
have
this
truss
graph?
The
third
case
is
to
have
a
form
of.
G
Yeah
you
could,
for
example,
so
very
imagine
it
in
a
following
case,
so
you
write
Aqua
code,
some
service.
You
want
to
have
a
kind
of
consensus
to
be
sure
that
the
result
of
the
service,
so
you
could
trust
the
result
of
the
service
yeah
and
you
can
write
with
some
form
of
I
know
like
syntax.
If
you
can
write
that
oh
I
want
to
run
the
service
actually
on
a
20
nodes
across
a
network
and
compare
results
and
have
a
bft
consensus
or
something
like
that,
it's
the
third
one.
G
G
G
Obtain
proofs
that
the
result
of
this
code
is
is
well,
it
is
like.
Is
it
really
result
produced
by
the
code
that
you
uploaded
and
it's
really
promising?
What
what's
the
nearest
yeah?
Thank
you
Bernard,
although
in
its
research
stage,
because
now
two
major
drawbacks,
the
first
one
is
a
performance.
So
it's
a
it's
like
this
performances.
I
know
on
the
real
examples
it's
about
dozens
of
seconds.
It's
not
not
so
good.
The
second
one
is
that's
not
all.
G
Webassemble
instructions
are
supported
now,
but
guys
are
still
actively
working
on
and
also
I
also
kind
the
weekend.
This
is
a
project
yeah.
It
was
about
service
calls
yeah,
and
we
want
to
provide
you
a
way
to
choose
like
option
from
this
for
from
this
list
of
forups,
for
every
service
call
so
usually
as
a
practice
would
be
something
like
that.
So
you
can,
if
you
don't
want
to
consensus,
key
or
something
like
that,
because
it
should
be
kinda
paid
options
yeah.
G
You
can
just
say
that
oh
I
trust
the
result,
and
it's
and
it's
how
work
now
yeah,
because
now
you
should
trust
result
of
services
or
you
can
like.
Otherwise,
you
can
should
do
your
own
consensus
in
some
way.
Second
option
is
not
about
service
result,
but
about
registration.
Where
about
how
aquarium
works
or
how,
like
all
this,
topology
hopes
are
done,
and
there
are
only.
There
are
also
some
thoughts
about
that.
The
first
one
is
also
to
use
the
key
magic
magic.
G
So
aquarium
will
produce
proof
that
this
topological
hopes
Hope
was
correct
and
the
like
on
each
step.
This
proof
could
be
easily
validated
and
now
what
what
is
its
far
future
far
bright
future.
Now
we
are
working
on
signatures
in
aquarium,
so
you
can
like,
for
example,
see
last
pull
requests
in
aquarium
made
by
E1.
G
So
this
poor
request
there
intended
to
introduce
signatures
and
every
node
would
sign
like
every
service
result
and
the
signature
will
be
put
in
data
that
move
across
Network
and
then
it
would
be
compared
on
each
peer
and
each
peer
would
analyze
was
like
appeared
in
the
middle
tamper
data
or
not.
So
it's
basically
force
that
okay.
G
G
Main
the
main
attacks
that
we
want
to
mitigate
with
that
is
a
peer
in
the
middle
or
man
on
the
middle
we
have
on
some
other
node,
could
temper
service
result
from
different
nodes,
and
also
we
want
to
review
this
mechanism
for
all
chain
part
so
on
chain.
We
also
have
Aqua,
VM
and
Aquarium
will
like
validate
particles,
submit
the
tone
chain,
and
this
particle
will
contain
signatures
and
according
to
validate
whether
all
hopes
be
correct.
Yeah,
it's
not
not
about
service
calls.
It's
only
about
hopes
that
cops
are
correct.
G
According
to
the
data
that
such
Services
provide,
yeah,
it's
and
it's
the
second
viewer
of
verification,
validation
and
security
in
our
system.
So,
like
basically,
two
to
two
things.
The
first
one
is
about
service
calls.
There
are
four
ways
to
mitigate
them,
and
second
one
is
about
Aqua
VM
and
about
orchestration
where
security
and
probability.
A
G
Hope,
I
hope
that
you
know
like
it's
really
a
tough
topic
and
we
put
already
a
lot
of
like
kind
of
effort
in
this
topic.
We
discussed
it
time
to
time
and
now
I'm
working
on
a
kind
of
document
about
how
it
should
be
organized
and
how
it
should
be
structured.
So
hopefully
when,
when
I
finish,
review
this
document,
so
hopefully,
if
you
want
I,
can
assured
somewhere,
though
it
would
be
just
the
research
I
think
that
we'll
implement
it
I
know
I.
So.
C
Okay,
guys
so
looks
like
our
goal
is
getting
to
its
logical
ends,
so
thanks
everyone
for
attending
shout
out
to
the
guys
from
Talent
Lair
for
their
demo
and
well.
Thank
you
all
for
attending.
Thank
you
for
your
all
your
questions
and
see
you
on
our
next
Community
call
so
guys
yeah
have
a
good
evening
and
see
you
thank.