►
From YouTube: wasmCloud Community Meeting - 08 Feb 2023
Description
Welcome to the wasmCloud community! Tune in live where we discuss the latest developments in the wasmCloud ecosystem, WebAssembly standards, and break out sweet demos.
Agendas for wasmCloud community meetings can be found at: https://wasmcloud.com/community
A
Alrighty,
hello,
everyone
welcome
to
the
wasm
Cloud
Wednesday
community
meeting
on
February
8th
we've
got
a
pretty
jam-packed
agenda
today.
As
usual.
It's
always
always
going
to
be
fun,
but
let
me
go
ahead
and
share
that
really
quick
and
then
we'll
get
right
into
the
super
fun
demo
that
we
have
every
week.
A
So
if
we
take
a
look
at
today's
agenda,
this
is
up
on
a
deploy
preview
but
it'll
be
live
on
the
Watson
Cloud
site
here,
just
after
the
meeting
with
the
notes
and
and
recording
we're
going
to
have
Jordan
demoing
wasm
air,
which
is
actually
a
demo
from
probably
a
few
years
ago,
maybe
even
before
wasmo
Cloud
was
called
wasmcloud,
but
a
super
cool
demo
to
show
off
with
actors
and
a
few
providers.
I've
got
a
little
announcement.
A
Just
a
general
call
that,
after
this
meeting
about
an
hour
after
this
meeting
wraps
up
at
three
there's
going
to
be
a
bytecode
Alliance
live
stream
with
Bailey
and
Luke
Wagner
talking
about
wasm
standards.
So
that's
going
to
be
really
exciting.
I'm
going
to
talk
about
one
of
the
new
wash
releases,
the
awesome,
Cloud
roadmap
and
then
go
a
little
bit
into
actor
models
and
and
wasmcloud
actors
and
I
think
that
this
will
be
a
this
would
be
pretty
full
for
a
community
meeting.
A
C
B
Cool
yeah,
so
it
was
well
before
wasm
Cloud
was
called.
Wasn't
Cloud
Kevin
had
this
awesome
demo,
where
a
little
backstory,
and
so
when
you
look
in
things
like
the
SDR
World,
which
is
the
software-defined
radio
world,
you
start
to
find
that
nope
nope
nope
nope,
you
know
I,
don't
where's
the
plus
button
anyway,
a
lot
of
our
radio
waves
out
there
are
insecure
and
there's
a
lot
of
fun
data
that
we
can
just
kind
of
grab
out
of
the
air.
B
One
of
them
is
airplane
data
and
I
apologize
that
my
thing's
freaking
out
right
now.
This
is
a
seven-year-old
computer
and,
what's
cool
is
if
you
buy?
If
you
go
on
Amazon,
you
buy
the
right
little
dongle,
which
costs
about
24
bucks
you
plug
it
in
and
there's
a
whole
lot
of
software
out
there.
You
can
actually
stream
the
unencrypted
data
of
aircraft
locations
to
your
computer.
One
famous
right
now
is
elon's
plane.
He
gets
very
angry
when
anyone
tracks
his
plane.
B
So
this
is
what
Kevin
did
a
while
back.
It
was
in
the
terminal.
It
used
a
then
telnet
capability
provider
which
I
will
not
be
using
because
it's
rust
and
I
couldn't
figure
it
out.
But
essentially
what
will
happen?
Is
you
see
back
in
the
day?
Oh
my
God.
B
So
back
in
the
day
when
they
did
it,
so
that
was
Kevin
at
his
house
and
this
was
Liam
his
house,
so
you
could
actually
see
the
stations,
you
could
see
the
aircraft
and
you
could
you
know
which
was
really
cool
now
fast
forward
to
local
days.
B
You
have
Jordan
in
Colorado
and
you
have
Liam
in
Washington,
DC
and
actually
what's
happening.
Is
we've
created
a
provider?
The
provider
provides
the
asbd
adsb
data,
which
is
air
data,
doesn't
I,
don't
really
means,
but
I
don't
really
want
to
scroll
into
my
house,
because
it's
on
top
of
my
house
but
Liam's
is
not
on
top
of
his
house,
because
I
didn't
know
his
address.
B
But
if
you,
if
you
go
in
close
enough,
you'll
actually
see
a
little
tower
that
says
Liam
and
what
that
represents
is
a
Raspberry
Pi
near
Liam's
house
that
you
know
is
the
antenna
and
what
we
do
is
it
does
some
math.
It
knows
the
location
of
the
antenna,
it
pulls
the
data
out
of
the
air
and
then
with
that
data
it
can
actually
calculate
the
Latin
log
of
all
these
planes
and
if
you
look
closely
enough,
the
planes
have
their
ID
numbers
and
they're
actually
moving
every
five
seconds.
B
Sorry
I'm,
not
a
front-end
guy
I,
can't
make
the
playing
point
in
the
right
direction.
Sorry,
but
this
is
really
cool,
so
we're
actually
working
in
unison,
Liam
streaming
from
his
pie
in
DC
and
me
streaming
from
my
VM
in
Colorado,
I
live
in
Boulder,
that's
close
enough
yeah
and
it's
really
cool.
So
essentially
what
would
happen
is
if
we
sent
all
of
you
this.
You
know
thirty
dollar
dongle,
you
plugged
it
in
and
attached
to
the
lattice.
B
We
could
essentially
use
wasmcloud
to
replicate
FlightAware,
which
is
a
website
that
does
this
as
well
and
right
now,
I
mean
you're.
Already
seeing
like
IDs,
but
you
know,
when
you
break
down
the
messages,
there's
a
lot
more
data,
we
can
overlay
things
like
what
flight.
It
is.
What
area
you
know,
what
playing
the
tell
tell
the
tail
tag
of
the
plane
is.
We
can
actually
do
heading
and
point
the
plant
in
the
right
direction.
So
no
it's
kind
of
cool,
and
if
we
look
here,
this
is
essentially
what
it's
doing.
B
We
have
this
dump
1090,
that
is
a
open
source
piece
of
software.
That's
been
around
for
a
while.
It
essentially
grabs
it
all
out
of
the
you
know,
out
of
the
air
and
then
serves
it
over
a
telnet
server,
and
then
our
provider
picks
it
up
off
the
telnet
server
and
sends
it
to
our
processor.
B
Our
processor
then
does
some
stuff
to
create
the
data
and
sticks
it
in
our
KV
store,
and
then
we
just
have
a
typical
API
that
if
we
were
to
hit
the
API,
you
would
see
the
data
and
then
the
front
end
scraping
those
endpoints
every
X
seconds.
B
A
Yeah
so
Jordan
I'm,
gonna
I'm
gonna,
ask
a
few
more
questions
so
that
that
provider,
I
I
know
you
said
that
it
kind
of
interacts
with
something
that's
open,
source
and
readily
available.
What
did
you
I
know
you're
a
a
fan
of
the
Gophers?
Did
you
write
this
one
and
go
or
was
this
one
already
available.
B
So
dump
1090
is
running
as
a
process.
It's
serving
its
data
to
a
telnet
server.
At
that
point,
our
provider,
which
is
go
picks
it
up.
You
know
just
streams,
the
talent
provider
or
the
telnet
data
back
to
it
and
then
takes
the
raw
message,
edits
the
raw
message
and
extracts
the
data
that
I
want
and
then
sends
it
off
to
the
processor
to
be
processed.
However,
I'm
processing
it.
A
C
A
I
was
just
trying
to
get
a
handle
on
like
where
all
these
components
have
to
run
looks
like
you're
running
it
all
like
on
maybe
on
your
local
machine.
So.
B
B
Liam's
pie
in
DC:
this
is
my
computer
in
Colorado,
and
I
am
cheating
because
you're
asking
yourself:
how
are
they
sharing
that
redis?
That's
actually
over
tailscale,
so
Liam
and
I
are
on
the
same
telnet,
which
allowed
me
to
connect
the
HD.
This
red
is
store
here
to
the
redis
server
on
my
laptop.
D
Could
you
just
front
that
with
the
provider,
though,
you
know,
couldn't
the
you
just
have
the
adsb
dump
night
1090
capability
providers
on
the
remote
nodes
and
that
communicates
to
you
know
an
actor?
That's
Upstream
at
your
place
and
obliviate
to
me
for
tail
scale
in
this
case.
So.
B
Kinda,
this
is
kind
of
where
the
the
so
we
can't
have
multiples
of
the
same
provider
running
on
the
same
lattice.
B
So
I
have
to
put
us
on
different
link
depths
and
then
all
different
link
desks.
Then
the
actors
have
to
be.
You
know
one
per
link,
deaf
and
then
yes,
the
capability
provider
at
that
point
could
still
point
to
the
same
redis
server.
But
at
that
point
it
it's
essentially
the
same
thing
so
kind
of
not
really
is
the
answer
there.
B
I,
don't
know
how
it
was
done
back
in
the
WASP
days.
If
link
deaths
were
able
to
be
shared
or
not,
but
to
my
knowledge,
I
can't
run
two
of
the
same
provider
on
the
same
on
the
same
link,
definition
right,
Kevin,
question,
mark.
E
Yeah
back
in
the
good
old
days,
the
idea
was
that
your
was
it.
The
link
name
would
correspond
to
like
the
the
station
ID
or
the
antenna
ID,
and
so
you'd
run
one
provider
plus
link
name
for
each
of
the
base
stations
that
are
running,
and
then
you
could
have
any
actor
that
any
of
the
adsb
processor
actors
running
anywhere
handle
any
of
that
input,
because
you
would
basically
just
have
to
create
one
link.
Def
per
base
station.
E
So
that's
one
way
to
architect
it.
There
are
a
couple
of
different
ways
to
deal
with.
You
know
pooling
the
data
that
are
a
little
bit
more
efficient
but
yeah.
This
is
generally
the
idea.
B
And
and
I
I
will
say
through
this
process,
that's
the
one
thing
I
would
actually
look
for
input
on
is
is
the
better
way
to
architect
it
because
to
Liam's
point
this
is
not
the
smartest
way,
because
I'm,
not
even
using
link
deaths
at
this
point
essentially
telescale
is
is.
Is
my
hack
to
get
around
link
definitions.
A
And
beat
beat
Kevin
by
a
millisecond,
so
just
just
in
case
I
understand
like
I,
want
to
understand
right.
Is
there
any
reason
why
we
couldn't
use
one
link,
definition
for
the
the
redis
provider
and
then
just
use
the
like
the
station
ID
as
like
a
prefix
in
redis,
so
that,
like
the
same
connection
or
any
actor,
can
act
on
any
station?
It's
it's
more
likely
to
be
the
local
actor.
That's
right!
D
B
It's
on
this
link,
Def
and
if
I
were
to
put
Liam
in
the
same
lattice,
it
would
be
the
provider
and
and
Liam
right.
So
just
imagine
they're
both
sitting
there
and
then
I
have
the
actor
over
here.
But
the
actors
are
compiled
with
the
link.
Def
set
right,
so
I
wouldn't
be
able
to
connect
both
of
them
or
may
I've,
never
written
an
actor.
A
E
I
was
about
to
bust
there,
so
the
one
of
the
architectures
that
I
I
think
I
talked
about
it
during
one
of
the
conference
talks
that
I
gave,
but
I
didn't
actually
document
it
in
terms
of
like
a
reference
architecture
and
I
think
your
point
is
extremely
good,
which
is
that
once
we
get
this
thing
sort
of
Resurrected
documenting
the
various
architectures
for
the
various
different
scales
is,
would
be
a
huge
benefit.
E
You
would
want
to
start
a
capability
provider
per
Jump,
Then
per
dump
1090
process
and
that
provider
is
basically
responsible
for
scraping
from
the
dump
1090
process
decoding
the
stuff
that
comes
off
the
wire,
because
I
found
this
out
the
hard
way
the
GPS
coordinates
are
not
actually
in
normal
latitude
longitude
when
they
come
off
the
1090
dump
they're
in
a
bit
packed
optimized
form.
E
So
all
that
work
should
be
done
by
the
provider.
Then
the
provider
shoves
a
adsb
update
message
down
to
the
one
bound
actor,
so
you
have
one
actor
and
you
have
a
link,
diff
per
dump
1090
station
and
you
can
run
you
know,
500
copies
of
the
actor
doesn't
matter,
but
you
would
run
you
know
n
number
of
those
in
order
to
establish
the
the
right
level
of
scale.
But
again
these
actors
are
stateless.
E
And
then
you
have
actors
consuming
that
data
which
are
likely
running
close
to
the
edge,
if
not
already,
on
the
edge,
and
then
those
actors
are
then
responsible
for
bubbling
that
data
to
the
the
true
back
end
and
inside
that
true
back
end
is
where
the
processing
persistence
view
materialization.
All
that
stuff
takes
place
so.
E
Yeah
I
would
I
would
love
to
write
it
before
you
know
guide
on.
You
know
how
this
would
how
this
would
be
built
to
be
a
flight
to
work
loan
versus
a
a
small
adsb
demo.
D
Well,
Kevin,
Kevin
I
think
that's
awesome.
It
would
be
great
now
that
Jordan's
kind
of
like
updated
everything
and
you
know
brought
it
back
to
the
current
version
of
wasm
cloud.
Maybe
we
could
do
a
spike
on
that,
as
we
kind
of
build
this
out
as
a
community
example
or
demo
or
something
along
those
lines.
B
That's
actually
great
guidance,
I
think
I
followed
at
least
80
percent
of
everything.
You
said
when
I
wrote
it
I
did
not
know
that
actors
could
have
multiple
handlers.
That
is
new
to
me.
Therefore,.
E
A
There,
because
Kevin
I
always
find
it
really
really
fun.
Listening
to,
like
you
reason
out
the
way
things
can
be
architected
and
why
it's
most
efficient
I
have
no
idea
how
it
would
how
feasible
it
would
be
to
put
this
in
like
a
generic
guide,
but
I
think
like
when
we're
writing
up.
Examples
like
this
reasoning,
why
we've
created
some
components
as
actors?
A
What
like
the
relationship
with
link
deaths
and
all
that
stuff
and
and
not
just-
and
this
isn't
like
accusing
anything
like
I-
think
we
lay
out
our
examples
currently,
but
we
may
not
explain
exactly
why
we
have
this
as
a
separate
actor
and
why
we're
doing
this,
like
in
the
pet
clinic
example
like
why
we
have
an
API
Gateway
and
then
we
do
actor
calls
like
that.
That
stuff
would
all
serve
as
really
good
examples
for
people
trying
to
take
their
ideas
and
turn
it
into
a
wasm
Cloud
app
in
in
the
most
efficient
way.
A
E
It's
almost
like
for
some
of
the
larger
samples.
What
we're
what
we
could
do
is
basically
create,
like
mini
adrs,
for
that.
So
to
your
point,
we
we
would
want
to
document
and
walk
people
through
not
only
what
the
various
components
are
and
how
it's
all
laid
out,
but
why
it's
laid
out
that
way
and
why
we
chose
not
to
lay
it
out
in
another
way:
yeah
yeah.
D
Phenomenal
job
I
just
want
to
kind
of
point
out
that
I
have
no
idea
when
Jordan
got
all
this
done,
because
I
didn't
even
plug
in
my
Raspberry
Pi,
until
probably
11
pm
last
night
eastern
time.
So
I
didn't
really
give
you
a
lot
of
time.
I
was
shocked
that
you
have
all
this
up
and
running
and
ready
Jordan
what
an
incredible
an
incredible
demo
today.
Thank
you
so
much
for
all
the
hard
work.
Absolutely.
B
It
was
fun
I
will
I
will
get
it
buttoned
up
to
to
a
proper
architecture.
Now
that
I
know
so
yeah.
A
Sweet,
oh
yeah.
Thank
you.
Thank
you.
Jordan
all
right,
I
am
gonna,
pull
a
little
bit
of
an
audible
and
rearrange
the
order
of
things
in
the
community
meeting,
because
I
think
you
know
with
it
with
our
time
left.
One
of
the
most
important
things
to
talk
about
is
the
waslam
cloud
roadmap.
A
This
was
proposed
a
few
weeks
ago
in
the
community
called
Taylor
here,
actually
wrote
it
up
mostly
and
has
gotten
some
good
feedback
on
the
pull
request,
but
I
think
Taylor.
You
had
a
couple
more
things
that
you
wanted
to
either
either
tease
out
or
bring
up,
and
we
kind
of
want
to
do
a
little
bit
more
of
a
call
for
feedback
here
before
we
merge
this
in
and
start
working
on,
creating
tasks
and
things
to
make
this
roadmap
real.
F
Yeah,
so
Brooks
is
sharing
it
right
now
and
we'll
link
it
I'm
assuming.
But
this
is
an
open,
open,
PR
right
now
on
the
main
water
Cloud
repo,
just
proposing
like
how
we're
gonna
go
forward
with
some
of
the
overall
roadmap
just
to
review.
If.
F
Heard
this
before
this
roadmap
is
meant
to
be
just
like
the
guidelines
for
what
the
maintainers
are
thinking
of
it's
not
like
a
restrictive
document.
It's
not
saying
things
have
to
be
on
this
list
to
be
worked
on
or
anything
like
that.
It's
just
giving
an
idea
of
what
we're
thinking
of
like
moving
forward
I've
kind
of
added
definitions
under
each
of
the
categories
to
say
exactly
what
we
mean
for
each
one.
F
For
additional
feedback,
this
is
going
to
be
the
last
week
and
then
we're
going
to
merge
with
approvals.
So
if
you
have
anything
else
to
say
there,
that'd
be
a
good
one
to
to
drop.
Your
comments
on
I
also
would
like
to
point
out
just
because
it's
here
that
and
I
know,
Rex
is
going
to
be
talking
a
little
bit
about
watch
in
a
second
but
0.60
just
finally
landed.
So
for
those
who
who
were
here
last
week,
the
tag
has
landed
and
you
can
now
zero
dot.
F
60
things
just
a
big
note
for
for
this
I'll
probably
go
back
and
add
some
addition.
Those
release
notes,
are
Auto
created,
so
I'm
going
to
probably
go
back
and
add
something
there,
but
there.
This
is
a
breaking
change
release.
We
are
changing
everything
underneath
the
hood
with
how
without
claims,
basically,
your
link,
defs
and
other
stuff
are
being
stored.
Underneath
the
Hood
there
were
a
bunch
of
bugs
that
people
would
run
into
because
of
like
race
conditions
of
where
things
were
received.
When
and
what
not.
F
So
what
this
is
going
to
do
his
it's
going
to
essentially
slurp
up
all
the
old
data
from
your
lattice
cache
and
write
it
into
key
value.
But
what
this
does
mean
is
if
you're
running
any
0.59
hosts.
When
you
spin
up
a
new
0.60
host,
the
everything
will
still
work
until
you
change
anything
so
start
an
actor
delete,
an
actor
any
of
those
things
then
it'll
all
break.
F
So
if
you're
going
to
be
updating,
make
sure
you
update
from
your
0.59
host
to
0.60
hosts,
there's
also
some
signing
changes
that
we've
done
and
I
know
that
Kevin
explained
this
last
week,
but
the
high
level
changes
that
is
forwards
compatible,
not
backwards
compatible,
so
anything
that
you
use
prior
to
0.60
will
still
work
just
fine.
But
if
you
sign
something
with
the
new
libraries
that
are
coming
out
in
washington.15,
they
will
not
run
on
a
0.59
host.
F
So
these
are
all
changes
that
we've
needed
to
do
for
a
while
that
were
causing
a
lot
of
weird
issues
and
things
that
you
you
may
have
like
seen
like
the
side
effects
of,
and
so
we
just
wanted
to
make
sure
everyone
knew
that
this
was
a
breaking
change
and
that
those
were
kind
of
the
big
breaking
changes
right
there
just
to
be
aware
of
so.
If
you
are
running
your
own,
was
in
Cloud
lattice
make
sure
you
are
updating.
F
All
of
your
hosts,
like
I,
said
as
long
as
you
don't
add
anything
like
running
them
side
by
side
will
not
crash
anything.
If
you
change
anything,
the
0.59
hust
will
be
out
of
sync,
so
make
sure
you
try
to
update
those
as
soon
as
you
can,
which
width
wash
up.
That
should
be
pretty
easy
if
you're
doing
like
local
testing.
So
that's
why
0.15
is
going
to
contain
those
changes.
F
Wanted
to
bring
that
up
too
to
make
sure
everyone
knew
any
questions.
A
Taylor
I
just
wanted
to
to
double
check
because
I
know,
you
said
you
know,
like
the
kind
of
Spiel
that
you
just
gave
is,
is
not
just
going
to
be
something
over
text.
Where
is
that
going
to
go
like
the
the
instructions
and
and
kind
of
details
for
people
who
are
looking
to
update
in
the
right
way?
Where
are
we
going
to
put.
F
E
F
Change
that
down
the
line,
if
people
have
suggestions,
that's
why
we're
a
community
but
for
now
I'm
just
going
to
see
audit
and
say
I'm
going
to
put
it
inside
of
the
release
notes
for
now,
because
I
want
it
somewhere.
So
people
know,
and
then,
if
we
want
to
like
change
this
to
like
having
a
change,
log
style
thing
or
something
else,
I'm
totally
down
with
that.
F
F
A
C
Find
my
mute
button
yeah.
Thank
you.
Is
there
anything
like?
We
should
be
aware
like
how
should
we
handle
the
the
difference
in
claims
right
now
when
when
building,
because
that
was
a
bug
I
experienced,
is
there
something
I
should
change?
I
might
have
missed
that
when
you
were
saying
it,
no.
F
So
probably,
what
happened
if
you're,
referring
to
your
issue,
so
Stephen
had
opened
an
issue
where,
like
it
said
it
couldn't
find
claims
and
whatnot
I
think
we
accidentally
pushed
a
tag
that
was
Zero
fourteen
one
as
a
patch
release,
rather
than
a
that
has
been
yanked
now,
so
you
grabbed
it
in
a
little
bit
of
time.
F
It
was
available
because
that
had
those
breaking
changes
for
the
signing,
and
so
what
was
happening
is
your
0.59
stuff
was
saying
like
hey
I,
don't
know
and,
like
your
tooling
was
all
saying,
I,
don't
know
what
to
do
with
this.
It
didn't
have
the
new
changes,
and
so
those
those
changes
are
now
taken
care
of
like
in
the
zero.
This
you
can
just
use
it.
You
don't
have
to
do
anything
else.
C
A
Yeah
and
I'll
I'll
go
ahead
and
and
add
a
little
more
detail
to
that
and
then
come
back
back
to
Jordan.
The
the
only
thing
that's
different
with
the
new,
like
the
new
claims
with
new
signing
and
everything
is
the
embedded
hash
of
the
webassembly
module.
That
is
a
forwards
compatible,
not
backwards
compatible
change,
so
I
just
want
to
just
want
to
talk
about
how
you
were
able
to
get
0.14.1,
because
it
was
my
my
mistake.
A
I
I,
put
in
two
little
bug
fixes
slash
quality
of
life,
things
into
wash,
which
was
allowing
people
to
use
pre-release
tags
like
letting
people
test
our
release,
candidate,
0.60
hosts
with
wash
up
and
just
a
little
bug
fix
for
for
creating
a
default
wash
context.
A
So
these
were
just
two
little
things:
I
merged
and
I
cut
a
a
patch
release
for
wash,
but
I
did
forget
that,
just
after
we
released
0.14,
we
merged
in
the
newest
version
of
wascap,
and
this
is
actually
where
that
breaking
change
comes
into
play.
So
what
I
I've
gone
and
yanked
the
0.14.1
release
out
of
crates?
A
It's
not
present
in
our
package
cloud
or
or
Brew,
or
anything
like
that
anymore,
so
we're
going
to
be
putting
out
a
PR
pretty
soon
for
0.15
and
that'll
include
0.60
of
the
wasm
cloud
host
as
the
default
host
version
for
wash
up.
So
as
soon
as
you
upgrade
wash
to
the
newest
version,
and
you
run
wash
up
to
get
a
new
host
like
everything
will
be
the
the
proper
version.
You
won't
have
to
worry
about
coordinating
breaking
changes
in
that
way.
So
this
was
actually
another
something
on
the
community
agenda.
A
I
wanted
to
make
sure
that
I
was
was
clear
about
0.14.1
being
something
that
was
incorrectly
pushed
as
a
patch
bump.
So
thank
you,
Stephen
for
being
on
top
of
the
latest
and
greatest
wash,
but
you
should
should
be
able
to
resolve
your
issue
just
fine
by
going
back
to
0.14.
B
No
I
just
had
a
statement.
I
just
wanted
to
say
that
the
the
adsb
work
I
showed
was
all
done
on
60
release
candidate
eight
and
the
now
Infamous
14.1
wash
so
that
was
used
for
all
that
and
while
I
did
experience
a
few
differences,
it
was
only
things
that
had
changed
and
weren't.
Yet
documented
I
will
say
the
one
that
got
me
was
I
have
wash
drain
all
in
a
lot
of
my
scripts
to
get
rid
of
actor
caching
locally.
B
Don't
that
now
deletes
the
download
file
folder
and
that
will
delete
the
whole
front
end
of
the
washboard.
So
I
would
it's
now
like
washed
during
oci
and
wash
during
live.
So
if
you
use
wash
drain
all
don't
do
that
anymore.
A
A
It
would
probably
be
a
good
quality
of
life
thing
to
if
you
drain
downloads,
to
check
and
see
if
there's
a
running,
wasm
Cloud
host,
because
we
could
probably
prevent
some
of
those
those
issues.
You
said
that
was
the
problem
right.
If
you
had
a
locally
running
host
and
you
drain,
and
you
just
remove
the
downloads
folder
that
ends
up
messing
with
the
process,
it.
B
Like
deletes
all
the
CSS,
it's
still
there,
you
can
still
refresh
it,
but
like
all
the
the
all
the
pretty
is
gone.
A
Yeah
I
like
that
as
a
I
like
that,
as
a
like,
a
a
good
first
issue
to
check
and
see
if
there's
a
host
running
locally
before
we
remove
all
the
binaries
and
stuff.
E
Yeah
I
just
wanted
to
add
some
quick
context
for
those
who
might
not
be
aware,
the
the
reason
why
we
changed
wascap,
which
in
turn
changed
the
the
way
that
the
hashing
algorithm
works
when
we
cryptographically
sign
the
modules
is
all
specifically
so
that
we
could
support
newer,
was
and
binaries
generated
by
newer
emitters
from
programming
languages,
so
the
newest
version
of
tinygo
will
build
wasm,
Cloud
friendly
modules,
which
it
didn't
before
the
new
version
of
rust
will
generate
wasi
binaries
that
will
work
with
the
new
host
and
that
didn't
used
to
work
either.
E
If
anybody
had
ever
run
into
that
unknown,
opcode
error,
that
was,
that
was
essentially
what
we
were
fixing
that
yeah
the
op
code
252
Jordan's
talking
about.
So
this
brings
all
of
the
tooling
up
to
date,
so
that
we're
able
to
read
the
most
modern
generated
web
assembly
files.
A
All
right,
yeah
well,
then,
look
out
look
out
should
be
either
later
this
week
or
early
next
week
that
wash
0.15
will
will
come
out
and
that's
going
to
be
be
a
pretty
fun
release
there.
These
changes
have
been
you
know,
we've
been
testing
them
and
trying
to
get
them
out
for
for
a
few
weeks
now
so
looking
forward
to
have
that.
Having
that
out.
A
All
right
well
for
the
the
last
portion
of
our
call,
at
least
before
we
get
to
the
free
discussion
part.
You
know
we,
we
had
a
conversation
the
other
day
in
the
community,
call
about
wasm,
Cloud
actors
and
the
actor
model,
and
that
ended
up
being
a
really
fun
conversation.
We
were
talking
about
terminology
and
came
to
the
conclusion.
I
think
it
was
Kevin
that
said
it
that
you
know.
A
Looking
at
a
framework
like
akka
for
actors,
our
wasmcloud
actors
really
embody
the
the
term
actor
that
akka
uses
for
everything,
except
for
the
fact
that
they
can't
spawn
their
own
actors
and
I'm
I'm,
actually
not
super
familiar
with
the
akka
framework.
I
haven't
like
ran
anything
through
it.
A
So
I
was
hoping
hoping
to
get
a
little
more
detail
on
what
that
actually
looks
like
and
Kevin.
If
I'm
totally
teeing
you
up
here,
but
I
I
want
to
understand
the
idea
of
actors
launching
other
actors,
because
you
can
technically
do
it
with
wasmcloud
you
can.
You
can
use
the
lattice
control
interface
to
say:
hey,
launch
an
actor,
but
is
this,
you
know,
is
the
concept
of
an
actor
launching
another
actor
to
perform
a
little
bit
of
work
and
then
and
then
exit?
A
Is
it
to
create
another
long-running
actor
like
automatically
scaling,
throwing
out
a
couple
questions
but
yeah
I
would
love
to
hear
a
little
bit
more
about
this
feature
and
why
it's
not
something
that
we
officially
support
in
wasm
Cloud
right
now,.
E
Okay,
so
real
quick
to
start
the
it
may
or
may
not
have
been
clear
from
what
Brooks
was
saying,
but
the
the
notion
that
actors
need
to
start
other
actors.
That
is
a
characteristic
of
the
generic
of
the
actor
model
itself,
which
predates
okay,
so
that
that
idea
of
actors
being
able
to
start
other
actors
has
been
around
for
decades
and
isn't
something
that
that
DACA
just
came
up
with,
but
they
embraced
it.
E
So
you
know
before
we
look
at
the
implementation
details
of
how
it
might
work,
it's
probably
worth
looking
at
why
people
need
or
think
they
need
the
ability
to
start
new
actors
from
within
one
in
ARCA.
It's
it's
basically
mandatory,
because
the
only
way
you
can
start
an
actor
is
inside
an
actor
with
ours.
E
E
That's
a
pretty
common
use
case.
The
next
most
common
use
case
is
for
building
supervision
trees.
Where,
when
an
actor
starts
another
actor,
the
actor
has
logic.
It
builds
into
it
for
how
to
deal
with
the
failure
of
the
child
actor,
whether
it
wants
to
restart
it
or
whether
it'll
restart
it
after
three
failures
or
you
know,
all
of
that,
behavior
and
logic
is
typically
done
through
an
actor
supervisor
and
finally
another
the
I
think.
E
The
third
main
reason
why
you
have
actors,
starting
other
ones,
is
for
resiliency,
so
you
want
to
run
a
backup
of
an
actor
in
case
one
dies.
You
want
to
be
able
to
resurrect
one
if
it
dies.
Some
of
that
goes
back
to
the
supervision
tree
concept,
but
those
are
I
mean
there
are
variations,
but
those
are
the
the
main
General
buckets
for
why
people
want
actors
to
be
able
to
create
actors
specifically
when
it
comes
to
wasmcloud.
E
And
so
the
the
general
approach
thus
far
has
been
that
the
actor
actor
supervision
is
something
that
the
waslam
cloud
runtime
takes
care
of
by
default.
So
when
you
run
an
actor,
we're
responsible
for
making
sure
that
it
comes
back
from
the
day
and
after
it
dies
and
that
if
you
want
to
run
10
copies
of
it,
you
tell
us
to
run
10
copies
of
it,
and
we
do
this
if
you
want
to
communicate
with
act
from
one
actor
to
another.
E
We
make
that
happen
without
you
needing
to
have
a
supervisory
relationship,
but
one
of
the
the
ways
that
we
see
managing
the
the
workflows.
That,
typically,
are
the
ones
that
require
people
to
be
able
to
create
their
own
actors.
Most
of
that
we
see
coming
out
of
our
declarative
application,
product
or
wadum.
So
if
you
want
to
declare
that
you
need,
you
know
to
maintain
10
instances
of
this
actor
across
a
spread
of
five
hosts,
all
of
which
have
a
certain
set
of
characteristics.
E
Then
why
Adam
will
do
that?
For
you
and,
more
importantly,
the
actors-
don't
know
that's
how
things
are
being
done.
So
one
of
the
things
that's
always
kind
of
not
bothered
really
but
sort
of
chafed.
At
me,
a
little
bit
about
the
way
manual
actor
supervision
happens
in
things
like
akka.
E
Is
that
if
I
write
code
to
spawn
a
child
actor,
then
I've
now
written
code
that
isn't
business
logic,
it's
more
like
infrastructure,
but
it's
now
tightly
coupled
with
my
business
logic,
because
it's
sitting
right
there
in
the
actor
and
so
what
it
typically
means.
I
can't
do
is
dynamically
alter
the
way
in
which
my
actors
scale
and
are
supervised.
E
E
So
it's
it's
really
easy,
especially
for
those
of
us
who
really
love
akka,
to
want
the
ability
to
create
a
child
actor
and
be
able
to
do
things
like
spawn
this
and
things
like
that,
and
that
I
think
is
a
dangerous
major
reaction.
I
really
think
that,
or
the
cases
that
I
described,
the
external
management
of
actors
is
going
to
be
better
for
us
in
the
long
run.
E
Now
there
are
other
really
valid
use
cases
that
people
have
typically
used
after
supervision,
trees.
Four,
that
I
think
we
can
do
without
supervision
trees.
So,
if
I
want
to
spawn
some
long-running
piece
of
work
and
then
get
the
results,
when
it's
done,
I
think
that's
probably
something
more
more
appropriately
suited
to
the
capability
provider
Paradigm.
Where
I
tell
my
provider,
here's
a
bunch
of
long-running
work
that
I
want
you
to
do.
E
I
want
you
to
scale
it.
However,
you
see
it
see
fit
and
then
send
me
a
message
when
you're
done
that
contains
the
completed
payload
and
that
still
pure
business
logic,
because
you're
just
saying
I
want
this
business
logic
to
run
on
demand
and
I
want
to
be
notified
about
what
happened
and
whether
or
not
an
actor's
supervision
tree
is
spawned.
E
A
Yeah
yeah,
that
was
that
was
actually
that
was
really
really
helpful,
because
I
I
had
previously
kind
of
gone
into
it,
and
this
is
probably
just
that
using
actor
models
is
not
something
that
I've
been
doing
for
years
and
years
and
years,
but
the
I
think
it
makes
a
lot
of
sense
that
wasm
cloud
is
taking
the
approach
of
of
removing
the
non-business
logic
from
the
actor
model
and
and
like
kind
of
putting
that
as
a
part
of
our
platform
and
and
further
I
I,
think
it
makes
a
lot
of
sense
for
externally
managing
where
that
work
can
go,
and
it
sounds
like
that.
A
There
may
be
some
other
things
that
we
consider
in
the
future,
like
in
terms
of
having
actors
that
have
their
own
State
and
you
know
bringing
in
some
other
Concepts.
You
know
I
know
you
said
that,
or
you
mentioned,
that
there
are
valid
use
cases
for
doing
things
like
this,
that
we
may
not
want
to
just
completely
remove
that
yeah.
E
It
makes
it
may
seem
like
I've
let
loose
my
inner
pedant,
but
the
I
think
the
differences
are
both
subtle
and
super
important
that
you
know
we
when
we
design
stuff
like
this,
we
need
to
take
a
step
back
from
you
know.
Why
do
I
want
this
accuracy?
Provision
tree
is
this
because
that's
just
how
I've
managed
work
like
that
in
the
past,
or
do
I
whatever
is
what
I
really
want?
E
The
ability
to
run
this
particular
function
spread
out,
however
much
it
needs
to
scale
against
this
particular
large
data
set
and
then
to
be
informed
when
the
the
results
are
completed.
What
I,
what
I
just
described,
the
latter
of
what
I
just
described,
is
business
logic
and
writing
code.
That
says,
spin
up
200
children
is
infrastructure.
That's
the
the
dynamic
runtime
shape
of
my
environment
that
my
actors
should
not
know
about,
and
I
realize.
E
That's
that
drawing
that
opinion
is
somewhat
controversial,
because
you
know
that's
not
the
line
that
DACA
takes,
but
I
prefer
ignorant,
slash,
dumb
actors
where
all
they
worry
about
is
getting
their
business.
Logic
done,
and
that's
the
end
of
that.
A
I
really
like
that
and
I
think
we're
continuing
to
highlight,
like
with
the
last
two
chats
that
we've
had
on
actor
model
is
that
we
could
have
a
really
productive
actor
model
page
in
the
wasmcloud
documentation
of
you
know,
starting
with
what
is
the
active
model
at
all,
I
think
it
makes
a
lot
of
sense
for
us
to
do
some
of
that
education,
and
then
you
know
people
get
to
get
that
fundamental
right
there
I
know
we
have
a
whole
section
in
our
documentation
under
app
development
for
actors,
I.
Think.
A
E
E
And
then
you
know
once
they've
got
that
initial
step
of
you
know
being
able
to
compile
the
hello
world
or
whatever
then
hitting
people
with
a
little
bit
of
theory
is
is
okay,
but
if
you
just
sort
of
dump
30
pages
of
theory
before
somebody
starts
writing,
you
know
practical
applications,
then
you'll
lose
them.
A
E
I'm
I'm
super
guilty
of
this
myself,
but
I've
gone
to
a
number
of
pages
for
brand
new
products
and
I
see
words
on
the
page,
but
I,
don't
know
what
they
mean:
I,
don't
really
care
I,
just
click
the
install
thing
and
start
going
and
I
think
a
lot
of
people
are
like
that.
They're
just
like
get
me
started,
give
me
that
initial
hit
of
dopamine.
E
Let
me
see
what
this
feels
like
and
then
you
know
as
I
begin
to
progress
from
you
know
hello
world
to
more
practical
and
advanced
applications.
Then
it's
fine
to
Pepper
in
some
Theory
and
some
academic
stuff,
and
some
you
know.
Why
does
this
actually
happen?.
A
Well,
I'm
I'm
gonna,
write
I'm
gonna
write
that
one
down
having
an
actor
model,
opinionated
page
on
wasm
cloud.
You
know
after
we
get
into
the
meet,
because
I
think
that
this
would
be
really
helpful
and
I
want
to
thank
actually
CJ,
who
was
on
the
call
earlier
today,
but
but
had
a
drop
I
want
to
thank
one
of
our
community
members
CJ
for
dropping
us
a
whole
heaping
load
of
awesome
feedback
on
our
initial
documentation.
A
We
actually
had
someone
else
in
the
Watson
class,
like
just
the
other
day,
give
us
some
again.
Some
really
really
awesome
feedback
around
our
terminology.
You
know
getting
started
and
some
of
the
things
that
they
got
hung
up
on
like
right
when
they
were
looking
at
wasmcloud
at
first,
and
so
you
know,
I
just
want
to
put
it
out
there
that
these
are
they
all
the
things
that
we're
taking
together
and
I
think
we're
planning
on
taking
on
some
of
that
work
to
revamp
the
beginning
of
our
documentation.
D
Today,
if
you
catch
up
later
on
YouTube,
but
we
are
going
to
get
both
of
those
to
wonderful
groups
of
feedback
open
up
on
the
WASP
Cloud
repo
and
Chuck
also
got
his
first
contributor
badge
knocked
out
so
huge
thanks
and
welcome
to
the
community.
There
yeah.
A
Nice
all
right,
well,
I,
think
that
was
all
that
I
had
planned
for
the
actual
agenda
for
the
community
call.
However,
there's
one
one
more
thing:
at
least
that
I
wanted
to
call
out
as
long
as
I
can
actually
get
my
browser
to
cooperate.
I
just
want
to
continue
to
beat
this
hey
if
you
are
in
the
webassembly
ecosystem
and
interested
in.
Oh
wait.
This
actually
isn't
even
the
right
one:
hey.
D
My
Brooks,
while
you're
looking
for
that
I'll,
give
you
some
air
cover
here,
there's
still
time
to
left,
to
submit
your
exciting
ideas
and
vision
to
the
cloud
native
webassembly
day
featured
in
Amsterdam
at
this
year's
kubecon,
there's
been
a
slight
change
to
the
days
this
year
and
all
days
are
included
with
the
all-conference
pass.
D
I
had
my
touch
base
with
the
cncf
this
morning
and
those
passes
are
on
track
to
sell
out
very
soon.
So
if
there's
interest
in
attending
and
getting
one
of
these
all
access
days,
you're
going
to
want
to
go
ahead
and
pull
the
trigger
and
get
this
going
sometime
soon.
D
The
cfp
is
still
open
for
another
four
days,
I'm
gonna
be
out
posting
on
all
the
things
you
know:
webassembly
Reddit,
webassembly,
Twitter,
yeah,
zulip,
all
the
things
trying
to
drum
up
some
more
excitement,
I'm
program
chair
again
this
year
and
we're
excited
to
pull
together
a
great
theme.
I
know
the
BCA.
D
The
by
code
Alliance
has
been
pulling
together
a
road
map
for
their
priorities
for
the
year
and
I
expect
that
we'll
try
to
align
the
content
to
some
of
the
new,
exciting
things
coming
live
in
webassembly,
including
support
for
new
languages,
the
component
model,
maybe
the
new
wasm
time,
release
schedules
and
things
along
those
lines.
But
the
excitement
is
always
what
comes
out
of
the
community,
so
fingers
crossed
and
excited
to
see.
What
you
have
in
mind
was
that
enough
air
cover
Brooks.
A
It
was
I
I
can't
believe
that
it
took
like
seven
minutes
for
me
to
come
up
with
this
one
had
a
little
bit
of
a
failure
to
it
wasn't
seven
minutes.
It
was
like
two.
C
A
A
half
a
little
bit
of
an
issue
finding
it
on
Google,
but
I
did
find
the
I
think
part
of
the
issue
was
the
and
I
will
totally
offload
the
blame
here.
The
co-located
events
are
now
kind
of
all
in
their
own
category.
So
when
you
submit
a
cfp,
it's
just
for
the
it's
for
the
co-located
events
and
you
select
which
one
instead
of
having
like
a
different
page
for
every
single
one,
all
right,
it's
pretty
much
the
same
but
anyways
yeah.
Thank
you.
A
A
Just
just
a
reminder,
if
you
all
are
free
this
afternoon,
please
come
hang
out
in
the
bike
load,
Alliance
stream
a
little
bit
later
today,
our
very
own
wasm
cloud
contributor,
Bailey
Hayes,
will
be
on
this
call
with
Luke
Wagner,
which
is
one
of
the
one
of
the
original
creators
of
webassembly
and
one
of
the
people
really
driving
forward
wasm
standards
today.
A
So
this
is
going
to
be
a
really
fun,
really
fun
chat
on
on
behalf
of
the
by
code
Alliance
and
is
perfect
for
anyone
who
maybe
has
been
in
the
wasm
cloud
space,
but
is
looking
for
just
a
looking
to
stay
a
little
more
updated
with
webassembly
standards
themselves.
This,
of
course,
is
just
talking
about
Wazi
talking
about
Wazi
standards
and
all
of
those
things.
This
is
going
to
be
a
really
really
fun
stream.