►
From YouTube: wasmCloud Community Meeting - 12 Jul 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
Sweet
hello,
everybody
Welcome
to
the
waslam
cloud
community
meeting
for
Wednesday
July,
the
12th
today
is
going
to
be
all
about
wit.
We've
got
a
demo
around
witty
providers,
which
is
a
fun
pun.
That
Jordan
came
up
with
and
I'll.
Let
him
explain
a
little
more
around
what
this
this
effort
means
something
that
we've
been
doing
on
the
maintainer
side
and
we're
gonna
get
to
show
off
a
little
bit
today
and
then
I've
queued
up
some
discussion
in
the
end.
A
For
what
in
the
world
is
wit,
why
wasn't
cloud
is
transitioning
to
use
it?
You
know
kind
of
where
it
plugs
in
in
the
webassembly
world
and
I
really
just
wanted
to
set
up
some
time
so
that
we
can
all
talk
about
it.
We
can
brainstorm
anybody
who's
coming
in
and
tuning
into
the
community.
A
Maybe
is
a
new
new
person
coming
or
contributing
understanding
what
what
wit
is
and
why
it's
important,
so
I
will
go
ahead
and
stop
taking
the
floor,
because
I
think
I'd
like
to
hand
it
over
to
Jordan
so
go
ahead
and
you
should
be
able
to
share
and
everything
Jordan
so
go.
B
For
it
cool
one,
let
me
see
if
I
can
get
this
working
hello,
everyone,
please
wait.
B
Whatever
okay
hope,
there's
nothing
too
personal
on
my
monitor.
Okay,
can
you
see
that
Brooks.
B
Yeah
so
about
a
week
ago,
maybe
maybe
a
little
longer
I
decided
to
take
a
a
peek.
B
How
do
I
do
that?
Oh.
A
A
Sorry
Jordan
one
more
thing:
I
can
see
on
the
live
stream.
It's
a
little
a
little
blurry.
If
you
could
get
a
little
make
this
AARP
approved
and
zoom
in
a
little
bit.
A
Maybe
one
more
okay,
yeah
I'll
I'll,
let
you
know
if
it's
because
the
stream's
a
little
behind
but
I
just
want
to
make
sure
that's
visible,
I.
Think
it's
good.
Okay,.
B
Well
again
so
yeah
I
looked
about
a
week
ago,
I
started
looking
into
wit
and
Bailey
will
go
into
it
and
much
more
technical
detail,
but
it's
essentially
just
an
ideal.
A
lot
like
Smithy,
however,
it
was
built
for
the
webassembly
ecosystem,
so
I
took
on
the
challenge
of
since
go
is
the
point
of
least
friction
and
I'm
the
most
familiar
with
it,
trying
to
remove
all
the
Smithy
generated
interfaces
and
replace
it
with
the
wit
IDL
interfaces.
B
So
I,
one
of
the
my
starting
point
was
having
to
identify,
in
wit,
what
like
wasm
clouds,
RPC
bus
looks
like
and
there's
a
PR
and
wasn't
quite
interfaces,
but
this
is
essentially
what
I
what
I
came
up
with
right.
So
if
you
were
to
pull
up
the
Smithy
version
of
our
core
contract,
you
would
see
it
pretty
much
Maps
one
to
one,
with
the
exception
of
a
few
things
like
the
option.
B
Types
aren't
in
Smithy
and
well
map
types,
but
we
won't
get
into
that,
but
essentially
the
while
the
contract
is
like
95,
similar
code
generation.
There
are.
There
were
some
changes
that
you
know:
they're
not
one-to-one,
Smithy,
to,
to
wit,
so
I
took
that
on
and
what
I
did
was.
I
I
took
the
provider
SDK
that
we
already
have
and
go
and.
B
You'll
you'll
see
now
everywhere,
where
we
did
have
like
interfaces
or
wasn't
called
interfaces
core
tinygo
we've
now
replaced
it
with
this
core.
The
you
know
somebody
out
lives
in
the
repository
with
it
and
if
we
dig
into
that
which
is
not
going
to
be
on
that
screen,
let
me
pull
this
up.
B
E
B
Okay,
which
generates
something
extremely
similar
to
what
we
did,
what
we
had
in
Smithy.
So
what
you're
looking
at
here
on
the
right
is
if
we
were
to
go
and
take
the
by
code,
alliances
with
binding
binary
that
they
have
in
their
GitHub
repo
and
run
it
over
this
wit
file.
We
would
get
this
output
and
essentially,
what
we've
done
is,
you
know,
replace
the
Smithy
with
this
stuff,
so
the
demo
is
still
a
work
in
progress,
but
it's
very
it's
fun.
B
On
two
parts
we
have
a
provider
and
an
actor
running
in
wasm
cloud,
with
no
more
Smithy
IDL
interface
pieces
generated.
The
only
thing
I
can
show
you.
The
provider
is
running
right
now.
Is
you
can
see
in
Nats
here
that
the
32nd
health
check
that
it
does
is
running?
You
can
see
the
ping
pong
provider
here,
and
we
can
see
here
that
we
can
actually
query
the
actor.
B
You
say
ping.
It
says
pong
if
we
were
to
link
these
two
right
now
it
actually,
you
would
see
the
provider
send
an
invocation
over
to
the
actor.
It
passes,
the
all
of
the
wasm
cloud,
Security
checks.
However,
I
do
have
a
bug
in
there,
that
is,
that
the
the
actor
is
is
crashing,
but
that
being
said
by
next
Wednesday
I
hope
to
have
that
fixed
and
we
can
link
them
and
then
we'll
see
a
full
round,
robin
wit
only
active
provider
example.
B
So
it's
you
know
it's
not
that
exciting
to
look
at,
but
this
does
align
us
or
begin
to
align
us
with.
Where
is
it.
C
B
Which?
Okay
so
actually.
B
B
B
However,
you
will
see
like
we
will
have
this
go
generate
line
at
the
top
of
every
file
and
what
that's
going
to
do
is,
while
my
understanding
is
wasn't,
Cloud
will
have
all
the
Wazi
Cloud
interfaces
built
in
that
doesn't
address
custom
contracts,
much
like
my
extremely
Advanced
ping
pong
contract,
which
is
when
I
ping
pong
I
take
a
ping
and
I
return
a
pong.
So
we
have
to
have
a
way
to
to
to
do
the
Custom
Contracting.
B
This
lovely
file-
you
know
code
over
here,
which
is
essentially
the
two
types
I
had
and
an
interface
that
says
you
know
anybody
that
satisfies
ping,
but
you
would
actually
see
this
interface
satisfied
in
the
actor,
because
the
way
this
is
written,
it's
a
provider
to
act
or
call,
but
the
actor
and
providers
share
this
contract
and
then
this
file
called
hand
done.
So
this
is
the
work
that
I.
That
still
has
to
be
done.
B
So
at
the
moment,
Smithy
via
weld
generates
all
this
code
for
us
and
it's
it's
pretty
much
just
serialization
code
closed
right
now,
I
have
to
hand
generate
it
all.
However,
it
is
as
straightforward
as
well
as
as
old
Smithy
piece
used
to
be
so
as
soon
as
we
I
guess
we're
going
to
call
it
bind
you
and
wasm
cloud
or
something
like
that.
B
As
soon
as
we're
able
to
write
the
wasm
cloud
specific
pieces
of
the
code
generation,
which
would
be
all
of
this,
this
will
be
ready
for
what
I'll
call
the
community
to
start
playing
with
right
now.
If
you
want
to
do
it,
it's
absolutely
possible.
You
just
have
to
hand
write
all
of
this,
which
means
I
was
just
kind
of
looking
at
the
looking
at
Old
examples
and
pulling
in
the
new
the
new
types
so
you'll
see
like
right
here.
This
is
a
new
generated
type.
E
Like
that,
I
like
that,
do
you
mind
showing
a
little
bit
on
on
like
the
workflow
for
how
you
built
these
things.
B
E
B
Yeah,
so
let
me
get
in
there,
so
ping
pong
was
actually
still
done
with
wash
new
provider.
It
generated
this
structure
and
I
changed
it
quite
a
bit,
but.
B
Me
all
right,
no,
whatever
okay,
so
right
now,
right,
if
we
were
to
do,
was
start
this
from
new
right.
We
would
run
something
like
what
it
sure
has:
okay,
we
would
go
go
generate
and
you
see
now
go
generate
is
actually,
if
you
recall,
a
wrapper
around
with
binding.
So
actually,
if
we
were
to
run
this
command,
it
would
get
the
exact
same
output.
And
then,
when
you
go
into
gin
right,
we
have
all
of
the
files
necessary
to
make
this
work.
B
You
know
the
C
calls
and
everything
to
work,
make
it
work
with
I.
Think
I
assume
something
like
awesome
time.
We
are
using
it
more
as
a
general
purpose
IDL
from
this
perspective,
so
we
are
actually
able
to
remove
all
the
C
type
code,
go
into
ping-pong.go,
remove
this
and
then
remove
the
functions,
and
at
this
point
we
essentially
have
our
contract
that
we
would
get
in
Smithy.
So
a
little
bit
of
massaging
has
to
happen,
but
we're
pretty
close
to
to
having
something.
That's
iterates,
pretty
well
with
Blossom
cloud.
A
A
A
What
do
you
see
the
the
migration
path
looking
like
for
for
providers
like
on
the
wasm
cloud
slide
aside?
We
have
you,
know
seven
or
eight
capability
providers
that
are
open
source
and
use
the
Smithy
interfaces
so.
B
I'm
glad
you
asked
that
Brooks,
here's
the
one
I
that
I
am
internet
famous
for
right.
So
this
is
the
one
provider
that
I've
written
and
it
uses
obviously
the
core
interfaces
and
and
go
since
it
is
not
a
custom
contract.
B
Pretty
much
what'll
happen
is
we'll
come.
We
will
replace
these
two
lines
with
the
output
of
what
go
generate.
B
Put
so
it'll
be
in
the
same
directory,
but
in
like
generate
and
then
the
only
real
update
which
I
can
probably
minimize
by
changing
the
way
changing
like
some
of
the
generated
names
are
long
and
obnoxious,
but
it'll
just
be
coming
in
and
changing
the
types
like
right
here,
so
this
will
say,
wasn't
Cloud
Core
dot
was
a
Cloud
Core
type
link,
definition
and
you'll
have
to
change
all
that
out,
but
the
logic
itself
wouldn't
actually
change
at
all.
B
It
would
just
be
type
changes
which
I
think
we
can
minimize
by
making.
You
know
paying
a
lot
of
attention
to
the
co-generation.
A
Okay,
so
it
sounds
like
a
good.
That's
really
awesome
to
to
hear
it
sounds
like
a
good
bit
of
the
changes
are
just
kind
of
like
editings
and
imports
and
generate
lines
at
the
top
of
the
file
and
then
as
long
as
we're
kind
of
careful.
If
we
can
make
it
so
that
the
new
generated
type
is
the
same
name
as
the
old
generated
type
Mo,
it
should
be
a
relatively
easy
transition,
because
it's
just
on
kind
of
like
the
types
side.
B
Correct
I
mean,
quite
frankly
since,
like
go
I,
don't
know:
if
Russ
does
this
but
go
since
you
can
have
these
import
aliases
right
as
long
as
I
can
match
the
names
we
can
import
the
new
and
as
core
as
well,
and
there
shouldn't
be
any
code
changes
so
yeah
that
just
has
to
do
with
paying
attention
to
how
we
how
we
name
these
moving
forward.
A
Awesome
yeah
I
think
on
the
Rough
Side
it'll
just
come
down
to
changing
the
you
know
the
interface
for
the
module
path
that
we're
importing
from
and
the
type
names
can
stay
the
same
sweet.
My
end
is
still
up
because
I
had
one
more
question
as
far
as
like
an
actor
developer,
so,
like
I
wrote
an
echo
actor
that
links
to
your
tailscale
HTTP
server
right
or,
like
a
you,
know,
any
actor.
What
what
needs
to
change
there
like
when
we
release
the
new
providers,
using
wit
as
the
interface
definition?
B
So
it's
actually
going
to
be
fairly
similar.
The
both
the
sdks
will
I'm
trying
really
hard
not
to,
but
they
might
be
a
breaking
change,
but
right
now
they're
not
so
there
will
be
just
you'll
you'll
update
the
actor
and
the
provider,
go
modules
or
I,
guess
rust,
crates
and
then
that's
it.
The
the
the
way
we're
gonna
lay
it
out
I
think
is
for
something
like
a
Custom,
Contract
or
I.
Guess
recommend
right.
B
B
So
that
being
said,
the
example
actor
will
be
generated
from
something
like
wash
new
actor,
so
it'll
be
pretty
pretty
familiar.
I
guess
the
word
I'm
looking
for,
but
that
being
said,
I
I
think.
If,
when
we
move
forward,
all
these
new
contracts
will
have
a
example,
provider
and
actor
in
the
repo
with
them,
so
it'll
be
easily
referenceable.
A
B
I
mean
this
plain:
prong
actor
I
have
right
now
right.
It
actually
requires
no
code
changes.
B
A
Yeah
I
I
think
that
makes
sense
right,
like
with
the
as
we
change
interfaces
as
long
as
there's
nothing
super
fancy
going
on
the
types
match
up,
then
it
should
all
serialize
deserialize,
just
as
it
did
before.
No
matter
the
source
interface
I
think
that'll
be
really
important
to
keep
in
mind
as
we
keep
working
on
this
and
if
there,
if
there's
breaking
changes,
then
then
so
be
it
I
think,
there's
a
lot
of
things
that
are
going
to
change.
A
You
know,
depending
on
what
happens
with
the
with
the
standards
so
just
be
transparent.
On
on
that,
no.
A
D
A
We
can
go
ahead
and
move
into
the
discussion.
Part
of
the
call
I
specifically
set
up
a
little
time
to
talk,
about
wit,
and
you
know
with
this
specific
effort
talking
about
wit
as
the
interface
definition
language
for
our
capability
providers.
A
But
of
course,
wit
is
going
to
end
up
being
so
much
more
than
just
for
this
and
I
I
think
Bailey
is
easily
the
best
qualified
and
best
explainer
of
this.
So
I'll
go
ahead
and
throw
it
over
to
to
her
to
go
through.
You
know,
wit
and
and
all
the
things.
E
Yeah
I
I
think
it
was
a
good
call
out
Brooks
that
we
probably
need
to
take
a
step
back
and
kind
of
look
at
another
where
this
fits
into
the
whole
ecosystem
and
the
set
of
standardization
efforts
that
we're
doing
so
webassembly.
E
There
is
a
wazzy
working
group
within
webassembly
and
they
have
done
an
initial
proposal
for,
of
course,
wazzy
preview
too,
but
it
builds
on
top
of
this
new
standard
that
allows
us
to
do
things
like
working
with
high
level
types
and
letting
us
link
together
with
other
different
components,
and
so
a
webassembly
component
is
different
from
a
webassembly
module.
E
But
if
you
understand
that
we're
talking
about
high
level
types
and
we're
introducing
this
new
API
well,
when
you
look
at
the
binary,
that's
output
you'll
see
that
the
wasm
module
is
the
first
like
eight
ish
bytes
and
four
wasm
component.
Obviously
it
has
a
component,
but
then,
when
you
look
inside
it
you'll
see
that
a
was
a
module.
It's
basically
passing
just
numbers
around,
whereas
with
a
wasm
component,
I'm
able
to
use
high
level
interfaces
like
logging,
and
so
one
of
the
things
that
we
learned.
E
While
we
were
working
on
Wazi
preview,
one
we
being
the
w3c
standardization
effort-
is
that
it's
really
difficult
to
version
and
support
abis.
But
it's
significantly
easier.
If
you're
able
to
do
things
at
a
higher
level,
and
so
instead
of
defining
these
with
ABI
as
we've
started,
defining
them
with
an
IDL
and
that's
what
we
talk
about
when
we're
talking
about
width
here
and
width
stands
for
the
webassembly
interface
types,
and
so
we
can
use
these
interface
types
to
talk
between
in
this
diagram
that
link
Clark
Drew.
E
On
the
left
hand,
side
that
computer
is
basically
representing
the
webassembly
host,
so
I
can
load
a
webassembly
guest
component
and
use
that
to
talk
to
the
host
with
these
high
level
types.
But
I
can
also
link
together
and
talk
to
other
components
that
are
written
in
other
languages,
but
over
these
high
level
types
I
could
talk
to
them,
and
so
that's
basically
linking
high
level
types
and
there's
this
other
third
thing
called
platform,
virtualization
and
layering.
E
That
are
the
key
three
features
of
the
component
model
and
if
we
dig
into
like
how
are
all
of
these
different
standards
layered,
it
all
starts
on
top
of
the
web
assembly
core
specification
and
that's
your
webassembly
modules
and
a
component
actually
wraps
a
webassembly
module
today.
It
fully
encapsulates
a
single
webassembly
module
with
shared
nothing
linking,
but
we
are
actively
working
on
shared
everything
linking
to
be
able
to
support
Python,
and
so,
in
that
case,
it'll
be
one
component
to
many
webassembly
core
modules
with
Wazi
preview
2.,
it's
all
defined,
in
wit.
E
E
But
the
main
thing
like
the
goal
of
all
of
this
is
that
anybody
now
can
come
and
build
modular
interfaces.
So
I
expect
communities
like
Envoy,
proxy
or
open
policy
agent
to
have
their
own
sets
of
interfaces
that
everybody
basically
uses
and
it's
provided
by
a
registry
and
we
can
build
and
share
and
version
these
independently
and
so
I'm
showing
you
this,
but
I
do
want
you.
You
know,
I
need
the
caveat
here.
It
is.
E
It
is
not
officially
standardized,
yet
everything
is
very
much
an
action,
but
we're
reaching
a
point
now
where
there
is
a
level
of
stability.
We've
got
a
specific
version
that
we're
targeting
right
now
of
the
component
model
ABI
and
when
I
talk
about
what
that
API
is
I'll
hit
that
in
just
a
sec
but
I
just
wanted
to
give
this
caveat
and
that
we
know
there's
at
least
one
more
feature
that
we're
missing
before
we
say:
we're
not
changing
the
wit,
we're
component
model
specification
and
that's
for
resources
and
handles.
E
So
what
we
basically
just
saw
from
Jordan
is
he
was
able
to
build
a
webassembly
component,
but
he
had
a
few
other
steps
leading
up
into
that
to
be
able
to
test
some
things
out.
Actually
Jordan.
D
E
Dope,
okay,
cool
all
right,
I
didn't
lie
so
yeah,
basically
when
what
we're
talking
about
here
on
this
side
of
it,
the
wasm
component
that
we're
producing
we're
talking
about
building,
basically
actor
components,
and
so
Jordan
used
a
variety
of
tools
to
get
to
the
point
of
having
outcomes
a
component.
Today,
none
of
these
top
level
languages
support
targeting
Wazi
Preview
2
directly,
almost
all
these
languages
that
I'm
referencing
here
they
say
Yazi
preview
one
and
then
we
do
this
adaption
stuff
to
get
it
into
being
a
component.
E
But
Ross
specifically
is
like
this
close
to
having
a
onesie
preview
to
Target,
and
so
you
can
skip
that
adaption
step
for
that
one,
and
so
once
you
once
you
have
it,
you
also
want
to
generate
your
your
gas
language
binding.
E
So
it's
a
little
bit
unfortunate
right
now
that
with
binding,
generates
C
bindings
for
go
that's
kind
of
ugly,
but
it's
leveraging
basically
an
existing
breast
crate
that
obviously
we
started
with
breast,
and
so
it's
reusing
a
lot
of
that
existing
code
to
be
able
to
build
a
lot
of
those
things.
And
so
that's
your
guess,
language
bindings
and
that's
that's
the
part
that
lets
the
your
your
code.
E
So
actually,
let's
dig
in
deeper
I'm
gonna,
go
past
that
and
talk
about
the
shared,
nothing
linking
spec
right,
okay,
so
your
component
instance
has
imports
and
exports,
and
that
is
defined
by
your
wit
definition.
Those
are
those
are
the
apis.
Basically,
that
say
what
goes
in
and
what
goes
out
and
when
I
say
it
fully
encapsulates
core
was
a
module.
What
I'm
showing
is
that
all
of
its
memories,
its
tables
globals?
All
of
that
isn't
accessible
to
anybody,
that's
talking
to
it.
E
They
talk
to
it
through
the
imports
and
exports,
and
so
with
share
nothing
Linkin.
We
get
a
ton
of
really
cool
benefits
like
I.
We're
able
to
actually
do
principal
at
least
Authority,
even
within
a
single
application,
which
is
something
that
has
before
now
before
the
component
model
exists,
is
something
that
nobody
could
really
do.
E
You
basically
had
a
giant
environment
variable
blob
of
all
the
keys
to
your
database
and
to
your
key
value,
store
to
the
way
you
talk
over
your
message
broker
and
basically
anything
that
was
in
your
supply
chain
could
just
say:
hey,
I
know
what
the
environment
variable
for
AWS
Keys
usually
looks
like.
Let
me
just
speak
and
get
those
and
now
I
have
access
to
your
data.
E
So
by
saying
you
know,
hey
this
library.
That
is
only
supposed
to
be
doing
the
thing
that
does
maybe
my
messaging.
It
does
not
need
to
know
how
to
talk
to
my
database
right
and
so
I
can
pass
the
right
things
in
and
out,
and
then
that
means
that
all
all
of
the
boundaries
for
what
these
apps
do
is
clearly
defined,
and
that
lets
us
do
a
lot
more
modular
style
programming.
So
there's
a
ton
of
different
benefits,
I
see
in
the
future,
yeah
Liam.
C
Oh
no
finish
the
section
you're
on
there's
a
question
from
YouTube
and
chat
there
I
think
you
may
want
to
maybe
talk
about
if
I
understand
the
question
right,
maybe
take
a
step
back
and
do
a
little
comparison
between
me
and
what
we're
abstracting
from
from.
Maybe
containers
versus
this.
E
Yeah,
that's
a
good
question.
Okay
I'll
finish
this
last
bit
and
then
I'll
answer
that.
So
when
we
talk
about
lifting
and
lowering
types
and
that
you
see
some
of
that
in
the
guest
generation,
that
Jordan
was
showing
for
making
the
thing
that
he
was
generating
work
within
a
web
assembly
runtime.
E
What
that
is,
is
Lifting
and
lowering
types,
and
so,
when
you're
at
when
say
you're
linked
together,
rust
and
a
python
component,
the
rust
representation
of
strings
is
different
from
the
python
representation
of
strings.
And
so
when
I
link,
those
together
I
have
to
know
how
to
bring
it
up
to
a
webassembly,
lift
it
to
a
webassembly
or
lifts
it
to
my
rust
string
type
when,
when
it's
coming
to
me
in
rest,
I
also
need
to
know
how
to
take
it
down
to
the
i32
representation
within
a
webassembly
module.
E
So
when
we
talk
about
lifting
and
learning
we're
talking
about
being
able
to
get
it
into
a
common
representation
which
is
what's
defined
by
the
canonical
ABI
within
the
that's
kind
of
like
part
of
the
component
model
spec
and
then
there's
getting
it
into
what
will
let
you
work
within
all
of
these
different
languages
and
so
to
address
the
question
about
you
know
component
model
as
an
abstraction.
E
It's
definitely
true
when
people
think
about
okay,
well,
I
I,
put
things
in
a
container,
and
so
I
bet.
I
could
find
a
better
slide
for
this,
but
basically
right
now
when
we
actually,
you
know
what
I'm
doing
it
I'm
going
to
go
ahead
and
grab
a
different
slide.
Deck.
E
E
D
E
And
so,
when
I'm
talking
about
what
is
a
component,
what
I'm
talking
about
is
cracking
open
that
one
spot
that
one
place
where
the
application
is
and
then
breaking
down
the
way
that
we
build
apps
today
from
first
principles.
So
in
this
case,
I'm
showing
like
hey
I,
want
to
use
a
aw,
a
keystone,
Value,
store
and
and
I
want
to
talk
to
AWS.
E
Well,
when
I
do
that,
I
typically
am
going
to
pull
in
something
like
dynamodbs
API
and
that
might
also
bring
in
and
install
additional
system
libraries
or
more
things
inside
my
container
to
be
able
to
do
that.
And
so
this
import
is
one
of
many
different
Imports
that
are
going
to
exist
in
my
system.
Right,
typically
I'm,
not
just
talking
to
a
key
value,
store,
I'm
doing
a
lot
of
other
stuff.
E
So
I
have
a
lot
of
other
libraries
I
brought
in
if
I'm
doing
messaging,
it
might
be
Kafka
and
that
one
definitely
brings
in
a
system
library,
and
so
when
I
crack
open
that
app.
That's
the
thing
that
I
want
to
I
want
us
to
find
a
way
to
make
those
smaller,
more
efficient
and
built
in
a
different
way.
E
And
so
you
take
a
component
and
you
plug
it
into
the
host
that
matches
all
of
those
same
apis,
and
so
if
a
host
has
Wazi
Preview
2
support,
it's
got
the
right
knobs
that
any
component
that
wants
to
use
wise
you
can
plug
straight
into
so
I
think
that
part
was
really
fun
to
show
off
and
talk
about
with
the
community,
and
when
we
talk
about
how
we
build
things
within
the
was
in
Cloud
ecosystem,
you
know
we're
not
just
doing
components
locally
on
one
single
web
assembly
runtime
and
what
I'm
seeing
a
lot
of
people
do
is
build
capabilities
directly
into
the
host,
which
means
I've
taken
all
those
cves
and
all
those
vulnerabilities
everywhere
else
and
I've
kind
of
put
them
all
in
the
same
box
again
and
I
made
them
all
run
within
the
same
process
and
that's
kind
of
failing
now.
E
There
are
a
lot
of
folks
that
are
trying
to
find
different
ways
of
making
that
safe
and
and
to
be
clear,
this
box
here,
that's
my
sandbox
right.
That's
the
thing
that
guarantees
all
the
safety
reasons
for
why
I'm,
also
interested
in
building
with
web
assembly
web
assembly
components
so
I
think
I
can
I
can
probably
stop
there.
E
There's
you
know
this
is
something
I
like
to
talk
about
a
lot
I
sped
through
kind
of
you
know
what
it
looks
like
to
link
things
together,
but
I
guess
one
thing
I
didn't
say
is
that
I
can
take
rusco
and
JavaScript
and
when
I
compose
those
together
I
can
either
use
the
wasum
tools.
Compose
command
or
I
can
use
crate.
So
every
every
tool
within
wasm
tools,
project
which
is
part
of
the
bytecode
alliance.
C
So
if
I
could
restate
one
of
the
things
that
I
think
I
just
heard
you
say
is:
is
that
there's
some
compelling
reasons
that
we
don't
want
to
bake
these
standard
capabilities
into
the
host,
because
that
moves
us
back
to
the
same
problem
we
have
in
the
containerized
world
where
we
are
including
all
of
our
non-functional
requirements
at
compile
time.
You
know
static.
You
know
static
versions
of
them
as
opposed
to
the
dynamic
loading
at
runtime,
which
is
what
you're
saying
when
they're
external
to
the
hosts.
C
In
that
way,
a
platform
like
Blossom
cloud
or
you
know
a
commercial
one
could
load
the
latest
version.
That's
most
the
you
know
the
most
recently
built
that's
up
to
date
that
catches
the
latest
cve
or
log4j
at
runtime,
as
opposed
to
compile
time,
did
I
understand
that
right,
yeah.
E
That's
that's
one
of
the
major
places.
I
think
that
people
can
find
ways
to
sandbox
some
of
those
capabilities.
I
think
there's
lots
of
different
options
and
there's
other
ways
of
you
know:
defining
like
a
DUI
live
or
like
a
dynamically
linked
thing
in
other
web
assembly
run
times.
I
know
some
folks
are
trying
that.
E
So
if
there's
a
vulnerability
in,
say
the
HTTP
server
that
vulnerability
isn't
in
my
host,
that
vulnerability
is
only
in
the
HTTP
server
and
that's
the
only
thing
that
I
need
to
update
and
then
from
there
it's
all
about
relinking
to
that
new
version
and
that's
incredibly
powerful,
because
the
thing
that
we
need
to
get
away
from
is
turning
the
crank
across
the
world.
Every
time
we
have
one
of
these
major
cves.
E
This
is
how
I
like
to
describe
it,
which
is
like
if
we
have
another
log
for
J
event,
which
is
like
a
common
Library.
That's
in
everybody's
code,
I
for
the
sake
of
the
planet,
am
not
interested
in
finding
ways
to
recompile
all
of
our
code,
all
across
the
world
and
I
really
just
want
to
fix
one
thing:
that's
wrong
and
components.
Let
me
do
that.
E
Yeah,
we
didn't
really
talk
about
world
files,
that's
its
own
conversation,
but
I
like
talking
about
it.
If
anybody
I'm
seeing
CJ's
comment
there,
so
yeah
part
of
wazzy
pre-v2
is
defining
basically
two
World
definitions
and
the
way
to
think
of
a
world
file
is
that
it's
a
collection
of
imports
and
exports.
So
those
interfaces
that
I've
been
talking
about
those
high
level
interfaces.
E
So
every
line
here
each
one
of
these
Imports.
These
are
things
that
we're
standardizing
individually
those
interfaces,
but
then
we're
also
standardizing
the
collection
of
these,
so
that
together
they
make
something
whole
that
you
can
think
of
as
like
an
execution
environment
and
so
one
of
the
first
ones
most
people
will
be
used
to
is
probably
like
running
a
CLI
World,
which
is
really
similar
to
what
we
have
available
in
Wazi
preview.
One
and
many
of
these
apis
will
be
familiar,
but
some
of
these
are
new
and
awesome.
E
Like
the
poll
API
and
that's
kind
of
the
underpinning
for
letting
us
do
like
back
offering
in
some
early
async
Behavior,
we
was
a
preview.
2
itself
won't
support
native
async.
A
lot
of
that
is
going
to
be
handled
by
our
webassembly
runtime.
To
begin
with,
it
has
a
table
and
it's
keeping
track
basically
of
all
of
those
pollables,
but
we're
able
to
start
writing
code
that
takes
advantage
of
that
from
the
guest
side,
and
so
this
is
a
simplified
version
so
that
it
would
fit
on
my
slide.
E
But
basically,
this
is
what
it
looks
like
for
the
CLI
world
that
we're
standardizing,
and
the
very
bottom
here
is
the
Run
command,
which
is
like
okay,
I
have
a
CLI
and
I.
Just
you
know
think
about
any
CLI
that
you
run
on
your
command
line.
You
just
run
it.
That's
that's!
Basically
what
that
is
for
for
the
for
components
that
want
to
run
in
webassembly
Worlds.
That
support
command
modules
is
a
different
way
of
saying
that
we
didn't
talk
about
the
difference
between
reactors
and
commands,
but
I
don't
think.
E
So
any
more
questions
I
mean
this
is
you
know,
I
could
give
a
keynote
on
this
easy,
but
I.
Think
there's
a
lot
here.
What's
exciting
is
that
this
set
of
work
right
is
basically
stabilized.
I
can
build
stuff
on
this
and
it
hasn't
broken
me
in
a
few
weeks,
which
is
a
big
deal
for
me
at
least,
and
a
lot
of
the
activity
for
the
other
side
is
there's
another
world.
E
So
there's
the
wazzy
CLI
world,
the
other
world
that
we're
going
to
standardize
as
part
of
wazzy
preview
to
you
is
the
HTTP
proxy
world.
So
you
could
think
of
that
as
an
app
that
needs
HTTP
and
some
logging
some
of
the
same
capabilities
here
within
the
CLI,
but
otherwise
something
that
actually
supports
HTTP
and
that
kind
of
shows
two
very
different.
Runtime
environments
right.
E
It's
not
just
about
trying
to
find
a
thing
that
kind
of
emulates
posix,
but
like
not
really
right,
because
it's
missing
all
of
those
other
things
that
Docker
does
it's,
why
it
starts
so
fast
and
it's
why
it's
so
tiny
and
there's
a
lot
of
reasons
to
do
it
that
way
and
I'm,
not
particularly
interested
in
finding
ways
to
virtualize
Linux
badly.
What's
more
interesting
is
finding
new
ways
to
write
applications
for
the
modern
world.
E
So
these
components
are
declaratively
linked,
they
might
be
statically
linked.
They
might
also
be
dynamically
linked,
but
there's
a
little
Dynamic
depends
on
your
definition.
You
can
do
this
at
runtime
and
that'll.
Give
you
that
feeling
of
Dynam,
dynamices
and
dynamism
I,
don't
know
how
to
say
it.
I'm,
just
not
gonna,
but
yeah
I'm
interested
in
in
more
on
that
question
CJ
or
wait.
Sorry
that
was
l,
foreign
well
I'll
answer
that
more
CJ.
You
want
to
answer.
E
Yeah
so
with
wazzy,
previously,
we
kind
of
defined
a
set,
a
district
set
of
of
apis
that
represented
an
ABI,
an
application,
binary
interface,
whereas
this
is
defined
using
Independence
width
definitions
and
each
one
of
those
independent
web
definitions
or
idls,
and
it
and
it's
not
about
separating
out
the
build
itself.
E
So
our
previous
incarnation
of
this
was
actually
just
with
webassembly
modules.
So
it
was
part
of
the
core
webassembly
specification
and
wazzy.
E
Basically,
the
things
that
came
out
were
more
numbers
for
it,
and
now
what's
different
is
the
thing
that
comes
out
is,
like
you
know,
literally
like
the
the
binary
syntax
of
the
dot.
Wasm
is
different,
so
it's
more
than
just
the
build
I
guess.
D
Right
thanks,
yeah
that
clarifies
a
little
I
would
have
to
sort
of
dig
in
I
think
to
ask
a
a
more
intelligent
question.
I'm,
definitely
interested
in
in
how
this
works
at
a
low
level.
So.
E
I
mean
we
haven't
yet
had
a
call
for
like
implementers
on
a
lot
of
this
stuff
right
we've
been.
We
have
component
model
implementation
weekly
calls
where
we've
been
talking
about
building
this
implementation
and
giving
feedback
back
to
the
specification.
So
there's
the
w3c
standardization
process
and
then
there's
a
group
of
us
working
within
the
by
code
Alliance
to
build
up
implementation
and
give
feedback
to
folks
like
Luke
Wagner,
one
of
the
original
creators
of
webassembly
who's,
the
key
Champion
for
the
component
model.
E
We
go
back
and
give
him
feedback
like
it's,
not
gonna,
quite
work,
I,
don't
think,
and
so
within
was
some
time
is
the
first
reference
implantation,
and
so
that
was
a
really
long-winded
answer
of
there
are
no
wrong
or
stupid
questions,
because
a
lot
of
us
are
figuring
this
out
and
it's
all
being
invented
right
now.
D
Gotcha
cool
yeah
I
might
hit
you
up
on
the
slack
to
get
maybe
links
to
those
conversations,
because
that
sounds
interesting.
Thanks.
C
You
know
I
just
wanted
to
add
I,
think
that
you
know
the
a
lot
of
the
folks
at
cosmotic.
Are
you
know,
working
hard
on
planning
or
implementing
a
lot
of
this
in
wasm
Cloud
right
now?
C
C
Think
one
of
the
things
that
I'll
continue
to
ask
across
our
team
is
that
you
know
we
do
this
stuff
in
you
know
in
the
public
slack,
and
we
have
the
conversations
there,
because
I
know
that
I
feel
like
it
took
me:
I
had
to
listen
to
it
a
few
times
to
get
all
the
pieces
to
fit
together
and
understand
how
they
were
really
coming
together
in
this
elegant
way.
It's
very
similar
to
the
long-term
Ambitions
of
where
wasmcloud
started.
You
know
three
or
four
years
ago,
plugable
components.
C
Some
of
the
details
are
a
little
different.
You
know
Smithy
versus
a
wit,
and
but
the
the
amazing
thing
is
is
that
as
I've
watched,
Roman
and
Bailey
and
Victor
and
all
the
other
folks
that
are
working
on
this
effort
in
the
background,
it's
is
how
much
of
our
current
ecosystem
translates
directly
over.
C
So
conceptually
a
bunch
of
our
tooling,
you
know
all
of
these
sorts
of
pieces,
so
I
think
we
we
should
double
down
and
make
sure
that
we
are
over
communicating
on
wasm
cloud
slack
and
and
continue
in
this
meeting
to
sort
of
do
these
weekly
updates.
I
don't
know
if
we
would
want
to
do
one
every
week,
Bailey
for
the
next
few
months.
If
that
doesn't
feel
too
heavy,
you
know,
maybe
we
just
give
a
demo
of
you
know
Roman
what
you're
working
on,
and
that
would
be.
C
That
would
be
great
because
I
know
that
I
feel
like
every
week.
My
mind
is
blown
as
as
this
stuff's
really
come
together
and
you
know
I
didn't
mean
to
leave
out
names,
I
mean
Jordan,
you
know,
Kevin
Brooks,
Taylor
I
mean
everybody
I
feel
like
on
our
side.
Is
we
really
working
hard
on
the
implementation
of
the
stuff.
A
Yeah
Victor
too
yeah
I,
just
I,
wanted
to
add
on
just
a
little
board
there
just
to
say
that
this
is
such
an
exciting
such
an
exciting
time
for
wasm
cloud,
in
terms
of
like
what
we're
doing
with
the
webassembly
module,
and
now
that
we
are
seeing
some,
you
know
you
were
like
into
the
phase
where
we're
rapid
prototype
being
in
and
seeing
working
pocs
with,
with
wit
and
worlds
and
Wazi
Preview
2.
A
All
of
those
things
are
super
exciting,
and
you
know
they've
kind
of
graduated
from
something
that
we
can
think
about
as
maintainers
as
like
gosh
I
can't
wait
until
this
works,
and
now
it
does
so
expect
to
see
a
lot
more
activity
on
on
the
standard
side
and
and
communication
there.
It's
it's
a
really
exciting
time.
E
Yeah
I
want
to
take
another
swing
at
it,
so
this
is
an
example
of
a
world
definition.
Another
way
of
thinking
of
a
world
sometimes
I,
just
think
of
them
as
a
component
themselves.
So
when
you
build
a
component
and
I
I
run
a
command
like
wasm
tools,
wit
that
will
print
out
the
wit
definition
of
that
component,
so
I
don't
actually
need
a
wit
file
to
know
what
the
wit
definition
of
a
component
would
be.
E
So
this
one's
kind
of
fun,
because
this
shows
a
little
bit
more
on
that
linking
of
being
able
to
link
to
multiple
guest
components.
So
in
this
case
it's
it's
contrived,
but
I
wanted
to
have
a
greeting
application
that
greeted
from
go
rust
and
JavaScript
and
I.
Think
I've
showed
this
off
at
the
community
call
before
so.
I
won't
like
Go
and
show
off
too
much
of
this
demo,
but
specifically
around
World
files.
E
This
is
this
is
an
example
of
that
of
how
do
I
bring
in
all
those
different
libraries
and
and
then
run
them,
and
so
this
app
when
you
look
at
its
source
code,
it's
pretty
simple.
You've
got
the
bindings
for
those
different
libraries.
A
E
So
you
simple
code,
I'm
able
script
to
the
rest
to
the
Gopher
call
all
from
my
one
rust
app
that
was
defined
by
that
one
world
definition
here,
and
so,
when
I
build
this
thing
to
make
it
work.
I
I
used
a
little
cheat
code
within
the
blasom
tools
compose,
which
is
a
CLI
and
and
kind
of
told
it
where
all
I,
where
I
put
all
of
these
was
and
each
one
of
these
themselves
is
the
web
assembly
component.
D
E
This
should
still
work,
so
you
should
be
able
to
pull
in
my
project
here
and
give
it
a
whirl
for
yourself
and
this
kind
of
walks
you
through
some
of
what
it
looks
like
for
a
lot
of
those
CLI
commands.
But
for
many
of
these
for,
like
the
rest
ones,
there's
just
one
one
step
to
be
able
to
start
and
build
a
component
which
is
really
great.
E
But
I
I
think
I
want
to
leave
time
for
Liam
to
talk
through
some
of
the
conferences
I've
enjoyed
also
getting
to
work
with
him
on
them.
I'm
getting
really
excited
about
one
of
the
events
than.
C
Than
your
epic
explanation
today,
I
gotta,
be
honest:
I
want
to
pull
out
that
whole
part
of
the
video
and
just
publish
that
as
a
separate
video
like
you
know,
you're
just
like.
Let
me
just
drop
this
Like
It's
Hot,
but
it's
a
quick
update
on
conferences.
C
A
wasam
Khan
is
a
well
underway.
We
had
a
96
submissions
and
the
cfps
are
almost
finished
being
reviewed.
The
program
Committee
of
which
Bailey
and
I
are
two
of
the
chairs
sure
trying
to
get
the
schedule
out
next
week.
It's
going
to
be
exciting,
I
think
we'll
have
around
36
talks,
there's
also
training
sessions
available.
This
is
a
September
six
and
seven
I
would
encourage
you
to
get
registered.
We
weren't
sure
about
size.
C
I
could
see
this
one
I'm
selling
out
pretty
quick,
there's
also
an
additional
event.
That's
happening
on
Friday
of
the
same
week,
that's
being
put
on
by
the
by
code
Alliance.
C
Now
the
official
name
is
going
to
be
hack,
the
world,
where
it'll
be
a
one
day,
hackathon,
where
we
take
some
of
this
new
language,
tooling,
for
components
like
cargo
component,
JS
component
size,
Pi
Etc,
and
we
look
at
some
of
the
top
Frameworks
in
each
language
and
we
look
to
see
how
many
of
them
we
can
turn
into
components
should
be
a
really
fun
day.
C
Well,
we're
hoping
we
have
a
big
sponsor.
That's
in
the
area
that
may
be
co-hosting
this
with
us,
we'll
watch
for
more
details
on
that
coming
soon
and
then,
of
course,
the
ever
favorites
kubernetes
kubecon
is
just
around
the
corner.
The
main
cfp
for
kubecon
is
closed.
C
If
you
are
a
member
or
a
leader
of
a
work
group
or
a
spa
or
a
Sig,
you
still
are
eligible
to
nominate
talks
through
the
16th,
but
wasam
Khan
is
included
again
on
the
day.
It
will
be
on
Monday
on
November.
The
6th.
The
cfp
is
still
open
until
August
the
6th,
so
please
feel
free
to
get
those
contributions
in
and
I
think
a
bunch
of
these
others
are
going
to
be
essentially
wasm
related
as
well.
C
My
read
from
Telco
day
as
well
as
the
lfedge
stuff
that's
been
going
on,
are
that
there
are
quite
a
few
web
assembly
related
talks
that
are
flooding
of
those
cfps
as
well.
So
if
you
have
any
questions
or
if
you
need
any
help
with
your
cfp,
don't
hesitate
to
reach
out
Bailey's
again
a
program
chair
for
wasmcon
and
up
on
Twitter.
The
program
chair,
she's
from
Solo,
or
the
co-chair
with
me
for
watching
face
from
solo,
did
I
miss
any
books,
any
any
other
conferences.
A
And
that's
that's
what
I'm,
what
I
know
of
so
far
that
we've
got
on
the
roadmap?
I'm
sure
there'll
be
more!
You
know,
as
all
the
cfps
and
everything
draw.
E
I
think
we
should
at
some
point
pull
our
community
and
figure
out
where
we
should
have
some
wasmcloud
meetups.
C
Well,
you
know
kcd
kubernetes,
Community,
Day
DC
is
I,
think
in
the
middle
of
October
or
September,
and
it's
co-located
with
devops
dates
in
a
gorgeous
building
right
on
the
national
malts
in
the
Red
Cross
building
down
there
it'll
be
a
nice
three-day,
a
hackathon,
so
Billy
Mabel,
so
we
can
catch
up
for
that.
A
All
right
everybody
we're
kind
of
rolling
right
up
to
the
to
the
hour
here,
so
a
really
great
demo
from
from
Jordan
on
on
the
whip
providers.
Thank
you
so
much
Bailey
for
for
coming
in
and
talking
about
you
know
not
just
wit,
but
but
all
things,
awesome,
components
and
and
Liam
for
talking
about
the
conferences
that
we
have
coming
up.
A
Are
there
any
last?
Second
things
that
anybody
wanted
to
mention
before
we
hop
off
the
live
stream.
C
C
So
there'll,
be
you
know
some
authoritative
documentation
out
coming
that
talks
about
all
the
new
things
that
are
coming
in
blasi
preview,
two,
what's
in
what's
out
and
what's
the
status
so
I
think
that'll
be
everybody
should
watch
for
that
I'm
sure
it'll
show
up
on
Twitter
and
all
the
usual
all
the
usual
places.
A
Awesome
well
thanks:
everybody
I'm
gonna
go
ahead
and
stop
the
community
stream
for
now,
but
thanks
for
tuning
in
and
I
guess
we'll
see
you
all
next
week
for
another
fun.