►
From YouTube: wasmCloud Community Meeting - 2 Aug 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
Hello
internet
here
are
our
beautiful
faces.
Welcome
to
the
WASP
Cloud
community
meeting
for
Wednesday
August,
the
2nd
we've
got
a
just
a
couple
of
agenda
items
today,
but
I
think
that
we'll
have
some
great
discussion
coming
from
both
the
the
demo
and
then
the
WASP
Cloud
road
map
discussion.
So
it
should
be
a
a
pretty
fun
call.
B
And
we
have
the
demo
and
kick
us
right
into
the
discussion,
because
I
want
to
monopolize
the
time.
Let
me
go
ahead
and
share.
B
So
right
here
we
have
first
off
a
working
example
of
the
provider
SDK
with
the
current
rest
host.
It's
really
a
lot
of
the
new
changes
are
going
to
be
out
there
like
we're
we're
changing
a
few
things
that
are
going
to
be
more
of
the
like
forward
compatible
with
the
new
rest
host
stuff.
B
That's
coming
out,
but
I
want
to
show
that
it's
working
and
following
the
RPC
protocols
that
we
expected
to
follow
this
provider
right
here
is
that
our
Nats
messaging
provider,
converted
over
to
the
widified
version
of
the
contract
and
the
actor,
is
kind
of
a
Franken
actor.
That
I
did
to
make
sure
this
would
work
and
they're
all
linked
together.
B
So
I
mean
this:
isn't
that
impressive,
a
demo,
but
the
fact
that
it
is
like
using
the
hand
rolled
wit
that
is
soon
to
be
generated,
it's
being
worked
on
by
Victor
and
so
I
can
come
in
here
and
say
that's
wreck
and
I
it'll
return
it
back
to
me.
So
that
means
that
this
thing
is
getting
a
I'm
publishing
a
request
in
Nats
it's
getting
received
by
the
provider
and
sent
to
the
actor,
and
then
the
actor
is
replying
over
naps,
using
the
the
publish
functionality
of
the
contract.
B
So,
like
I
said
that
doesn't
seem
that
impressive.
But
this
is
the
entirely
new
provider.
Sdk
and
I
forgot
to
bring
over
the
code,
so
I
can
show
a
little
bit
of
it.
There
we
go
so
I'm
going
to
enhance
this.
C
B
Okay
and
I'm
going
to
show
you
that
this
is
actually
inside
of
provide
of
the
new
of
the
wasm
cloud
like
actual
repo
right
now,
so
you
can
go
to
awesome,
Cloud,
Watson
club
and
see
the
provider
SDK,
and
this
has
all
the
stuff
we've.
Actually,
if
you
take
a
look
at
it,
have
slimmed
it
down
quite
a
bit:
oh
boy,
I'm,
just
going
to
do
this
on
GitHub
enhancing
is
too
much
for
for
people
today.
D
B
And
we'll
keep
the
chat
up
window
so
I
can
see
if
there's
any
questions
so
anyway.
This
is
now
inside
of
here
as
a
crate.
We're
still
not
still
not
fully
released
yet
because
we're
making
sure
it
gets
all
integrated
in
with
everything
else,
but
it's
based
off
the
wit
stuff.
B
It's
using
like
the
core
wasm
Cloud
wit
file
that
we've
put
together
and
then
it
also
is
hand
right
now
this
is
hand
rolled,
but
it
is
being
it's
working
on
the
generation
here
soon
and
so
it's
it
simplified
things
down
quite
a
bit
and
inside
the
code
itself
we
have,
you
can
take
a
look
at
it
and
see
all
of
it.
There's
some
stuff,
that's
similar,
but
we
kind
of
like
really
trimmed
it
down
to
make
it
as
as
simple
as
possible.
B
So
that's
the
provider
SDK
now
Meanwhile
we're
also
working
on
something
called
the
widification
providers
and
some
things
called
wazifil,
and
this
is
where
I
will
I
mean
I'll
before
I.
Go
there
any
questions
here
from
the
interwebs
or
the
current
audience
before
I
move
on
to
the
the
other
wit
stuff.
A
The
the
big
question
I
have
here
Taylor,
you
know,
I,
think
that
the
provider
SDK
and
using
wit,
is
going
to
change
the
process
of
like
developing
on
a
capability
provider
but
like
in
terms
of
like
binary
compatibility
like
this
or
not
this,
but
like
the
Nats
provider
that
you
had
that
you
were
showing
is
now
using
width.
Is
that
still
compatible
with
like
the
Old
Nas
messaging
provider
that
uses
the
Smithy
interface
like?
Could
I
just
drop
your
new
provider
in
as
a
replacement
or
did
anything
change
there.
B
Right
now,
the
big
change
is
that,
like
the
tracing
context,
is
on
the
invocation
now,
instead
of
nats,
it
helped
remove
an
ads
dependency
from
our
thing,
which
was
causing
all
sorts
of
headaches
and
the
other
thing
like
we're,
trying
to
get
everything
to
what
we've
been
calling
full
replacement
value.
So
it's
going
to
basically
be
a
slot
in
for
what
we
have,
but
then
we're
going
to
start
making.
Probably
some
changes
after
that,
so
things
will
things
that
currently
exist.
B
Right
now
will
run
in
the
new
rest
host,
but
we're
not
making
any
guarantees
that
the
new
stuff
is
going
to
run
on
the
old
host
right
now
and
that's
just
that's
kind
of
normal
as
these
projects
evolve.
So
right
now,
like
it's
the
exact
same
binary
protocol,
it's
expecting
there
could
be
little
changes
underneath
the
hood,
but
like
I
I'm,
not
making
any
guarantees
right
now
we're
just
trying
to
match
that
what
we
got,
and
so
that's
what's
going
on
with
with
this
work
that
I'm
showing.
B
So,
okay,
perfect,
with
that
I'm
going
to
roll
into
some
stuff
that
talks
a
little
bit
about,
like
wit,
standards
and
we're
going
to
get
a
little
technical
here,
but
I'm
going
to
try
to
keep
it
fun
and
light-hearted,
but
I
I
really
want
to
explain
like
why
we're
doing
what
we're
doing,
because
it
also
shows
how
freaking
awesome
components
are.
So
what
we're
currently
working
on
is
something
called
the
Wazi
film,
and
this
is
purely
for
custom
contracts.
B
So
for
the
built-in
contracts,
what
we've
been
calling
Wazi
Cloud
these
are
like
are
the
standard
supported,
Community
contracts?
We
have
right
now
key
value,
HTTP
server,
those
kind
of
things
those
are
going
to
be
built
in
to
the
to
the
new
rest
host
they're,
going
to
be
really
easy
to
just
drop
in
without
any
changes
like
with
a
currently
running
like
component,
doesn't
have
to
be
wasmo
Cloud
specific
at
all.
B
But
what
we
are
going
to
need
to
do
for
custom
contracts,
which
we've
always
supported
and
we'll
continue
to
support,
is
we
have
to
have
something
called
a
Wazi
film.
This
is
a
translation
layer
and
this
is
a
really
cool
trick
because
it
makes
it
so
that
wasm
cloud
specific
logic
is
never
ever
ever
ever
ever
in
your
business
logic
code.
So
to
show
this
I'm
going
to
do
a
diagram
here
and
was
there
a
question
I
heard
a
Mike
go
for
a
second
was.
B
You
Brooks,
okay,
I
was
just
making
sure.
Then
we
had
a
question.
So
this
looks
a
little
bit
beautiful
Mindy.
But
let
me
walk
through
the
the
thing
here.
C
B
The
idea
is,
and
I'm
working
on
the
concrete
examples
of
this
right.
Now
we
have
a
few
things
inside
the
Watson.
Cloud
wasn't
Cloud
repo
that
show
like
what
an
actor
will
look
like,
but
essentially
is
all
you'll
have
is
a
business
logic
and
you'll
have
your
wit
files,
so
someone
might
have
a
contract
when
we
look
at,
let
me
actually
bring
over
the
wit
messaging
contract.
B
I'm
going
to
de-enhance
a
couple
times,
so
this
is
the
like
with
Watson
Cloud
messaging
contract.
This
will
eventually
be
a
built-in,
but
I'm
just
going
to
show
it
as
an
example.
B
That's
going
to
that's
going
to
bind
with
this
component.
Is
this
called
composing?
Hence
the
name
component
that
I
require
an
import
called
consumer
I'm
going
to
import
that
from
something.
So
you
need
to
export
something
that
gives
me
consumer
and
I'm,
going
to
export
a
Handler
thing
that
you
can
call.
So
that
means
this
method
is
available
for
you
to
call
now.
This
is
written
once
again
entirely
outside
of
the
logic
of
Wasson
cloud.
Now
to
get
all
the
goodness
and
goodies
that
wasn't
Cloud
gives
you.
B
We
have
to
write
essentially
a
translation
layer
and
this
translation
layer
will
be
written
because
of
the
power
of
webassembly
once
in
any
language
that
you
can
do
it
at
first
it'll
be
rest
and
will
generate
it
automatically
for
you
and
then
it'll
build
and
be
ready
to
use,
but
then
any
language
that
uses
the
Custom
Contract
that
you've
defined
will
need
this
Wazi
fill
for
the
actor.
So
when
you
build
your
actor,
it's
going
to
take
your
thing
that
has
zero
was
in
Cloud,
specific
business
logic
and
join
in
this
Wazi
fill.
B
So
that's
what
this
diagram
over
here
is
showing
what's
going
to
happen.
So
up
here
is
the
the
wasm
cloud
host,
which
we're
not
we're
going
to
set
that
aside
for
a
second,
but
you
have
your
business
logic,
which
is
at
this
top
layer
right
here.
This
business
logic
is
what
you've
written
and
inside
of
it
you're
going
to
have
something
that
essentially
says
I
actually
wait.
I
do
have
my
test
actor
up.
This
is
this:
is
a
Franken
actor
so
oops,
not
that
one
this
one.
B
This
is
a
Franken
actor,
but
essentially
like
I.
Have
this
handle
thing
and
I
say
like
I
can
handle
a
message
that
comes
in
and
I
have
and
in
my
or
and
in
here
I'm
calling
messaging
consumer,
so
I'm
consuming
like
I'm,
taking
that
consumer
thing
that
we
just
saw
inside
the
messaging
contract
and
I'm,
calling
the
publish
message,
the
publish
method
and
the
publish
method
is
going
to
take
the
broker
the
the
broker
message
type
and
pass
it
in
so
you'll.
B
See
like
right
here:
I
have
the
Watson
bizarre
PC
because,
like
I
said
it
was
a
Franken
actor,
but
in
the
real
world
this
doesn't
even
exist
and
all
that
happens
is
you
come
in
and
you
say
messaging
consumer
and
it
sends
it
off.
There's
no
knowledge
at
all
of
what
wasm
cloud
looks
like
in
this,
so
the
Wazi
fill
stuff.
When,
in
this
example
like
let's
say,
we
had
a
Custom
Contract
called
Foo
and
we
had
a
Custom
Contract
called
bar.
B
Now,
if
who
were
like
the
messaging
contract
in
this
case,
I
would
say:
I
need
to
have
something
right.
If
we
go
back
to
that
that
file
the
the
wit
file
right
here,
the
actor
is
expecting
to
import
a
consumer
from
somewhere,
so
I
have
to
tell
it
to
import.
B
I
mean
I,
have
to
export
the
consumer
free
to
call,
in
this
case,
I'm
exporting
a
foo,
so
the
Wazi
fill
comes
in
and
does
the
translation
it'll
receive
those
parameters,
serialize
them
to
wasimbus
RPC
for
you
and
then
send
that
thing
out
over
the
host
call
back
to
the
host?
So
it's
going
to
so
all
the
translation,
all
the
goop
that
makes
wasn't
Cloud
work
is
entirely
encapsulated
inside
of
a
webassembly
module.
B
That's
then
just
composed
with
what's
going
on,
and
so
the
host
call
thing
right
here
is
what's
provided
by
the
host
and
it
goes
out
that
direction,
so
we
serialize
it.
It
gets
called
now
where
it
becomes
complicated,
and
this
is
where
I
know
this
is
technical,
but
it's
going
to
show
how
cool
this
this
whole
thing
is.
Is
we
now
have
multiple
ways
that
oh
a
module
could
be
called
so
imagine
if
something
could
respond
to
a
Nats
message
or
any
message
from
a
broker
or
to
an
HTTP
request.
B
Both
of
those
are
different
calls
that
can
happen
now.
What
we
need
to
do
to
handle.
That
is
that
we
in
our
Wazi
fills
we
will
that
get
generated.
You
don't
have
to
write
any
of
it,
though
you
can
custom
write
it.
If
you
want
to
do
your
own
serialization
or
you
have
like
special
security
requirements
or
encryption,
you
want
to
add
or
something
along
those
lines.
It's
all
doable,
but
it
has
to
export
like
guest
call,
Foo
and
guess,
and
then
the
multiplexer
automatically
translate
it.
B
It
essentially
takes
a
single
guest
call
in
so
the
wasm
cloud
host
says:
hey
I
got
a
message
that
says
like
I'll,
even
add
text
here,
so
you
can
see
it
looks
like
I
I
got
something
that
was
message
dot
handle,
or
in
this
case
we
could
say
like
food.handle
and
so
that
gets
sent
in
the
guest
call.
The
multiplexer
says:
oh
well,
which
one
does
this
go
to?
Oh
well,
I
see
this
is
Foo,
so
I'm
going
to
set
it
to
guest
call
Foo.
B
B
All
this
is
we're
handling,
attaching
multiple
contracts
doing
all
this
stuff
and
your
business
logic
never
ever
changed.
We
just
put
it
all
together
and
and
now
it's
able
to
work
in
this
really
cool
stuff
that
the
wasm
cloud
host
and
the
ecosystem
gives
you.
But
you
didn't
have
to
do
anything
else
through
business
logic,
we
literally
just
composed
two
additional
components
on
top
of
it
automatically
for
you,
and
then
it
can
run
with
ease
inside
of
of
wasm
cloud.
B
So,
like
I
said,
it's
a
little
bit
low
level,
but
this
is
the
kind
of
stuff
that
we're
we're
really
excited
about
inside
of
the
component
model
and
where
the
standards
are
going
and
why
we're
putting
so
much
effort
into
making
all
this
wit
stuff
work,
and
the
good
thing
is.
This
is
only
if
you're
really
curious
about
it
for
most
people
who
are
building
in
this,
they
never
even
have
to
know
that
this
stuff
is
going
on.
B
Underneath
the
hood
you
just
have
to
know,
I
have
a
a
piece
of
business
logic
and
it's
implementing
a
contract
for,
and
it's
implementing
this
contract,
from
wit.
That's
the
only
part
you
would
need
to
ever
know
about
for
most
people,
but
for
the
Curious,
which
are
most
the
people
who
are
really
involved
in
the
webassembly
community
right
now.
This
is
what's
going
to
be
going
on
underneath
the
hood
and
what
we're
trying
to
do
and
improve
on
with
all
this
work
we're
handling.
B
So
that
was
a
lot
and,
of
course,
it
leads
into
the
next
discussion,
not
a
plant
Brooks
again.
A
Yeah
I'm
a
little
I'm
a
little
quick
on
the
hand
draw,
but
please
anybody
feel
free
to
to
jump
into
I,
don't
want
to
monopolize
the
time.
I.
Just
have
you
know,
questions
okay,
so
Taylor
I
can
kind
of
see
at
the
top
there
and
I
think
this
is
getting
it.
My
first
question
that
there's
a
difference
between
Wazi
calls
like
Wazi
API
interactions,
Wazi
Cloud
interface
interactions
and
then
custom
contracts,
and
so
the
way
I
think
I
understand
it
is
that
Wazi
and
Wazi
Cloud
things
are
natively
supported
with
wasmcloud.
A
They
don't
require
this
multiplexer
idea
like
they're
imported
or
they're
exported
by
the
host,
and
we
Implement
them
normally
all
of
this
stuff
for
RPC
handling
and
the
the
multiplexer
and
stuff
that's
all
for.
If
you
wanted
to
come
and
create
a
custom
contract
for
something
that's
not
a
defined
interface
is.
B
A
Okay,
there's
a
question
in
the
chat
but
I'll
I'll
jockey
to
be
after
that.
B
B
There's
a
great
question,
so
the
big
difference?
Well,
there's
a
couple
big
differences.
One
of
them
I
want
to
point
out
that
these
these
middle
components,
so
your
business
logic,
could
be
written
in
Python.
Your
Wazi
fill
could
be
written
in
Rust
and
your
multiplexer
could
be
written
in
go
now,
we're
not
going
to
do
that
to
start
off
with,
but
you
can
do
that.
B
There's!
No,
the
language
Bindings,
that
a
consumer
of
wasm
cloud
needs
to
needs
to
have
are
just
the
findings
that
are
that's
part
of
Whitby
and
gen
thing.
Let
me
pull
over
that
tab
over
into
here
so
with
binding
is
the
main
tool
chain
here
and
the
there's
already
generators
for.
If
you
come
down
here,
rust,
CNC,
plus
plus
Java,
for
specific
types
of
java,
the
TVM
and
Tiny
go
and
then
all
that
needs
to
happen
for
this
to
to
be
able
to
be
used
by
other
languages
is
to
implement
it.
B
And
this
is
why
Community
standards
are
so
important.
We
don't
write
a
was
on
cloud
specific,
binding
for
actors
anymore
and
eventually
for
providers.
As
soon
as
some
of
the
last
Wazi
stuffer
providers
like
wazzy
stuff
lands
like
threads
and
those
kind
of
things,
then
we
can
start
doing
providers
in
webassembly
as
well,
which
makes
this
even
easier,
but
there's
nothing
specific
for
actors
now.
B
And
so,
if
you
look
at
any
of
the
actors
right
now
inside
of
our
example,
repo,
let's
just
take
I
mean
I,
I
wrote,
Blobby,
so
blobby's
near
and
dear
to
my
heart.
If
you
look
at
the
code
inside
of
like
Blobby
or
any
of
the
actors,
you're
gonna
see
a
whole
bunch
of
stuff
up
here.
That's
like
wasn't
Cloud
interface,
blob
store,
wasimbus,
RPC,
actor,
Prelude,
wasm,
Cloud
interface,
HTTP
server
and
there's
all
this
stuff.
That
is
in
the
in
the
actor.
That's
very
specific
to
us
and.
B
B
So
that's.
What
is
the
like?
The
big
difference
here
is
we're
completely
decoupling
the
wasm
cloud,
specific
Logic,
the
Watson
Cloud
specific
logic
is
all
encapsulated
in
the
Wazi
fill
stuff
for
custom
contracts
or
inside
the
host
for
like
the
built-in
Wazi
Cloud
things.
So
hopefully
that
answers
your
question.
Cj
I'm,
not
sure.
If
there's
more,
you
wanted
to
to
get
a
some
Vision
on
there.
C
Hey,
yes,
that
definitely
answers
my
question.
It's
very
cool
and
I
can
see
how
this
would
be
one
like
very
helpful
for
migrating
existing
applications
over
but-
and
maybe
you've
said
this,
but
with
the
new
context,
could
you
reiterate
the
other
big
benefits
of
this
sort
of
decoupling,
of
the
business
logic
from
the
wasm
cloud,
specific
Bindings
that
you
need
to
import.
B
Yeah,
this
means
you're
technically
entirely
portable,
let's
say
you're
using
like
like
we,
we
coordinate
with
all
the
or
we're
always
collaborating
all
the
time
with
the
people
who
are
behind
spider,
lightning,
Deus
Labs
over
at
Microsoft
and
they're
helping
work
on
these
Wazi
Cloud
things.
You
could
technically
take
a
module
that
runs
on
spider,
lightning
and
literally
just
shift
it
over
to
wasm
cloud
or
to
anyone
else
who
implements
one
of
these
things.
B
So
it's
a
complete
decoupling
from
like
the
underlying
platform
for
what
you
need:
you're
able
to
Luke
Luke
Wagner
who's,
a
big
name
in
the
web
assembly.
Space
he's
described
this
as
virtual
platform
layering,
and
that's
what
we
mean
by
this.
Like
you,
you
could
do
this
same
kind
of
thing
for
any
platform
you
wanted
to
to
make
it
work
with
that
platform.
For
us
we
have
something
called
a
host
call
and
a
guest
call.
B
That's
was
implied
specific,
but
it
is
now
entirely
decoupled
amount
to
the
side
from
the
actual
logic
going
on
over
here.
So
your
your
big
benefit
is
you
get
less
problems
with
like
security
and
dependencies
there,
where
you
have
like
I'm,
not
I'm,
not
compiling
in
like
a
Nats
client
and
a
redis
client
and
a
HTTP
client
or
an
HTTP
server
Library
into
my
code,
it's
entirely
decoupled.
B
It's
provided
by
depending
on
where
you're
running,
because
a
web
assembly
can
be
provided
by
another
web
assembly
module
or
it
could
be
provided
by
something
on
the
other
end
like
we
do
in
in
wasm
Cloud,
where
your
HTTP
server
could
technically
be
running
in
an
entirely
different
region
of
of
the
world
and
that
all
those
benefits
so
like
we
take
those
when
we
make
it
distributed
in
the
wasm
cloud
sense.
So
all
of
that
still
exists.
B
A
Brooks,
hey,
it's
me
not
a
plant,
so
one
other
thing
that
I
think
you
said
once
or
twice
Taylor
when
you're
talking
about
this
is
like
the
wasm
cloud,
specific
stuff
and
I.
Think
there's
like
there's
like
two
main
things:
there
there's
like
the
old
interfaces
or
the
the
interfaces
that
we're
using
currently
that
we're
changing
use
with
and
then
there's
what
the
host
will
do
for
you
for
Wazi
cloud
and
and
Wazi
calls,
but
for
custom
components
or
custom
interfaces.
A
Every
single
invocation
in
the
wasm
cloud
system,
like
actor
to
provider
actor
to
actor.
All
those
things
are
always
signed,
like
with
the
hash,
to
make
sure
that
it's
not
tampered
with
in
transit
and
it's
verified
for
where
or
it's
signed
with
the
cluster
key
or
cluster
seed
that
you
use
to
run
the
host.
So
you
can
make
sure
that
it
came
like
a
specific
origin
that
you
trust.
Are
there
other
things
that
like?
What
is
there?
A
Something
else
that
you
can
think
of
there
I
want
to
make
sure
that
we,
like
I
I,
guess
outline
what
the
multiplexer
like
what
this
component
is
going
to
be
doing
for
you,
because
it's
more
than
just
making
it
compatible
with
wasm
cloud
like
there
are
actual.
B
B
The
wazifil
world
looks
like
this
and
it's
saying,
like
hey
I'm,
going
to
export
the
consumer,
so
you
know
the
the
actor
can
import
it
I'm,
going
to
import
its
Handler
method,
I'm
going
to
import
some
things
from
the
host,
so
I
can
do
host
calls
and
I'm
going
to
export
this
guest
call
thing
so
that
I
can
be
called
so
I
can
handle
messages
and
so
inside
of
the
library
code.
B
What
I
have
is
an
implementation
for
guest
call
messaging,
which
is
what
gets
invoked
and
that'll
be
exported,
and
then
I
will
have
here.
I
have
the
consumer
right
and
I'm
going
to
fill
in
all
the
stuff.
That'll
do
the
serialization
right
here,
so
everything
you
named
is
pretty
much
what's
going
on.
This
is
all
the
serialization
and
magic
and,
like
I,
said
we're
going
to
generate
this,
but
we
know
just
from
having
talked
to
many
different
people
out
in
the
community.
B
Some
people
might
have
very
specific,
like
encoding
protocols
and
stuff
they
use
for
their
their
data,
or
they
encryption
is
another
one.
That
I
mentioned
it's
a
common
requirement.
You
can
come
in
here
and
do
all
that
encryption
and
all
that
type
of
decoding
and
stuff
all
inside
of
where
these
to-do's
are
at.
You
are
not
actually
even
like
you
do
not
have
to
use
the
stuff
we
generate
for
you.
We
just
try
to
make
it
as
drop
dead.
Simple
now,
I
haven't
written
anything
for
the.
B
What's
that
called
for
the
the
multiplexer
yet,
but
I
can
show
you
like
what
the
world
will
semi
look
like
grab
it
so
for
and
just
in
a
note
page,
so
I'm
going
to
put
it
over
here.
So
the
multiplexer
will
look
something
like
this.
It's
going
to
import
this
same
contract
that
we
had
right
here,
it's
going
to
import
that
guest
call
messaging
and
it's
going
to
export
wasm,
Cloud
bus
guess
so.
B
Like
if
you
start
following
this
chain,
all
the
way
up
like
if
I
copy
the
messaging
over
here
at
the
world
files,
so
this
is
actually
like
the
whole
chain
of
of
what's
going
on
and
so
inside.
The
actor
like
I
have
I'm
importing
a
consumer
and
I'm
exporting
a
Handler.
So
here
you'll
notice,
I'm
exporting
a
consumer.
So
this
line
is
tied
directly
to
this
line,
and
I
am
importing
a
Handler
I'm
importing
the
Handler
from
here
and
then
I'm
importing
guess
this
from
somewhere,
which
I
don't
have
yet
and
then
I
am
exporting.
B
At
the
multiplexer-
and
it
says
oh-
hey,
I'm
importing,
so
these
two
lines
right
here
are
tied
together
and
then
I
am
exporting
a
guest
call.
So
this
is
going
to
be
called
by
somebody
else.
I
don't
know
who
and
I'm
going
to
import
something
that's
coming
from
somewhere,
and
so
this
is
an
oversimplification,
but
essentially
what
the
world
looks
like
for
this
thing
when
it's
all
composed
together
is
something
like
this.
B
It's
going
to
have
an
import
was
on
cloud
bus
host,
something
like
this.
Like
I
said,
this
is
not
100
accurate
and
just
doing
it
for
explanation
of
like
what
this
looks
like
and
I'm
going
to
have
something
that
looks
like
this.
B
So
this
is
what
the
final
world
looks
like,
because
all
the
things,
the
the
other
things,
are
all
satisfied
or
taken
care
of.
So
it
is
looking
for
something
like
this
now.
If
we
compare
this
to
my
little
diagram
over
here,
hey
host
call
guest
call.
Those
are
the
two
things
that
are
provided
by
the
host.
B
B
This
whole
thing,
so
it's
just
it's
exports
that
bubble
up
like
you
like
what
keeps
bubbling
up
and
what's
taken
care
of
internally
to
the
component
is,
is
what's
going
on,
underneath
the
hood
So
eventually
like
I,
said
what
we
get
to
is
the
something
that
looks
like
this,
which
is
what
we
need
like
this
is
what
the
like
our
was
on.
Cloud
host
is
expecting
this:
it's
expecting
something
that
can
import
The,
Host,
calling
functionality,
and
it's
expecting
something
that
it
can
call.
It
has
to
be
able
to
start
it
and
invoke
it.
B
So
it's
expecting
something
to
call,
and
that's
that
is
the
world.
According
to
the
laws
and
Cloud
host,
it
doesn't
care
about
all
the
other
stuff.
It
cares
about
this,
the
the
those
things
are
present,
and
so
what
we're
essentially
doing
is
if,
if
you
have
something
like
a
Wazi
feels
essentially
saying
like
hey
like
they,
they
host
is
not
there's
no
Handler
that
the
the
host
is
giving
me.
B
There's
not
this
Handler
thing
and
there's
not
this
consumer
thing
that
that's
there
too,
like
I
I,
don't
know
about
these
things,
so
we
give
something
else
that
does
know
about
it
until
we've
reduced
it
down
to
the
stuff
that
the
host
can
give
us-
and
this
goes
for
anything
in
the
webassembly
space
Not
Just,
not
just
wasn't
cloud
like
this
same
logic
follows
for
anything
else
that
is
going
to
be
using
components
is
there's
something
that
a
a
world
that
a
host
can
provide
and
your
world
has
to
conform
to
that
world
to
be
able
to
run
in
it,
and
so
that's
that's
how
all
this
is
kind
of
put
together.
C
A
I
think
yeah
yeah,
no
I
I
think
this
definitely
helps
and
I
know
that
a
lot
of
these
details
are
going
to
be
not
at
the
level
that
a
waslam
cloud
developer
will
normally
have
to
interact
with
you
know.
This
is
all
kind
of
design
in
the
background,
but
I'm
looking
forward
to
some
of
the
documentation
around
around
this
stuff,
because
I
think
it's
going
to
feel
really
nice
as
soon
as
we
start
building
with
it,
but
having
these
diagrams
and
things
will
still
be
really
nice
to
explain
now.
B
Okay
and
then
there's
one
question
I
think
has
to
do
with
what
we're
talking
about.
It
came
from
YouTube
and
it
was
a
question
of
what,
if
there
will
be
multiple
implementations
at
the
same
time
and
I'm
assuming
by
that,
you
mean,
like
multiple
implementations
of
a
given
contract.
There's
there's
two
I'll
answer:
both
I'll
start
with
that
one,
so
you'll
notice
that
we
actually
have,
in
that
wit
file
in
these
web
files.
B
You'll
see
that
we
have
these
versions
here,
these
versionings
actually
matter,
and
they
help
pin
it
to
a
specific
thing.
So,
if
you
have
two
different
versions,
you
could
technically
have
two
different
contracts
right.
We
won't
do
that
with
probably
the
built-in
contracts
as
much,
but
for
your
own
custom
contracts.
You
could
technically
be
running
two
different
ones:
I'm,
not
sure
how
it's
going
to
behave
at
the
higher
link
depth
level
for
wasmcloud,
but
like
from
a
wit
level,
there's
versioning
for
it
now.
B
If
we
talk
about
the
other
way
that
this
could
be
like
something
along
the
lines
of
like
what
like
multiple
things
that
are
going
on,
that's
and
I,
don't
think
that's
what
you're
asking,
but
just
to
reiterate,
like
that's
the
idea
of
the
multiplexer
like
we
technically
have
two
ways
to
call
this
inner
this
contract,
or
this
this
composed
actor
and
the
multiplexer
is
what
takes
care
of
that.
B
It's
the
thing
that
says,
I'm
turning
a
guest
call
into
sending
it
to
guest
bar
guests
would
call
Foo
or
guest
call
Bar,
so
those
are
kind
of
the
two
things
there.
Hopefully,
that
answers
the
question:
if
not
I
can
try
to
clarify
more
later.
B
Okay,
that
was
supposed
to
kick
start
the
current
discussion
around
where
things
are
at
with
weight
and
whatnot,
but
bricks
I'll
hand
it
back
to
you.
A
All
righty
so
I
think
that
that
makes
sense,
I
think
Taylor,
already
kind
of
did
this
call
to
action,
but
does
anybody
else
have
any
other
questions.
B
A
Want
me
to
yeah
yeah
I
typed
a
couple
of
things
in
the
YouTube,
so
we
can
definitely
keep
those
going
I
want
to
make
sure
that
we
thank
you
I
want
to
make
sure
that
we
have
enough
time
to
go
over
the
roadmap
Advanced.
If
you
had
a
question,
go
ahead.
E
Those
may
be
conflicting
statements,
okay,
so
my
my
concern
is
simply
is
about
this.
This
all
looks
great.
This
is
exactly
what
I
was
hoping
to
see
that
it's
happening
so
quickly
is
really
really
encouraging.
Excellent,
excellent
excellent,
but
the
part
that
I'm
worried
about
is
exception,
handling
and
so
and
and
so
so
here's
Here's
the
the
the
the
caveat
right
like
what
history
has
taught
us,
because
there's
been
plenty
of
RPC
where
corba
and
all
kinds
of
idls
in
the
past.
E
What
history
has
taught
us
is
that
that
the
the
idea
that
you
can
make
local
process
calls
transparent
remotely
that
doesn't
work,
so
don't
even
try
it
just
forget
about
it
right,
so
our
PCS
are
distinct
from
inter-process
communication
right,
so
so
RPC
introduces
a
class
of
errors
that
you
need
to
deal
with
and
so
the
to
to
make
everything
transparent.
E
So
if
I
just
write
my
WIC
contracts
and
it's
I've
got
a
function
in
the
the
return
result
is
a
Boolean
when
I
actually
go
to
use
it,
the
result
may
be
Boolean
or
it
may
be
guess
what
the
something
went
wrong
right
with
the
network.
E
You
know
with
the
lattice,
as
the
case
may
be,
or
the
host
or
whatever
so
so
we
need
to
be
able
to
handle
that,
and-
and
so
my
my
general
thought
on
this-
is
that
what
we
need
to
do
when
we
put
this
stuff
together
is
to
combine.
So
first
of
all,
we
use
the
the
result
which
which
has
both
the
the
happy
path
and
and
the
error
path
right
so
you've.
E
So
when
I
write
my
my
function
well,
if
I,
if
I
did,
if
I
did
write
my
function
as
just
returning
a
Boolean,
then
the
actual
return
from
the
RPC
is
is
a
result
which
introduces
the
RPC
errors
right
now
we
don't
want
to
Stack
that
I,
don't
think
right,
so
so
I
think
what
we
probably
want
is
to
be
combining
those
right
so
that
the
the
contract
is
going
to
include
all
the
RPC
errors,
plus
the
errors
that
that
are
introduced
anyway.
That's
my
my
worry
about.
E
The
whole
thing
is
just
that:
we're
handling
that
and
I
always
like
to
when,
when
we're
doing
something,
do
the
hard
part
first,
because
the
the
easier
parts
will
will
may
change
if
you
need
to
do
something
with
the
hard
part
right.
So
that's
my
concern.
A
Okay,
yeah
Vince,
I
I
think
that
that
makes
that
that
makes
a
lot
of
sense,
and
that
is
something
that
we've
already
kind
of
dabbled
in
with
our
current
model
of
wazenbus
RPC
is
when
you're
returning
an
error
for
a
thing.
Is
there
error
in
the
business
logic
like
hey?
A
This
was
an
invalid
request
and
so
I'm
returning
like
an
HTTP
error,
or
were
you
not
connected
to
the
network
at
all
in
the
first
place,
and
so
it's
like
the
the
network,
RPC
level,
error,
I,
guess
that's
kind
of
just
like
a
high
level
reset
and
to
make
sure
that
I
understand
well.
A
Yes,
yeah
did
I
think
we
definitely
have
to
handle
that
and
there's
a
couple
of
different
pass
that
we
could
take
to
depending
on
how
much
we
want
to
what's
the
right
way
to
say
this,
depending
on
how
much
we
want
to
force
an
ideology
on
on
people.
I've
gotta
I've
got
a
thought
there,
but
I'll
let
Kevin
go
because
he
may
just
sum
up
what
I'm
thinking.
F
Yeah,
it's
hard
to
figure
out
where
to
start
like
Vance.
So
this
is
a
it's
a
huge
topic
that
has
been
plaguing
us
since
the
dawn
of
time,
and
it
will
probably
continue
to
do
so
forever.
F
A
couple
of
things
that
I
think
are
really
important
to
keep
in
mind
is
that
when
you
model
something,
in
wit,
that
interface
there's
no
such
thing
as
a
local
version
of
making
a
wit
call,
so
whether
you
are
just
hopping
across
a
single
component
boundary
or
whether
you're
hopping
across
a
component
boundary
then
going
through
a
fill
then
going
over
RBC,
the
consumer
of
that
with
contracts
doesn't
really
know
or
care.
F
You
know
how
many
intervening
hops,
but
it
does
always
assume
that
it
is
a
an
attempted,
remote
call,
so
that
can
fail.
It
can
time
out.
It
can
have
all
sorts
of
errors,
and
so
I
think
in
advance
did
a
good
job
of
describing
this.
Is
that
there's
this
a
struggle
between
when
you
define
a
contract
with
a
result
type
in
it
or
when
you
define
a
contract
with
a
Boolean
or
whatever
as
a
reply?
F
What's
the
difference
between
the
remote
end
successfully
returning
an
error,
if
that
makes
sense
versus
an
inability
to
communicate
with
the
remote
end,
and
that
returns
an
error
and
in
a
number
of
distributed
systems,
circles
the
the
prevailing
opinion
there
is
that
it
doesn't
matter
it
doesn't
matter
to
your
code
and
by
your
code
I'm,
referring
to
like
the
consumer
of
a
wit
contract.
F
It
doesn't
matter
to
the
consumer
or
the
wit
contract,
whether
the
thing
failed.
Sorry
I
should
say
it
shouldn't
matter.
It
shouldn't
matter
to
your
code,
whether
the
the
reason
why
you
got
a
failure
was
because
of
a
network
communication
failure
or
something
else.
Now
that
error
can
be
the
reason
for
that
failure
can
be
encapsulated
in
a
result
type
but
yeah
they're
they're
in
all
the
systems
I've
used
and
that
you
know
that
includes
things
as
old
as
korba
and
things
like
akka
and
you
know
obviously
Verizon
cloud
right.
F
The
there
is
no
easy
answer
for
this
and
yeah,
like
the
like
van
said
in
the
chat
right,
the
whether
or
not
you
retry
depends
on
whether
or
not
you've
encoded
into
your
contract
re-attempting
for
failure.
F
So
yeah
it's
a
it's
a
really,
really
long
subject
that
I'm
sure
people
have
actually
written
full
books
on
or
they
could
write
full
books
on
this
one
topic,
but
typically
I
just
prefer
to
model
all
of
my
responses
as
results,
and
you
know,
treat
a
failure
as
a
failure
and
you
know
deal
with
it
that
way.
F
I've
I
don't
want
to
take
up
too
much
of
the
time,
but
I've
built
a
bunch
of
systems
in
the
past.
That
did
the
you
know.
If
this
fails
try
again
and
then,
if
it
fails,
try
again
and
again
and
again
and.
F
What
I've
noticed
is
that
determining
whether
or
not
you
should
try
again
based
on
whether
you
think
it
was
a
network
failure
versus
whether
the
component
on
the
remote
end
actually
returned
an
error
having
that
distinction
actually
causes
more
problems
than
it's
worth,
at
least
in
the
systems
that
I've
built
in
the
past
I
know.
Other
people
have
different
opinions
on
that,
though,.
A
Yeah
I
think
I
think
this
topic
is
definitely
one.
We
could
talk
about
for
a
whole,
Community
call
and
and
Beyond
only
other
thing
I
was
gonna
say
is
I
I.
A
Think
that
the
way
and
the
the
opinion
that
I
had
the
way
that
we
do
it
now
isn't
perfect,
but
it's
a
decent
way
to
model
the
difference
where,
when
you're
interacting
with
RPC
things
in
wasm
Cloud
returning
an
error
is
essentially
modeled
the
same
way
that
graphql
does
its
requests
where,
even
if
you
have,
if
you
make
a
graphql
request
and
something
goes
wrong
or
you
have,
you
know
it's
an
invalid
request
or
something
essentially,
what
the
client
is
expecting
you
to
do
is
return
an
HTTP
200,
but
then
with
information
in
there
saying
hey
by
the
way.
A
This
like
wasn't,
wasn't
correct.
So
you
you
don't
return
like
400s
and
500s
for
those
errors,
it's
kind
of
like
how
we
do
it
with
wasm
bus
RPC,
where
the
RPC
error,
error
type
is
stuff.
Like
you
know,
network
communication
errors
so
that
those
kind
of
bubble
up
all
the
way
through
the
call
like
the
the
the
the
the
web
assembly
call.
A
But
then
the
the
recommendation
is
basically
to
use
an
okay
result,
but
with
information
on,
if
there
was
an
error-
and
that's
something
you
know-
that's
asking
people
to
specifically
model
their
things
in
a
certain
way,
so
I
mean
I.
Think
the
question
is
either
we
can
do
something
like
that
or
or
kind
of
flatten.
The
result.
A
I
think
the
key
thing
is
just
going
to
be
how
it
feels
to
write
idiomatic
code
and,
if
I,
have
two
microservices,
that
talk
to
each
other
and
like
I,
want
to
return
a
specific
error
from
one
and
then
handle
it
in
the
other
by
retrying
or
trying
to
call
out
to
a
different
capability.
That
just
has
to
feel
at
least
from
my
opinion.
If
that
feels
good,
then
that's
most
of
the
most
of
the
concern,
I,
think
and
I.
Think
I'm
gonna
Kevin
has
a
lot
more
experience.
D
Vance
I
really
appreciate
how
you've
socialized
this
topic
and
brought
this
up
on
slack
in
here
and
I.
D
Understand
that
there's
a
lot
of
prior
art
in
this
area
on
different
design
patterns
on
how
we
might
might
handle
this.
My
ask
is
and
I
think
we've
done
this.
A
few
times
is:
what's
the
best
way
for
us
to
socialize
a
few
different
approaches
to
this
and
have
a
discussion
around
them
and
I.
D
Don't
know
if
Kevin
you've
done
some
wonderful,
you
know
rfcs
or
you
know
things
like
that
before,
where
we've
kind
of
summarized
some
different
design
patterns
on
on
how
this
might
manifest
itself,
because
I
also
know
you
know,
events
you've
got,
you
know
significant
experience
in
you
know
all
these.
Some
of
these
high
performance
systems
that
are
being
operated
at
scale.
So
your
thought
is
really
welcome
here,
and
this
would
be
a
great
time
to
get
it
in.
My
final
ask
is
Kevin,
as
you
think,
through
this
is.
D
How
would
or
could
we
propose
this
as
a
webassembly
standard
you
know,
is
there?
Would
it
be
pluggable
right?
You
know
like
so
long
as
it
meets
some
contract.
Then
you
could
have
multiple
implementations
behind
it.
You
know
that
would
be
I.
Think
the
sort
of
dream
here
for
what
something
may
look
like,
but
I
recognize
that
different
exception
approaches
may
have
different
may
have
different
interfaces
that
you
may
desire.
D
A
Yeah,
thank
you,
Liam
events
that
was
super
worth
The
Detour,
but
I
will
call
it
now.
I
want
to
make
sure
we
have
enough
time
to
talk
over
the
roadmap,
and
we
can
keep
this
discussion
going
in
slack,
I,
think
and
then
maybe
even
bring
it
up
is
the
main
thing
for
next
week's
Community
call
I,
think
it'll
be
worth
definitely
worth
the
time,
so
the
second
thing
and
I
knew
we
would
have
good
discussion
so
glad
that
worked
out.
A
A
As
you
all
know,
in
any
open
source
project
has
constant
kind
of
iteration
in
churn,
as
people
are
fixing
bugs
and
adding
smaller
features,
and
you
know
maintaining
the
project,
but
looking
forward,
we've
shared
a
couple
of
diagrams
before,
but
don't
really
have
like
an
established
roadmap,
and
so
I
put
a
lot
of
effort
into
that.
A
A
But
really
the
purpose
of
this
document
is
to
outline
some
of
our
bigger
goals
for
the
wasmcloud
project
and
then
I've
very
Loosely
pinned
our
roadmap
to
Q3
Q4.
You
know
quarter
three
and
quarter
four
of
2023,
because
that's
the
time
period
that
we're
taking
on
some
of
this
effort,
so
I've
outlined
a
couple
of
goals
here
and
I.
Think
there
may
be
more
I
think
we
may
be
able
to
hone
these
in.
A
But
what
we're
really
specifically
focusing
on
right
now
is
leveraging
as
many
webassembly
standards
as
possible
in
terms
of
Wazi
wasm
components,
implementing
the
Wazi,
Cloud
interfaces,
Etc
and
I.
Think
these
other
ones
are
always
in
the
back
of
our
mind,
but
not
as
big
of
a
focus
of
like
the
bigger
development
efforts
now
now
inspired.
A
Our
current
roadmap
is
really
inspired
by
some
of
the
some
of
the
content
in
the
by
code:
Alliance
Blog,
the
webassembly
and
updated
roadmap
for
developers,
so
I
highly
recommend
you
checking
that
one
out
in
order
to
get
an
idea
of
where
the
standards
are
looking
right
now,
but
at
the
top
level,
I
tried
to
boil
it
down
to
three
big
things:
three
big
things
that
we're
really
working
on
right
now
and
for
the
past
couple
weeks.
A
This
first
one
has
been
the
focus
for
leveraging
webassembly
interface
types
or
width
for
our
interfaces.
This
is
really
big
in
terms
of
us
contributing
to
the
wide
variety
of
projects.
You
know
we
use
rust
and
tine
ego
for
our
SDK
languages
now
or
rust,
and
go
for
the
providers
and
using
webassembly
interface
types
and
webassembly
components.
A
Will
let
us
extend
that
language
support
to
see
JavaScript
python
more
and
more
languages,
essentially
as
they
come
available,
because
we're
not
hand
rolling
an
SDK
anymore,
which
is
really
exciting,
planning
to
implement
and
use
the
Wazi
Cloud
instead
of
proprietary,
wasn't
Cloud
interfaces
when
I
say
proprietary.
It's
not
like
any
of
this
hasn't
been
open
source
for
a
long
time.
Just
means
that
it's
not
you
know,
building
your
application
in
terms
of
the
wasm
cloud,
key
value,
interface,
you're,
building
it
in
terms
of
the
Wazi
Cloud,
key
value,
interface
and
I.
A
Guess
that's
only
one
letter
and
a
hyphen
difference
when
you
say
it,
but
it's
really
big
in
terms
of
looking
at
the
standards
and
then
big
thing.
Number
three
is
transitioning
feature
Focus
to
rust.
This
just
recently,
I
think
it
was
this
morning.
Kevin
put
it
in
as
adr13.
It's
really
focusing
on
the
waslam
cloud
restaurant
time
so
that
we
can
be
right
up
there
with
the
webassembly
standards
and
offer
a
portable,
stable
and
high
performance
runtime.
A
Now
there
is
a
diagram
here
and
I
would
recommend
like
opening
it
in
a
different
tab,
so
that
you
can
actually
read
it,
but
you
can
take
a
look
at
like
how
this
graphically
all
fits
together,
but
the
one
last
thing
that
I
want
to
call
out
here,
because
this
is
more
of
a
motivation
and
explanation
side
of
the
roadmap-
is
the
GitHub
projects
board
and
I've
linked
to
it
a
few
a
few
times
in
here,
just
so
that
it's
really
easy
to
find.
But
I'll
show
you
how
to
find
it.
A
If
you
just
go
to
the
wasm
cloud
organization,
so
github.comcloud,
you
can
go
to
the
projects
here
and
then
see
the
wasm
cloud
roadmap
now
I've
taken
the
efforts
that
we
have
on
the
roadmap
and
put
them
into
a
couple
of
different
views
here.
But
because
this
is
open,
source
timelines
always
are
rapidly
changing.
We
may
have
more
or
less
contributors
at
any
given
time.
We
don't
have
specific
dates
on
these
efforts.
Instead,
we
have
something
like
a
now
next
later
format
for
the
roadmap,
so
this
first
view
is
just
a
very
high
level.
A
A
That's
a
little
of
a
fourth
category
called
blocked,
which
is
essentially
just
this
one,
for
example,
is
blocked
and
there's
a
note
on
this
somewhere
here
we
go,
you
know
blocked
on
on
some
other
efforts.
A
Victor
is
working
on
that,
and-
and
things
like
that,
so
all
of
these
views
just
display
the
same.
The
same
larger
efforts
in
a
different
way,
but
I
think
they're
going
to
be
really
useful
in
order
to
see
what
efforts
we're
currently
working
on,
especially
what
we
have
in
progress
and
and
that
we're
completing
and
I'd
like
to
try
and
surface
this.
In
a
couple
more
places,
I'll
try
to
pin
it
in
slack,
and
you
know.
Obviously
this
will
go
into
the
website.
A
A
I
think
that's
going
to
be
really
important.
So
I
know
that
we're
kind
of
at
the
top
of
the
hour
here
happy
to
answer
any
questions
or
take
any
feedback
or
or
take
that
offline
as
well,
but
I
hope
that
that
roadmap
really
helps
keep
everybody
in
line
or
keep
everybody
informed
about
where
we're
actually
at
with
our
work.
A
C
A
Everyone
well,
then,
I
think
that
we'll
go
ahead
and
call
it
thanks
for
a
great
thanks
for
a
great
meeting
today,
lots
of
great
discussion,
a
great
demo
from
Taylor
and
great.