►
From YouTube: wasmCloud Community Meeting - 3 May 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
All
right,
hello:
everyone
welcome
to
the
wasmcloud
community
meeting
for
Wednesday
May,
the
3rd
I'm,
going
to
go
ahead
and
share
our
agenda.
Really
quick.
We've
got
a
couple
of
things
on
the
DACA
today,
a
quick
demo
and
then
some
updates
and
discussions
so
should
be,
should
be
a
lot
of
fun
so
without
without
further
Ado.
Let's
go
ahead
and
kick
it
off.
We
have
a
one
of
our
community
members
who
came
in
just
a
few
months
ago.
A
B
Great
so
nice
and
simple
I
assume
you
can
see
my
screen
yeah,
so
what
we
did
with.
We
created
an
actor,
so
this
rating
actor
and
a
a
provider
which
is
this
prefix
table
provider
and
then,
of
course,
we're
using
the
HTTP
server
and
so
the
HTTP
server
we've
got
a
linked
definition
called
NRF.
Nrf
is:
did
you
see
this
tab
change,
yep.
B
So
this
is,
this
is
an
API
for
rating.
It's
it's
based
on
the
5G
core
interfaces
for
for
for
rating
rating
usage
in
like
like
a
5G
core,
and
so
what
we're
going
to
do
we're
going
to
do
a
post
to
to
to
rating,
and
then
we
get
back
a
rating
ref
which
we
can
use
in
in
in
the
others,
and
so
the
in
a
in
prepaid
service.
B
You
you,
you
send
a
rating
request
and
then
you
send
more
rating
requests
during
the
session
so
that
you
can
be
cut
off
mid-session
when
you
run
out
of
credit.
So
it's
it's
basically
prepaid
prepaid
service.
B
So
so
that's
basically
it
the
HTTP
requests
come
in
using
this
NRF
protocol
and
the
the
rating
actor
handles
it
and
then
to
perform
the
rating
he's
actually
going
to
get
that
that
rating
identifier
from
number
gen
so
getting
a
unique
guid
and
then
then
he's
going
to
interact
with
the
prefix
tables
provider,
and
so
what
prefix
tables
is,
and
so
this
provider
has
been
developed
with
a
contract
that
allows
you
to
create
tables
and
life
cycle,
manage
tables
in
the
and
the
rows
and
the
tables
and
the
rows
represent
prefixes
and
then
the
like.
B
B
And
so
that's
what
that,
what
that
act,
what
that
provider
is
doing,
and
so
he's
just
going
to
take
the
in
the
example
I'm
using
here
which
doing
a
text
message
so
I'm
sending
like
an
SMS
and
the
destination
will
be
matched
against
the
prefix
table
to
get
a
rate,
and
then
that
rate
is
is
returned
and
I
can
just
show
that
happening.
B
B
And
yeah,
so
we've
got
201
created
back
and
you'll,
see,
there's
a
location
header,
there's
the
guid
that
we
pulled
out
of
number
gen
and
we've
we're
using
search
Json
in
the
actor
and
we've
decoded
the
Json
payload
and
provided
the
Json
payload
back
and
and
that's
it.
A
Nice
and
and
Ben
so
just
have
a
quick
question
when
I
first
heard
raiding,
like
I,
think
of
rating
is
like
giving
somebody
five
stars
like
on
an
Uber
driver.
You
know
thing
rating
in
this
context.
What
it
seems
to
have
a
different
connotation.
Is
it
like
the
cost
to
like
send
that
message
or
that
data
of
5G,
or
something
like
that?
Yeah.
B
Absolutely
so
so
it's
all
about
like
in
my
business,
it's
Communication
service
providers,
their
their
businesses,
they're
commercial
businesses
right,
so
we're
not
giving
things
away
and
like
if
you
have
a
prepaid
cell
phone
behind.
It
is
an
online
charging
system
and-
and
it
is
every
time
you're
doing
something
on
your
phone.
That
usage
is
reported
and
then
the
rating
engine
decides
what
to
charge
you
for
it
and
then
charges
it
you
for
it
in
real
time,
because
it's
prepaid.
B
So
if
you
run
out
of
like
on
Tuesday
afternoon,
if
you
run
out
of
out
of
credit,
then
your
service
is
going
to
stop
right.
So
that's
what
this
engine
does
rating
charging
account
balance
management
and
I
just
demoed
just
the
rating
part
of
it.
A
Okay,
that's
really
that's
really
awesome.
Thank
you
for
I
know
that
we
went
back
and
forth
in
the
wasm
cloud
slack
a
little
bit
talking
about
link
names
and
getting
the
right
setup,
but
thank
you
for
for
demoing
it.
It's
super
cool
to
just
see
it.
You
know,
even
even
if
it's
looking
at
a
plain
white
terminal
with
some
Json
output,
it's
cool
to
see
some
of
this
stuff
demoed
for
real.
B
So
the
the
the
the
interesting
Parts
the
next
part,
because
that
provider
is
really
just
a
fake
provider
at
the
moment
it
it's
not,
there
are
no
prefix
tables,
so
so
prefix
tables
is
a
capability
that
six
scale
have
it's
implemented
in
erlang,
and
so
the
next
job
is
I
need
to
get
that
backing
capability
connected
to
that
provider,
and
it's
like
I'm
not
going
to
implement
that
in
Rust.
It
needs
to
be
connected
to
the
erlang
implementation.
A
Okay,
so
it
sounds
like
we
should.
Probably
you
know
it
sounds
like
a
big
discussion,
but
we
should
follow
up
on
offline
about
you
know.
If
we're,
of
course,
Watling
Cloud
supports
capability
providers
written
in
a
language,
it's
not
specific
to
rest,
but
we'll
want
to
follow
up
on
how
we
could
connect
that
potentially
to
erlang,
like
you
said,
the
the
prefix
tables
is
implemented
in
erlang
and
wouldn't
want
you
to
have
to
rewrite
that
whole
thing.
C
A
Cool
well
thank
thank
you
again,
Vance
great
to
great
to
see
the
demo
we'll
go
ahead
and
move
on
to
our
next
agenda
item
here.
What
we
have
is
the
wadham
0.4
release
update.
A
Last
week
we
showed
a
little
bit
of
a
demo
of
what
I'm
working
and,
as
usual,
there's
always
a
ton
of
there's.
There's
been
a
lot
of
activity
in
the
water
repo
lately,
including
a
couple
of
issues
that
have
been
filed
and
work.
That's
going
in.
We
just
recently
released
zero
four
zero
Alpha
2,
which
includes
a
couple
of
fixes
around
making
some
things
in
the
Manifest
optional.
D
I'll,
let
you
keep
sharing
bricks,
you're
a
great
sure
so
anyway,
yeah
I
just
want
to
give
an
update
on
where
things
are
at
so
I
was
out
on
vacation,
so
I
didn't
ran
at
kubecon,
so
I
haven't
been
able
to
update
on
this
in
two
weeks,
so
we
are
there
we're
at
an
alpha
two.
At
this
point
we
have
some
things
in
the
heads
up
right
there
at
the
very
top.
D
You
can
stay
there
for
a
second
bricks,
I
guess
and
we're
we're
just
working
on
fixing
a
few
things
around
statuses
scaling,
algorithm
stuff,
which
is
going
to
require
a
change
to
the
host
and
then
I'm,
currently
working
on
ede
tests
right
now,
Brooks
is
working
on
some
of
that
scaling,
algorithm
stuff
as
well,
and
then
we're
just
updating
things
with
documentation
and
thanks
to
everyone
who
has
been
trying,
we've
had
a
couple
of
you
who
are
definitely
on
this
call,
who
have
been
really
pounding
on
it
and
trying
it
out.
D
So
we
really
appreciate
that
as
soon
as
we
get
past
these
last
things
we're
going
to
mark
it
as
a
full
0.4
release,
which
means
it
will
be
the
reason
it's
not
1.0.
It's
going
to
be
production
ready,
but
it's
not
going
to
be
API
stable.
If
that
makes
sense,
so
we
might
make
changes
in
how
we
do
things.
D
We
might
change
up
underlying
algorithms,
that
kind
of
stuff
in
future
releases,
but
it
will
be
to
a
point
where,
where
people
can
use
it
in
production,
so
I
just
wanted
to
give
people
an
update
that
that's
where
we're
at
that,
like
there's
still
some
active
work
going
on,
there's
a
couple
different
features
and
things
in
the
issues.
If
anyone
wants
to
like
get
started,
there's
actually
a
really
good
starter
issue
that
Brooks
opened:
oh
no,
not
that
on
the
config
Json
right
there.
D
This
is
one
that
we
also
want
to
add
before
we
hit
0.4.
That's
why
I
signed
it
in
there,
this
one's
actually
not
too
difficult
to
do.
If
you
want
to
get
your
hands
dirty
with
some
rest
or,
if
you're
looking
to
learn
for
it.
So
this
is
definitely
a
good
first
issue.
If
someone
wants
to
get
involved
right
now,
just
let
us
know
and
we'll
make
sure
that
it
says
that
hey
you're,
you're
you're
assigned
to
this.
D
We
will
let
you
do
it,
and
then
we
won't
accidentally
code,
something
on
top
of
you.
So
that
was
just
the
the
quick
update
there.
Brooks
that
I
think
would
just
be
was
just
going
to
be
good
for
everyone
to
hear
where
we're
at
with
it,
and
in
case
you
didn't
know,
you
can
run
Woodham
in
pretty
much
any
type
of
style.
So
if
you
go
to
the
release
page
real,
quick,
Brooks.
D
You'll
see
that
we
have
all
the
different
architectures
right
there,
so
you
can
run
a
raw
binary
and
then,
if
you
go
back
out
to
the
top
and
into
packages,
you'll
see
that
we
have
a
Docker
image
as
well.
You
can
click
on
that,
so
people
can
see
they'll
and
we
so
we
have
those
available.
Every
time
we
publish
domain,
we
have
a
canary
that
goes
out
and
then
we
also
have
the
the
release
tags
on
there.
D
A
I'll
just
add
one
more
thing:
I
know
that
one
way
that
we're
going
to
recommend
people
run
wadham
will
be
through
wash
I.
Have
this
PR
out
right
now
for
wadham
support
and
wash
app
support,
and
that's
actually
approved
I'm
working
on
a
couple
Logistics
with
some
other
PRS
that
we
have
open
right
now.
A
But
essentially
what
it
looks
like
is:
let's
see,
I
don't
have
a
instructions
in
here,
but
you
run
wash
up
and
that
will
actually
run
bottom
it'll
it'll
download
the
binary
and
run
it
in
the
background
that
can,
of
course
be
disabled,
but
as
soon
as
this
merges
we're
going
to
ask
more
people
to
get
out
and
test
it,
because
I
think
this
is
going
to
be
a
lot
easier
in
terms
of
you
know:
you're
not
unpacking
a
tarball
I.
Think
we're
also
going
to
work
to
put
this
into
our
examples.
A
So
like
the
pet
clinic
Docker
compose
where
we
have
the
postgres
database
and
everything
we'll
probably
run
watum
as
a
Docker
image
or
as
a
Docker
container,
and
that
will
be
the
thing
that
actually
starts
the
actors
and
providers.
So,
just
slowly
kind
of
pushing
our
examples
in
this
direction,
because
it's
just
so
nice
to
be
able
to
say
wash
app,
deploy
pet
clinic.
It's
really.
It's
really
fun.
We're.
D
Doing
some
pretty
complex
things
too,
Brooks's
Brooks
didn't
mention
this
but
like
Brooks,
is
currently
working
on
for
a
cosmonic
stuff
he's
working
on
turning
all
of
the
components
that
we
run
in
Wasim
Cloud,
which
is
pretty
much
most
of
the
cosmotic
platform
into
a
Witham
manifest,
and
it's
pretty
awesome
actually
so
we're
we're
gonna
be
contributing
our
own
button
fixes
and
stuff.
We
find,
as
we
do,
those
things
as
well
so
trying
to
keep
it
as
as
a
as
a
dog
food
as
possible
as
well.
A
All
right
well,
thank
you,
Taylor.
Moving
on
to
the
next
part
of
our
agenda
kind
of
pretty
pretty
quick
moving
thing
today,
I
wanted
to
call
out
one
thing:
I
know
that
this
is
more
on
the
cosmotic
side,
but
of
course,
every
application
that
you
write
before
cosmonic
is
just
wasn't
loud
actors
and
providers,
and
so
I
wanted
to
call
out
some
of
the
submissions
for
the
cosmonic
hackathon
or
specifically,
the
winners
that
came
in
and
that
we
announced
earlier
this
week.
A
So
some
of
the
things
that
we
saw
I
won't
go
super
deep
into
these
projects
and
use
cases
you're
welcome
to
check
them
out
for
yourself.
They
are.
They
are
public,
but
we're
really
hoping
to
reach
out
for
to
some
of
these
people
who
submit
it
to
the
hackathon,
hopefully
get
these
contributed
as
wasmcloud
examples
and
the
reason
being
one
of
the
first
ones.
Here
this
dog,
the
dog,
the
Bug
Hunter.
Let
me
see
if
I
can
I,
don't
think
I
have
the
the
GitHub
link
here.
A
It
is
I
wanted
to
pull
up
the
architecture
diagram
because
it's
really
sweet.
What
some
of
these,
like,
some
of
the
wasm
cloud
components
that
came
out
of
this
this
specific
contributor,
the
the
submitter
created
a
few
actors
and
a
capability
provider
for
grabbing
the
current
system,
time
which
they
actually
went
and
contributed
to
our
awesome,
Cloud
examples,
repo
I,
think
that
is
either
merged
in
now
or
is
ready
to
go.
A
I
also
want
to
call
out
one
of
the
the
other
two
submissions
that
had
really
interesting
uses
of
AI.
This
Dr
Wright,
submission,
essentially
is
prompt.
Engineering
would
go
find
you
know
it's
it's
a
awesome,
Cloud
application
that
would
go,
find
research
papers,
you
can
select
them
and
then
it
will
give
you
a
prompt
to
give
to
like
chat
GPT.
A
To
summarize
the
research
papers,
for
you
really
slick
and
then
Mech
extension
is
like
a
a
chat,
a
chat
Edition
where
you
can
and
I'll
pull
up
the
actual
architecture.
For
that
as
well,
because
it's
really
slick
to
look
at
where
was
that
I
might
have
just
been
part
of
the
part
of
the
video.
A
So
let
me
go
and
pull
that
up,
so
it
might
be
a
little
small
actually,
but
I
just
wanted
to
mention
that
it's
using
all
of
kind
of
like
our
built-in
awesome,
Cloud
examples
like
redis,
HTTP,
server,
HTTP
client
to
do
like
printifying
of
language
and
translations.
So
you
can
type
out
a
message
and
then
like
translate
it
to
German.
It's
it's
really
slick,
so
I
would
highly
recommend
going
to
check
these
out.
A
Of
course
everything
everything
was
hosted
on
cosmonic,
but
it's
all
was
on
cloud
under
the
hood,
so
really
cool
submissions
to
this
to
the
hackathon
I
just
wanted
to
at
least
call
that
out.
Anybody
have
any
questions
before
we
go
on
to
the
next
part.
A
Alrighty
then
I
think
the
next
thing
is
is
on
me
again.
So
we've
been
thinking
about
a
couple
of
things
as
we
push
towards
stability
in
wasm,
Cloud
I
know
that
there
are
a
lot
of
there
are
frequent
fun
and
breaking
changes
in
the
webassembly
space,
and
so
that's
kind
of
we're,
keeping
an
eye
on
that
as
we
try
to
push
for
a
was
on
cloud
1.0.
A
But
some
things
are
a
little
insulated
from
that
and,
as
we
think
about
maturity,
we
were
considering
the
wash
command
structure,
so
the
wash
has
been
around
for
a
couple
of
couple
of
years.
Now
pretty
much
since
the
beginning
of
wasm
cloud.
It's
had
a
you
know.
It's
had
many
Breaking
changes
and
commands
that
change,
but
some
of
the
feedback
that
we've
gotten
just
from
General
Community
is
that
some
of
the
sub
commands
feel
complicated.
A
Some
of
them
are
pretty
well
nested
like
wash
control,
get
inventory
and
then
the
host
ID
or
wash
control,
start
actor
or
wash
control.
Link.
Query
like
there
are
a
lot
of.
A
There
are
a
lot
of
four
sub
command,
nested
things
and,
in
general,
some
of
the
commands
are
kind
of
available
in
in
not
the
best
context
like
some
some
commands
were
top
level
commands
when
they're
really
only
used
once
or
maybe
twice
and
so
I
put
together
a
little
bit
of
an
RFC.
Let
me
go
ahead
and
ping
that
in
the
chat,
because
the
comments
are
welcome
from
from
anyone
here
around
reworking
the
command
structure.
A
A
The
the
wasm
cloud
multi-tool
for
all
things
was
on
cloud
development,
but
I
organized
it
into
a
couple
of
different
sections
around
what
I
feel
like
Wash's
main
responsibilities
are
around,
generate,
build
and
deploy
wasm
Cloud
projects
interact
with
running
watsonplat
applications
bootstrapping,
while
Some
Cloud,
runtime
environments
like
with
up
and
then
down
to
take
it
down,
and
then
some
of
the
extra
stuff
around
managing
settings
was
on
cloud
cache
downloads
from
wash
up
things
like
that,
and
just
to
put
it
all
on
one
page,
I
I
wanted
to
show
like
what
a
a
help
text
may
look
like
for
wash
with
this
structure.
A
I
would
love
to
organize
this
kind
of
like
a
lot
of
go
clis
do
like
Nats
and
Cube
control,
wow
I
said
it
wrong
that
sucks
and
in
into
four
main
sections
applications
building
projects,
configuring
wash
and
then
dealing
with
runtime
environments.
So
I
think
that
this
pushes
us
a
lot
closer
to
a
stable,
wash
CLI.
A
You
know
eventually,
when
we,
when
we
push
to
release
a
1.0,
I,
think
we're
about
to
be
on
0.18
we'll
want
to
have
these
be
stable,
because
people
are
going
to
write
scripts
on
based
on
these.
We
already
have
scripts
based
on
wash
so
the
goal
would
be
to
make
breaking
changes.
Now,
while
we
can
I
wrote
up
like
a
full
bulleted
list,
if
anybody
has
like
a
format
for
a
standard
CLI,
you
know
just
full
output
with
every
sub
command
and
flag.
A
Please
let
me
know
I'd
love
to
Output
that
as
a
format,
but
I
wanted
to
call
out
a
few
things
in
this
RFC
as
as
big
changes,
because
many
things
like
using
build
and
inspect
aren't
going
to
change,
but
what
I
did
do
is
get
rid
of
the
control
sub
command
entirely
in
favor
of
having
simpler
top
level
commands.
A
So,
instead
of
doing
wash
control
start
actor,
I
propose
that
we
do
something
like
wash
start
and
then
the
oci
bundle
or
file
reference
same
with
stop.
Instead
of
wash
control,
get
inventory
or
wash
control,
link,
query
I
propose
we
do
wash
git
links,
wash
get
claims
wash
git
and
then
a
host
ID
for
the
host
inventory.
Things
like
that
and
I
think
that
this
will
simplify
the
usage
of
wash
and
and
will
be
a
little
more
discoverable
for
people
first,
using
the
the
CLI.
A
Not
everything
is
going
to
be
listed
and
the
commands
that
people
use
most
often
are
kind
of
readily
at
readily.
At
your
fingertips,
I
was
a
little
worried
about
this
being
a
lot
of
top
level
sub
commands,
but
organized
in
this
way.
I
think
it
actually
looks,
looks
pretty
okay,
so
I
got
some
great
feedback
from
Bailey
and
Stephen.
Thank
you
all
so
much
for
for
commenting
here.
A
This
is
an
awesome.
I
actually
didn't
see.
Wait
did
I
like
it.
Nope
I
didn't
see
this
one
yet
so
I
gotta
I
gotta
parse
that
I'm
not
gonna
do
that
live,
but
please
feel
free
to
leave
comments.
Commands
commands
comments,
questions
things
like
that
on
this
RFC,
especially
if
you've
had
a
CLI
experience,
a
tool
that
you've
used
that
you
really
really
like,
because
we
want
to.
We
want
to
kind
of
emulate
that
so
any
any
questions
comments.
This
is.
A
This
is
totally
good
time
for
people
to
offer
feedback,
if
you
thought
of
it,
while
while
I
was
chatting
and
have
it
up
on
on
the
screen.
F
I'm
really
excited
about
it,
thanks
for
putting
that
together,
Brooke
I
think
it's
where
most
of
us
cells
live
and
breathe
on
the
pli
and
getting
that
experience
right
is
super
important,
and
it's
not
one
of
those
things
that
once
we
get
super
trained
on
that
we'll
ever
want
to
change
after
the
fact.
So
thank
you
for
all
the
thought
you
put
into
it.
F
You
know,
I
think
the
main
thing
that
we
learned
there
is
that
you
want
your
top
level
commands
to
be
right
and
you
want
it
to
be
really
obvious
how
to
add
new
commands
because
they
always
come
up
and
I
think
the
scene
that
you're
supposed
to
and
by
grouping
it
you
solve
it
that
way.
The
other
hard
lesson
learned
was
about
having
launching
points
per
plug-ins
early
so
that
when
people
start
trying
to
add
new
types
of
commands,
you
get
a
chance
of
people.
G
All
right
yeah
what
Bailey
said
about
the
plugins?
That's
one
of
the
links,
I
shared
I,
don't
completely
understand
it,
but
it
was
like
detolme
created
this
crate
called
inventory
and
the
goal
was
around
making
it
easier
for
plugins
to
integrate
into
your
project,
and
it's
done
in
a
way
so
that,
however
many
people
are
working
on
the
CLI
Flags
or
whatever
it
could
be
like
a
thousand
people
working
on
it
at
once,
and
you
won't
step
on
each
other's
toes.
G
I
I,
don't
understand
it
fully!
I
just
thought
it!
It's
based
on
G
flags
and
when,
when
you're
talking
about
CLI
stuff,
I
thought
this
might
be
of
interest,
it
seemed
pretty
cool
when
I
was
looking
at
it.
But
it's
it's
above
me
at
this
time.
A
Yeah,
this
is
really
neat.
I
I
saw
you
sent
this
and
I
didn't
get
a
full
chance
to
parse
it.
This
is
the
one
right.
This
inventory,
crazy,
yeah,
yeah
I
think
we
so
we've
done
a
little
bit
of
brainstorm,
General
brainstorming
around
what
wash
plug-ins
would
look
like
when
we
were
in
Amsterdam,
actually
I
think
we
had
a
dinner
where
a
few
of
us
were
were
spitballing,
some,
some
pretty
wild
ideas.
A
Let's
see
Kevin,
would
you
like
to?
Would
you
like
to
share
any
of
those,
or
would
you
rather
get
them
into
like
an
RFC.
H
Both
actually
I'd
like
to
get
it
down
in
an
RFC
I
think
I
may
actually
have
it
in
an
RFC
sitting
around
somewhere
Yes.
Actually
I.
Do
it's
just
not
public
sorry
about
the
coffin,
exchanging
pneumonia
with
my
wife
and
who
were
alternating
who's,
sick
yeah.
So
the
idea
behind
the
crazy
idea
behind
the
plugins
is
that
wash
could
wash
could
theoretically
treat
itself
as
a
Bare,
Bones,
webassembly
host
or
wasm
Cloud
host,
and
you
could
write.
H
You
could
basically
write
an
actor
that
uses
a
limited
set
of
interfaces.
That
would
be
your
plugin
to
wash,
and
so
you
could
basically
download
you
know
doom.wasm
to
play
Doom
insidewash
using
a
wazzy
plug-in
or
you
know.
Maybe
you
could
do
productive
things,
but
yeah
I'd,
rather
just
do
do.
F
See
the
reason
why
I'm
excited
about
it
for
the
longest
time
I've
I
believe
the
webassembly
is
the
last
plugin
model.
You'll
ever
need
it's
so
perfect
for
that
and
US
choosing
to
build
something
that
kind
of
built
you
know
moved
that
along
is
really
cool
and
exciting.
Also,
you
know
I
like
seeing
new
places
if
they
do.
C
This
is
making
me
think
of
Young's
comment
about
like
dealing
with
secrets,
so
like
pause
till
that,
because
this
sounds
like
something
that
could
be
really
applicable
there
too.
That's
cool.
A
Yeah,
using
using
what
I
think
I
think
we
would
be
doing
ourselves
a
disservice
if
we
use
the
plug-in
model
other
than
webassembly
for
wash
we've
gotten
some
spitballing
around
it,
maybe
not
anything
formal
yet
so
at
at
risk
of
derailing.
The
rest
of
the
call
I'll
probably
propose
that
we
move
on,
but
we
should
certainly
brainstorm
about
this,
especially
on
ways
to
to
get
this
working
just
to
just
to
wrap
up
the
the
wash
discussion
this
is.
A
This
is
in
an
RFC
there's
still
a
few
things
to
to
work
out
there
around
the
command
restructure.
But
what
you'll
probably
see
this
surface,
as
is,
is
probably
myself
or
someone
else
on
the
wash
maintainer
side
will
take
that
RFC
do
a
first
pass
of
restructuring
the
commands
to
kind
of
be
in
the
format
that
we'd
like
for
or
for
this
RFC,
but
not
necessarily
adding
anything
new
and
then
another
another
restructure
to
do
that.
So
this
is
going
to
be
a
breaking
change.
A
It
won't
be
the
final
iteration,
but
my
plan
is
to
maintain
backwards
compatibility
with
any
scripts
that
exists
today,
so
things
like
watch
control
start
actor.
If
you
type
that,
in
with
this
new
structure,
it
would
just
essentially
proxy
to
wash
wash
start
so
would
would
love
to
maintain
backwards.
Compatibility
for
for
a
while.
A
All
right,
I
think
we'll
go
ahead
and
move
on
to
the
we're
in
the
second
half
of
the
call.
Now
we've
got
a
couple
more
things
to
talk
about
and
I
want
to
make
sure
we
leave
plenty
of
brainstorming
time
for
for
secrets
and
provider
configuration
so
Kevin
and
I
don't
want
to
make
you
talk
too
much
since
it
sounds
like
it's.
A
Your
turn
to
hold
the
pneumonia
ball,
but
I
did
want
to
call
out
this
PR,
which
I
did
not
review
quite
yet
around
reorganizing,
some
of
the
Watson's
documentation,
I
think
around
the
same
vein
of
us
brainstorming.
We
have
certainly
been
thinking
about
our
Watson
Cloud
docs
and
how
they
can
be
most
effective
and
so
I
wanted
to
give
you
a
chance
to
call
out
some
of
the
changes
that
you've
made
here.
Kevin.
H
Sure
the
basic
idea
here
was
to
make
the
documentation
more
accessible
when
we
looked
at
what's
what's
out
there
now
and
what
the
the
new
user
journey
is
like
for
when
they
first
hit
the
documentation,
it
it
didn't,
seem
accessible
enough
and
it
felt
like
the
there
wasn't
a
clear
path
from
you
know.
Through
the
documentation,
there
were
a
bunch
of
places
where
we
had.
H
You
know
we
had
detail
on
a
on
a
concept
in
the
reference
guide,
and
then
we
had
high
level
detail
on
the
same
concept
somewhere
else,
and
so
we've
tried
to
consolidate
the
various
pieces
and
make
sure
that
you
know
all
of
the
the
detail
is
where
you
need
it,
and,
more
importantly,
is
that
it's
trying
to
give
you
a
progressive
buildup
of
of
knowledge,
rather
than
hitting
you
right
up
front
with
all
of
the
details.
H
So
hopefully
what
this
means
is
that
when,
when
people
hit
the
quantum
clogged
docks,
they'll
have
a
much
better
experience
going
from,
you
know
welcome
all
the
way
to
building
real
apps.
A
Yeah
and
just
to
be
clear,
I'm
doing
I'm
having
fun
on
my
own
doing
fancy
stuff
over
here,
but
on
the
left.
I
have
our
current
documentation,
structure
and
and
on
the
right.
I
have
Kevin's
proposed
changes
which
I
like
a
lot.
It
gets
you
started
and
then
introduces
you
to
a
lot
of
different
or
to
the
different
main
wazzle
Cloud
Concepts
I,
think
you
said
Kevin
that
before
we
don't
even
have
a,
we
didn't
have
a
page
on
link
definitions
or
something
until
all
the
way
down
in
the
reference
right,
yeah.
H
You
had
to
go
into
into
reference
and
then
I'm,
not
even
sure
where
it
was
reference
host,
runtime,
link
definitions,
one
of
the
symptoms
that
documentation
or
one
of
the
the
problems
that
documentation
can
have,
and
it's
not
just
ours.
It's
sort
of
a
trap
that
everybody
falls
into.
Is
you
write
documentation
based
on
the
idea
that
your
audience
knows
where
to
find
the
information,
you're,
writing
and
that
that
doesn't
actually
do
new
users
any
good?
A
Right
any
other
questions
for
any
questions
for
Kevin
here,
let
me
go
ahead
and
I'll
pull
up
this
PR
and
again
link
that
in
the
chat
as
well,
because
this
is
another
one
of
those
things
that
anybody
is
welcome.
To
welcome
to
comment
on.
A
All
right
well
keep
an
eye
out
for
for
that,
we're
going
to
be
doing
a
little
like
like
Kevin
said.
This
is
a
lot
of
reorganization
and
a
couple
of
empty
pages
that
we're
filling
out,
but
we're
going
to
be
kind
of
continually
improving
the
documentation,
of
course,
as
as
time
goes
on
all
right
now,
I
wanted
to
carve
out
some
time
to
talk
about
something
that
we've
gone.
A
We've
done
a
lot
of
brainstorming
in
the
waslam
cloud,
slack
and
I
want
to
make
sure
that
we
have
time
to
discuss
it
during
the
community
call.
The
FaceTime
is
nice
for
this
type
of
discussion.
A
Stephen
has
been
asking
a
couple
of
questions
around
wadham
and
around
using
environment
variables
to
supply
configuration
and,
and
there's
kind
of
two
different,
two
different
angles
to
to
go
from
here.
I
wanted
to
talk
about
the
first
one,
which
is
just
configuration
things
like
supplying.
Actually,
if
you
look
at
the
config.json
issue,
this
will
be
a
good,
a
good
use
for
that,
where
we're
providing
configuration
to
a
capability
provider,
something
like
on
the
HTTP
server
we're
supplying
what
type
or
what
address
to
listen
on
right.
A
Variable
I
think
another
good
use
case
for
this
would
be
and
this
kind
of
gets
into
secret
territory.
But
let's
just
talk
about
regular
plain
text
is
okay
configuration
first,
you
know
this
type
of
URL
may
change.
I
would
love
to
be
able
to
put
environment
variables
inside
this
manifest
and
then
I
I
think
the
right
way
to
do
this
would
be
for
wash
to
grab
that
environment.
Variable.
Put
it
in
the
Manifest
and
then
everything
after
that
uses
the
value.
A
So
that's
that's
one
side,
I
think
we
should.
We
should
absolutely
do
that
and
that
can
certainly
be
in
the
short
term.
Not
dealing
with
Secrets
is
really
well.
It's
really
easy.
It's
just
parsing
environment
variables.
Now
the
next
part,
which
is
what
I've
carved
this
discussion
timeout
for,
is
well
what
if
these
values
are
secret.
A
So
when
we're
configuring
the
link
between
an
actor
and
a
database
capability
provider,
you
probably
have
to
give
some
kind
of
secret
configuration,
so
a
username,
a
password
or,
if
you're,
interacting
with
an
API
a
token
or
a
TLS
certificate
to
use
you
know.
All
of
these
things
are
things
that
are
inherently
protected,
with
the
way
that
we
do
link
definitions,
but
not
to
the
rigor
of
a
Secret
store,
especially
not
the
way
that
you
specify
them
they're
stored
in
Nats
jet
stream,
which,
in
order
to
access
the
jet
stream
key
Value
Store.
A
You
have
to
have
Nats
credentials
and
it's
not
just
stored
straight
up
in
plain
text.
Things
like
that,
but
the
secrets
management
story
isn't
all
the
way
there.
So
with
that
kind
of
Prelude
I
want
to
talk
about
how
we
could
handle
secrets
on
link
definitions
or
or
provider
config
for
wasm
cloud,
and
this
is
just
full
full
brainstorm
time,
I'm
happy
to
say
more,
but
I
feel,
like
I've,
been
doing
the
prelude
for
a
little
while
I
I'd
like
to
actually
give
it
to
Stephen
to
add
any
more
color.
G
I've
been
trying
to
think
about
this
a
lot
because
things
like
API,
keys
and
stuff
I
imagine
can
be
pretty
important
to
keep
here
and
when
Jan
mentioned
the
provider
yesterday,
it
had
me
thinking
a
lot
because
I
started
like
looking
into
if
it's
okay
to
secure
things
in
environment
variables,
like
secrets
and
it's
like
even
root
like
if
you're
not
root,
you
have
access
to
the
environment
variable
file
and
it
was
kind
of
like
freaky,
and
it's
like
trying
to
see
how
other
things
do
it.
G
So
it's
kind
of
cool
to
imagine,
I
I'm
really
liking
what
was
brought
up
about
the
wassum
plug-in
because,
like
what
I
was
trying
to
think
about
is
if
you
were
going
to
go
the
provider
route,
how
do
you
stage
it
so
that
maybe,
if
it's
like
a
secret
extraction
provider-
and
you
you
need
those
Secrets
before
you
start
up
other
providers?
G
Can
you
like
stage
it?
But
then,
with
this
whole
other
thing
about
plugins?
Is
there
a
way
to
use
plugins
as
your
secret
interface?
And
then
it's
like
you
have
different
plugins
for
your
different
secret
management
tools,
so
whether
it's
like
AWS
or
vault-
or
you
just
want
to
do
it
locally,
I,
don't
know
it
kind
of
lets
it
be
modular.
G
The
the
alternative
was
I,
don't
know
trying
to
use
like
whatever
you
get
over
the
wire
and
then
encrypting
it
and
storing
it
in
jet
stream,
like
that
seems
like
it
wouldn't
necessarily
be
very
modular,
so
I
don't
know
it's
been
fun
to
imagine,
but
I'm
a
little
out
of
my
depth
here.
So
it's
kind
of
cool
to
think
about.
A
Johan
I
know
you
dropped
a
lot
of
a
lot
of
cool
feedback
around
the
way
that
you
do
it
in
kubernetes.
Did
you
want
to
talk
a
little
bit
more
about
that.
E
Yeah,
so
one
of
the
things
that
I
brought
up
is
kind
of
having
a
meta
provider
a
little
bit
like
the
capability
to
have
an
interface
to
get
to
to
secrets
in
some
form
or
the
other
and
I
think
for
broader
adoption
of
wasn't
Cloud
it's
necessary
to
to
acknowledge
that
there
are
already
things
are
out
there,
that
people
use
like
AWS,
Secrets
manager
or
vault
right,
and
they
have
some
stuff
attached
to
it
like
rotation
of
keys
and
passwords
and
logic
behind
it
already
and
I,
don't
think
it's
people
will
necessarily
change
that
and
it's
also
compliance
and
stuff
there's
so
much
stuff
in
in
there
right
and
right
now,
it's
a
very
low
key
entry.
E
You
paste
your
passwords
or
secrets
into
the
into
the
link
right
and
hope
that
it's
stored
in
a
in
a
seek
in
a
safe
way
right
and
right
now
it's
in
jet
stream,
that's
reasonably
safe,
but
do
people
trust
it.
So
this
is
my
first
gut
feeling
was
oh
I'm
posting
here
my
my
things.
I
can't
push
that
out
to
somewhere
because
they're
real
Secrets,
I
I
used
right
for
the
testing.
E
So
I
see
jet
stream
as
necessary
to
distribute
secrets
and
to
Cache
it,
but
not
necessarily
as
the
secrets,
managements
and
Storage
Solutions.
So
that's
where
this
Mata
provider
came
up
so
provider
for
link
definitions
right.
H
I
just
wanted
to
mention
in
case
people
didn't
hadn't
seen
it
is
that
I,
don't
know
where
it
is
in
the
road
map,
but
Nats
is
actually
planning
on
making
it
so
that
you
can
encrypt
jet
stream
at
rest.
So
if
you
store
things
as
a
key
value
bucket
or
even
just
a
regular
stream,
full
of
you
know
arbitrary
data.
H
The
goal
is
that
you
can
just
turn
on
encryption
in
the
server
and
it'll
store
it
both
on
disk
and
in
memory
in
a
in
an
inaccessible
format.
There's
yet
another
level
of
paranoia
which
involves
making
sure
that
the
memory
space
that
a
wise
and
Cloud
hosts
consumes
doesn't
actually
contain.
Any
plain
text
Secrets,
which
is
the
chat,
is
hilarious,
which
is
a
it's
a
a
different
level
for
a
different
level
of
security,
so
the
The
Meta
providers.
H
The
idea
is
kind
of
cool
we'll
have
to
Noodle
on
that
a
bit
but
I
think
one
of
the
I
had
a
point
that
the
dogs
are
barking
and
I.
Can't
remember,
yeah
I,
think,
there's
just
different
layers
and
I
think
as
long
as
we
make
sure
that
the
layers
are
stackable
and
don't
interfere
with
each
other,
then
I
think
we'll
have
a
decent
story
around
secretly
devs.
I
Yeah
I
think
the
the
idea
of
a
meta
provider
is
super
interesting
because
I
also
hit
this.
This
issue
I
think
a
week
or
two
ago
or
not
issue,
but
like
this
desire
for
a
teacher
which
was
I,
was
trying
to
come
up
with
a
way
to
do
an
internal
registry.
Oh
Brooks
did
I
jump
you
in
the
line.
I'm.
Sorry,
do
you
want
to
go?
I
Okay,
okay,
so
I
I'm,
so
sorry
I
got
so
excited
so,
but
this
idea
of
some
sort
of
like
meta
provider
or
even
being
able
to
you
know
I,
think
plugins
is
also
kind
of
towards
this
idea
of
like
what,
if
I
could
replace
fundamental
pieces
of
wazen
cloud
with
something
that
can
plug
in
or
or
you
know,
Implement
a
trait
or
an
interface,
or
something
like
that
and
then,
oh
now,
my
secrets
just
they're,
backed
by
ACM
or
oh
now,
my
registry
I,
don't
need
to
worry
about
a
Docker
registry
somewhere.
I
The
fact
that
one
of
the
nodes
on
my
network
is
has
the
creds
that
can
authenticate
to
a
registry
and
then
pull
those
bytes
down
like
means
pretty
much
any
of
them.
In
the
lattice
can
do
this,
and
you
know
we
I
think
that's
some
of
that
is
the
fact
that
Nats
is
so
magical
and
it
gets
us
this
like
secure
foundation
and
messaging
layer
and
I.
Think
that,
like
the
more
that,
we
I
think
we're
going
to
see
this
pattern.
I
So
like
there's
two
right
now,
we've
got
secrets
and
then
Registries
with
my
personal
example
like
I.
Don't
think
that
we
should
have
to
add
a
case
statement
every
single
time
that
we
want
to
add
a
new
type
of
actor
that
we
want
to
implement,
like
maybe
that's
an
interface
that
we
Implement
and
then
or
sorry,
maybe
that's
an
interface
that
we
Define
and
then
it's
like
easily
discoverable
in
docs,
and
it's
like.
Oh,
you
have
a
new
registry
type
or
you
even
want
to
implement
one
yourself
just
implement
this
interface
and
it
works.
I
A
Yeah,
so
I
did
ask
around
in
the
Nats
slack
about
this
type
of
encryption
and
they
talked
about
encryption
encryption
at
rest.
A
You
can
you
can
enable
that
they
still
recommend
doing
file
system
encryption,
which
is
fine
to
you
know
in
defense
in
depth,
but
one
of
the
things
that
they
also
recommended
as
an
alternative
to
encryption
at
rest
is,
you
know,
essentially,
when
a
secret
value
comes
into
your
system
in
the
Watson
Cloud
ecosystem,
when
we,
when
we
do
a
link
put
with
secret
configuration,
essentially,
the
recommendation
was
to
use
an
encryption
key
there
to
encrypt
it
and
then,
when
you
actually
need
to
pull
the
value
out
and
hand
it
to
a
capability
provider
or
something
that's
where
that's
where
you
decrypt
it.
A
You
know
I
think
we
can
probably
get
into
the
technical
discussion
later,
it's
a
little
different
from
brainstorming,
but
what
I'm
trying
to
think
about?
As
as
we
talk
about
different
ways
to
maybe
do
you
know
a
meta
provider
or
different
ways
to
keep
secret
values
secret?
A
You
know,
there's
the
there's
the
the
point
where
you
have
a
secret
value
and
you
need
to
give
it
to
a
waslam
cloud
system
so
that
it
can
reference
that
secret
value
later
and
then,
when
you
actually
need
to
use
that
secret
and
those
seem
like
complicated
areas.
We
do
a
lot
of
our
communication
over
Nats.
So
if
we
were
to
try
and
use
the
secret
provider
like
the
AWS,
Secrets
manager
or
or
hash
Court
Vault
wherever
we're.
Actually
you
know
if
we
use
the
secret
reference
wherever
we're.
A
Actually,
whenever
we
need
to
pull
that
secret
value
out,
it
would
need
to
have
a
direct
connection
to
that
Secrets
manager
and
that's
something
that
sounds
hard
to
do
in
a
really
clean
way
across
a
really
distributed.
System
since,
like
if
you're
trying,
if
you're
running
a
capability
provider
on
an
edge
device,
it
probably
doesn't
have
a
direct
connection
to
your
AWS
Secrets
manager.
Things
like
that.
So
that's
kind
of
one
reason
why
I've
gravitated
in
the
direction
of
doing
something
like
encrypting
and
then
storing
in
jet
stream.
A
A
So
I
don't
have
any
concrete
suggestions
there
just
further
in
the
conversation,
these
are
some
of
the
things
that
some
of
the
things
that
I've
been
thinking
about
when
going
across
this
discussion.
F
I
think
I'm
next
I
think
there's
a
lot
to
learn
from
why
we
had
to
have
different
types
of
secret
managers
in
the
kubernetes
world,
because
so
many
people
have
policies
that
are
specific
to
where
their
secrets
have
to
be
stored,
and
so
that
being
pluggable
is
I.
Think
key,
so
we
can't
actually
be
too
opinionated
here.
It's
just
one
thought:
if
we
want
to
bring
those
people
over,
you
know
building
a
bridge
from
where
they
are
and
lots
of
clouds,
but
the
thing
that
I've
been
thinking
about
a
lot.
F
You
said
brainstorms,
so
you're
the
thing
that
I
I
think
a
lot
about
is
like
this
is
part
of
wasm
Club,
but
really
at
a
layer
below
when
we're
building
things
with
components
and
we're
assembling
different
pieces
of
our
app
actor
our
actor
component,
it
will
have
other
components
that
I
don't
want
to
necessarily
have
all
of
the
secrets,
and
so
what
I'm
thinking
about
there
is
let's
say:
I've
got
a
piece
that
handles
vlogging
like
my
login
component.
F
Even
if
it's
a
built-in-
and
even
if
it's
part
of
Blossom
cloud
and
it's
trusted
in
everything,
I
still
don't
want
it
to
be
able
to
even
pull
off
of
the
contact
all
the
secrets
that
are
for,
like
my
database
provider
and
everything
else,
there's
so
much
more
that
we
can
do
now
with
the
component
abstraction
that
we
weren't
able
to
do
with
application.
F
Well
today,
right
because
my
mom's
not
exactly
here
yet
and
so
I
I
want
to
make
sure
that
whatever
we
design
isn't
I
mean,
isn't
just
a
grab
bag.
You
know
like
we're
doing
a
really
good
job
of
having
links
that
are
specific
to
capabilities
and
I
want
to
make
sure
that
that
level
of
granularity
persists,
even
internal
components
or
that
make
up
a
single
active
component.
E
But
yeah
I
think
I'm
next,
so,
with
a
having
another
grab,
bag,
I,
agree
and
I
thought
in
my
head
and
I,
don't
know
every
detail
of
Western
Claudia
so
bear
with
me
was
kind
of
on
a
link.
You
have
a
link
to
that
provider
right.
You
can
basically
say:
okay
for
this
link.
E
I
use
hash,
Vault
right,
you
link
to
that
provider,
and
then
you
have
this
interface,
where
you
can
get
your
secrets
and
how
that
works
in
the
background,
I
I
think
needs
to
be
needs
to
be
overnight,
because
you
cannot
predict
where
the
actor
is
going
to
be.
It
doesn't
have
connection
direct
connection
to
the
to
the
provider
or
to
some
API
external.
So
the
only
way
to
make
that
really
work,
I
think
is
currently
Nets
under
the
hood
yeah
and
you
know
the
other.
E
The
other
side
of
it
is,
and
how
do
you
define
that
interface
and
that
I
think
is
one?
Is
the
interface
just
for
the
call?
It's
kind
of
key
value
store
right,
some
somewhat,
but
also,
how
do
you
define
what
secret
you
want
to
reference
and
different
secret
provider
have
different
ways
of
having
an
ID
for
the
secret
right
and
that's
another
thing
where
we
internally
use
some
conventional
configuration
right.
We
came
to
a
standardized
way
from
our
consumer
assignment
yeah.
G
Because
it
kind
of
aligns
with
that
so
like
where
what
I'm?
Thinking
too
is,
if
you
you're
doing
it
through
like
a
link,
definition
and
then
you're
able
to
have
multiple
providers,
then
it's
easy
for
a
user
to
be
able
to
say
I'm
working
with
Azure
Corp
fault.
You
just
use
the
Vault
provider
I'm
working
with
AWS
secret
manager.
You
use
the
secret
manager
provider
and
then
the
interface
just
gives
it
to
what
like
Watson
cloud
watum
and
the
same
manner
that
it
can
process.
G
But
how
you
deal
with
those
Secrets
is
done
in
the
provider,
so
taking
those
formats
that
are
output,
but
it
it's.
It
might
also
be
interesting
that
if
you
can
manage
the
the
link
name
or
the
name
of
the
provider
to
break
it
down
for
specific
features
like
I'm
I,
imagine
you're
going
to
not
want
to
give
access
to
like
your
entire
secret
manager,
vaults
to
a
single
provider.
So
it
would
be
nice
to
be
able
to
say
you
know
this
micro
service
or
this
function
and
has
access
to
this
namespace
of
Secrets.
J
I
would
want
to
come
back
and
I
think
Bailey
really
nailed
it
on.
You
know
this
is
assault
decision
for
many
organizations
and
the
you
know,
plugability
and
frankly,
support
for
Vault
and
AWS
secret
managers,
probably
like
what
an
MVP
looks
like
here,
because
those
are
gonna.
That's
gonna
cover.
You
know
eighty
percent
of
the
market
or
more
on
day
one
and
it
that
would
give
us
an
established
pattern
to
sort
of
make
sure
that
it
shows
up
here
because
I
yeah,
possibly
Octan
one
pass.
J
What
I've
seen
on
the
Enterprise
side
is
almost
exclusively
ball.
You
know,
I
mean
I
I've
only
seen
a
handful
of
of
Enterprises
go
AWS
secret
manager,
but
that's
like
you
know,
that's
my
just
personal
anecdote
to
be
on
there.
A
Yeah
I
think
that's
a
great
call
out,
Liam
and
and
kind
of
it
touches
on
one
of
the
things
that
we
started
talking
about
too,
which
is
how
to
properly
store
secret
things
and
Nats
and,
and
the
answer
is
you're-
probably
right.
It's
not
that
it's
using
the
the
well-established
Secrets
providers
to
because
that's
what
people
are
already
going
to
be
using
I
feel
like
I
raised
my
hand
with
an
idea
in
mind
and
I.
A
Don't
remember
exactly
what
it
is
so
John
if
you,
if
you
want
to
go
ahead,
I'll,
try
to
think
of
what
I
was
going
to
say.
E
Just
want
to
add
that
world
and
everybody's
secret,
as
a
kind
of
Enterprise
level
thing
is,
is
absolutely
necessary,
but
to
to
have
a
slow
entry
barrier
to
not
think
about
Secrets
management
too
much,
but
still
be
reasonably
secure
and
that's
key
Value
Store,
as
a
Secrets
manager
kind
of
as
a
provider
is
also
should
also
be
kind
of
available,
so
people
can
be
without
any
big
configuration
of
any
secrets
manager
get
into
Wilson
clown
right.
E
The
other
thing
is
that
it's
also
I
think
important
how
how
then
this
those
secrets
are
provided
to
the
actor
actually
how
they
service
in
the
actor?
How
you
make
that
available
right,
there's
also
this
level
of
do.
We
is
there
environment,
variables,
kind
of
thing
right
where
you
have
the
risk
of
being
logged,
or
is
it
like
I
I,
come
from
kubernetes
were
like
mounted
like
a
file.
What
we
do
right
to
also
let
the
actor
read
it,
and
so
you
can
actually
rotate
everything
without
restarting
the
Pod
now.
E
This
is
not
so
relevant
in
miles
from
cloud,
but
might
be
a
a
thought.
A
Well,
I
mean
it's
running:
wasm
Cloud,
as
as
a
container
in
a
pod
is
you
know
right
now
our
recommended
kubernetes
strategy,
so
I
think
it's
really
valid
to
to
go
at
it.
From
that
angle,.
C
A
Okay,
well
we're
we're
getting
to
the
end
here.
I'm
gonna
try
to
summarize,
where
we've
gotten
with
this
discussion,
so
we
could
go
back
later
and
maybe
turn
this
into
like
an
RFC
or
a
little
more
formal,
so
that
we
can
keep
brainstorming.
A
We
certainly
need
to
have
a
way
for
components
in
wasm
Cloud
to
be
able
to
access
secrets
that
comes
in
a
couple
of
different
forms.
Actors
may
need
to
be
able
to
reference.
A
Secrets
capability
providers
may
need
to
be
able
to
reference
secrets
and
there's
going
to
be
difficulties
around
how
we
actually
take
a
a
secret
from
an
external
world
or
or
a
reference
to
a
secret
value,
whether
that's
a
lot
of
manifest
or
a
wash
command
and
then
turning
it
into
something
where
the
wasm
cloud
runtime
itself
can
pull
out
of
a
Secret
store
to
give
that
value
to
the
actor
or
the
capability
provider.
A
But
that
being
said,
the
first
class
kind
of
citizens
that
we
should
consider
supporting
will
probably
be
some
kind
of
Middle
Ground
secure
of
nats
key
value
store.
You
know
something
that
can
be
encrypted
at
rest,
but
may
not
be
a
fully
managed.
Secret
store
hash
record
Vault
because
of
its
prevalence
in
the
ecosystem,
and
then
maybe
AWS
Secrets
manager
and
designing
for
these.
A
couple
of
different
use
cases
will
give
us
a
nice
generic
look
of
of
what
the
the
generic
requirement
will
have
to
be.
A
There's
a
lot
of
questions
around
how
we
can
give
certain
components
access
to
certain
secrets.
We
don't
want
to
blow
up
our
capability
model
by
saying
once
you
have
access
to
the
secrets,
you
can
have
all
the
secrets,
but
more
more
discussion
and
brainstorming,
and
how
to
do
that
we'll
follow.
A
Let's
see
only
the
thing
I
can
add
is
that
this
I
guess
maybe
doesn't
necessarily
get
easier
or
harder,
but
there's
more
facets
to
it
once
we
start
talking
about
wasm
components,
because
you
want
your
application
component
to
have
access
to
a
secret,
but
maybe
not
the
components
that
you
pull
in
from
from
public
Registries
that
Implement
certain
pieces
of
functionality
Liam,
you
want
to
add
on.
J
A
little
more
there
I'm
sorry
I,
know
we're
a
time,
but
Bailey
I
would
love
to
hear
the
thinking
on
how
this
becomes
a
capability
Grant
to
each
component.
You
know
that's
what
I
feel
like
the
sort
of
like
each
secret
then
should
be
granted
as
a
capability
like,
or
would
it
be?
J
Maybe
that's
the
question
to
sort
of
noodle
on
how
that
might
manifest
itself
there
right
that
that
now,
like
I,
can't
believe
it
took
us
that
long
to
or
maybe
it
was
said
earlier
and
I
missed
it,
but
I
feel
like
that
feels
like
the
right
pattern
that
this
is
just
another
like
a
secret,
shows
up
then,
as
a
capability
grant,
that
you
can
then
give
to
a
component.
A
Jordan
I
wanted
to
throw
in
your
comment,
at
least
before
we
exit.
Do
you
want
to
say
it?
Do
you
want
me
to
say
it
yeah.
A
Okay,
Jordan
Jordan
left
the
comment
that
I
want
to
make
sure
we
capture
that.
Essentially,
what
was
on
cloud
should
be
trying
to
do
on
this
topic
is,
is
create
an
interface
in
order
to
access
and
and
manage
Secrets
and
outside
of
that
leave
the
hard
things
like
secrets
and
encryption
and
everything
to
the
to
the
professionals.
I
think
that's
a
a
good
thing
to
keep
in
our
mind.
So
we
don't
over
engineer
this
and
try
to
you
know
reinvent
the
wheel.
K
Yeah
I
know
I
know
it's
hard
right
now,
because
we
don't
have
all
those
professionals
like
writing
providers
yet,
but
it
will
come
if
we
Shore
up
the
interfaces,
give
them
something
really
solid
to
build
on.
It
will
come
but
yeah
to
your
point.
Maybe
there
needs
to
be
like
a
wasenclaw.
Built-In
secret
got
six
things
in
KV
store,
but
needs
to
have
a
big
old
disclaimer.
Don't
use
this
in
production
until
Nats
or
cenadia
says
this.
Is
a
production
sock
compliant
certified
place
to
keep
secrets
until
then?
You
just
can't.
A
Yeah
very
true,
well,
thank
you
Jordan,
for,
for
that
perspective,
it's
a
great
it's
a
great
point.
I
think
we're
going
to
continue
to
work
on
this
and
brainstorm
on
the
issue
in
the
wadham
repository,
because
that's
where
it
started,
we
may
end
up
moving
that
into
the
wasm
cloud.
Slash
wasn't
Cloud
repo
because
it
kind
of
affects
the
whole
ecosystem,
but
we'll
kind
of
approach
that,
from
there
I
know
that
we're
over
time.
Thank
you.
A
Everybody
for
staying
over
a
little
bit,
I
really
appreciate
you
spending
the
time
to
come
and
chat
and
I
really
loved
the
brainstorming
session
that
I
this
was.
This
was
really
productive
and
really
fun
to
chat
through
I.
Think
I
think
we'll
go
ahead
and
end
the
call
here
and
then,
as
usual,
everybody's
welcome
to
hang
out
for
a
little
bit
if
we
wanted
to
chat
a
little
bit
more.
So
thanks
everybody
for
for
tuning
in
talk
to
you
later.