►
From YouTube: wasmCloud Community Meeting - 18 Jan 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
And
I'm
gonna
do
the
intro
again,
which
is
which
is
going
to
be
fun
all
right,
hello,
everyone
Welcome
to
wasm,
Cloud,
Wednesday
or
January
18th.
This
is
our
community
meeting
and
as
we
get
started
today,
I
just
wanted
to
reiterate
a
couple
of
things.
As
we
look
at
our
agenda
Liam,
would
you
mind
giving
me
screen
sharing
permissions?
A
One
of
the
points
on
our
agenda
today
is
simply
to
chat
about
Community
meetings,
streams
and
and
kind
of
the
implications
for
that
so
I'll
go
ahead
and
share
my
I'll
go
ahead
and
share
my
window
really
quick.
So
if
you
look
at
the
agenda
today,
I
put
it
second
I'll
correct
this
to
be
the
first
thing
that
we
talk
about,
but
first
of
all,
hello.
Everyone
on
YouTube,
Twitter,
LinkedIn,
all
the
different
streaming
platforms.
A
So,
just
a
general
reminder
for
anybody
on
the
zoom
that
this
is
being
live
streamed.
All
the
meetings
before
were
being
recorded,
anyways
and
and
posted
to
YouTube,
but
this
makes
it
really
nice.
We
can
just
go
ahead
and
right
after
the
call
ends
post
the
link
at
the
bottom.
You
know
in
this
recording
section
and
go
from
there,
so
I
just
wanted
to
call
that
out
really
quick.
It
seems
with
a
little
bit
of
friction.
A
We
figured
out
the
right
way
to
get
this
to
stream
to
all
the
places
and
so
really
excited
to
bring
you
this.
This
meeting
live
every
week
now,
for
that
being
said
with
that
being
said,
that
was
all
of
the
fun
disclaimer
for
the
beginning
of
the
call.
A
As
usual,
we
like
to
try
and
start
off
with
some
form
of
demo,
and
we
have
a
very
exciting
one
with
a
couple
of
topics
that
will
probably
follow
this
week
with
a
first
time
contribution
from
one
of
our
fellow
team
members
at
cosmonic,
Patrick
Patrick.
Actually,
if
this
is
the
first
time
you've
been
on
a
call,
do
you
want
to
go
ahead
and
do
an
intro
and
then
just
kind
of
generally
roll
into
your
your
demo.
B
I
said
yeah
sure
I
am
Patrick
gray
I'm
on
the
human
team
at
cosmonic,
been
doing
infrastructure,
devopsy,
SRE
stuff
for
oh
man,
almost
a
decade
now
and
yeah
I
was
super
excited
last
week
to
kind
of
like
just
look
at
the
code
base
for
Watson,
Cloud,
OTP
and
kind
of
like
I've,
never
really
written
Elixir
before
so.
B
Please
review
my
code
with
all
of
the
eyes
for
knits
and
fixes
that
you
can,
because
you
know,
I,
don't
want
to
accidentally
introduce
any
bugs,
but
yeah.
We
were
talking
about
local
Dev
and
making
the
local
Dev
Loop
faster
and
I
kind
of
wanted
to
take
a
stab
at
starting
actors
from
file
and
there's
been
some
chat
on
the
pr
about
like.
B
Should
we
enable
this
by
default,
or
should
we
just
have
it
kind
of
like
wash
can
set
an
environment
variable
and
start
it
up,
but
that
hasn't
quite
kicked
out
yet
I
mean
I'm
totally
happy
for
it
to
be
only
working
for
local
debt,
but
yeah
should
I
just
go
ahead
and
demo.
It
Brooks.
B
Oh
no
Zoom
would
like
to
record
okay.
One
second
I
need
to
allow
it
there
we
go.
C
A
While
we're
doing
the
zoom
Shuffle
I
figured
I
could
go
ahead
and
share
the
the
actual
pull
request.
I
can
go
ahead
and
drop
this
into
the
chat.
Actually
anybody
who's
who's
watching
on
our
various
platforms.
I
think
we
should
be
able
to
re-share
that
comment
as
well,
but
it's
the
it's
one
of
the
more
recent
PRS
in
the
wasm
cloud,
OTP
repo
foreign.
A
Probably
asked
Patrick
to
re-sign
in
and
reprove
that
he's
a
real
human
and
reprove
his
identity
and
everything
I
just
want
to
give
a
shout
out
to
CJ
one
of
our
community
members
who
was
going
through
some
of
our
documentation
and
introductory
tutorials
and
kind
of
gave
a
really
simple
readout
about
what
he
wanted
in
a
developer
experience
for
a
project
like
this.
It
is,
it
sounds
really
simple
when
you
think
about
it,
but
the
the
one
two
three
step
is
I
want
to
be
able
to
change.
A
Some
code,
run
a
command
and
then
have
the
new
code
loaded
and
and
testing
against
it,
and
that
is
kind
of
some
of
the
inspiration
for
what
got
us
talking
about
local
development
experience,
what
it
means
to
start
an
actor
from
a
local
file
and
then
I
have
stalled
long
enough
to
give
it
back
to
Patrick.
Oh.
B
Hey
yeah,
sorry
about
that.
I
am
still
on
a
new
Mac.
Getting
all
the
right
permissions
in
place
host
disabled
participant
screen,
sharing.
A
B
A
B
So
yeah
so
currently
starting
it
from
I've
got
my
Branch
running
over
here
for
the
wise,
Supply
OTP
host
and
then
I
can
grab
the
host
ID
and
set
it
to
Like,
A,
bash
environment
variable
and
then
I
can
go
and
look
at
that
host
and
see
that
it
doesn't
have
any
actors
right
now
and
then
in
this
pane,
what
I've
done
is
I
just
have
the
the
hello
world
actor
and
I
changed
some
of
the
the
strings
in
here.
B
So
this
you
know
it
says
hi
from
file
and
then,
if
you
don't
give
it
a
name,
it
just
says
anonymous.
So
let's
go
ahead
and
watch
build
that
hooray
and
then
we
do
Bosh
control
start
actor
file,
and
then
you
get
your
local
path
which
bash
or
zsh
should
be
setting
give
it
the.
What
is
it
I
file?
B
B
B
If
it's
running
in
a
container,
you
would
have
to
like
copy
it
into
the
Container
or
otherwise
like
mounting
a
directory,
and
then
what
we
can
do
is
let's
go
get
our
image
for
you
again,
so
we'll
be
a
little
clear.
B
Oh
that's!
Less
pretty.
B
There
we
go
that's
a
little
better
and
then
lastly
figured
out
how
to
call
oh,
let's
get
our
actor
ID
actor
ID
equals
gotta.
Do
it
up
there,
because
that's
where
I
said
how
to
study?
B
Ready
and
then
we
do
call
Factor
ID
what
we
need,
a
hello,
don't
we?
What
is
it
header
there?
It
is
that
should
be
it
yep.
So
we
called
our
active
ID
with
this.
Is
the
I
guess
like
the
call
that
gets
sent
over
to
it,
and
then
it
knows
that
this
is
an
HTTP
request
and
then
we
get
some
fun
characters
here,
but
what
we
see
here
is
hi
from
file
Anonymous.
B
B
Problem
right
now
is
that,
because
the
reference
to
the
file
on
the
file
system
doesn't
change,
the
wise
and
Cloud
host
will
like,
if
you
just
keep
starting
more
actors,
it'll
actually
be
starting
different
versions
of
the
actor,
and
then
they
would
be
like
giving
you
different
responses.
So
if
you
have
to
do,
watch
control
stop
after
I
think
it's
after
I'd
be.
B
Reset
our
actor
ID
to
the
actor
ID,
and
then
we
will
call
and
then
now
we
get
high
from
file
and
then
Anonymous
is
lowercase
if
you're
on
a
Mac.
Another
cool
thing
that
you
could
do
is
like
you
use
like
I
notify,
and
then
you
can
write
like
a
really
tiny
bit
like
one-liner
bash
script,
to
like
recompile
this
and
run
this
in
one
terminal
as
you're
editing
your
code
on
OS,
X
or
sorry
on
Mac
OS.
B
There's
this
little
program
called
FS
watch
that
uses
the
custom
Mac
OS
apis
and
you
can
do
the
same
thing
but
I
think
Brooks
you're
interested
in
possibly
making
wash
do
that
automatically
in
future
I,
don't
you
said:
maybe
I
I
don't
know,
but
anyway
yeah.
That's
my
little
demo
and
that's
it
for
me.
How
do
I
stop
sharing?
Oh
there?
It
is.
A
A
It
watches
that
local
file
on
disk
for
any
changes,
and
so
when
you
run
wash
build
it'll,
see
that
it
changed
and
reload
it
and
I
would
love
to
just
build
that
in
to
wash
something
like
you
know
why
and
don't
take
any
of
this
is
a
final
API.
It's
like
wash
Auto
Dev.
You
know
on
a
file
like
that's
that's
sweet,
and
so
you
can
just
have
that
running
kind
of
in
one
terminal,
and
that
would
essentially
do
the
same
thing
where
you're
talking
about.
A
If
you
start
multiple
instances
of
the
same
actor
but
they're
actually
different,
like
the
implementation,
is
different.
How
you
can
do
a
call
and
it'll
be
round
robin
between
them
that
can
also
take
care
of
kind
of
the
stopping
and
starting.
That
makes
a
lot
of
sense.
B
Yeah
I
also
want
to
talk
to
folks
that
figure
out
like
is
there
for
local
file,
since
it's
kind
of
like
a
one-off,
like
custom,
one,
maybe
there's
a
different
way
like.
Maybe
we
could
just
do
a
shot
sum
of
the
actor
somewhere
in
there,
and
you
know
when
we
restart
it.
It
just
detects
that
the
actual
you
know
under
dot
was
and
file
change
or
something
I,
don't
know,
but.
A
Yeah,
it's
like
when
you
start
an
actor
and
it
has
the
same
public
key
of
an
actor
that's
already
running.
If
the
Shah
song
is
different,
that
means
the
actor
is
different
and
you
know
we
we
kind
of
we
do
this
in
a
less
robust
way
now,
which
is,
if
you
try
to
start
an
actor
from
an
oci
reference,
and
it's
a
different
oci
reference
then,
and
you
may
have
run
into
this
or
people
may
have
ran
into
this.
A
It
says
hey
by
the
way
you're
already
running
this
actor,
and
it
looks
like
it's
probably
going
to
be
different
so
that
that
sounds
like
a
bad
idea.
That'll.
This
will
handle
these
requests
differently.
So
stop
it
first.
So
the
that's
right
and
coffee
guy
is
exactly
correct
that
in
the
JWT
we
actually
already
have
the
hash
embedded.
We
do
it
for
to
avoid
tampering.
A
We
embed
the
hash
of
the
module
so
that
you
can't
like
change
it
in
transit.
You
know
that
what
you're
running
is
what
was
signed
sweet.
We
got
a
couple
of
a
couple
hands
up,
Liam
I
think
you
were
first.
D
Sure
Patrick,
you
know
this
feels
deceptively
simple
and
I
appreciate
the
discussion
around
some
of
the
nuances
around
like
change
detection
things
like
that,
but
the
feature
itself
we
were
looking
at
I
think
hiding
behind
a
feature
flag
to
say
you
know
to
enable
this
feature
set
or
not.
Would
you
mind
sharing
why
we
would
want
this
behind
a
feature
flag
and
why
this
may
not
be
the
best
practice
for
production
or
for
productionizing
awesome.
D
Cloud
I
just
found
that
discussion
to
be
relevant
and
interesting.
B
Yeah
so
I
mean
Kevin
gave
a
great
set
of
feedback
on
the
PR,
but
I.
Think
one
example
would
just
be
the
fact
that,
like
when
you're
deploying
systems
in
the
cloud
and
your
own
Hardware
that
can
disappear
on
Hardware
virtual
machines
that
could
disappear
from
you.
Maybe
you
could
lose
a
file
system
here
or
there,
relying
on
local
hard
drives
to
always
kind
of
have
all
the
files
that
you
sync
to
them
in
the
first
place,
isn't
necessarily
a
great
idea.
B
You
know
I
think
we
definitely
want
to
push
people
towards
well
I.
Think
in
the
past
we
push
people
towards
their
spindle
and
then
there's
also
the
oci
preferences,
which
can
use
in
oci
registry
and
I.
Think
like
there's
an
opportunity
for
other
types
of
you
know
distributed
stores,
but
we
generally
don't
want
I
I
mean
I
I!
B
Think
that
it's
good
to
not
just
give
people
that,
like
oh,
just
use
a
local
file
and
then
like
SCP
everything
to
all
the
servers
in
your
infrastructure,
I,
don't
think
that's
necessarily
best
way
to
go
about
it
and
then
I
think
Kevin.
You
had
some
good
input
on
like
the
security
side
and
other
stuff.
E
Yeah
I
just
to
begin
with
I
I
kind
of
wanted
to
take
Umbridge
to
Brooks's
reference
that
this
is
not
that
our
current
setup
is
not
as
robust
part
of
the
reason
why
there
are
why
deploying
an
actor
is
as
friction
full
as
it
is
right
now
is
because
we
have
intentional
guard
rails
around
everything.
E
The
one
of
the
scenarios
that
can
ruin
someone's
day
in
the
distributed
system
is,
if
I,
have
an
actor
on
one
machine,
or
you
know
an
actor
in
one
virtual
host
and
another
actor
and
that
same
actor
in
another
virtual
host.
But
the
implementation
differs
then,
when
Verizon
cloud
goes
to
round
robin
your
requests
between
the
two
actors,
you're
going
to
get
half
of
them
work,
half
of
them
won't
work.
The
old
way
and
half
of
them
will
work
the
the
new
way,
and
we
need
to
avoid
that
scenario.
E
I
mean
there
are
intentional,
like
blue-grain
testing
things
when
you
would
want
to
do
that
on
purpose,
but
you
don't
want
to
be
able
to
accidentally
cause
a
drift
in
functionality
within
that
same
actor
across
your
lattice.
So
we
have
guard
rails
in
place
so
that
we
will
detect
that
when
you
attempt
to
start
an
actor
on
say,
host
a
if
that
actor,
that
you're
starting
on
host
a
is
different
than
the
same
actor.
E
With
the
same
identity
running
on
host
B,
we
will
actually
reject
your
attempt
to
start
that
actor
on
host
a
and
we
do
that
so
that
we
can
try
and
prevent
the
Divergence.
And
you
know
we
actually
will
admit
a
message
saying
that
what
you
really
want
to
be
doing
is
making
a
live,
update,
call
which
will
correctly
move
you
from
one
version
to
the
next.
E
So,
from
a
security
standpoint
and
from
just
the
distributed
systems,
standpoint
being
able
to
load
bytes
from
the
file
system
is
super
convenient
for
developers
in
a
local,
iteration,
Loop
iteration
Loop,
but
is
scary,
dangerous
in
production,
and
so
that's
kind
of
why
we
want
to
be
able
to
Either
Leave
It
Off
by
default
or
make
it
easy
to
disable
things
like
that.
E
E
A
A
If
this
feature
is
mainly
meant
for
local
development,
can
you
set
an
environment
variable
or
something
to
enable
this
that
says,
Dev
or
local
or
something,
and
that's
actually
exactly
what
what
we've
been
talking
about
in
the
the
pr
Patrick
floated,
wasmcloud
enable
local
files,
something
just
just
some
environment
variable
that
will
be
disabled
by
default,
to
take
the
secure
Choice
by
default,
but
then
some
of
our
tools
that
are
specifically
that
specifically
revolve
around
local
Dev
things
like
wash
up
or
what
we
kind
of
proposed
earlier,
with
the
wash
Auto
watch
and
actor
things
like
that,
those
would
enable
it
by
default
those
those
would
enable
the
environment
variable
so
that
it's
just
the
best
experience
for
local
development
Patrick
did
you
want
to
say
anything
else
on
on
that
one.
A
Yeah,
thank
you,
Patrick,
hey
anybody.
Anybody
else
have
any
other
questions
or
comments
for
for
Patrick
or
this
notion
of
a
local
development
loop
with
starting
from
files.
F
I'll
say
my
piece
for
what
it's
worth
I've
actually
been
thinking
about
this
future
for
a
very,
very
long
time,
and
local
developments,
specifically
for
me
and
I'm
being
selfish,
does
not
mean
same
machine.
So
picking
things
up
up
the
file
system
does
not
close.
F
My
developer
loop
I
would
be
more
interested
if
we
could
look
at
a
approach
where
wash
was
the
mechanism
that
uploaded
over
the
lattice
to
the
host,
because
all
of
my
development
goes
on
a
machine
behind
me
and
Via
wash
on
my
Mac
so
like
that
feature
set
really
wouldn't
help
unless
I
start
scp-ing
things
around.
A
Okay,
interesting
I
actually
raised
my
hand
a
little
preemptively
coffee
guy,
because
I
was
thinking
you
know,
maybe
that
you're
gonna
bring
up
Docker
and
like
yeah.
We
need
to
have
some
extra
things
in
our
documentation
for
mountains.
A
You
know
that
it
certainly
is
something
that
and
I
think
Patrick
had
already
thought
about
it.
He
made
a
comment
about
it,
but
that's
a
great
great
point
that
local
development
doesn't
always
mean
on
your
exact
local
file
system
and
love
the
idea
of
brainstorming,
something
where
we
upload
bytes
over
a
lattice,
and
you
know.
Essentially
you
have
a
control
interface
connection
to
a
host.
That
means
you
can
start
an
actor
over.
That
connection,
see
Kevin
I
feel
like
you've.
You've
had
some
thoughts
on
on
this
one.
A
Did
you
have
anything
else
that
you
wanted
to
add
for
that?
I
think
that
this
notion
has
kind
of
floated
around
before,
but
there
are
some
complications
in
terms
of
Nat's
message:
maximum
sizes
and
dealing
with
dealing
with
uploading
actors
over
Nats,
as
some
some
strange
edge
cases,
yeah.
E
E
So,
for
example,
we
support
the
ability
to
tell
a
host
to
scale
up
the
in
the
number
of
instances
of
a
running
actor
and
if
the
bytes
for
that
running
actor
were
received
via
direct
stream
over
Nats,
then
that
host
now
has
to
make
to
maintain
a
special
way
to
keep
those
bites
so
that
it
can
scale
them
and
further.
If
you
try
and
tell
another
host
to
start
an
actor.
E
This
is
where
the
the
Divergence
comes
in,
because
now
you
can,
if
you're
able
to
directly
stream
bytes
from
say
wash
to
a
host,
then
you
now
have
the
ability
to
easily
create
that
Divergence,
where
you
can
push
two
actors
with
the
same
public
identity
that
have
two
entirely
different
implementations,
and
so
again
we
would
have
to
put
guard
rails
around
that
to
make
sure
that
when
you
try
and
do
that,
we
can't
we
will
try
and
detect
a
difference
or
potential
Divergence
and
block
you
from
starting
the
second
actor.
E
So
again,
super
short
version
is
yes.
It
would
be
very
handy
to
be
able
to
remotely
push
bytes
to
an
actor
or
to
a
host
without
having
to
use
a
registry,
and
we've
been
planning
on
doing
that
for
a
while.
Now
the
trick
is,
of
course,
just
doing
it
in
a
safe
and
reliable
way
that
doesn't
give
you
easy
ways
to
accidentally
ruin
your
cluster.
G
I
was
just
wanting
to
bring
up
like.
Could
we
just
combine
The
Best
of
Both
Worlds
here
to
start
and
then
work
like
I'm
trying
to
think
of
the
don't?
Let
perfect
be
the
enemy
of
good
here,
because
I
think
to
solve
it
for
like
anyone
using
it
all
the
time.
But
is
there
a
problem
with
having
a
having
this
like
over
naps?
G
It
doesn't
even
have
to
store
into
an
object
store,
it
could
go
gnats
to
disk
and
it
only
is
supported
with
the
development
flag
on
I
mean
it's
the
same
thing
as
like
doing
with
a
file
like
it's,
it's
the
same
danger
of
doing
it
with
a
local
file.
If
you're
joined
to
a
cluster
like
then
multiple
people
mentioning
it
with
doing
it
like
with
cosmotic
super
constellations
but
like
if
you
like.
It's
the
same,
it's
the
same
set
of
difficulties.
G
So
if
we're
very
clear
with
a
with
a
feature
flag
that
we
give
people
the
inner
Dev,
Loop
type
of
thing
like
just
that
that
that
part
without
having
to
solve
the
rest
of
it
at
first.
So
it
gives
us
two
steps,
rather
than
having
to
solve
the
whole
kit
and
caboodle
before
we
actually
have
that
functionality
available.
B
So
just
I
guess
one
thing
I
had
mentioned
in
the
future,
like
even
if
you're,
working
on
local
Dev
and
you're,
trying
you're
opening
up
to
speed
connection
and
you're
copying
something
you're
adding
like
as
actors
get
bigger
that'll,
be
you
know
that
that's
going
to
add
more
time
in
and
like
I
feel
like
rust
is
already
takes
long
enough
to
compile,
but
I
think
that
yeah,
like
maybe
some
combination,
slash
of
the
features
would
work
there.
The
question
I
actually
had
was,
and
I
don't
want
to
Kevin.
E
Yeah
sure
I
I
just
wanted
to
add
that,
like
you
said,
the
the
ability
to
send
bytes
send
actor
bites
directly
to
or
even
send
provider
bytes
for
that
matter
directly
to
a
host.
Again
is
one
of
those
things
that
creates
that
potential
Divergence
that
can
cause
all
sorts
of
horrible
problems.
So,
yes,
I
think
what
you
would
want
to
be
able
to
do
is
explicitly
enable
the
or
you
know
this
mode
or
I
guess
put
in
other
ways
to
explicitly
remove
the
bumpers
from
the
side
of
the
bowling
lane.
E
I
would
like
to
see
a
unified
way
of
doing
both
and
also
have
a
way
to
to
make
it
explicit
that,
if
you
want
to
do
these,
you
have
to
turn
off
some
guardrails.
B
Yeah
and
I
guess
the
thing
that
still
sticks
out
for
me
is
like
I,
don't
understand
like
I'm
compiling
a
different
binary.
Every
time
like
I
can
change
a
single
character
in
my
little
hello
world
and
compile
it
and
that's
a
different
binary
every
time,
so
I
guess
I
I.
Just
don't
still
don't
understand
why
the
content
or
the
binary
itself
can't
changing
can't
indicate
to
the
system
that,
like
this
is
a
different
thing.
E
So
yeah
Jordan
I,
know
you're.
You
got
your
hand
out,
but
I
want
to
answer
real
quick
before
I
forget
one
of
the
other
one
of
the
other
many
implicit
guard
rails
inside
wasmcloud
is
the
concept
that
an
actor
is
immutable
and
it
wasmcloud
is
designed
to
be
pushed
and
run
in
production
on
quote,
unquote,
immutable
infrastructure
and,
as
a
result,
if
you
tell
what
the
wasm
cloud
lattice
to
run
version
0.0.1
of
your
actor,
the
assumption
is
no
one
should
ever
be
able
to
change
the
bytes
that
are
associated
with
0.0.1.
E
That's
why
we
did
explicitly
turn
off
the
ability
to
pull
latest
from
oci
registry
images,
and
so
that's
another
guardrail
that
these
features
I,
don't
want
to
say
violate.
But
if
you
were
to
allow
these
features
to
go
unchecked
in
production,
they
would
basically
erect
the
stability
and
predictability
of
your
lattice.
B
Jordan,
do
you
earn
Coffee
Guy?
Do
you
want
to
go.
F
I,
actually,
don't
remember
my
whole
question,
but
I
think
it
was
around
Kevin
I'm,
not
I,
guess
I'm,
not
completely
understanding
the
difference.
So
the
most
the
powerful
mechanism
here
becomes
the
tag
to
an
oci
reference.
Then,
because
is
what
it
sounds
like
because
to
me,
when
a
host
pulls
something
down
from
a
registry,
we
cash
it
on
disk
and
then
that
host
uses
that
cash,
if
I
push
it
over
the
lattice
and
it
caches
it
to
disk.
F
There's
still
a
lot
of
info
in
the
in
the
jots
that
we
could
reference
hash
and
whatnot.
But
it
seems
to
me
that
the
immutable
piece
is
the
tag
in.
Is
that
but
because
I
guess,
without
the
tag
I,
don't
see
how
it's
any
different
from
pulling
an
oci
reference
to
pushing
assigned
actor
over
the
lattice,
because
they
both
end
up
in
a
cash
Factory.
On
this,
it.
E
Doesn't
really,
why
isn't
Cloud
doesn't
really
make
any
distinction
between
tagged
or
untagged
images?
All
it
does
is
try
as
hard
as
it
possibly
can
to
enforce
that.
If
one
host
has
has
started
an
oci
reference
that
when
another
host
attempts
to
start
the
same
oci
reference,
it
is
for
the
same
set
of
bytes.
F
E
B
Yeah
I
guess
coming
from
like
kubernetes
Docker
World,
you
know
like
like
human
readable
tags
are
always
just
that:
they're
human,
readable
tags
and
anytime
you
like
configure
the
system
with
them.
B
It
will
just
pull
different
bytes
like
if
you
rev,
that's.
Why,
like
you
know,
using
latest
tag
in
production
is
a
anti-pattern
when
you're
running
you
know,
containers
and
so
I.
Guess,
that's
where
I
wonder
like
could
the
system
itself,
you
know
say
you
have
you
know
your
your
actor
ID?
B
Couldn't
the
system
itself
also
ID,
you
know
say
like
this:
is
actor
ID
blah
at
hatch?
You
know
because
like
if,
if
you
are
revving
it
or
if
you
are
changing
it
and
then
that
way,
you
could
still
be
able
to
maintain
the
fact
that,
like
you
are
running
this
act
here
and
even
if
you
do
end
up,
you
know
Val
breaking
best
practices.
The
system
will
still
maintain
that
single
binary
because,
like
right
now,
will
the
oci
reference
does
it?
E
Not
oh
interesting
yeah,
the
oti
reference
we
perform
the
guard
rails
on
you
can't
you
can't
mutate
the
the
contents
of
an
actor
for
the
same
oci
reference.
But
your
point
is
a
good
one,
which
is.
We
could
probably
relax
some
of
the
requirements
that
we
have
around
things
like
the
oci
references
matching
and
things
like
that
and
rely
more
on
the
combination
of
the
public
ID,
the
public
key
and
the
internal
hash
from
the
Json
token.
E
And
if
we
use
the
combination
of
those
two,
then
we
should
be
able
to
allow
a
little
bit
more.
Flexibility
in
terms
of
letting
arbitrary
bytes
come
in
still
won't
solve
the
problem
about
the
availability
of
bytes
from
arbitrary
hosts,
but
it'll
at
least
make
it
so
that
you
can
still
kind
of
shove
bites
around
with
a
little
bit
more
confidence.
G
And
looks
like
we
have
a
little
bit
more
brainstorming
to
do
around
that.
So
is
the
decision
here
too,
to
just
have
that
and
this
file
thing
or
do
we
want
to
all
go
more
towards
the
let's
try
to
figure
out
how
to
do
this
over
the
lattice
type
of
type
of
idea.
F
Selfishly
I'm
gonna
start
practicing
everything
I
say
with
that
over
the
lattice
then
makes
it
so
that
it's
a
It's
like
a
something,
no
matter
what
host
and
you
know
all
hosts
in
the
future
can
support.
If
you
support
you
know,
the
lattice
schema
right
instead
of
like
a
feature
embedded
into
the
actual
run
time.
So
that's
why
I
like
lattice.
B
You
know
it's
my
first
contribution
and
I,
don't
assume
that
it
will
be
accepted,
but
I
do
want
to
point
out
that,
like
a
read
off
of
an
SSD
is
going
to
be
probably
an
order
of
magnitude
faster
than
an
SCP
and
then
a
save
and
then
another
read,
or
what
have
you
so
I
really
do
think
you
know
I
went
into
it
with
this,
like
what
is
the
best
possible
experience
for
local
Dev
when
you
have
a
compiled
actor,
slash,
binary
and
I
I
think
this
is
as
close
as
you
can
get
to
that
speed.
G
Yeah,
that
was
my
other
concern
too,
is
just
from
a
road
mapping
thing
we're
starting
to
try
to
like
put
together
what
we
want,
what
we're
hoping
to
get
done
with
the
Watson
Cloud
project
over
the
next
year,
or
so
we're
trying
to
put
some
ideas
together
and
the
thing
is
it's
just
about
Road
mapping
this
like
I
love,
the
lattice,
ID
I,
think
it's
good
to
consider
that
and
do
it,
but
I
also
don't
want
to
just
say:
well
a
couple:
people
in
community
caller
the
kind
of
people
who
like
to
do
remote,
Dev,
which
I'm
not
saying
that's
bad,
and
so
therefore
we're
just
gonna
wait
like
we
have
something
that
can
work
right
now
and
could
definitely
be
useful
for
a
local
developer
who's
just
trying
this
out
and
so
I
think
that
and
and
yeah
that's
one
of
those
things
that
there's
the
cave
Easter.
G
We
there's
a
bunch
of
ideas
there
Jordan,
but
even
that,
like
I,
instead
of
going
down
like
this
one
is
so
simple
and
straightforward.
It
is
on
your
file
system,
it's
on
and
so
like.
It
just
seems
like
a
really
straightforward
way
to
do
it,
and
so
my
argument
would
be
that
we
should
do
both,
because
we
don't
necessarily
know
when
we're
going
to
put
on
and
have
the
time
to
properly
do
and
fully
complete.
G
We
want
to
make
sure
we
fully
complete
these
features,
not
not
like
get
halfway
there,
and
so
I'd
rather
have
both
of
them
than
have
a
one
that
we're
waiting
for,
and
we
might
not.
We
might
not
get
to
for
a
couple
months
from
now.
Any
thoughts.
B
F
E
Yeah
I'm
I'm
fine,
with
getting
whatever
works
now
made
available
so
long
as
the
default
mode
in
production
is
to
not
allow
this.
G
Yeah
I
think
feature
flag,
backed
was
was
a
thing
we
all
agreed
on.
So
I
think
that
that's
what
it'll
be
and
then
we
can
merge
in
basically
what
Patrick's
been
working
on
and
then
we'll
have
that
available,
and
then
we
can
start
leveraging
that
for
like
local
wash
development,
Bailey.
H
Do
we
have
examples
of
where
we
Mark
features
as
experimental,
because
I
think
yes
disallowed
in
production
enabled
by
flag,
but
also
would
be
great
if
it's
something
that
we
are
considering
redoing
in
a
different
way
later,
marking
it
as
experimental,
so
that
people
are
aware
that
it
might
not
always
work
that
way.
Yeah.
E
G
Yeah
I
think
the
standard
here
is.
We
have
a
the
log
like
Kevin
said:
that's
always
a
good
thing
to
have
just
a
big
warning.
Sign
that
says:
hey
you've
enabled
this.
This
is
an
experimental
feature
that
will
likely
be
removed
or
or
Supply
I'd,
say
supplanted
like,
but
with
a
different
feature
in
the
future.
G
Also,
this
is
not
supposed
to
be
used
for
production,
all
the
warning
stuff
and
then
I
also
think
we
should
start
having
in
our
documentation
yeah.
That's
the
other
thing
too,
like
I've
seen
that
I
was
actually
about
to
go
to
that
too
Bailey's
like
when
we
document
this
and
the
environment
variable
we
choose
I've
always
seemed
like
yeah.
It's
like
the
x's
in
different
places,
but
I
always
like
to
stick
with
the
like.
G
So
to
be,
was
on
cloud
underscore
and
then
the
rest
of
the
names
would
be
like
wasn't
cut
underscore
X
underscore
rest
of
the
name,
and
then
that
should
be
documented,
so
I
think
what
we
want
to
do.
Patrick
to
merge,
just
I
think
we're
going
to
try
to
do
this
with
a
lot
of
things.
Moving
forward,
too,
is
before
we
merge
your
actual
code
PR.
We
want
to
see
an
accompanying
docs
PR.
G
That
shows
like
what
all
the
things
are
to
configure
it.
All
the
warnings,
caveats
proviso's,
you
know
all
those
kind
of
things
and
then
once
we
see
that
up,
we
can
merge.
We
can
merge
both
of
them
and
call
the
feature
done.
So
that's
what
I'm
thinking
like
is
the
path
forward
here
is
then
we
can
very
clearly
document
it
as
like
on
the
starting
and
actor
page
and
we'll
just
have
like
the
warning
box.
G
That
says
this
is
only
for
use
and
development
and
will
be
likely
replaced
with
a
different
feature
down
the
road.
Just
all
those
kind
of
things.
B
Yeah
I
also
think
it'd
be
great.
You
know
say
on
the
local
Nats
route.
You
know
there
is
a
Docker
file
when
you
read
the
wising
blood
docks.
There's
like
a
Docker
file
pointed
out
that
if
you
want
to
do
development
with
Docker,
you
can
run
everything
separately
in
containers
and
I.
Think
that
is
not
served
as
well.
By
this
feature,
you
know
we
need
something
to
make
that
Loop
even
easier
as
well.
G
I
mean
for
what
it's
worth
I
talked
about
for
like
two
years.
At
this
point,
the
idea
of
having
bindle
over
Nats,
eventually
I'll,
get
around
to
that
when
I
decide
to
hack
on
it
out
of
just
wanting
to,
but
like
that's
not
like
on
the
roadmap
or
anything,
it's
just
something
that
I
there
is
a
proposal
out
there
and
things
we've
talked
about
so
there's.
E
G
Okay,
the
only
other
thing
I
wanted
to
bring
up
and
Kevin
I
might
have
you
speak
to
some
of
this
is,
and
by
the
way
I
took
over
for
Brooks
Brooks
did
not
just
like
I'm,
not
just
shoving.
Brooks
aside,
you
can
call
me
alt
bricks
and
so
I
just
wanted
to
bring
up
the
upcoming
wascap
092
upgrade
so
ascap's,
probably
something
you
might
not
have
heard
of,
because
it's
kind
of
underneath
the
covers
a
lot
of
times,
but
is
the
signing
Library?
G
It's
how
we
actually
sign
like
with
the
capabilities
and
everything
when
you
have
an
actor
and
a
provider.
Those
things
get
signed
and
have
this
thing
that
says:
hey
I
have
these
capabilities.
These
are
what
this
is.
What
I'm
allowed
to
use
so
we're
coming
out
with
a
new
version
of
this,
and
it
is
a
breaking
version
so
0.9
it
will
be
0.9.2.
G
We
had
some
patches
that
we
worked
through
as
we
tested
some
of
the
edge
cases,
and
this
will
be
a
complete
breaking
change
for
the
fact
that
anything
signed
with
it
must
be
run
on
a
0.60
host
but
I'll.
Let
Kevin
speak
to
some
of
the
details
around
him.
E
So
the
the
short
version
is
that
the
library
that
we're
using
to
read
and
then
rewrite
the
webassembly
module
in
order
to
embed
the
signature
in
it
is
old
and
unmaintained.
And
so
what
happened
is
at
some
point.
The
webassembly
modules
that
are
being
created
by
quote-unquote
modern,
compile
targets
contained
one
or
more
opcodes
that
this
library
was
never
aware
of,
and
you
can
produce
this
pretty
easily
by
generating
YZ
binaries.
E
But
yeah
Jordan's
got
it
I'm
code
252,
my
favorite,
so
the
the
main
idea
behind
that
is
that
it's
just
it's
older
than
the
standard
that
we're
generating
so
the
upgrade
to
Alaska
makes
a
change
so
that
we
can
read
the
new
versions
of
all
these
wazzy
files.
E
But
as
a
result
of
that,
the
hashes
of
the
bytes
that
we
generate
for
a
human
module
are
not
compatible
with
the
hashes
that
we
used
to
generate
for
the
old
ones,
because
the
old
one
actually
had
some
proprietary
code
in
it.
That
rewrote
certain
aspects
of
it.
So
a
round
trip
of
those
bites
was
lossy,
so
short
version
is
we
have
to
in
order
to
keep
up
with
the
new
targets.
We
need
to
use
a
newer
form,
a
newer
library
and
the
newer
Library
won't.
Let
us
make
backwards,
compatible,
hashes.
G
Yeah,
so
old
ones
will
still
work
in
the
new,
so
it
it's
backwards
compatible.
But
not,
let
me
make
sure
you
said
the
backwards
compatible,
but
not
forwards
compatible.
If
that
makes
sense.
So
you,
if
you
basically
after
we
upgrade
these
libraries
once
you
build
an
actor
and
sign
it,
you
won't
be
able
to
run
it
on
an
old
I.
Think,
that's
I,
think
I
got
reverse
I!
Think
that's
forward
compatible.
E
To
be
able
to,
you
won't
be
able
to
run
it
on
an
old
was
the
cloud
host.
A
new
ASM
Cloud
host
will
load
old,
one
Cloud
binaries,
but
it
will
skip
the
hash
check.
E
G
Yeah
and
Bailey
correct
me
if
I'm
wrong.
This
is
also
getting
us
more
in
line
with
what
the
actual
like
some,
this
other
signing,
specs
that
are
going
on
right
now,
it's
not
all
the
way
there,
because
those
specs
are
really
new
right,
but
we're
trying
to
move
towards
like
kind
of
having
standards
here,
so
that
we're
following
along
with
it
well.
H
You
know
we're
making
the
standard
right
now,
the
in
the
web
assembly
space
there
was
a
webassembly
signing
proposal,
but
that
seems
to
have
really
stalled
out
for
over
a
year
now
so
I'm
kind
of
feeling
like
a
lot
of
what
we're
doing
in
Wow's
cap.
H
Maybe
we
could
talk
about
you
know,
making
a
general
purpose
outside
of
Blossom
cloud
and
have
it
be,
you
know,
be
the
standard
that
would
be
great
for
all
of
us
right,
because
we
wouldn't
have
to
make
too
many
changes
for
wasmcloud,
but
also
it
would
be
encouraging
the
rest
of
the
community
to
sign
all
the
things
which
is
really
what
we
need
to
be
doing
in
software.
So
more
platform
terms
that
offer
that
the
better
for
us
as
end
users
existing
in
the
world.
G
G
As
an
FYI,
so
people
people
know
when
you
update
your
host
that'll
happen.
If
you
have
any
issues,
please
reach
out
on
Watson
Cloud
slack
and
we
tried
to
test
the
different
edge
cases
and
whatnot.
So
that
is
the
end
of
what
we
had
scheduled
to
talk
over
agenda
wise.
Does
anyone
else
have
any
other
things
they
wanted
to
talk
about
or
go
over
before
we
get
to
the
end
of
the
call.
G
F
Now
I
just
wanted
to
thank
Bailey
for
pointing
me
in
the
right
direction,
so
over
the
last
day
or
two
I've
actually
gotten
the
wasm
cloud
go
host
to
implement
actor
verification
via
extracting
the
jot
from
the
custom.
What's
it
called
custom
custom
sections
in
the
was
awesome,
module
and
validating
it,
so
the
wasro
folks
had
a
library
exactly
what
Bailey
told
me
to
go
and
yeah
so
just
wanted
to
share
that.
G
Awesome
thanks:
Jordan
Liam
did
you
want
to
go
since
you
raised
your
hand
or
should
Steven
still
beat
you
to
the
punch
on
the
digital
one?
So
Stephen
can
go
foreign.
C
C
One
was
about
I
think
during
Patrick's
demo.
There
was
like
this
line
about
like
wash
control,
and
then
it
was
like
using
HTTP
server
to
with
an
actor
ID
I.
Think
I
was
wondering
if
you
could
do
something
like
that
with
like
a
an
RPC
call
or
I've,
never
gotten
to
use
that
stuff
before
and
that
was
really
cool
to
see.
G
Yeah,
so
there's
watch
call
that's
what
it's
called
honestly
and
I.
Think
we've
all
admitted
this
multiple
times
in
public.
It's
a
little
gnarly
to
use
because
you
kind
of
have
to
figure
out
exactly
what
it's
supposed
to
look
like,
ideally
in
the
future
I'd
love
to
maybe
make
it
a
little
bit
easier
to
like
know
what
the
things
should
look
like
and
then
be
able
to,
because
we
know
what
the
interfaces
look
like
and
what
things
should
be.
Yeah.
C
But
that
that
was
kind
of
along,
like
my
second
question,
because
I
was
I'm,
trying
to
imagine
like
creating
an
API
Gateway
right
now
and
trying
to
figure
out
how
to
test
like
a
downstream
actor
from
that
Gateway
and
it
it's
really
cool
with
the
the
test
harness
how
you
could
do
that
for
providers.
So
I
was
wondering
if
it's
possible,
to
do
something
similar
to
with
the
test,
harness
for
like
an
actor
to
act
or
call
which
would
be
really
awesome
if
it's
possible
I
just
don't
know
yet.
G
Yeah,
so
that
is
possible
with
wash
call
the
testing
thing
personally,
I've
always
envisioned
like
if,
when
we
figure
out
how
we
want
to
do
like
a
testing
framework
for
actors
that
we
do
it,
so
it
works
in
any
language
so
that
it
tests
against
the
actual
compiled
webassembly
module
versus
like
the
tests
inside
of
the
language.
That
way,
we
don't
have
to
create
language,
specific
libraries
or
things
for
every
single
one,
but
yeah
there's
nothing
in
there's,
no,
nothing
in
the
test
framework
right
now.
G
That
does
that
and
it's
something
we've
been
turning
over
for
a
while
figuring
out
how
we
want
to
do
it,
because,
just
because
some
of
the
limitations
on
how
you
test
these
things
actually
in
in
various
languages
is
a
little
bit
weird.
But
yeah
you
can
do
a
wash
call
of
pretty
much
anything.
G
You
just
have
to
know
what
the
thing
should
look
like,
so
so,
basically,
just
the
interface
shape,
yeah
the
interface
shape
and
like
the
method
name,
that
it
should
be
calling.
Okay.
E
It's
a
little
bit
more
Awkward
than
that
and
definitely
highlights
the
need
for
us
to
make
this
easy,
but
part
of
it
is
because
part
of
the
difficulty
is
that
the
contents
of
the
message
received
by
the
Target
actor-
those
are
known
only
to
the
actor,
so
the
the
payloads
that
an
actor
expects
are
opaque
to
wasm
cloud
and
therefore
opaque
to
wash
so.
The
only
people
who
know
the
shape
are
people
that
have
used
the
generated
code
from
the
interface.
E
It's
it's
a
bit
janky
now,
but
the
developer
experience
is
that
particular
aspect
of
serialization
was
optimized
for
Speed
and
Performance
and
size
on
The
Wire
and
not
you
know,
being
able
to
interact
with
over
net.
So
there's
probably
a
lot
of
things
that
we
can
look
into
to
make
that
easier.
G
D
I've,
just
just
last
last
one
on
that
Brooks
has
I
had
some
awesome
demos
on
community
meetings
a
while
ago,
where
he
would
go
through
and
do
the
washcal
stuff
for
like
testing
and
QA
and
stuff
like
that
live
on
the
calls
I'll
see
if
I
can
find
a
link
to
that
and
drop
it
into
a
blossom.
Cloud
Slack.
C
Okay,
it's
just
about
the
interfaces
so
for
actor
to
actor
interface.
Would
you
need
a
an
interface
for
each
actor
to
act
or
call?
So
if
I
want
to
talk
to
a
different
type
of
actor,
you
need
an
interface
for
each
one
of
those
calls.
E
Yeah,
so
each
you
would
be
you
if
you're
using
Smithy,
you
would
go
in
and
Define
an
actor
receive.
True
interface,
and
you
know
set
that
up
the
way
you
usually
set
up
all
of
your
other
interfaces,
and
then
you
can
use
that
to
make
an
accurate
actor
call.
The
pet
clinic
example
uses
that.
Thank
you,
one
of
the
other
things.
That's
that
you
can
do
I
think
it
was
you
that
was
mentioning
like
the
API
Gateway
pattern.
E
So
one
thing
you
can
do
that's
kind
of
nice
is
if
you
have
different
actors,
but
those
actors
all
speak
the
same
interface.
E
You
can
use
things
like
call
aliases
to
Target
those
actors,
and
then
you
can
call
any
one
of
a
number
of
back-end
actors
with
the
same
interface,
even
if
they're
not
the
same
exact
actor.
So
you
could
do
things
like
route,
an
incoming
request
to
a
particular
actor
based
on
the
content
of
the
message.
Oh.
G
Lastly,
we
have
Liam,
which
is
I'm
glad
you
remembered
because
I
had
that
on
the
list
and
it
drifted
up
under
a
comment.
So
I
forgot.
D
Just
a
couple
of
notes:
cfp
for
cloud
native
wasn't
day
is
live
in
conjunction
with
kubecon
EU
it'll
be
taking
place
on
April
the
18th
in
Amsterdam.
So
please
pull
together
your
submissions
and
we'd
love
user
stories.
We
love
technology,
Edge
native
kubernetes,
all
the
things.
There's
lots
of
information.
There's
a
change
this
year
into
how
registration
works.
If
you
register
for
one
Cloud
native
day,
you
register
for
them
all.
D
D
I
would
also
add
that
you
can
catch
up
with
the
wasmcloud
crew.
At
a
couple
of
upcoming
conferences.
You
can
catch
us
at
shmukh
Khan
this
weekend.
If
you're
in
Washington
DC,
you
can
catch
us
you'll
be
able
to
catch
a
couple
of
us
at
wasmayo
in
Barcelona
Spain
in
March,
and
we
may
have
some
other
events
coming
up
here
as
well.
We'll
keep
those
up
on
slack.
G
And
I
will
be
at
kcd
Los,
Angeles
and
scale
in
March,
so
you
can
also
catch
us
there.
If
you
want
to
talk
things,
basically
we're
going
to
be
anywhere
Coast
to
Coast.
The
center
of
the
country
is
a
little
bit
harder
because
there's
not
many
conferences
there,
but
sorry
to
all
the
people
in
the
middle
of
the
US,
but
yeah
we'll
be
in
the
EU,
we'll
be
Coast
U.S,
West,
Coast,
us
and
I
always
look
for
excuses
to
come
to
Canada,
but
generally
it's
BC.
So
sorry,
Toronto.
D
I'll
get
these
on
the
wasm
cloud
calendar.
If
you
go
to
waslamcloud.com,
there
is
a
calendar
link.
There
I'll
make
sure
that
we
have
those
conferences
up
to
date
there,
because
there's
even
a
couple
more.
D
There
was
just
a
case
study
published
from
psyllium
in
partnership
with
cosmotic,
about
how
cosmonic
is
orchestrating
wasm
cloud
and
has
created
a
version
of
psyllium
that
works
with
a
nomad,
but
that
that
development
team
was
just
accepted
at
Hashi.
Conf,
we'll
be
doing
a
presentation,
I
want
to
say
in
February
I
mean
our
CTO
Kevin
will
be
at
Cloud
native
security
Con
in
Seattle
on
next
week.
So
we
actually
have
a
ton
of
events
coming
up
here.
G
Okay,
well,
I
think
that
is
it
for
today
we're
right
at
12.
Well,
my
time-
and
you
know
we're
all
in
different
times,
so
thanks
everyone
for
coming
and
we
hope
you
enjoyed
it.
This
will
be
available
almost
immediately
right
after
because
we're
streaming
it
out.
G
So
thanks
again
for
everyone
and
they're
they're
great
their
great
conversations
and
questions.
So
we
hope
you
have
a
great
week
and
we'll
see
you
all
next
week.