►
From YouTube: wasmCloud Community Meeting - 13 Sep 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
Look
at
that
the
old-fashioned
recording,
thank
you.
Everybody
Welcome
to
the
Watsonville
community
meeting
for
Wednesday
September
13th
we're
having
a
little
bit
of
technical
difficulties
on
the
live
streaming
side.
So
we're
going
to
be
recording
this
one
and
uploading
it
after
the
fact,
but
we're
all
kind
of
coming
off
of
wasenkon,
which
was
an
amazing
conference
for
amazing
conference
for
for
wasm
cloud.
A
Amazing
conference
for
webassembly
and
components
in
general
and
I'm
really
excited
to
share
a
couple
of
the
or
at
least
one
of
the
really
exciting
things
that
we
did
over
the
last
week
and
demoed
at
the
conference.
And
then
we
can
go
into
checking
in
on
one
of
our
Milestones
just
general.
Looking
at
our
road
map
and
then
I
believe
Taylor
has
an
update
on
Ozzy
feels
that
he
wanted
to
share
a
little
bit
later
as
well.
A
This
one
should
be
fun,
so
let's
go
ahead
and
take
a
look
at
the
first
thing
on
the
agenda,
which
is
rust
and
Tiny
go
webassembly
components.
This
is
really
a
fun
one.
Let
me
see
if
I
can
open
this
up
in
vs
code,
because
I
don't
know
it
might
just
be
easier
to
look
at
it
there.
A
So
during
the
this
was
actually
during
the
cosmotic
workshop
at
the
conference,
we
demoed
and
had
people
launch
two
intro
modules
or
two
intro
webassembly
or
wasmcloud
actors
that
were
webassembly
components
instead
of
being
just
like
wasm32,
unknown
unknown
webassembly
modules,
and
one
of
the
big
things
about
this
means
is
that
these
components
were
actually
built,
using
wit
and
wit,
binding
and
don't
actually
include
wasm,
Cloud,
specific
dependencies
or
sdks
in
order
to
have
them
build
and
run
inside
of
wasm
cloud.
A
So
we'll
take
a
look
at
the
restaurant
first,
because
I
think
we
generally
do
things.
We
generally
have
a
lot
of
our
examples
in
Rust
and
that's
what
I'm
at
least
most
familiar
talking
about
and
then
I'll
take
a
look
at
the
go.
The
time
any
go
on
as
well,
and
Jordan
can
always
hop
in
and
correct
me
if
I
say
anything
wrong.
So,
looking
just
first
at
the
cargo.com,
we
can
see
that,
on
the
dependency
side,
we
have
a
very
normal
list
of
dependencies.
A
There's
nothing
was
in
Cloud
specific
in
here,
which
is
very
exciting.
That
means
that,
in
order
to
build
this
actor
and
run
it
in
wasmcloud,
we
didn't
actually
have
to
use
one
of
our
specific
sdks
to
get
this
working.
We
use
wit
bungen
to
generate
types
and
bindings,
and
then
we
use
some
other
creates
like
for
error
handling
and
guessing
the
mime
type
things
like
that.
If
we
actually
take
a
look
at
the
source
code
for
this,
we
can
see
right
at
the
top.
A
We
have
used
the
whitbunge
and
generate
macro
to
to
generate
types
bindings
and
specifically
export
this
one
function
called
Wazi
HTTP
incoming
Handler.
This
comes
from
the
this
is
a
function
in
the
wit.
It's
going
to
be
our
one
export.
This
is
very
analogous
to
the
way
that
we've
done
things
in
wasm
Cloud,
for
a
long
time
where
actors
will
have
a
certain
a
certain
set
of
incoming
handlers.
A
A
This
is
just
because
of
the
the
naming
scheme,
but
this
actually
implements
the
exact
set
of
functionality
that
the
key
value
counter
implements
so
the
whole,
like
the
the
end
result
of
the
contract.
Here,
the
the
thing
that
this
actor
does
is
receive
HTTP
requests
and
then
increment
a
counter
in
a
key
value
store
and
then
return
that
result
as
an
httpe
response.
A
So
you
can
see
here
that
we
have
a
kind
of
just
a
unit
struct,
for
the
actor
name
and
in
implementing
the
guest
method.
We
have
a
single
function
called
handle.
It
takes
an
incoming
request,
which
is
you
know
very
similar
to
our
HTTP
requests
and
then
for
a
response.
We're
actually
writing
out
to
a
we're.
Actually
writing
the
response
out.
A
It's
it's
just
slightly
different,
but
you
can
see
the
business
logic
comes
down
to
be
very
similar
when
you
have
a
get
request
at
slash,
API
counter,
we
get
the
key
value
bucket,
which
you
can
see.
This
is
in
the
key
value.
No,
that's
actually
an
imported
function
and
then
we
can
use
the
KV.
The
Wazi
key
value,
Atomic
increment
function
to
increment
the
value
in
the
counter,
and
then
we
write
out
our
HTTP
response.
Now
it's
worth
mentioning
that
a
lot
of
this
is
working.
A
You
know
this
is
all
working
directly
with
the
with
the
Wazi
stand,
standard
interfaces
which
is
really
exciting.
If
we
take
a
look
at
the
actual
wit
file,
the
thing
that
describes
a
collection
of
imports
and
exports
that
this
actor
uses,
we
import
three
from
waziki
value,
I
think
we
don't
even
technically
use
this
one.
We
import
the
Wazi
logging
function
and
then
we
export
the
Wazi
HTTP
incoming
Handler.
A
This
has
the
a
couple
of
benefits,
of
course,
we're
using
wit
to
generate
the
bindings
and
types
here
which
is
really
exciting,
where
actually,
when
we
run
get
out
of
here,
Zoom
rust.
When
we
run
wash
build
here,
we
are
actually
building
wasm32
Wazi
webassembly
component
instead
of
a
blossom,
32
unknown
unknown,
webassembly
component
or
sorry
webassembly,
module
lots
of
terminology
and
has
the
net
benefit
of
again
not
using
wasmoglob
sdks
means
that
it's
not
a
requirement,
or
at
least
a
a
constraint.
A
So
you
can
actually
take
a
webassembly
component
that
you've
built
using
this
world
on
your
own,
maybe
even
for
a
different
framework
or
SDK
and
run
it
in
wasm
Cloud
without
having
to
change
it.
It's
really
really
awesome
stuff.
We
can
see
a
couple
of
things
if
we
inspect
the
the
webassembly
module.
It's
going
to
look
a
little.
It's
going
to
look
very
similar
to
to
what
we
do
before,
because
we're
still
signing
the
webassembly
component,
but
we
also
have
extra
information.
A
We
can
use
the
wasm
tools
tool
chain
and
the
sub
sub
commands
component
wit
to
actually
pull
out
the
final
wit
file
in
the
world.
That
we
use
for
this
component,
so
we
import
a
couple
more
things
like
with
Wazi.
I
o
streams
in
order
to
stream
the
the
HTTP
response
out.
We
do
import
Wazi
HTTP,
which
brings
in
some
stuff
from
Wazi
CLI.
A
A
Okay,
if
we
take
a
look
at
the
hello
Cosmo
go,
this
is
very
similar.
This
uses
go
generate
instead
of
or
just
kind
of
like
a
wit,
bungen
tool
here
to
generate
the
interfaces
and
again
it
has
a
kind
of
a
unit.
Struct
and
a
single
function
called
handle
which
gets
a
Wazi
HTTP
incoming
Handler
incoming
request,
and
then
you
can
write
out
to
this
response
as
well.
So
I
think
there's
certainly
some
opportunity
to
kind
of
wrap
some
of
these
things.
In
nice
little
Handler
functions.
A
A
If
you
all
want
to
take
a
look
at
this
code,
let
me
go
ahead
and
send
this
repository.
This
is
the
repo
that
we
used
for
the
workshop,
and
some
of
this
is
geared
more
towards
launching
these
actors
on
on
cosmotic.
But
of
course,
that's
all.
Of
course.
That's
all
wasmcloud
under
the
hood,
so
it'll
all
work
the
same
here
right
I
definitely
wanted
to
I
I
wanted
to
show
off
that
example,
because
it
is
sorry
for
the
surprise,
light
mode.
A
It
kind
of
hurt
my
eyes
so
I'm
sure
it
might
have
hurt
yours
too
I
I'm,
really
proud
of
where
we
got
leading
up
to
the
conference
to
have
a
pure
webassembly
component
that
can
run
in
wasmcloud
and
I'm
really
excited
now
that
we're
coming
home
to
kind
of
build
on
that
get
a
little
more
documentation
start
start
converting
our
current
examples
over
to
this,
this
method,
just
kind
of
goes
it
just
kind
of
all
works
works
in
our
favor
there.
A
We
also
had
some
really
exciting
a
really
a
really
fun
time
at
the
bytecode
alliance
hackathon,
which
was
on
Friday,
got
to
hang
out
with
some
of
the
people
like
guy
Bedford,
who's,
working
on
the
componentized
JS
effort
to
write,
JavaScript
components
and
Joel
dice,
who
was
a
main
contributor,
and
maybe
even
the
the
first
and
major
contributor
to
componentized
Pi,
which
is
the
effort
for
doing
that
with
python
components.
So
I'm
really
excited
to
keep
experimenting
with
language
support.
A
A
That's
a
reality
that
isn't
that
far
away
I
just
want
to
reiterate
before
stuff
for
questions
that
wasn't.
Cloud
continues
to
work
with
the
Wazi
preview,
one
style
or
the
Standalone
webassembly
module.
So
you
can
actually
go
through
all
of
our
current
and
existing
examples.
Like
the
echo
example,
all
the
ones
that
use
this,
the
wasm
cloud
SDK
to
have
those
nice
wrappers
builds
a
webassembly
module.
Those
all
still
work
in
the
OTP
and
rust
host,
and
that's
not
going
away
anytime
soon.
So
this
is
fully
backwards.
A
Compatible
is
essentially
what
I'm
saying,
as
we
continue
to
experiment
with
adding
component
model
support
and
things
like
that.
Okay,
lots
of
questions
or
lots
of
talking
time
for
questions.
Anybody
have
any
anything
I'd
like
to
ask
about
this,
or
just
kind
of
generally,
some
of
the
work
that
we
did
for
components.
A
All
right,
great,
well,
I,
really
look
forward
to
adding
more
documentation
and
examples
we're
going
to
be
sending
those
out
and
in
the
wasmo
cloud
slack
as
we
start
getting
some
of
those
done,
but
for
now
just
be
with
us
and
and
celebrating
webassembly
components.
Really
fun.
A
Taylor
I
know
that
the
other
thing
or
jordis
did
you
have
a
you.
Have
a
question
feel
free
to
happen?
Yeah.
C
So
if
you
look
and
they're
different,
if
you're
looking
at
repo
under
the
branches,
there's
a
step
for
each
branch
as
well
as
some
PRS
that
showed
the
code
changes,
see
how
we
have
start
here,
HTTP
key
value
UI
and
then,
if
you
look
at
the
pull
requests,
gotta
love
it
when
I
get
that
opening
in
an
incognito
window
bricks!
C
A
C
Yeah,
so
there
you
go,
and
then
each
of
these
has
like.
So
you
can
see
the
like
diff
of
code,
that's
added
for
each
step.
So
that
way
you
can
walk
through.
Lachlan
did
an
amazing
job
here,
putting
everything
together.
So
you
can
see
exactly
like.
What's
attitude
the
go
thing
and
the
rest
thing
to
make
it
to
follow
along
with
each
step,
so
you
start
from
basically
like
a
hello
world
to
yeah,
and
you
can
see
kind
of
the
overview
right
here.
C
So
you
can
go
from
Hello
World
to
like
a
simple
key
value
thing
to
adding
a
UI
to
a
couple,
a
couple
different
things
like
that,
so
anyone
can
follow
along
with
that.
If
you
want
to
see
what's
going
on
and
given
how
fast
component
stuff
is
working,
we
can't
guarantee
this
won't
break
within
the
next
three
weeks,
but
we
might
go
back
and
try
to
update
that
as
quick
as
we
can.
If
a
lot
of
people
are
using
it
as
a
learning
opportunity.
A
The
only
other
thing
that
I
really
want
to
show
for
for
people
who
are
looking
at
Bailey,
the
only
other
thing
that
I
want
to
show
off
or
or
at
least
highlight-
is
that
if
you
are
getting
working
with
with
webassembly-
and
you
want
to
understand,
webassembly
components
and
kind
of
the
history,
Journey
motivation,
all
those
things
I
would
highly
recommend
Luke
Wagner's
keynote
from
wasmcon.
There
are
so
many
good
ones.
Bailey
had
an
awesome
keynote
Liam
had
an
awesome
keynote.
A
I
talked,
which
was
on
Taylor
and
Bailey.
Had
an
amazing
talk
that
you
should
watch
I.
Actually,
you
know
what
we
can
go
ahead
and
show
those
off
as
well
at
least
pull
them
up.
A
Yeah,
so
here
is
the
talk
that
Taylor
did
with
Liam
component
model,
the
final
abstraction
I'm
pulling
all
these
links
from
our
awesome,
Cloud
slack
actually
in
the
in
the
general
chat,
so
I
won't
spam
and
send
them
all
here,
spaghetti
code
into
dreamy.
Fettuccine
was
it's
got
to
be
one
of
my
favorite
talks,
I
didn't
catch,
it
live,
and
so
I
saw
it
this
morning
and
I
regret
not
looking
at
it
because
it
was
so
fun.
A
My
talk,
I
had
a
lot
of
fun
with
I.
Did
some
corny
jokes?
So
you
know
you
get
to
look
forward
to
that
and
then
you
know.
Of
course
it's
always
worth
watching
a
short
and
sweet
Keynotes
that
Liam
and
Bailey
had
Wazi
standards
in
the
component
model
and
then
finally
Bailey's
keynote
around.
Are
we
componentized
yet
which
had
a
really
awesome
metaphor
for
components?
Centering
around
a
kind
of
a
metro
station,
the
wasm
component
model
Central
Station?
This
was
this
is
really
fun
all
the
talks.
A
I
was
in
Connor,
really
good.
It's
really
hard
to
try
and
recommend
some
because,
as
soon
as
you
mention
one,
you
have
like
three
more
that
you're
like
oh
well,
this
one
also
Builds
on
that
I
really
enjoyed
guy
bedford's,
componentized
JS,
talk.
A
I
know
a
lot
of
people
went
to
Dan
gomen's
Talk
on
the
Wazi
OS
again
I'm
just
going
to
end
up
naming
the
whole
schedule,
so
you
can
see
Victor's
ping
there
or
if
you
just
look
up
from
the
Linux
Foundation
YouTube
Blossom
con,
you
can
find
the
the
playlist
there's
a
group.
It
was
a
great
conference.
I
didn't
I!
A
Think
you
know,
after
going
to
a
lot
of
like
kubecon
wasm
days
or
it's
kind
of
all
jam-packed
into
a
day
and
and
you
like
it's
very
kind
of
wild,
seeing
everybody
really
quick
and
then
it's
over
I
really
enjoyed
having
two
days
to
with
multiple
tracks
and
and
all
of
that
so
huge
shout
out
to
the
organizers.
Anybody
on
the
program
committee
and
all
of
that
I
can't
speak
highly
of
it.
Enough
wow
I
got
on
a
little
tangent
there.
A
Let's
see
Taylor
I
was
gonna
actually
see
if
this
was
a
good
time
to
go
over
your
work
or
like
kind
of
updates
on
wazy
fills
because
I
think
the
discussion
or
like
going
over
the
road
map.
We
can
always
just
kind
of
do
in
the
end,
then
this
follows
into
that.
Well,.
C
C
Yes,
okay,
so
we
are
almost
there
there's
some
stuff
we
need
to
do
like
I
have
my
name
on
there
to
migrate
the
blobs
to
our
best
to
use
our
provider
SDK,
there's
actually
another
issue
that
I
think
just
opened
that
you
can
add
into
here
Brooks
from
Connor,
and
it
was
around
yeah
publishing
the
new
greats
which
we'll
need
to
do
for
everybody
to
do
this
kind
of
stuff.
So
we're
going
to
be
landing
a
few
of
those
things.
C
C
So
that's
something
that
will
get
us
there,
though,
because
of
kind
of
some
of
the
last
pieces
that
have
to
fall
into
place
in
inside
of
wit,
and
it
will
clean
up
a
lot
of
stuff
because
you
may
have
noticed
when
Brooks
was
showing
off
some
of
the
code
that
we
abstracted
away
some
of
the
grossness
of
dealing
with
the
pseudo
streams
and
pseudo
resources.
We
have
as
part
of
like
that
code,
and
so
that
should
go
away.
C
C
The
same
basic
principles
still
apply
and
then
there's
also
a
possible
issue
that
could
not
be
an
issue
that
we're
discussing
in
the
wasm,
tooling
space
and
so
I'm
working
on
getting
Wazi
fills
working
because
until
we
get
wazipills
working,
we
can't
support
custom
contracts,
which
means
we
can't
fully
deprecate
Smithy
and
all
that,
because
custom
contracts
are
core
to
the
value
prop
of
Blossom
Cloud.
So
I
am
I,
am
working
on
yeah.
C
You
can
add
it
to
the
litified
thing
there
and
so
I'm
actually
going
to
be
testing
today
to
see
if
it
works,
because
apparently
it
might
work
with
the
way
we
figured
it
out.
Well,
mostly
Bailey
and
then
I
just
helped
out
figured
out
how
to
to
get
that
working
and
then
and
then
I
will
update
from
there.
But
basically
as
soon
as
we
get,
that
kind
of
part
landed
and
then
I
have
a
concrete
thing.
C
My
wazy
bill
should
work,
we're
going
to
add
tooling,
to
make
sure
that
Wazi
bills
are
pretty
much
Auto
generated.
You
can
always
hand,
write
them
or
choose
your
own
encoding,
but
for
like
the
default
encoding
that
the
underlying
wasn't
bus
uses
and
all
those
things
we're
hoping
just
to
have
like
basically
like
a
wash
generate.
So
when
you're
writing
a
new
interface
you'll
say
like
watch
new
interface,
it's
going
to
walk
you
through,
like
creating
like
the
interface.
C
If
you
want
to
create
like
a
first
or
an
example
provider
as
well
as
creating
the
Waze
bills
for
you,
and
then
those
will
get
automatically
generated
for
almost
all
use
cases
and
like
unless
you're
using
something
Advanced.
So
that's
where
things
are
standing
out
there,
but
we're
getting
we're
getting
very,
very
close
to
having
having
those
things
like
I
said,
he's
closer
than
I
thought.
It
was
going
to
be
after
talking
at
the
at
bacon
last
week
at
the
bike
Alliance
conference.
C
It
triggered
some
discussions
there
and
it
might
work,
and
if
it
doesn't
work,
then
we
have
the
right
people
engaged
to
help
fix
it,
because
it's
definitely
a
level
that
I'm
afraid
I
would
muck
everything
up
at
if
I
tried
to
implement
it,
but
I
might
try
anyway.
This
is
comment
in
this
space,
so
anyway,
that's
where
we're
at
with
where
to
find
things
so,
as
Crooks
show,
you
can
already
do
this
with
the
core,
like
wozzi
Cloud
contract,
so
we're
working
on
making
it.
C
So
you
have
everything
you're
used
to
having
and
then
it
means
we
can
deprecate
was
our
BC.
It
means
we
can
deprecate
all
the
Smithy
stuff
and
all
those
things
once
we
get
to
that
point.
So
that's
where
we're
currently
at
with
with
the
work,
that's
kind
of
our
effort
for
the
next
month,
or
so
as
things
land
in
the
open
like
the
open
source
like
stuff
with
wasm
and
then
lands
from
there
into
Watson
Cloud
as
soon
as
we
get
it
so
yeah.
That's
where
we're
at
with
the
wit.
A
All
right,
Euros
I
see
you
had
a
couple
of
questions
in
chat:
I'm,
just
gonna.
If
you
know
when
I'm
gonna
I'm,
just
gonna,
wrap
up
at
the
the
roadmap
and
then
I
think
we
can
just
go
on
to
full
on
end
of
community
call
Q
a
because
I
I
think
you
had
a
lot
of
good
questions.
There.
A
No,
it's
great,
so
yeah
I
just
wanted
to
generally
look
at
the
the
roadmap
I'm
glad
we
pulled
this
up,
be
because
you
know
we're
taking
a
look
at
the
widify
Milestone.
You
know
a
couple
of
things
have
made
it
in
here:
I
also
filed
a
new
Milestone
just
to
start
categorizing.
A
Some
future
work
that
doesn't
it
doesn't
quite
fit
into
defining
our
interfaces,
with
wit,
specifically,
it's
more
around
support
for
all
of
the
Wazi
Cloud
core
interfaces
in
wasmcloud,
which
I
know
that
we
have
implementations
for
incoming
HTTP
and
the
key
value
for
sure.
You
know
the
things
that
we
got
working
for
or
some
of
those,
but
there
are
other
ones
in
the
Wazi
Cloud
Core
as
well.
That
will
want
to
support
around
messaging.
You
know
things
like
runtime
config,
we'll
see
where
we
get
a
blob
store
for
sure.
A
I
know
that
we
need
to
spike
a
little
bit
about.
Maybe
some
of
these
but
I
want
to
be
able
to
support
any
component,
that's
built
with
Wazi,
Cloud,
Core
and
regular
Wazi
interfaces
to
work
in
wasmo
Cloud
out
of
the
box.
That's,
of
course,
the
the
goal
here,
but
taking
a
look
at
just
the
high
level
roadmap,
we've
got
a
lot
of
I
guess
this
should
probably
be
in
triage.
A
We've
got
a
lot
of
work
that
is
in
the
now
stage.
Most
of
it
is
actually
the
majority
of
it
is
complete.
Taking
a
look
at
the
work
status.
Page
we've
got
a
ton,
that's
completed
there,
which
is
awesome.
We
are
no
longer
unblocked.
Actually,
in
fact,
I
think
this
one
is
actually
done
Bailey.
You
can
correct
me
if
I'm
wrong,
but
the
latest
version
of
wash
actually
does
launch
the
rust
host.
So
I'll
go
ahead
and
move
that
to
completed,
which
is
you
know
what?
Let's
test
our
automation
here.
A
If
we
close
this
issue
fixed
in,
where
do
we
do
this?
Thank
you
for
for
riding,
along
with
me
on
this
roadmap,
Journey
I'm,
pretty
sure
when
we
close
this
issue,
it
should
move
to
the
to
the
completed
pane
in
the
roadmap
and
I
just
want
to
make
sure
that
that
works
should
be
here
closed
in
759.
Thank
you,
Bailey
and
Connor
for
working
on
working
on
this
one
and
Roman.
So
if
we
say
that
this
one
was
closed
by
759,
we
can
close
this
issue
as
completed.
A
Look
at
that
GitHub
project
automation,
it
does
work.
So
if
we
go
back
to
our
roadmap,
we
can
see
that
that
popped
over
there
great.
So
we
have
an
RFC
which
is
open.
This
one
should
be
closed
soon,
I
think
we've
already
we've
already
proven.
The
defining
interfaces,
using
wit,
works
it's
great
and
then
in
general,
we're
going
to
be
tracking
the
supporting
the
standardized
Wazi
worlds.
A
These
are
kind
of
the
remaining,
and
this
is
a
smaller
effort,
but
these
are
the
remaining
things
we
have
in
progress
now,
which
again
I'll
Point
everybody
back
to
the
roadmap
page
on
watsoncloud.com.
It
goes
through
the
high
level
efforts
that
we
really
want
to
support
and
and
work
on
through
the
end
of
this
year,
and
if
we
finish
all
of
it,
I
guess
we'll
just
have
to
I
guess
we'll
just
have
to
come
up
with
more
work,
or
maybe
we
take
the
rest
of
the
year
off
one
of
those
things.
A
One
of
those
things
will
happen
so
very,
very
exciting
stuff.
Okay,
just
wanted
to
do
one
last
update
on
the
the
general
Watson's
Cloud
road
map.
Once
we
get
through
some
of
these
things
that
are
on
our
Now
list,
we
will
start
you
know
next
will
become
now
later
will
become
next
and
then
we'll
start,
looking
at
more
more
things
to
do,
which
is
which
is
really
exciting.
A
Great,
a
huge
shout
out
to
everyone
on
the
walzemgo
Team,
everyone
who
has
contributed
to
wasm5
over
the
past
well
forever,
but
especially
last
couple
of
months
as
we're
working
towards
this
Milestone,
really
fun,
stuff
I
think
now
is
probably
a
good
time
just
to
open
it
up
generally.
For
for
any
questions,
I
know,
yordis
has
thrown
a
few
things
into
the
queue
which
I
think
are
going
to
be
great
discussion
points,
which
is
why
I
want
to
leave
some
time.
A
Theortis,
do
you
have
any
questions
that
you
want
to
talk
about
here?
If
it's
just
notes
that
that
is
totally
all
good,
but.
B
D
So
there's
lots
of
places
and
it
depends
at
what
level
you
want
to
talk
about.
There's
the
Watson
Cloud
level
right
so
I
feel
like
we're
like
at
the
top
of
this
pyramid.
So
we
have
some
of
our
Watson
Cloud
specific
interfaces,
but
there
aren't
many
they're,
pretty
that's
a
small
set
and
that's
why
I
think
of
it.
D
As
almost
like
a
pyramid
moving
down
there's
another
area
which
is
the
bicode
alliance
organization
and
inside
there
there
are
only
a
few
that
are
not
part
of
wazzy,
so
the
one
that
I'm
thinking
of
right
now
is
wazzy
vert,
but
I.
D
Think
probably
your
your
question
is
actually
about
the
meetings
that
we're
having
within
the
bytecode
alliance,
where
Taylor
has
been
bouncing
back
and
forth,
for
example,
in
that
issue,
with
Peter
and
Alex,
coming
up
with
the
right
solution
for
how
to
design
our
wazzy
fill,
and
so
that
issue
has
a
lot
of
good
context
there
and
we
talk
about
it.
A
lot
in
our
opponent
model,
bi-weekly,
is,
is
one
place,
the
place
that
they're
standardized
at
is
inside
the
webassembly
organization.
D
So
there's
the
wazzy
working
group,
which
I'm
a
co-chair
of
and
where
that's,
where
we're
talking
about
the
lazy,
Cloud,
Core
yzcli
and
the
yazih
TV
proxy
world,
and
so
those
are
the
ones
that
we
basically
just
demoed
with
a
lot
of
their
design
is
happening
basically
in
issues
for
each
one
of
their
repos
each
one
of
those
that
I
just
named
all
have
their
own
repo
inside
the
web
assembly
GitHub
org,
and
then
we
have
a
bi-weekly
meeting
for
wazzy,
where
we
we
don't
usually
have
discussion.
D
Necessarily
in
those
meetings.
It
usually
happens,
asynchronously
over
tickets-
that
was
probably
too
much
information,
but
there
it
is.
B
I'm
taking
notes,
you
know,
I
I'm,
creating
a
backyard
of
notes
about
it
so
like
following
up
to
that,
because
I
was
focusing
more
in
the
wasum
cloud
perspective
yeah.
So
so
it
will
be
more
from
the
awesome
cloud
like
you
know
where
how
how
somebody's
supposed
to
open
up
the
conversation,
how
to
go
about
it.
You
know,
where
is
the
process
around
the
awesome,
Cloud
level
of
width,
design.
D
I
think
this
meeting
is
a
good
one
for
Slack
we've
been
pairing
up
trying
to
work
through
and
make
make
it
work
first,
you
know,
but
I
I,
imagine
almost
all
of
it'll
happen
ever
Slack.
Thank
you.
A
Yeah
I
I
anticipate.
So
if,
if
you're
in
the
the
wasn't
God
slack,
which
just
general
call
out
for
anybody
who's
tuning
in
later,
you
can
always
come
and
join
us
in
slack
at
slack.wassenflod.com.
The
link
is
at
the
bottom
of
the
website.
A
We
have
many
different
channels
there,
and
that
includes
I,
don't
want
to
Silo
any
discussion
to
to
stifle
discussion,
but
we
do
have
a.
We
have
a
wasm
cloud
Channel
and
we
also
have
a
webassembly
channel
and
I
know
on
my
end,
I'm
trying
to
be
intentional
about
posting
things
that
you
know
go
around
the
development
of
webassembly
Standards
or
you
know,
updates
there
I
think.
A
A
A
I
see
that
you
also
had
a
question
around
the
the
washboard,
the
new
I
assume
you're,
talking
about
the
new
wasm
Cloud
dashboard.
B
Yeah
yeah
yeah
I
mean
I
I've
been
messing
around
with
with
the
front
end
part
of
it.
So
you
know
I've
been
just
trying
to
figure
out
what
what
you're
envisioning
in
the
future,
because
what
I'm
doing
more,
unless
it's
just
changing
the
the
UI
perspective
of
it
I'm
having
more
like
a
psych
sidebar
layout,
so
you
can
actually
scale
adding
functionalities
in
the
sidebar
in
the
future
right
and
clean
it
up.
B
Maybe
you
know
thinking
about
the
user
experience
that
you're
envisioning
instead
of
having
everything
to
be
just
one
page.
Maybe
that's
that's
the
the
vision
but
yeah
so.
C
Yeah
well,
if
only
we
had
a
maintainer
here,
Lachlan
I,
don't
know
if
you're
available
Lachlan
but
I'm
assuming
you
can
give
insight
to
what
you
were
doing.
B
B
Yeah
I
guess
I'm,
asking
for
permission,
I'm
trying
to
actually
be
aligned
with
you
all,
because
I'm
messing
around
and
I
have
sometimes
but
I
don't
want
to
be.
You
know,
like
neither
cause
you
problem
or
you
know
going
in
a
direction
that
definitely
you
did
an
Envision
which
thus
far
it
seems
that
I
am
in
line
with
I.
Don't
know
how
to
pronounce
his
name.
Larkland
yeah.
A
I
think
you
got
it,
you
gotta
agree
well,
yeah,
yeah,
I.
Think
the
core
of
this
discussion
is
what
the
washboard
is
meant
to
be
like
what
is
the
responsibility
of
the
project
and
I
think
at
its
core
and
the
functionality
that
it
implements
now
is
kind
of
a
not
necessarily
observability
in
like
the
open,
Telemetry
sense.
But
you
can
observe
the
state
of
the
lattice.
You
can
see
What
actors
and
providers
and
Link
definitions
exist,
and
you
can
do
that
on.
A
Multiple
hosts,
I
think
an
extension
of
that
which
I
would
love
for
the
washboard
to
be
able
to
do
is
act
as
another
control
interface
client
to
be
able
to
issue
commands
things
like
hey
go
start.
This
actor
go
delete
this
provider,
things
like
that,
and
we've
had
discussions
in
the
past
about
the
washboard
being
user.
Extensible
I
would
definitely
need
a
little
expertise
or
some
somebody
who
is
well
versed
in
in
that.
A
You
know
help
me
understand
like
if
you
come
into
the
washboard
and
not
necessarily
contributing
to
the
core
code
per
se,
but,
like
you
wanted
to
add,
like
a
visualization
to
show
you
know
how
many
actors
have
been
running
over
time.
Something
like
that.
That's
a
neat
idea.
I
think
it
certainly
falls
out
of
the
MVP
of
what
the
washboard
is,
which
is
what
it
is
now
but
I'll
stop
talking
before
I
need
to
say
anything,
wild
Lachlan
did
you
have
more
more
thoughts.
E
Yeah
no
I'm,
sorry
I
was
not
in
the
room,
the
what
Brooks
said
is
exactly
it.
It's
it's
we're
determining
what
the
purpose
is
for
it
and
we're
never
against
good
ideas.
More
than
happy
to
take
contributions
for
it.
E
The
washboard
as
it
is
right
now
is
a
half
replacement
for
the
one
that
was
coupled
with
the
Elixir
host.
So
we
because
we
transitioned
to
rust,
we
needed
another
one.
So
you've
read
that
RFD,
so
it
doesn't
do
some
of
the
things
that
the
existing
one
did
and
I
believe
that
that's
mentioned
in
the
the
pr
that
that
got
this
one
across
the
line.
E
It's
yeah
close,
not
not
necessarily
be
compatible
with,
because
there's
things
that
the
old
one
can
do
that
the
new
one
won't
necessarily
be
able
to,
but
there's
more
details
on
that
in
the
in
the
PR,
but
basically
because
the
existing
one
was
coupled
with
the
host,
you
could
do
things
like
upload
a
file
directly
to
the
host,
whereas
now
because
it's
sort
of
detached
it
is
its
own
thing.
Those
that
that
feature
would
mean
that
we'd
need
to
get
a
way
to
get
the
file.
E
The
bytes
of
the
actor
and
provider
across
to
the
host
over
Nats
and
that's
not
something
that's
possible
just
yet
yeah.
That's
a
good
question!
Victor!
What's
a
good
way
to
run
the
old
UI
I
believe
the
best
way
is
to
do
wash
up
and
specify
a
version
which
would
be
63.
F
E
Be
the
version
that
did
and
yeah
we
did
have
a
slightly
different
design.
We
were
just
trying
to
one
get
something
across
the
line
quickly.
It
was
a
week-long
project
if
that
that
sort
of
made
that
happen
and
to
think
about
the
things
that
people
are
going
to
be
doing
with
a
washboard
like
with
that
UI
versus
just
the
regular
CLI.
So
if
you've
got
thoughts
and
patterns
and
ideas
that
you
want
to
implement
more
than
happy
to
see
a
PR
for
it
and
we
can
work
together
on
getting
that
implemented.
B
Okay,
cool
yeah
I
mean
for
me,
I
was
just
like
I
said
just
trying
to
focus
on
a
psych
bar
layout
that
you,
you
can
scale
it
in
regards
of
really
how
high
level
capabilities
and
then
in
in
in
the
in
the
section
that
would
change
per
one
of
those
menu
the
same
year.
Thinking
about
it
horizontally
how
to
scale
as
well
kind
of
like
Argo
CD.
B
E
B
E
If
we
find
more
stuff
the
stuff
in
a
sidebar,
then
better
to
have
the
place
to
do
it
than
not
need
it,
yeah
I
agreed
with
Victor
mock-ups
and
thoughts
on
what
you
would
want
it
to
look
like,
even
if
it's
just
like
a
a
code
pen
that
has
an
example
of
what
you
would
want
it
to
look
like,
because
I
think
you
can
run
it
even
without
having
the
the
connected
to
the
lattice.
You
can
still
at
least
run
the
front
end
and
see
what
it
looks
like
it.
A
I'm
gonna
go
in
actually
and
create
a
milestone,
trying
to
use
all
the
GitHub
things
I'm
going
to
create
a
milestone
in
the
wash
repository
around
I.
Think
I'll
call
it
washboard
the
stable
release,
I'm
bad
at
naming.
But
right
now
you
know
the
washboard
is
behind
the
experimental
flag.
A
I
feel
very
pew
pew
pew
about
adding
new
features
to
it
and
experimenting
there,
because
it
is
behind
the
experimental
flag,
but
I
would
love
to
make
that
be
something
that
we
release
is
well,
not
experimental
and
stable,
and
so
I
think
the
washboard
first
wave
I
think
it'd
be
great
to
have
a
a
little
bit
of
a
design
doc.
Nothing
crazy!
A
Just
like
a
an
issue
to
track
like
what
exactly
we
would
want
it
to
like
what
we
want,
the
washboard
to
look
like
and
and
the
functionality
that
we
wanted
to
have
to
bring
it
out
of
experimental
and
that'll
really
help
with
just
putting
that
in
a
central
place.
Does
that
sound
like
a
good
idea?
Lachlan
theortis,
everybody
else
in
the
washboard.
A
Well,
I
will
call
it
yeah
I'll
create
an
issue
there
and
then
I
might
just
ask
for
washboard.
C
First
wave
is
totally
my
totally
my
vote.
A
Washboard
first
wave
it
is
cool
because
I
I
want
to
you
know:
I
want
to
keep
adding
to
the
to
the
washboard.
Now.
B
Yeah
the
the
last
question.
I
have
sorry
the
last
question
I
have
is
related
to
what's
on
cloud
itself.
I
think
is
like
when,
when
somebody
is
developing
actors
and
capabilities
whatever,
like
my
oh
actually,
the
actors
like
where,
where
do
I
put
okay
in
a
pipeline
and
ignore
the
assembly
for
now,
because
I,
don't
know
how
to
explain
this
like
I,
can
either
make
my
functions
aware
of
vloggers
telemetries,
all
the
stuff
or
I
just
wrap
my
function
in
those
things
and
I
lower
level
in
the
infrastructure,
or
something
like
that.
B
So
wants
me
to
do
when
I'm
implementing
doctors,
the
awesome
club
want
me
to
define
those
dependencies
and
I
have
control
over
and
I
have
to
wrap
it
or
in
the
long
term.
Do
was
on
cloud
wants
me
to
say:
hey,
don't
think
too
much
about
this
type
of
quote-unquote
infrastructure,
because
sometimes
it's
gonna
leak
into
the
into
your
actors.
So
instead
of
this
infrastructure
concerns
because
we're
gonna
wrap
your
components.
C
So
there's
two
views
here
as
it
stands
right
now
in
the
host
you
get
every
single
call
instrumented
if
you've
turned
on
open
Telemetry,
so
you
know
anything
that
goes
into
your
module
and
then
out
of
your
module.
If
you
want
it
to
be
that
way
so,
like
that,
that's
all
available
to
you.
C
If
you
want
to
be
like
instrumenting
specific
functions
on
the
inside,
we
don't
have
a
plan
for
the
that
yet,
but
that's
the
kind
of
thing
we're
in
the
future
I
see
us
possibly
doing
something
where
oh,
hey,
here's
a
here's,
an
instrumentation
like
component,
you
can
have
you
can
pull
in
like
an
instrumentation
contract
of
some
kind
that
might
be
standardized
across
most
of
the
industry.
Those
are
the
kinds
of
things
where
we
could
wrap
it,
and-
and
the
thing
is,
is
because
of
the
idea
of
being
able
to
layer
it.
C
You
could
technically
wrap
any
call
you
want
to.
So
if
you
have
like
your
cool
contract,
you
could
have
a
thing
that
exports
your
cool
contract
and
just
passes
it
through
to
the
next
thing
that
does
your
cool
contract,
but
then
add
some
instrumentation
around
it.
So
all
that
is
entirely
doable
in
the
future,
but
like
right
now,
it's
it's
entirely
in
the
host
and
you'll
know
when
things
are
called
and
because
of
the
underlying
like
wasimbus
protocol,
you
have
the
idea
of
what
methods
it's
calling
as
well.
B
Right,
I'm,
assuming
the
same
for
I
I'm,
not
going
to
use
I,
think
in
like
I'm,
assuming
that
you're
gonna
apply,
add
capability
to
add
filters
to
those
pipelining
right
because
I'm
thinking
in
loggers
open,
Telemetry,
Auto,
recession
or
authentication
stuff
like
that,
like
you
know
all
the
things
that
normally
you
may
want
in
a
in
the
pipeline.
But
not
necessarily,
you
know
complected
with
the
code
but
more
like
around
it
or
composed
with
it.
A
Yeah
did
that
answer
your
question
all
the
way
yours
is
there?
Did
you
ever
follow
up
yeah.
B
A
Yeah
any
high
level
feedback
when
it
comes
to
how
it
feels
to
build
an
app
with
wasmcloud
is,
is
super
helpful
because
I
I
think
the
end
goal
is
that
whenever
you
work
with
wasmcloud,
you
are
thinking
primarily
about
just
the
functional
logic
of
your
application
and
anytime
that
you,
you
stray
into
non-functional
requirements
or
if
you
feel
like
you're,
building
that
into
your
application,
then
that
kind
of
raises
a
flag
to
think
you
know.
Could
we
could
we
be
doing
this
in
a
better
way?
You
know
with
our
whole
philosophy,
yeah.
B
A
What's
the
right
way
to
say
this,
this
speaks
to
the
idea
of
capability
abstraction
when,
when
you
start
to
when
you
try
to
boil
down
a
capability
into
an
individual
interface
or
a
common
abstraction
that
could
be
fit
by
multiple
patterns
or
implementations,
you
have
to
do
that
essentially
with
the
lowest
common
denominator.
View
HTTP.
It's
actually
really
easy.
It's
nice
just
take
issue
to
be
requests,
return,
HTTP,
response
right,
but
then,
when
it
comes
to
event,
sourcing
or
data
pipelining
or
interactions
with
a
database,
you
you
can
have.
A
You
know
kind
of
the
thing
that
you're
talking
about
here.
You
ordis
like
with
Ecto
I,
forget
the
exact
thing
you
said
like
create
multi
or
multi-command
when
you
start
to
leverage
really
specific
functionality
or
look
for
something
that
you've
used
in
a
framework
specifically
before
and
find
that
missing
from
the
thank
you
from
the
interface
it
can
feel
like.
A
You
know
that
can
feel
strange
and
really
I
think
what
this
comes
down
to
is
the
implementation
details.
Here
you
know
using
a
capability
provider
for
the
event
sourcing
capability
like
concordance
is
going
to
have
you
know,
every
implementation
is
going
to
have
its
own
way
of
doing
things
and
the
advice
that
I've
always
given,
which
I
think
is
always
worth
examining.
If
it's
the
right
answer,
is
the
more
specific
your
contract
gets,
the
less
you
end
up
benefiting
from
the
abstraction
that
you
get
from
like
hey.
A
This
could
work
with
any
event
sourcing
provider,
and
it
may
just
mean
that
you
know
this
is
the
time
where
your
contract
is
tightly
coupled
to
your
requirements
and
that's
that's
okay,
using
the
contract.
In
this
way,
you
still
actually
do
get
the
benefit
of
being
able
to
hot,
swap
that
capability
provider
out
like
if
there
was
a
bug
or
or
a
vulnerability,
you
can
still
hot
swap
it
out
with
a
new
version.
A
You
just
won't
be
able
to
change
to
any
event
sourcing
capability
provider,
for
example,
and
that
can
be
okay
once
your
application
gets
specific
enough
that
you
have
those
requirements,
then
that's
that's
the
guidelines
that
I've
always
kind
of
given
for
that
specific
part
know
that
might
be,
might
not
be
the
the
best
answer.
Sometimes
you
know
for
people
who
want
to
have
you
know
something?
That's
that's
TurnKey
I'll,
definitely
look
to
Kevin
for
any
specific
advice
around.
You
know.
A
If
this
is
like
a
you
know,
something
that
we
can
optimize
within
concordance,
but
it
sounds
like
kind
of
a
new
operation
and
it
might
worth
it
might
be
worth
like
design
spiking
around
around
that,
for
example,.
D
B
Yeah
I
think
it
for
me,
it's
kind
of
like
I'm
chasing
that
wrong
key,
like
you
don't
care
too
much
about
it
like.
Let
me
remove
as
much
as
I
can
from
your
user
space
relying
on
Frameworks
or
something
like
that,
because
then
I
had
to
implement
it
in
every
single
programming
language
for
you
to
achieve.
You
know,
feel
the
exact
same
way
so
I'm
trying
to
avoid
that,
but
I
think
I'm
getting
into
you
guys.
A
Let's
see
the
I'll
need
to
review
the
event
sourcing
contract
to
see
everything
that
it
does,
but
I
remember
right.
It
essentially
has
very
nice
high
level
abstractions
around
handle
command,
handle
event.
Things
like
that,
and
so
I
know
that
from
the
handle
command
function,
you
can
return
multiple.
A
B
Is
it
no?
No
because,
like
sometimes
you
want
to
generate
an
event
based
on
whatever
the
state
of
the
aggregate
is
in
the
Saxon
command
Handler.
So
basically,
you
have
to
be
like
enqueued
even
applied
event
to
the
aggregate.
Then
do
the
next
operation,
because
that
application
on
that
event
would
evolve
the
aggregate
into
an
estate
and
then
you're
going
to
make
assumptions
about
it.
So
that's
right
the
way.
Commanded.
Those
is
like
something
like
Ecto,
where
you
create
a
multi
which
basically
just
a
data
structure
that
eventually
will
get
run
behind
the
theme.
B
F
Yeah
command.
That
actually
does
it
the
same
way.
We
do
it
I,
actually
modeled
the
concordance
one
after
the
commanded
Library.
So
with
commanded,
you
can
do
a
multi,
but
that
multi
is
based
on
the
state
prior
to
the
receipt
of
the
command
and
that's
exactly
what
concordance
does
so.
The
aggregate
receives
a
command
and
the
state
which
are
tightly
coupled,
and
so
it
receives
the
command
in
the
state.
F
You
then
return
one
zero
or
more
events
in
response
to
that,
and
then
that
same
aggregate
will
at
some
later
point
in
time,
be
delivered
that
event
and
its
state
and
there's
a
bunch
of
reasoning
behind
it,
but
the
the
blog
post,
where
I
talk
about
how
commands
aren't
real,
does
a
bit
of
explanation
in
terms
of
why
the
the
events
come
out
of
the
aggregate.
The
way
they
do,
but
yeah
short
version
is
that
the
commanded
multi
is
essentially
the
same
thing
as
concordance
returning
a
vector,
but
that's.
A
B
A
I
think
that
sounds
that
sounds
good
and
I
guess
the
worst
and
best
outcome
of
this
is
just
additional
documentation
around
the
the
way
that
concordance
does
things
I
really
actually
like
the
idea
of
event.
Sourcing
is
so
opinionated
and
specific
I
I,
really
like
the
idea
of
taking.
You
know
the
way
that
we're
implementing
it
with
Concordance
and
pointing
it
to
similar
Frameworks
to
say,
like
this,
has
very
similar
side
effects
and
implementation
details,
as
this
were
inspired
by
blah.
You
know
things
like
that,
so
thank
you.
A
All
right,
everyone
well
I,
think
that
this
was
some.
This
was
some
awesome
discussion.
I
know,
there's
going
to
be
a
couple
of
follow-up
things
in
slack,
I
put
the
link
to
the
wash
milestone
in
the
washboard
channel,
which
we
do
have
very
fun.
A
I
think
there's
going
to
be
a
little
bit
more
on
event,
sourcing
things
like
that.
Thank
you.
Everyone
who
is
here
for
dealing
with
the
whole
recording
thing,
I'm,
probably
gonna,
take
this
video
and
try
to
re-live
stream.
A
It
later
today,
just
to
kind
of
get
the
same
effect,
because
I
actually
scheduled
this
when
I
was
on
the
west
coast,
and
so
it
says
that
the
community
meeting
is
going
to
be
at
4
pm
today,
so
I
might
have
accidentally
covered
my
own
butt,
we're
just
gonna
stream
it
a
little
bit
later,
so
we'll
I'll
take
that
for
what
it
is.
But
thank
you
everyone
for
coming
great
to
be
back
and
looking
for.