►
From YouTube: wasmCloud: ssh Go Provider Demo, Blobstore Demo, WASI Support PR, wash 0.12.0 - 09/14/22
Description
wasmCloud is a platform for writing portable business logic that can run anywhere from the edge to the cloud, that boasts a secure-by-default, boilerplate-free developer experience with rapid feedback loop.
https://wasmcloud.com
A
B
Yeah
I
have
no
promises.
This
actually
works,
so
yeah
diving
down
further
into
the
world
of
go
providers.
There
was
like
when
I
first
heard,
like
thought
about
like
or
heard
about,
wasn't
cloud
and
wrapped
my
brain
around
it.
This
was
like
the
one
demo
wanted
to
do,
and
it's
not
ready
for
prime
time
because
it's
a
little
wonky,
but
it's
definitely
good
enough
to
demo.
B
Okay,
so
what
I've
done
is
essentially
created
a
provider
which
provides
an
SSH
connection
into
a
chat,
client
and
I
have
Monster
over
here
on
my
local
machine
and
derp
man
over
here
on
my
remote
machine
and
it's
pretty
much
just
an
interactive
chat.
This
right
window
is
supposed
to
be
a
user
window.
B
You
know
we
Holy
Trinity
there
I
I've
gone
and
I've
I've
I've,
taken
the
core,
tiny,
go
module
or
core
tinago
code
and
turn
it
into
a
module
and
then
also
at
the
same
time,
the
tiny
go
actor
code
and
or
so
yeah
sorry,
the
wasm
actor
code
and
the
wasm
provider
code
both
made
them
into
sdks
for
writing,
go
things.
So
there
was
a.
There
was
a
little
thing
there
was
code
had
to
move
around.
B
So
I,
I've
massaged
the
core.
You
know
the
core
interface
and
that's
not
so
don't
worry
about
that
and
also
the
actor
code
that
is
not
on
GitHub,
yet
the
Cloud
actor
Library
I've
massaged
a
little
bit
so
I'm
excited
I'm,
hoping
to
open
a
bunch
of
PR's,
get
a
bunch
of
reviews
from
a
lot
of
people
here
shortly
and
yeah
hopefully
make
you
know,
kick
rust
out,
I'm,
joking
everyone
and
yeah.
They
go
more
enjoyable
experience
in
awesome
club.
That's
really
it.
A
B
Yeah,
so
the
the
service
it's
providing
is
the
SSH
service
and
then
right
now,
because
of
some
of
the
limitations
with
the
go
actors,
I
think
Kevin's
Wazi
support
will
actually
take
a
lot
of
us
away,
I'm,
actually
building
the
the
terminal
interface
on
the
provider.
Side.
I
want
to
move
that
to
the
actor
side,
because
it's
really
just
string
manipulation
in
the
end
and
then
a
stream
gets
sent
over
in
the
in
the
engine.
Just
displays
it.
B
So,
ultimately,
what
I
want
it
to
be
is
a
is
a
SSH
terminal
provider
that
the
actors
can
actually
control
right
now
the
providers
I
think
doing
a
little
too
much
work
but
yeah.
So
the
actor
itself
is
what's
connecting
the
providers
to
the
to
the
Nats
messaging
system,
where
the
message
is
kind
of
live.
A
A
B
A
Cool
yeah
I'm,
really
looking
forward
to
those
PRS,
because
the
kind
of
stuff
that
you've
been
able
to
do
with
go
providers
is,
is
really
sweet
and
having
tiny,
go
and
go.
Support
and
and
rest
support,
for
both
things
is
is,
would
be
really
really
nice
that
captures
a
large
large
audience
of
people
who
are
writing
things
on
the
server
side.
Anyways.
A
A
All
right,
thank
you.
Jordan
I
think
we
can
I
think
we'll
move
on
I
actually
have
a
demo
that
you
all
kind
of
got
a
sneak
preview
for
before,
but
I
wanted
to
show
off
the
animal
image
generator
actor.
That
I
wrote
the
other
day
in
a
little
bit
a
little
bit
more
detail,
so
hopefully
we're
on
the
right
desktop
here.
A
What
I
was
actually
working
on
is
making
sure
that
when
we
came
into
our
actor
examples
that
we
had
an
example
that
used
all
of
the
different
or
at
least
an
example
that
used
each
capability
that
we
have
out
there
and
so
I
was
thinking
of
what
I
could
do
for
a
blob
store.
I
already
had
kind
of
worked
on
something
that
fetches
a
random
cat
or
dog
image
and
I
just
adopted
that
too.
Instead
of
fetching
it
and
returning
it
as
an
HTTP
response,
it
will
store
that
image
on
disk.
A
So
this
actor
needs
the
ability
to
make
HTTP
requests
receive
messages.
I
could
have
done
this
with
an
HTTP
server
capability,
but
I
thought
it'd
be
nice
to
mix
and
match
them
a
little
bit
and
the
blob
store
capability
so
that
it
can
actually
save
that
image
to
disk
and
there's
instructions
here
for
for
running
it.
This
is
actually.
This
is
a
PR
into
the
examples
repo
right
now,
but
the
code
itself
isn't
actually
to
all
it's
not
all
that
complicated
in
we
receive
a
message.
A
We
make
an
HTTP
request
to
download
an
actual
animal
picture
depending
on
if
it's,
if
you
ask
for
a
cat
or
a
dog
picture,
it'll
it'll
ping,
a
different
like
open,
free,
API
endpoint
for
that,
and
then
we
just
store
that
animal
picture
in
a
blob
store.
That's
what
this
put
object
requests,
but
since
we're
storing
it
in
a
container
which
could
be
like
a
folder
or
a
bucket,
you
know
I
created
the
container
ahead
of
time,
and
then
we
just
reply
and
we
say
Enjoy
your
your
picture,
but
that's
it.
A
This
is.
This
is
all
the
code
that
you're
actually
gonna
see,
and
this
is
all
in
our
examples,
repo.
So
not
not
anything!
You
can't
take
a
look
at,
but
what
I
actually
I
came
in
a
little
ahead
of
time
and
I
did
a
I
I
started
a
couple
things
and
linked
a
few
actors
together,
or
this
downloader
actor
to
http,
client
and
in
messaging?
A
A
The
way
the
local
file
system
blob,
store,
works,
you
give
it
a
file
route
and
it'll
store
things
under
the
actor
ID
and
then,
whatever
container
or
anything
that
you
have
set
up
so
I'm,
going
to
link
the
image
downloader
to
The
Blob
store
file
system
provider.
We
just
provide
the
blob
store
contract
and
then
you
just
have
to
give
it
a
root
which
I
have
specified
as
like
my
temp
directory.
A
So
as
soon
as
you
do
that
you
can
actually
come
in
and
we
can
send
a
Nats
message
we're
you
know,
a
pub
would
work
fine,
but
we
can
send
a
request
as
well
say:
hey
I
want
to
get
a
dog
picture,
so
you
asked
for
a
dog
picture:
it'll
create
this
container,
the
Brooks
demo,
animal
picks,
and
look
at
that.
We
got
a
dog,
it's
pretty
nice.
We
can
do
it
again.
This
is
actually
a
pretty
naive
implementation.
It
just
kind
of
overwrites
the
same
file
over
and
over.
A
We
can
also
ask
for
a
cat
instead
and
that
will
give
us
a
a
picture
of
a
cat
or
if
we
provide
something
that
the
actor
doesn't
know
how
to
parse.
We
get
a
very
reasonable
default,
a
porg
just
in
just
in
case.
You
know
you
send
some
garbage
input,
so
this
is
cool.
I
had
a
lot
of
fun.
Writing
this.
It's
really
neat
to
just
kind
of
go
through
the
motions
of
like
writing.
A
But
just
you
know,
it's
you
hack
around,
sometimes
and,
and
you
find
out,
I
was
thinking
that
we
could
actually
hot
swap
while
everything
is
running
without
changing
any
code
to
the
S3
provider.
So,
if
I
delete
the
blob
store,
link
from
animal
image,
downloader
I
can
relink
that
with
the
S3
provider
and
the
only
thing
that
the
blob
store,
the
the
S3
provider
needs.
Is
your
AWS
credentials
to
actually
talk
to
AWS
store
things
in
S3.
Things
like
that.
I
am
doing
this
in
a
way
that
is
a
little
more
I
guess.
A
A
demo
safe
I
have
like
an
environment
variable
file
in
My,
Demo
directory
called
aws.enb.
That
has
my
credentials
in
it.
So,
basically,
when
we
create
this
link
definition,
the
things
that
we
need
at
runtime
are
the
AWS
credentials.
So
we
can
swap
out
the
link
for
the
AWS
blob
store
and,
if
I
take
a
look
at
my
little
bucket
that
I
have
here,
I
created
it
ahead
of
time.
The
actor
is
like
resilient
enough
to
create
a
bucket
too,
but
just
to
make
it
easy.
You
gotta,
like
type
in
all
this
stuff.
A
A
So,
when
I
run,
this
I
can
link
it
to
the
file
system
when
I
try
to
generate
an
image.
It'll
save
that
to
my
local
disk.
But
then,
when
I
delete
that
link
and
I
instead
link
the
the
actor
to
the
S3
provider,
everything
works.
The
same
I
didn't
have
to
change
or
redeploy
anything
it's
just
when
I
go
to
put
the
object
instead
of
putting
it
on
the
local
file
system
you
put
in
S3
instead,
which
is
is
pretty
sweet.
A
A
I
wanted
to
show
that
off,
because
it's
a
fun
example
who
doesn't
like
looking
at
dogs
and
cats-
and
it's
also
a
very,
very
practical.
Hopefully
you
can
see
some
of
the
ways
that
swapping
capabilities
can
make
like
the
transition
from
Dev
to
production,
easier,
that's
kind
of
what
I
just
did
I
was
working
with
local
files,
and
then
you
know,
then
I
went
up
to
AWS
where
things
would
be
running
in
the
cloud
or
just
makes
things
easier
for
people
who
want
to
change
their
implementation.
A
A
C
Are
you
you
know,
I
think
I,
think
other
people,
though,
like
when
I
think
about
some
of
this
new
to
wasm
Cloud?
How
do
you
tell
that
story?
I
mean
you
know,
do
you
use
this
like
you
know
what,
if
moving
from
your
desktop
to
the
cloud
or
is
the
easy,
is
changing
a
variable
or
you
know
I
mean
like
how
do
you
explain
this
idea?
Do
you
think
to
others.
A
A
A
Yeah
there
there's
plenty
other
ways
that
we
can
kind
of
extend
this
demo
or
things
like
this.
You
know
things
that,
excuse
me
sorry,
John
I
just
saw
your
question.
That
example
is
actually
in
it's
in
a
PR
right
now
going
into
our
examples,
repo,
but
should
be
able
to
you'll
be
able
to
take
a
look
at
all
the
code
and
what
it
looks
like
all
right,
I
forgot
the
track
that
I
was
going
on
originally.
Oh,
you
know.
A
This
is
just
one
example
of
how
you
can
hot
swap
capability
providers
to
do
different
things
and
I
think
that
showing
finding
some
examples
where
the
difference
between
development
and
production
is
is
massive
and
causes.
A
lot
of
pain
gives
us
a
good
opportunity
to
show
off
why
this
is
so
so
powerful
and
so
cool.
A
Cool
well
thanks
thanks,
everybody
that
was
I
had
a
lot
of
fun,
putting
that
together
and
looking
forward
to
doing
more
with
it
now
for
the.
Unless
anybody
has
another
demo
that
they
didn't.
Let
me
know
about.
We
can
move
on
to
kind
of
the
wasmcloud
community,
section
things
that
are
happening
in
our
ecosystem
and
the
first
one
that
I'd
love
to
talk
about.
Is
this
PR
that
Kevin
put
out
on
a
on
a
Monday
that
had
me
like
spit
out
my
coffee
for
Wazi
support?
Kevin?
D
Yeah
sure
the
main
thing
that
I
was
trying
to
fix
was
a
lot
of
times,
especially
if
you're
using
go.
It's
really
easy
to
sort
of
accidentally
produce
a
wazzy
module
instead
of
a
freestanding
webassembly
module,
and
so
the
first
thing
I
wanted
to
do
was
just
make
it
so
that
the
Watson
Cloud
host
is
more
tolerant.
D
The
next
thing
is
that
there's
a
lot
of
a
lot
of
code
and
a
lot
of
libraries
that
you
compile
and
again
we're
not
trying
to
point
a
finger
at
go,
but
it
tends
to
happen
more
often
there,
because
the
you
know
the
web
assembly
support
has
just
been
a
little
bit
further
behind
rust.
So
you
know
what
will
happen?
D
So
the
other
thing
I
wanted
to
do
is
make
it
so
that
if
you
do
have
some
simple
code
that
emits
to
you
know
the
standard
I
o
stuff,
that
that'll
also
work
in
in
the
pr
right
now,
if
you
admit
to
standard
error,
standard
out,
that'll
essentially
Go
off
into
the
void,
and
we
don't
do
anything
with
it.
Yet,
once
this
is
merged,
there
will
be
a
another
PR
coming
very
shortly.
Thereafter
that
actually
uses
those
pipes
to
emit
the
stuff
from
your
webassembly
module
into
our
logs
and
that'll.
D
Also
go
that'll
even
be
compatible
with
our
open
Telemetry
stuff.
So
the
text
messages
that
your
actors
emit
from
Wazi
will
actually
make
it
through
to
the
distributed
tracing
stuff,
so
that'll
be
that'll,
be
coming
shortly
after
in
the
so
for
the
near
term.
What
it
means
is
that
your
stuff
isn't
going
to
break
and
then
we're
just
gradually
going
to
add
more
and
more
features
that
leverage
some
of
the
wazzy
stuff.
D
I
guess
there's
only
one
other
thing
I
wanted
to
mention
which
is
sort
of
a
security
concern
if
you've,
if
you've
done
some
work
with
YZ
before
you
know
that
you
can
read
from
the
file
system
and
you
can
read
environment
variables
and
you
can
examine
arguments
for
security
reasons
in
wasm
Cloud,
the
the
wazzy
based
file
system
is
empty.
There
are
no
arguments
and
there
are
no
environment
variables.
D
A
Do
we
know?
Is
that
a
specific
import,
the
the
goal
that
I'm
thinking
of
is?
If
somebody
tries
to
fetch
a
file
using
Wazi,
you
know
we
would
like,
ideally
we'd,
be
able
to
tell
them
hey.
You
know
this
isn't
working
awesome
Cloud!
You
should
use
this
file
system
provider
instead
or
something
like
that.
D
Yeah,
so
the
the
way
Wazi
file
system
works
is
that
the
file
system
is
essentially
virtualized
and
snapshotted
on
its
way
into
wazzy
when
the
engine
starts.
So
if
you've
used
like
the
while
some
time,
CLI
to
run
wazzy
modules
that
read
from
files
you'll
know
that
you
need
to
basically
point
that
CLI
at
a
directory
in
order
to
add
those
files.
D
What
it
really
means
is
where
is
he
doesn't
wazzy
modules?
Don't
actually
have
access
to
the
file
system?
What
they
have
access
to
is
a
virtual
file
system,
that's
populated
at
modulestart,
so
the
net
effect
of
the
wasm
cloud
security
is
that
your
virtual
file
system
has
no
files
on
it.
So
you
won't
panic
when
attempting
to
access
the
file
system,
but
you'll
get
like
file
not
found.
If
you
try
and
go
go
read
a
file.
D
And
this
the
same
thing
is
true
for
environment
variables
and
arguments.
Those
are
all
manually
passed
to
the
the
web
assembly
engine
at
start
time,
and
you
know
when
you're
running
the
wasm
time
CLI
it
takes
care
of
a
bunch
of
that
stuff
for
you
automatically,
but
again
for
for
wasm
cloud
to
maintain
its
security.
We
essentially
pass
an
empty
list
of
arguments
and
an
empty
list
of
environment
variables.
A
Okay,
do
you
think
that
there's
a
world
where
we
would
do
a
mixed
Wazi
and
was
in
Cloud,
you
know
component
model?
Where
you
can
you
know?
If
you
wanted
to
access
a
file,
you
could
access
a
real-time
file
with
a
blob
store
or
if
you
were
just
hacking
out
like
a
simple
example
or
something
you
could
start
the
wasm
cloud
runtime
with
a
folder
that
has
some
static
files
and
in
it
and
could
could
access
those.
D
Yeah
so
again
it's
kind
of
a
it's
a
there's,
a
difference
in
conceptual
and
abstraction
level,
between
the
wise
McLeod,
blob
store,
contract
and
a
an
operating
systems.
You
know,
directory
or
or
file
system.
So
I
don't
think
we
would
ever
be
at
a
point
where
was
and
Cloud
would
just
let
you
use
the
wazzy
functions
for
accessing
stuff.
D
Instead
of
people
using
the
intrinsic
YZ
file
system
function
calls
there
will
be
a
component
model
contract
for
accessing
a
blob
store,
and
then
anyone
can
use
that
contract
and
then
it's
up
to
the
host,
whether
it's
wasm
cloud
or
wasn't
time
or
anything
else
as
to
how
it
satisfies
that
contract
and
so
yeah.
Our
our
integration
with
YZ
is
more
just
to
remove
it
as
a
barrier,
rather
than
something
that
we're
kind
of
doubling
down
on.
A
Okay,
yeah,
that
makes
a
makes
a
ton
of
sense.
I
was
totally
interested
in
the
like
backwards
compatibility
of
a
Wazi
module
that
tries
to
read
a
file.
How
we
can,
like
you
know,
bring
that
into
the
wasm
cloud
ecosystem,
but
yeah,
okay
and
I
had
another
another
question.
That
was
all
one
question
with
Wazi
modules
and
the
way
that
they
can
kind
of
write
to
pipes
like
standard
at
standard
error
pipes.
A
A
However,
if
the
future
is
just
a
you
know
only
supporting
Wazi
modules,
which
sounds
reasonable
with
component
model,
and
you
know
better
Wazee
or
better
support
with
Wazi
for
Standalone
modules.
Would
we
just
remove
the
built-in
logging
contract,
just
let
actors
kind
of
admit,
to
standard
out
standard
error,
the
way
that
they
normally
would
like
with
a
logging
crate.
D
It's
a
good
question:
I
think
you
know.
Obviously
nothing
is
set
in
stone
and
kind
of
still
chewing
on
it,
but
I
think
it's
similar
to
the
difference
between
the
raw
file
system.
Access
versus
The,
Blob
store
contract,
you
know
admitting
to
standard
out,
doesn't
do
anything
with
log
levels
or
you
know,
formatting
the
log
data
as
Json
or
string
or
anything
else.
It's
just
raw
bite
dump.
D
So
while
we
still
might
support
the
raw
bite
dumping,
because
you
know
it's
really,
it's
actually
kind
of
hard
to
get
away
from
libraries
that
do
that
by
default,
and
we
would
support
that
so
that
it's
kind
of
there
for
backwards
compatibility.
But
I
still
think
that
you
know
a
wasm
cloud
or
component
model
contract
is
still
the
right
way
to
go
in
terms
of
logging,
because
it's
more
at
that
level,
it's
more
of
a
rich
feature
set
rather
than
just
dumping
bytes
to
a
pipe.
D
One
sort
of
interesting
subtlety
about
the
component
model
is
that
it
doesn't
actually
require
wazzy.
So
if
you're
familiar
with
the
component
model
standards,
it's
really
just
a
way
of
allowing
one
webassembly
module
to
communicate
with
another
one
or
you
know
a
host
pretending
to
be
another
one.
The
what
who
satisfies
the
other
side
of
the
contract
is
agnostic,
which
fits
in
pretty
well
with
the
wise
and
Cloud
idea
of
how
the
world
should
work.
D
But
those
standards
are
they
don't
require,
like
the
component
model
itself
doesn't
require
Wazi
to
work
now,
some
of
the
stuff
that
is
going
to
be,
you
know,
implemented
as
standards
further
down
the
road
like
there's
a
possibility
that
some
of
these
things,
like
key
value,
store
and
blob
store
and
whatnot
might
end
up
being
defined
as
contracts
within
the
YZ
umbrella.
And
if
that
happens,
then
you
might
need
to
turn
on.
As
you
support
in
order
to
get
access
to
those,
but
that's
down
the
road.
A
A
A
All
right,
well,
I,
have
one
more
thing
that
I'd
like
to
one
thing
I'd
like
to
share
and
then
got
gotta
kick
off
to
to
Matt
about
his
PR
I.
Just
wanted
to
share
that
wash
version
12..
It
was
officially
released
as
of
a
couple
of
days
ago,
had
a
couple
hiccups
in
the
actual
release
pipeline,
which
delayed
this
just
slightly.
But
we
have
some
huge
implementations
in
wash
12,
including
the
the
wadham
client.
A
The
the
sub
command
wash
app,
we've
got
the
start,
command
or
or
wash
up
is
now
fully
released,
so
people
can
go
out
and
start
wasn't
Cloud
by
just
writing
wash
up
which
we're
all
we're
all
really
proud
of
a
lot
of
small
fixes
and
and
big
fixes
for
things
like
you
know,
RCI
and
changing
up
some
dependencies
and
improving
the
ergonomics
of
the
actual
crate.
So
big
thanks
to
Matt
Wilkinson
Connor
Smith
on
the
on
the
cosmotic
side,
actually
surprised
that
this
is
his
first
contribution.
But
thank
you.
A
Thank
you,
Mo
fata,
for
the
first
contribution.
It's
really
awesome
to
get
new
people
coming
in,
like
a
surprise,
PR
comes
in
and
fixes
fixes
a
bug
which
is
always
always
a
lot
of
fun
and
a
huge
thank
you
to
dependabot
the
definitely
real
person
who
put
in
their
first
contribution.
So
it's
a
big
big.
Thank
you.
There
there's
a
lot
of
changes
in
this
one.
A
A
The
installation
instructions
are
are
continuing
to
slim,
more
more
and
more
down,
so
we've
got,
you
know
the
install
instructions
for
your
package
manager
of
choice
or
you
can
just
use
cargo,
and
then
the
only
thing
you
need
to
do
before
moving
on
to
getting
started
is
run
wash
up,
downloads,
Nats
and
wasmcloud
and
starts
it
all
up
for
you
we're
still
maintaining
our
docker
installation
instructions.
This
is
important
for
people
who
really
prefer
to
not
install
anything
on
their
local
machine.
Totally.
A
A
You
know
that
that
brings
on
an
additional
bit
you're,
not
going
to
use
an
interactive
command
line
to
do
that.
So
this
is
how
you
can
still
kind
of
install
the
the
host
runtime
manually
going
on
to
getting
started.
Everything
is
pretty
much
the
same
other
than
showing
you
that
was
on
cloud
logs
are
in
a
specific
location.
If
you
use
wash
up-
and
that's
that's
about
it,
but
I
I
was
really
excited
about
this.
A
Let's
see,
I
think
that
that's
that's
it
for
that.
One
other
thing:
I,
love
to
bring
up
I
know
that
this
PR
was
just
kind
of
pending
and
waiting.
While
we
were
trying
to
get
wash
version
12
out
the
door,
so
we
can
start
putting
this
into.
Like
Alpha
releases
is
the
wash
build,
PR
I
think
at
least
last
I
saw
Matt
you're
still
on
the
call.
Did
you
want
to
say
anything
about
this?
I
know
it's
gone
through
a
couple
commits
since
we
got
to
actually
reviewing
it.
E
A
Perfect
yeah,
thank
you.
Thank
you.
Matt
and
I.
Think
you're,
right,
I
think
this
was
we
left
some
comments
a
while
ago
and
it's
pretty
much
up
to
date
and
just
needs
I,
don't
know
if
you've
done
it
yet
probably
just
needs
a
rebase
with
Maine
and
and
should
be
good
to
good,
to
go
we'll
give
it
another
look
and
merge
it
in.