►
From YouTube: wasmCloud Community Meeting - 10 May 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
A
So
we're
going
to
be
we're
talking
about
a
couple
of
things
today,
starting
first
with
a
demo
and
showcase
about
what
Roman
has
been
working
so
diligently
on
in
the
OTP
host
repo,
which
is
basically
transforming
the
way
that
we
do
releases
into
using
an
open
source
project
called
burrito,
very
delicious
name.
The
beam
burrito
is
what
they
call
it,
but
it's
a
self-extracting
essentially
tarball
for
an
Elixir
release
and
that's
going
to
make
our
distribution
and
platform
support
a
lot
more
varied
across
the
operating
systems
and
architectures
that
we
support.
A
Roman,
of
course,
is
going
to
talk
more
about
that.
We're
going
to
discuss
something
that
came
up
in
our
community
slack
a
little
earlier
this
week
around
more
built-in
capability
providers-
and
you
know
built-in
in
air-
quotes
because
they
won't
be
built-ins
but
they'll
be
like
included
anyways
more
on
that
here
in
a
couple
of
minutes,
and
then
Bailey
is
going
to
talk
about
wasm
cloud
and
it's
path
to
becoming
a
cncf
incubating
project
which
is
really
exciting
so
without
further
Ado.
Why
don't
we
go
ahead
and
get
started?
Roman!
Take
it
away!
A
I'm
talking
about
bean
burritos.
B
Yeah
nice
job
to
do
about
that.
That
could
be
some
interesting,
Zoom
fame.
Let
me
try
to
turn
it
off
and
on.
B
Okay,
do
you
do
you
hear
me
right
now?
Do
you
see
me
okay
or
yeah?
That's
good!
All
right
and
my
screen
also
is
visible
or
yeah.
Okay,
cool
yeah,
all
right
so
very
close,
so
something
that
we
have
encountered
notice
is
that
so
this
could
be
a
bit
difficult
for
people
to
start
up
with
Cloud
OTP
because
of
different
dependencies,
mostly
brought
into
the
fact
that
we
use
Airline
and
elixir
to
actually
distribute
watching
Cloud,
so
I
found
it'll,
be
both
me
and
Patrick
have
worked
over.
B
The
last
few
weeks
is
to
making
that's
all
onboarding
kind
of
simpler,
so
I
should
yeah.
What's
it
called
OTP
host
will
just
work
in
various
different
contexts:
different
systems.
It
was
little
amount
of
dependencies
as
possible
and
so
a
quick
first
quick
kind
of
intro.
B
How
this
whole
process
actually
works
today
with
like
with
normal
Elixir
projects,
is
that
basically
application
developers,
they
call
mix
release
and
then
the
whole
Airline
distribution
which
is
currently
running
on
the
system,
is
getting
bundled
basically
together
in
one
directory,
and
essentially
that
is
what
is
a
shift
to
to
customers
or
to
users
of
that
application.
B
So
what
we
switch
to
is
this
project
called
burrito,
which
expands
a
little
bit
on
this.
This
approach,
where,
instead
of
bundling
the
exact
Airline
distribution
of
the
system
which,
like
the
releases
being
made,
you
can
now
specify
which
airline
distribution
you
actually
want
to
package
and
then
for
it
to
go
essentially
creates
one
simple
executable,
which
is
then,
which
is
built
specifically
called
a
system
with
your
packaging
as
the
self
extracts.
B
So
let
me
let
me
know
some
of
the
examples
would
be
a
more
interesting
thing.
So
unfortunately,
we've
had
some
issues
with
GitHub
actions
today,
so
it's
an
older
build,
but
these
aspects
are
just
as
good
as
the
fresh
ones
can
be
built.
So
I'm
going
to
just
fetch
one
or
two
such
effects
I'm
going
to
try
to
run
it
in
a
Docker
container
and
kind
of
show
how
it
works.
So
I
already
done
it
before
and
I
have
fetched
one
of
these
zip
files
over
here
and
they
just
affected.
B
So
let's
try
to
run
Ubuntu
container
Ubuntu
manual,
four
I'm
going
to
for
4
000
for
the
washboard
inside
the
container
to
my
house
system
and
I'm,
going
to
just
you
know:
Mount
all
my
file
system
to
the
to
The
Container.
So
the
only
dependency
on
Ubuntu
today
we
have
is
a
CH
certificates.
In
most
cases
this
should
be
already
installed
in
the
system.
So
it's
not
something
that
normal
users
would
need
to
install,
but
of
course,
in
a
new
Docker
container
they're,
not
there.
B
Yes,
I
would
have
to
install
these
so
go
to
do
after
blades,
then,
after
still
certificates-
and
this
is
just
to
be
able
to
establish
DRS
connections,
essentially
so
I've
also
fetched
the
latest
net
server.
It's
just
a
recent
release
package
for
Linux
and
I'm,
going
to
start
Nas
in
the
background
now
I'm
going
to
start
build
wasp.host,
and
so
what
this
is
going
to
do
right
now
is
using
burrito,
which
actually
uses
Zig
under
the
hoods
to
cross.
Compile
these
things.
B
So
it's
a
single
binary
which
is
going
to
self-destruct
itself
into
a
directory
on
my
assignment
of
container
and
now
I
can
go
to
localhost
or
thousands
and
in
a
moment
I
should
see
my
washboard
here.
It
is
right
so,
as
you've
seen,
I
just
took
a
completely
new
Docker
container,
with
Ubuntu
2004
running
and
I
just
installed
CH
certificates,
and
that's
it
right.
So
I
have
my
Russian
class
host
running
and
now
I
can
actually
kill
it.
B
I
can
run
again
the
same
binary
and
this
this
time
it's
not
good
enough
to
extract
yourself
anymore.
It's
already
is
extracted
from
the
system,
so
it's
not
just
run
it
directly
and
yeah.
It
need
to
hear
about
any
I.
Don't
think
you
even
know
about
the
Airline
under
the
hood,
it's
just
single
binary,
which
is
then
self-extracting
and
can
be
run.
B
In
fact,
we
can
do
the
same
on
Alpine
and
I'll
have
to,
of
course,
close
this
one,
because
I
already
I'll
get
the
portion
of
thousands
so
on
Alpine,
although
I
do
have
to
know
that
our
providers
currently
do
not
support
online,
but
I,
guess
that's
something
that
we
could
work
in
the
future,
so
we're
not
buying.
You
can
do
some
similar
on
Alpha
and
I
already
have
the
certificates
and
on
Alpine
the
only
dependency
we
have
is
actually
live
GCC
and
that's
something
that
is
yeah
brought
in
by
rust.
B
B
So
again,
it's
going
to
start
the
cell
for
the
system
and
in
a
moment
it
should
start
I
should
say
extract
itself.
Now,
I
should
be
able
to
again
go
to
house
for
a
thousands
and
sure
enough.
I
again
see
my
washboard
just
as
I
did
before
right,
so,
of
course,
on
both
of
these
systems
and
there's
actually
only
one
dependency
which
we
actually
were
necessary
yeah.
So
this
also
supports
Windows
and
Mac
and
those
systems.
In
fact,
there
are
no
dependencies.
B
So
this
should
just
work
out
of
the
box
yeah
if
you're
curious
how
it
works,
I,
definitely
encourage
you
to
check
out
the
burrito
project
and
yeah
I
said
they.
They
use
it
to
actually
build
these
self-destructing
binaries
and
it's
cross
compiled
for
different
targets,
and
so
one
thing
here
to
mention
also
in
terms
of
like
how
we
actually
do
it
in
in
our
investment
OTP
Repository.
B
Is
it
this
PR
that
I'll
talk
about
which
we
are
hoping
to
get
married
and
is
that
we
actually
build
a
Windows
distribution
fully
reproducibly?
So
it's
something
that
it
gives
you
exactly
the
same
binary
if
you
refer
to
rent
locally
or
in
CI
and
be
used
next,
for
that,
it's
a
project,
take
a
look!
If
you
want
to.
Essentially
it's
just
a
build
tool
to
build
stuff
reproducible
right.
B
We
also
use
using
things
actually
to
build
binaries
for
Windows
and
Mac,
but
before
we
actually
can
do
that,
we
first
have
to
build
the
roughness
outside
the
whole
sandbox.
If
you're
curious,
to
learn
more
I'm
happy
to
share
the
details,
but
I
guess
it's
out
of
scope
for
this
different
goal:
yeah
I!
Guess!
If
anyone
has
any
questions,
oh.
D
Thanks
Raymond
I
thought
I
might
summarize,
like
the
the
why
people
should
be
excited
about
this
if
you've
been
in
our
slack
for
a
while,
you've
probably
seen
people
complain
about
when
they
first
get
started
with
Blossom
Cloud
they've
got
to
install
openssl
and
it's
different
on
different.
You
know
if
you're
on
Linux
or
Ubuntu
222
versus
latest
and
greatest
that
kind
of
thing,
that's
like
the
first
thing
people
run
into,
and
this
gives
us
a
single
binary
with
that
included.
B
Yeah,
so
in
fact
we
compile
our
own
airline
to
actually
get
this
get
here
right.
Let
me
set
if
we
link
everything
we
can,
but
of
course
there
are
some
things
we
cannot
say
like
just
because
it's
La,
and
actually
one
thing
I
didn't
mention
here-
I
probably
should
have-
is
that
so
now
these
binaries
also
work
without
independencies
on
the
GitHub
action
Runners.
So
you
don't
actually
need
to
install
anything
on
the
runners.
If
you
were
to
use
case
of
actions,
let's
say
you
wanted
to
test
this:
that's
possible
OTP!
B
You
know
if
you,
when
an
actor
and
start
OTP
and
test
that
in
NCI
or
you
don't
need
to
do
anything.
You
can
just
friends.
D
A
And,
and
forgive
me
if
I'm
wrong
Roman,
but
it
actually
looked
like
this
release
only
took
like
24
minutes.
That's
a
little
quicker
than
our
little.
Our
Docker
cross,
compile
that
we
used
to
do.
B
Yeah,
so
there's
no
Docker
actually
used
for
a
release,
so
everything
is
either
automatically
or
maybe
a
cross
compiled
for
another
system,
and
so
one
thing
we
get
with
next
and
reproducibility,
which
I
mentioned
is
actually
caching,
so
you
can
see
here
there's
a
difference
here
in
these
two
builds
right
so
one
to
twenty
of
this
another
one
three
minutes,
and
it
that's
quite
okay.
B
It's
so
like
very
simple,
very,
very
similar
things
right,
and
so
what
happened
here
is
that
I
made
a
change
which
actually
changed
the
the
myth,
and
so
because
the
nif
changed
right
and
this
is
the
dependency
of
the
whole.
You
know
the
binary
resulting
binary
right,
so
I
actually
had
to
build
net
from
scratch.
This
build,
but
in
the
other
build
which
definitely
trim
is
the
nift
change,
wasn't
actually
required.
B
Artifact
I'm
I'm
wrong.
There
was
a
different,
a
different
dependency,
but
the
point
is
that
there's
the
dependency
was
not
actually
used,
it
wasn't,
I
was
it
was.
It
was
different,
except
because
we
compiled
nift
for
rcc4
there
was
an
F4
x86.
So
when
I
made
a
change
for
r64,
we
had
to
recompile
the
net
for
r64
and
update
our
cache
right
for
the
next
pull
that
new
thing
from
Cache
best
for
x86.
B
B
Actually
is
Elixir
Library,
which
we
actually
write
in
Rust
to
interface
of
things
like
we
use
it
wasn't
called
Library
developed
earlier.
We
presented
that,
and
so
so
native
is
the
entry.
A
Point
for
Elixir,
then
to
actually
call
these
gun
thrust
functions
directly.
Foreign.
A
Thank
you
so
much
for
for
showing
that
off,
I
wanted
to
just
make
one
more
call
out
that
that,
for
you,
the
people,
this
probably
isn't.
This
isn't
going
to
result
in
any
real
changes
to
your
workflow.
I'm
gonna
try
to
push
in
this
change
and
it
may
just
end
up
being
a
patch
release.
Well,
we'll
probably
do
a
minor
but
we'll
push
up
a
new
version
of
the
OTP
host
and
then
I'll
get
that
integrated
in
wash
so
effectively.
A
The
next
time
that
you
download
the
latest
and
greatest
wash
with
this
change,
we'll
be
executing
this
single
self-extracting
tarball.
Instead
of
kind
of
the
mix
release
directory
structure,
so
you
know
we're
going
to
be
changing
kind
of
the
format,
but
it's
not
going
to
change
the
way
that
you
actually
launch
wasmcloud.
A
You
should
just
notice
that,
as
you
start
to
work
on
different
types
of
Linux
targets-
and
maybe
if
you
get
a
new
Macbook
and
you
haven't
installed
openssl
on
it
yet
you're
going
to
notice
the
it
just
launches
without
you
having
to
do
that,
which
is
super
huge.
These
are
some
of
the
some
of
the
older
issues
that
we've
had
running
in
OTP
and
then
wash
for
a
little
while,
and
we're
really
excited
I'm
really
excited
to
push
this
in.
So
thank
you,
Roman.
A
All
right,
awesome,
well,
I,
think
now,
we'll
move
on
to
the
next
agenda
item
that
we
have
today
I'm
going
to
share
it
really
briefly,
so
that
everybody
can
remember.
A
We
queued
up
a
discussion
for
built-in
capability
providers
to
find
at
runtime
and
I
want
to
just
do
a
little
bit
of
a
little
bit
of
disambiguating
right
before
we
start
so
the
wazen
cloud
host
has
a
couple
of
built-ins,
namely
number
gen
and
logging
that
just
kind
of
come
as
core
capabilities
of
the
host.
It's
not
likely
that
you're
going
to
want
to
use
many
different
implementations
of
things
where
you
just
want
to
generate
a
random
number
and
and
often
for
things
like
logging.
A
You
want
to
have
something
built
in
that
you
don't
have
to
link
to
an
external
provider.
You
just
want
it
to
work
with
the
current
host
and
the
hosts
can
provide
a
different
implementation,
but
it's
not
the
same
plugability
as
a
normal
capability
provider,
and
this
discussion
isn't
really
around
those.
It's
more
around.
A
Nuance
of
thinking
about
teams
of
developers
who
are
using
wasm
Cloud
will
want
to
have
a
certain
set
of
core
capability
providers
that
many
different
applications
can
access
and
kind
of
having
those
available
by
default.
A
It's
not
that
we
would
change
anything
or
build
in
more
capability
providers,
just
that
if
you
were
working
on
a
project
and
everybody's
using
an
HTTP
server,
then
you'll
probably
want
to
have
an
HTTP
server
provider
available.
Now
that
can
still
be
hot,
swapped
and
hot
upgraded
to
a
new
version
to
resolve
vulnerabilities.
All
the
things
we're
not
changing
any
of
the
core
value
there,
but
really
it's
more
around
like
when
you
run
a
waslam
cloud
host.
A
Should
there
be
a
way
to
kind
of
configure
a
set
of
capability
providers
to
run
that
are
treated
like
built-in,
so
you
don't
have
to
explicitly
link
to
them,
configure
the
the
links
and
things
like
that
and,
of
course,
there's
nuances
to
every
part
of
that
statement.
But
I
wanted
to
set
a
little
bit
of
background
and
Jordan
I
think
you
were
the
one
who
actually
started
this
thread
and
started
talking
about
this
use
case.
A
Did
you
want
to
would
you
mind
elaborating
a
little
bit
more
on
on
what
you
were
thinking
about,
especially
if
I,
if
I'm
mischaracterized
it
foreign.
A
E
F
A
All
right,
I'm
pulling
up
the
recording
the
live
stream,
we're
going
back
two
minutes
and
we'll
replay
it
now
so
Jordan
you,
you
kind
of
you
brought
up
the
question
a
little
earlier
in
the
week
around
kind
of
adding
the
core
like
being
able
to
configure
a
core
set
of
capability
providers
that
act
like
built-ins,
yeah.
F
So
I
mean
I
mean
we
actually
started
this
discussion,
I
think
two
or
three
talks
ago
right.
It
was
all
over.
It
was
at
the
we're
talking
about
crypto
right
they're
like
built-in
number
generators.
I'm,
like
you
know
the
the
built-ins
that
we
provide
they're
they're,
all
even
they're,
really
good
for
like
prototyping
and
using
locally,
but
when
I
think
about
Walzem
Cloud
deployed
wherever
right.
We
we
don't
want
people
to
have
to
then
remove
logging,
and
you
know,
remove
the
built-in
logging
contract
and
then
re-link
the
the
use,
the
different.
F
What
is
it
contract
ID
to
be?
You
know
to
use
logging
or
something
and
I'm
just
using
logging,
because
that's
the
one
I
was
specifically
using
at
the
time,
but
but
then
it
dawned
on
me
like
if
we
can
start
the
host-
and
these
built-ins
are
like
this
in
my
imaginary
world-
there's
an
Ops
team
that
starts
a
cluster
of
awesome,
claw
hosts
and
they
start
them
with
if
they
started
with
no
like
built-in
modules
and
then
yeah,
we
use
the
the
you
know
the
logging
built
in
that's
already
there.
F
That's
kind
of
where
my
mind
was
at
because
I
don't
want
to
rewrite
all
my
actors
and
providers
to
use
a
different
logging
contract
which
I
guess
it
wouldn't.
But
I
also
don't
want
to
write
my
rewrite
my
CI
to
use
a
different,
wasn't.
Cloud
built-in
logging
wasn't
called
built-in
number
gen,
because
now
it
depends
on
what
production
level
I'm
at
as
to
what
contract
I
get
which
doesn't
feel
smooth.
A
Okay
and
so
I
know
you're
taught
you're
you're
talking
about
logging.
Do
you
see
this
kind
of
concept
extending
to
other
other,
like.
F
But
yeah
anyone
that's
done
like
large-scale
devops
right.
You
got
like
50
applications
running
in
this
environment
and
there's
like
a
handful
of
things.
You
need
them
all
to
do.
We
need
them
all
along
the
same
way.
We
need
them
all
to
use.
I,
don't
know
the
same
clock
we
need
them
all.
Do
you
know
X
number
of
things?
Even
this
goes
back
to
is
C
is
getting
secrets
of
built-in
or
something
along
those
lines
right.
F
Are
we
all
going
to
get
Secrets
the
same
way,
but
then
there's
things
the
the
developer
wants
to
do
like.
Maybe
I
want
to
use
this
HTTP
server
because
it
behaves
one
way
or
I
want
to
use
this
HTTP
server
like
the
Ops
Team
shouldn't
really
care.
There
should
just
be
approved
HTTP
service
Kevin's
on
oh
I'm,
about
to
get
slapped
down.
Do
it
Kevin.
G
No
I
guess
so
for
some
historical
context.
The
a
very
long
time
ago,
you
know
back
when
we
all
rode
dinosaurs
to
our
Muslim
Cloud
hosts.
G
There
was
a
specific
need
for
differentiating
between
a
built-in
contract
like
wasmcloud
built-in
logging
and
then
a
non-built-in
contract
and
part
of
what
we're
doing
like
right
now
is
taking
a
look
at
all
of
our
contracts
and
seeing
you
know
how
they
need
to
evolve
in
order
to
move
forward
with
the
component
stuff
and
we're
looking
at
the
wazzy
contracts
like
Bailey,
just
put
a
link
to
Lazy
logging.
G
G
G
G
If
you
find
yourself
in
a
position
where
you
have
to
use
a
different
contract
ID
between
Dev
and
fraud
than
that
contract
is
wrong
and
it's
the
wrong
level
of
abstraction,
you
should
have
the
same
contract,
no
matter
where
you're
running
whether
it's
on
your
laptop
or
Dev
or
product,
or
on
the
edge
or
in
a
Raspberry
Pi.
So
we're
aware
of
the
impedance
mismatch
in
the
built-in
contracts
and
so
we're
gonna.
You
know,
as
we
move
forward
we're
going
to
make
sure
that
those
kinds
of
things
are
corrected.
G
So
I
can
I
can
see
a
very
near
future
where
there
is
no
such
thing
as
a
built-in
contract.
There's
just
a
contract
that
may
or
may
not
be
satisfied
by
built-in.
G
It
depends
entirely
on
the
host
right,
so
what
what
an
OTP
host
can
treat
as
a
plugin
and
how
it
treats
those
plugins
is
probably
different
than
what
like
a
rust
host
might
be
able
to
treat
as
plug-ins.
So
it's
it's
it's
entirely
up
to
the
host
implementation.
So
you
know,
for
example,
let's
say:
you've
got
a
JavaScript
host
right.
G
What
the
JavaScript
host
can
do
in
terms
of
plugins
is
probably
far
more
limited
than
some
of
the
other
stuff
is
so
the
JavaScript
might
have
more
quote:
unquote:
hard-coded
built-ins,
but
then
you
know
the
the
OTP
host.
We
might
be
able
to
allow
people
to
write
their
provide
their
built-in
or
what
I
was
referring
to
as
auto
start
providers.
G
You
can
write
those
in
Elixir
or
erlang
and
just
have
them
loaded
into
the
host.
That
way,
so
there's
there's
a
ton
of
possibilities,
but
your
your
core
point
is
definitely
spot
out
and
that
we
need
to
resolve
that
discrepancy
in
the
contracts.
F
Very
cool
and
I
guess
my
last
question
is:
can
we
can
we
please
make
the
can
we
talk
about
maybe
allowing
the
built-ins
to
somehow
emit?
F
Oh
what
they're
doing
on
the
lattice?
It
seems
like
they're,
the
only
ones
that
we
have
no
visibility
into
like
I
I
played
this
week.
Writing
a
I
wrote
an
actor
that
parses
out
logs.
It
was
supposed
to
and
then
I
completely
forgot
that
even
when
we're
using
the
logging
contract,
it's
riding
them
straight
to
like
standard
out
and
not
echoing
it
onto
the
lattice
anywhere.
G
Yeah,
so
that's
actually
another
bigger
question
too,
and
one
that
hopefully
will
we
will
solve
for
more
than
just
bills-ins
but
yeah
there's
a
general
need
for
providers
to
be
able
to
emit
their
own
events,
and
they
don't
really
have
a
good
way
of
doing
that.
Right
now,
there's
some!
G
You
know
some
built-in
there's
some
helper
functions
depending
on
how
you're
writing
the
provider,
but
yeah
there
needs
to
be
a
better
way
for
providers
to
emit
events,
better
bi-directional
communication
between
the
providers
and
the
hosts
and
not
forcing
the
actors
to
know
the
difference
between
a
built-in
and
a
non-built-in.
A
I
had
a
I
had
a
little
bit
of
a
wild
tangent,
so
Vance.
If
you
wanted
to
ask
your
question:
go
ahead.
I
think
it's
probably
a
good
time
and
then
we
can
get
on
to
get
on
the.
C
H
H
If
you're
so
just
sticking
with
the
in
the
with
the
built-ins,
then
if
you,
if
you're,
going
to
keep
the
contract,
but
you
you
change
to
a
different,
a
different
provider
implementation.
G
If,
if
you,
you
can
delete
and
then
add
a
new
link,
definition
between
an
actor
and
a
provider
and
so
right
now
today,
you
can't
do
that
with
like
the
the
built-in
contracts,
because
they
are
specifically
built
in
you.
Can't
you
can't
link
to
an
external
version
of
guasm
cloud
built-in
logging,
the
ones
that
discrepancy
is
resolved.
Then
it
should
just
be
a
matter
of
changing
wish
providers,
the
implementation
for
your
blogging
or
or
whatever.
H
H
Because
the
link
definitions
are
really
all
about
the
lattice
so
well,
then,
how
does
it
work
when
you
change
from
one
provider
to
another?
So
if
I,
if
I,
if
I,
if
I,
want
to
migrate
from
one
implementation
of
the
HTTP
provider
to
another
implementation
of
the
same
contract?
How
do
you
accomplish
that.
G
G
No,
it
can
be
service
disruptive,
but
if
you
delete
the
link
definition.
G
Some
lower
level
distributed
systems
type
stuff
in
there
that
you're
right
if
it
could
be
service
disruptive
and
there
are
plans
for
making
it
easier
to
smoothly
transition
from
one
provider
to
another.
G
But
you
know
the
the
time
it
takes
to
delete
one
link
and
add
another.
One
is
pretty
small,
but
yes
at
its
heart.
That
is
a
disruptive
operation.
G
You,
if
you
add
the
second
link
to
if
you
attempt
to
add
a
second
link
to
a
different
provider
with
a
different
public
key
it'll,
reject
it,
because
that
actor's
already
linked
to
an
implementation
of
that
same
contract
right.
An
actor
could
only
be
linked
to
one
implementation
of
Any
Given
contract
with
any
given
link
name
at
a
time.
H
A
Yeah
I
think
along
that
line
and
then
I'll
ask
my
wild
question.
I.
Think
we've
essentially
we've
brainstormed
a
couple
of
different
ways
to
do
that
upgrade
like
for
actors.
We
have
a
live,
upgrade
feature
I.
Think,
essentially,
what
we
want
to
do
is
you
know
either
we
would
still
be
collecting
messages
like
in
the
process
inbox
and
then
switch
over
the
link
like
by
deleting
and
then
putting
again
and
then
deliver
the
messages
to
the
new
link
we
brainstormed
around,
like
Bailey.
A
It's
a
great
idea
to
do
like
a
b
type
testing
or
maybe
like
a
smaller
like
a
canary
style
deployment,
there's
a
lot
of
different
strategies,
but
that
that
one
will
probably
need
to
save
for
its
own
full
discussion,
because
that's
a
that's
a
great
piece.
A
So
the
question
that
I
was
going
to
ask
is
around
linking
an
actor
to
a
capability
provider
in
the
first
place
right
and
in
my
mind
this
serves
two
main
purposes.
The
first
one
is
to
tell
the
wasm
cloud
runtime
it's
like
hey.
This
actor
is
going
to
talk
to
this
capability
provider
and
that's
allowed
and
it's
okay
and
then
the
second
purpose
is
to
provide
optional
configuration
values.
So
you
can
add
configuration
on
a
link
depth
around
that
first
one.
A
How
much
security
are
we
getting
at
run
time
by
validating
that
a
link
exists?
I
know
that
we
would.
We
would
have
to
do
complex
things
to
make
an
actor
talk
to
a
provider
without
a
link,
but
if
that
was
something
that
didn't
exist
like
if
it
was
just
automatic,
does
that
compromise
us
on
on
security?
There
I
got
Kevin
to
nod
so
a
little.
G
Yeah,
so
the
the
the
the
scary
Edge
case
scenario,
for
that
is
you've
got
an
actor
and
the
actor
is
signed
with
the
capability
to,
let's
say
talk
to
a
key
value
provider
right,
there's,
no
assume
that
there's
no
link
and
then
well
as
implied,
does
some
heuristics
to
find
a
suitable
provider.
G
If
Wiseman
Cloud,
then
attempts
to
find
a
suitable
provider
there's
a
number
of
potential
issues,
the
first
one
is
that
it
doesn't
know
which
providers
need
config
and
which
ones
don't
the
next
one
is
that
if
there
is
an
imposter
on
the
network,
it's
it's
conceivable.
That
wasmcloud
would
choose
the
Imposter
first
as
the
potential
Target
for
that.
G
So
the
thing
that
that
particular
scenario
is
the
main
reason
why
links
between
actors
and
providers
has
always
been
both
explicit
and
secured,
because
you
need
to
have
permissions
on
the
lattice
to
be
able
to
add
a
link
definition.
The
actor
needs
to
be
signed
with
the
particular
claim
related
to
that
link
definition.
And
then
both
the
source
and
target
of
that
invocation
need
to
trust
each
other.
G
In
order
to
make
that
call,
and
if
we
just
sort
of
arbitrarily
pick
potential
provider
targets,
all
sorts
of
really
unexpected
problems
would
happen
at
runtime
that
are
most
of
the
problem
would
be
with
unpredictable
behavior
and
security
would
almost
be
like
a
secondary
problem.
G
G
But
if,
if
the
link
name
is
something
that
the
actor
needs
to
use,
then
it
can't
change
at
runtime,
because
the
actor
won't
be
able
to
say
you
know,
use
this
linked
name
now,
but
use
a
different
one
later.
If
you
can
sort
of
get
away
with
changing
link
names
for
like
a
messaging
actor
that
only
receives
messages,
because
it
necessarily
wouldn't
care
which
link
name
was
the
one
that
delivered
the
message.
But
you
can't
do
that
with
something
like
a
key
value
provider
or
even
like
the
HTTP
client.
A
Yeah,
it's
a
it's
really
interesting
that
on
actor
receive
operations,
the
link
name
can
change,
but
when
an
actor
is
calling
something,
it
has
to
keep
the
link
name
in
mind.
It
makes
sense,
but
it's
just
interesting.
I
Is
that
a
is
that
a
limitation,
it's
the
limitations
Maps,
because
it
can
only
publish
on
a
specific
subject
but
subscribe
to
the
store
start
subject,
or
is
that
a
chosen
path?
It's.
A
It's
more
it's
more
a
chosen
path.
I
think
Nat's,
like
subscribing
on
a
different
subject,
is
a
means
to
an
end
to
get
it
to
the
right
place,
but
it
is
intentional.
So
a
classic
example
we
used
before
is
where
we
have
a
service
that
has
essentially
a
Nats
front
end
and
a
Nats
back
end,
so
it
uses
specific
set
of
topics
and
a
different
connection
to
talk
to
back-end
Services
than
it
does
to
receive
receive
invocation.
A
So
people
can
publish
requests
to
a
Nats
API
and
just
for
separation
of
concerns,
kind
of
like
how
you
don't
have
a
database
exposed
publicly.
We
use
the
back
end
link
to
publish
things
to
the
back
end
and
the
front
end
link
to
publish
things
back
to
the
client
requester.
So
this
is
a
long-winded
way
of
saying
that
it's
not
a
limitation
of
naps,
which
is
good.
A
You
know,
because
that
means
something
that
we
can.
We
can
do
our
own
design
on
foreign.
A
Make
sure
we
can
do
a
few
more
minutes
on
this
topic,
because
it's
fun
and
we
leave
enough
time
for
the
incubating
discussion
at
the
end,
did
the
the
thing
that
I
was
kind
of
getting
at
around?
A
Do
we
even
do
we
need
to
link
to
a
provider
is
I'm
trying
to
brainstorm
around
ways
to
make
linking
feel
a
little
more
natural
or
super
easy
in
the
majority
of
cases,
because
until
you
get
to
a
more
complex
application
structure,
most
of
the
time
things
are
just
running
on
the
default
link
anyways
and
for
a
lot
of
our
capability
providers.
They
don't
even
run
with
a
set
of
configuration.
A
You
know,
HTTP
server
needs
to
know
what
port
to
listen
on,
but
things
like
HTTP
client
is
just
making
outbound
HTTP
requests.
Things
like
you
know,
depending
on
how
you
set
up
your
capability
provider,
Nats
and
and
redis,
and
things
could
have
a
default
connection,
so
they
don't
need
any
link
values
either
saying
I
kind
of
I
kind
of
want
that
to
just
work
like
I.
A
Just
want
them
to
be
connected
and
then,
as
soon
as
I
think
about
it
like
you
can
run
a
for
example,
redis
capability
provider
and
a
KV
Vault
capability
provider,
same
contract,
same
link,
name
in
the
same
lattice
and
there's
no
way
for
us
to
pick
which
one
an
actor
should
talk
to
by
default.
A
Unless
we
were
to
enforce
some
rule
around
one
contract,
ID
link,
name
pair
or
providers,
and
that
feels
a
little
artificially
restrictive
and
and
difficult
in
a
different
way.
So
anyways,
no
concrete
suggestions,
but
enough
thoughts
put
out
there
that
two
people
raised
their
hands
so
maybe
we'll
get
somewhere
Jordan.
F
Compiling
link
names
into
actors
right,
I've,
I
found
myself,
I
have
I,
have
four
or
five
different
compilation
or
your
compiled
actors
with
different
link
names
in
them.
So
if
we're
going
to
talk
about
this
subject,
I'd
like
to
talk
about
that
little
pain,
Point
too,
because
I
know
a
while
back
I
brought
up
to
Kevin
and
he
said
he
had
ideas,
but
I
don't
think
we
ever
talked
about
it
since.
G
So
yeah
I
had
a
a
comment
on
the
use
case
that
Brooks
just
brought
up.
This
was
trying
to
talk
about
some
of
the
the
negative
scenarios
that
would
happen
if
we
had.
You
know
implicit
links
and,
like
I
said
in
addition
to
the
security
problem,
the
big
one
is
what
Brooks
mentioned
where,
if
you,
you
can
have
many
different
providers,
all
sitting
on
the
same
contract,
ID
all
in
the
same
lattice,
and
you
definitely
don't
want
actors
to
accidentally
choose
the
wrong
one.
G
So
you
know
if
you're
trying
to
re,
if
you're
trying
to
store
data
in
writers
and
it
ends
up
being
dumped
into
Vault,
then
all
sorts
of
things
are
going
to
be
a
problem.
So
that's-
and
one
of
the
other
many
reasons
why
the
the
links
are
explicit
and
durable.
A
I
think
there's
there's
certainly
still
things
to
think
about
no
we're
always
kind
of
thinking
about
ways
to
improve
links
and
and
the
way
that
we
do
that
separation
there,
but
I
think
that
that
definitely
settles
it
for
me.
For
now
so
I
don't
I,
don't
really
know
if
we
got
a
concrete
action
item
to
take
out
of
this
at
the
discussion
around
having
additional
it
kind
of
started
with
additional
built-in
type
capability
providers.
A
A
Mostly
I
just
wanted
to
know
if
Jordan's
question
Jordan
feels
like
his
question
that
he
brought
up
in
slack
earlier
was
was
addressed
and
if
we,
if
you
have
some
ideas,
either
to
improve
or
just
some
things
to
think
about.
F
Vance
just
asked
a
question:
I
essentially
asked
in
slack
right
if
the
washboard
should
have
a
section
at
the
bottom
says
these
built-ins
are
up
and
running,
so
you
can
use
them.
I
like
that
I
feel,
like
my
question
was
answered.
Kevin
said
it's
it's
in
the
works.
Therefore,
it's
in
the
works.
D
We
should
have
a
follow-up
on
on
writing
up
some
rfcs
around
this,
because
we've
Kevin's
written
a
couple
that
are
out
there
right
now
that
have
gotten
some
really
good
conversation
and
we
need
we
need
more.
You
know,
I,
don't
I,
don't
know
that
we
know
the
right
answer
yet,
but
it
does
seem
like
everybody's
got
ideas.
F
Well,
so,
if,
if
okay
on
that
point,
though,
like
if
you
have
a
JavaScript
host
that
can't
that
you
know
has
more
quote
unquote
hard
coded,
then
we
get
to
a
rust
host.
That
has
you
know
the
ability
to
do
webassembly
modules
as
plugins
as
built-ins,
and
then
the
Elixir
host
has
Elixir
plugins
and
then
we
lattice
them
all
together
and
I
say
use
a
built-in
and
I'm
using
I'm,
saying
built-in,
because
that's
just
what
we're
talking
about
right
now,
how's
it
going
oh
God
Kevin.
That
was
fast.
G
F
G
I
think
a
compromise
between
your
wild
wild
west
or
Justin's
Wild,
West
and
where
we
are
now
is
if
the
list
of
built-ins
is
variable
and
we
don't
have
contracts
that
specifically
indicate
whether
or
not
they're
built
in
so
if
you,
if
you
are
using
so
the
logic,
would
go
something
like
this
and
I'm
just
spitballing
here.
So
don't
don't
hold
me
to
it,
but
the
idea
would
be.
You
have
a
contract,
let's
call
it
Wazi
logging.
G
If
the
host
has
a
built-in
for
wazzy
logging-
and
there
is
no
link
definition
within
site
of
that
host,
then
it
will
automatically
provide
you
with
built-in
unconfigured
access
to
that
that
provider.
But
if
there
is
a
link
definition
floating
around
in
Alaska
for
that
particular
contract,
then
that
one
would
take
precedence
so
in
other
words,
you'd
be
able
to
have
hosts
that
provide
reasonable
default
built-ins,
but
only
if
no
link
exists
for
that
particular
contract.
So
that
way,
you'd
be
able
to
have
a
logging.
G
I
think
is
probably
the
the
best
example
where
the
host
is
going
to
provide
a
default
implementation
that
just
emits
the
standard
out.
But
if
you
deploy
a
distributed,
logger
capability
provider
into
the
lattice
and
then
Define
a
link
definition
between
your
actor
and
the
distributed
logger,
then
the
host
built-in
won't
handle
that
request.
The
distributed
one
will
and
that
way
we
have
reliable
heuristics
to
figure
out
which
which
capability
provider
is
the
Target,
and
we
won't
arbitrarily
choose
random
capability
providers
to
satisfy
a
request.
G
So
link
definitions
would
stay
meaningful,
explicit
and
durable,
but
we
would
have
kind
of
a
a
hierarchy
of
defaults
that
allow
hosts
to
provide
a
variable
number
of
built-ins.
A
A
Awesome
I
think
that
sounds
great
I'm
really
excited
to
think
about
how
that,
like,
we
could
extend
the
host
runtime,
especially
as
we
get
to
using
things
like
Wazi
HTTP
like
we
could
provide
more
and
more
built-ins
and
then,
of
course,
people
can
always
override
that
with
their
own.
That
sounds
awesome.
Yeah.
G
One
of
the
things
that
I
think
of
when,
when
I
think
about
like
the
H
about
reasonable
defaults,
is
the
HTTP
client
right
right
now.
Today
you
have
to
deploy
an
actual
capability
provider
in
order
to
give
your
actors
the
ability
to
make
HTTP
client
requests,
but
a
host
could
easily
provide
a
default
built-in
for
an
HTTP
client,
and
that
way
you
wouldn't
have
to
supply
a
link
definition
for
it
and
it
would
just
work.
G
A
Yeah,
that
sounds
like
a
good,
maybe
addition
to
the
control
interface
or
something
you
could.
You
could
ask
a
host
what
its
built-ins
are
or
auction
an
actor
to
a
host,
that
it
provides
the
right
built-in
something
something.
G
Yeah
the
host
already
dumps
a
labels
dictionary.
We
could
probably
either
use
the
labels
dictionary
or
you
know,
add
something
similar
just
make
it
part
of
the
the
host
inventory.
G
A
Back
with
the
Dinosaurs
like
before
oh
cool,
well,
I
apologize,
Bailey,
I,
got
super
excited
and
drawn
up
with
that,
but
I'm
really
happy
that
we
have
that
RFC
coming
out
of
it.
I'm
gonna
go
ahead
and
throw
it
to
you
with
our
remaining
time
to
talk
about
was
in
Cloud
incubating.
D
Yeah
thanks
Rick's
it's.
This
will
be
really
quick,
because
the
steps
to
become
incubating
are
actually
pretty
simple
and
we
basically
hit
all
of
them
already.
I
just
wanted
to
make
a
call
out
that
this
was
happening
on
the
community.
Call.
D
You've
probably
seen
me
put
in
a
couple
different
issues
for
things
that
I'd
like
to
have
done,
but
actually
all
the
issues
that
I've
put
in
so
far
are
stages
for
getting
to
graduated
and
not
actually
incubating,
but
the
the
majority
of
the
vetting
process
within
the
cncf
starts
at
the
incubating
stage
and
allows
at
the
sandbox
stage,
and
so
one
of
the
things
they
ask
you
to
do
is
take
a
look
at
the
graduated
aspects
and
just
show
that
you're
you're
moving
in
that
direction,
so
that
you'd
be
a
really
great.
D
You
know
hosted
project
that
is
graduated
so
right
now
we
are
at
the
sandbox
stage
and
what
I
expect
is
to
be
at
really
soon
really
soon
being
maybe
in
two
months
two
months
is
probably
would
be
my
best
bet
we'll
be
at
the
incubating
stage.
You
know
hard
goal
for
me
is
I
want
to
be
there
before
keep
con
Denae.
So
what
that
basically
means
we
already
do
a
lot
of
this
stuff.
D
The
call
out
is
that
I
plan
on
getting
us
to
have
an
adopters,
markdown
file
and
I
would
love
it.
If,
if
anybody
who
is
a
direct
adopter,
especially,
you
know
folks
that
are
on
this
call,
if
they,
if
they
could,
you
know
talk
about
how
they've
been
using
wasmcloud.
D
That
will
really
help
me
make
make
this
last
statement
here,
and
it's
it's
for
at
least
three,
but
as
many
as
I
can
get
is,
is
my
my
goal?
I
think
showing
how
it's
being
used
in
a
lot
of
different
places
will
be
important,
because
the
TOC
who
we
send
this
to
our
our
partners
in
hooking
up
all
kinds
of
different
services
within
cncf.
D
I
was
gonna
call
out
the
thing
that
you
set
up
Brooks,
which
is,
if
you
go
to
our
Wows
of
cloud
root,
and
then
you
click
the
open,
ssf
best
practices.
We
are
at
96
almost
there,
which
is
what
we
need
for
the
graduated
stage,
and
we
actually
just
got
another
green
check
here.
So
we're
moving
our
we're
moving
along,
probably
meet
this
one
already
so
yeah,
just
just
like
so
close,
three
things
and-
and
one
of
those
looks
like
I-
think
we're
already
good.
So
very
soon.
D
We'll
have
this
one
as
well:
go
ahead.
Brooks.
A
Yeah
all
right
I
had
a
little
thing,
so
hey
Bailey,
I'm,
a
user
and
oh
no,
my
mic
cut
out
at
that
exact
time.
I.
C
A
A
wise,
I'm,
glad
user
and
I
would
I
would
love
to
give
you
my
my
feedback
and
talk
about
what
I'm
doing
with
it
Bailey.
How
can
I?
How
can
I
best
get
in
contact
with
you
to
let
you
know.
D
If
you
are
comfortable
with
it,
I
would
say
post
it
in
the
wasn't
Cloud
slack,
because
then
you'll
get
a
bunch
of
emojis
from
everybody,
because
everybody
loves
seeing
usage
like
real
usage.
If
you're
not
into
that,
send
me
send
me
a
direct
message
and
and
I'll
I
will
write.
This
I'll
include
it
in
the
report
that
we
send
to
the
TOC,
but
yeah
like
Taylor,
said,
get
that
sweet
sweet
hit
of
emoji.
A
All
right,
well,
I'm,
gonna,
go
ahead
and
stop
the
stream
and
we're
all
welcome
to
hang
out
for
a
little
bit.
I
made
and
thank
you,
everybody
for.