►
From YouTube: wasmCloud Community Meeting - 21 Jun 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,
everybody
Welcome
to
wasm
Cloud
Wednesday
on
Wednesday
June
21st.
We've
got
a
demo-packed
agenda
today,
we're
actually
going
to
move
a
couple
of
things
around,
but
we're
going
to
start
with
two
demos
to
kick
off
the
call
and
then
we're
going
to
talk
about
a
discussion
item
which
we've
kind
of
kicked
off
before
in
a
few
scattered
issues
and
or
Community
calls.
A
But
I
really
want
to
set
aside
some
time
for
us
to
brainstorm
and
talk
about
the
secrets
in
awesome,
Cloud
applications,
discussion,
I,
think
this
will
be
a
really
interesting
one
to
go
through.
So
let's
go
ahead
and
get
started.
I
have
the
first
demo
here
as
titled
wasmcloud
Azure
web
Hooks
and
auto
updating
oci
URLs.
So
let
me
go
ahead
and
give
you
a
little
bit
of
motivation
around
what
what
this
demo
is
going
to
solve.
A
So
we've
had
a
decent
problem
in
the
wasm
cloud
ecosystem,
where
we
have
some
official
capability
providers,
and
example,
actors
that
we
publish
to
Azure
container
registry
or
just
as
a
webassembly
module
or
a
capability
provider
and
Azure
CR
natively
doesn't
support
unauthenticated
content
Discovery
as
an
oci
registry.
It's
an
optional
part
of
the
spec
I.
Guess
they
implement
it.
For
people
who
have
you
know,
authenticated
access
to
the
registry,
but
you
can't
go
to
watsonpod.azurecr.io
and
look
around
at
the
different
things
we
have
published.
A
B
A
You've
probably
seen
it
in
a
bunch
of
different
readme's
in
across
open
source
organizations,
just
the
I
can
just
show
you
know
this
kind
of
format.
It's
called
a
Shields
badge
super
useful,
and
so
what
we've
been
using
is
the
dynamic
Json
badge
where
you
can
essentially
use
their
API
provide
a
custom.
You
know
their
their
payload
and
it
will
give
you
a
nice
little
layout
here
for
the
the
capability
provider
URL.
A
So
next
to
all
of
our
capability
providers,
we
have
this
nice
little
badge,
it
actually
uses
the
pretty
sure
this
is
the
common
or
simple
icon
for
wozmo
cloud,
which
Jordan
helped
push
through
is
like
an
official
icon.
You
can
reference
to
which
is
really
cool
in
the
URL
and
all
of
that
now.
A
The
problem
with
this
is
that
readme's
in
GitHub
I,
don't
know
what
other
platforms
have,
but
the
markdown
doesn't
really
have
the
ability
to
run
a
custom
piece
of
code
like
you
can't
put
Javascript
in
here,
like
you
can
in
MDX,
so
you
can't
have
something
that
auto
updates
based
on
when
we
push
a
tag
to
GitHub,
for
example.
A
So
essentially
what
it
was
up
to
us
to
do
is
whenever
we
publish
a
new
version
of
the
capability
provider,
we
would
have
to
either
update
this
or
you
know,
just
a
couple
of
months
after
we
set
up
this
or
I
set
up.
This
project
called
oci
refer
and
it
used
a
very
sophisticated
algorithm
in
order
to
keep
track
of
the
actual
the
what's,
it
called
to
actually
keep
track
of
the
oci
URLs.
A
So
if
you
look
at
the
contents
of
this,
wasn't
Cloud
actor
before
we
effectively
had
it's
a
an
actor
that
implements
the
HTTP
server
contract.
We
had
a
shields.
This
is
the
kind
of
payload
that
Shields
expects
where
you
have
a
schema
version
and
a
message
and
a
logo.
So
we
have
the
wasm
cloud
logo
and
all
that
and
then
here's
the
AI
algorithm
for
determining
the
latest
provider
version
aka
me
hard
coding
it
in
the
actor
and
then
updating
it
whenever
we
publish
a
new
oci
version.
A
So
last
week,
I
kind
of
got
to
thinking
and
I
actually
got
around
to
a
suggestion
that
Jordan
who's
here
in
the
call
gave
me
a
long
time
ago,
which
is
the
fact
that
Azure
in
their
container
registry,
has
a
Web
book
that
you
can
call
after
it
pushes
a
new
image
version
to
that
to
Azure
CR
so
effectively.
What
we
have
now
is
whenever
we
push
up
a
new
capability
provider
or
an
example
actor
to
Azure,
it
will
send
this
payload
to
the
newest.
A
So
this
actually
worked
really
really
well
from
the
beginning.
I
hadn't
really
used
many
different
projects
that
have
web
hooks
that
that
quite
work
like
this,
but
the
Azure
docs
were
pretty
helpful.
It
offers
a
little
way
for
you
to
send
a
test:
URL
I'm,
just
hosting
my
actual
actor
in
cosmotic,
to
make
it
easy
to
like
expose
that
publicly.
A
Let
me
show
you
some
of
the
things
that
it
can
do
so.
The
first
easy
endpoint
is
that
if
you
actually
send
a
I
can
zoom
in
a
little
here.
If
you
send
a
curl
request
to
this
cosmotic
URL,
you
can
actually
ask
it
for
any
version
of
a
recently
published
thing
that
we've
pushed
for
for
wasmcloud.
So
if
we
ask
it
for
the
HTTP
server
URL,
it
can
it'll
respond
with
the
payload
format
that
shields.io
expects.
A
A
Even
some
of
the
new
example
actors,
like
the
actor
actor
call
ones.
Pinger
and
ponger
are
both
available
there.
So
really,
the
the
main
endpoint
that
we
can
use
here
is
by
is
fetching
an
oci
URL.
A
We
can
also
post
at
this
with
an
authentication
token
and
all
of
that
to
add
in
new
capability
providers,
but
one
thing
that
I
set
up
additionally,
is
this
notion
of
categories
and
I
think
this
is
going
to
be
really
useful.
We
can
use
the
same
actor.
The
same
kind
of
data
store,
that's
coming
right
out
of
azure
in
order
to
fetch
all
of
the
official
capability
providers.
A
So
this
one,
it's
the
slash
category
endpoint,
if
you
give
it
a
payload
with
the
category
name,
which
this
is
all
just
kind
of
set
up
manually.
This
will
actually
give
back
every
single
official
wasm
Cloud
capability
provider,
with
the
name
and
the
oci
URL,
and
then
I
think
I
also
set
one
up
for
actors
yep,
which
just
includes
Pinger
and
ponger
for
now,
but
this
effectively
gives
us
a
way.
A
I
know
that
it's
been,
you
know
it's
it's
kind
of
a
fun
gag
when
we
get
into
it's
kind
of
a
fun
gag
when
we
get
into
demos
and
things
like
Taylor
is
going
to
start,
the
newest
key
value
store,
and
he
says
oh
Brooks.
What's
the
latest
version
of
KV
redis
like
it's
fun
during
a
demo,
but
really
what
it
speaks
to
is
the
discoverability
of
our
capability
providers
and
so
having
them.
A
That's
auto
updating
something,
that's
really
robust,
so
we
we're
not
like
parsing
it
from
a
GitHub
tag
and
then,
assuming
that
it
made
it
into
Azure
CR
like
this
web
hook,
fires
whenever
a
new
image
is
pushed,
which
is
really
really
handy,
so
happy
to
kind
of
show
a
little
bit
more
around
the
code
like
effectively
what
what's
all
that's
really
happening
here
and
the
reason
why
it
was
so
easy
to
develop.
A
This
is
because
of
the
wasm
cloud
abstractions
like
I,
didn't
have
to
bring
in
HTTP
server
clients
or
key
Value
Store
like
libraries,
or
anything
like
that.
All
I
had
to
do
is:
do
a
nice
little
match
on
an
HTTP
request
and
then,
when
the
Azure
web
hook
comes
in
a
little
deserialize
form
up
the
actual
reference
for
the
oci
URL
and
then
I
call
this
store
reference
function,
which
is
just
a
little
bit
below.
A
We
just
use
a
key
value
sender
and
we
set
that
name
of
the
capability
provider
and
the
value
is
the
oci
URL.
So
it's
honestly
a
really
simple
solution
and
probably
should
have
carved
out
some
time
earlier
to
get
this
done,
because
you
know
I
think
Jordan
probably
suggested
this
web
hook
thing
to
me.
I,
don't
know
maybe
six
months
ago
and
I
thought
it
would
just
be.
You
know,
kind
of
hard
to
set
up,
but
it
really
ended
up
being
pretty
simple.
A
I
was
able
to
test
this
locally
using
redis
and
then,
when
I
actually
pushed
up
to
cosmonic
I
was
able
to
use
like
that
key
value
store
and
nothing
had
to
change.
Yada
yada.
It
was
all
all
pretty
fun.
There's
also,
you
know:
git
delete
kind
of
things
for
the
for
the
categories,
so
yeah
I
just
wanted
to
show
off
this
pretty
cool
this.
A
This
new
actor
I
actually
wanted
to
officially
show
it
updating
a
badge
but
I
refresh
this
page
on
accident
this
morning,
when
we
released
the
0.18.2
for
HTTP
server,
but
it
super
works
and
it's
pretty
clean
and
so
I
definitely
wanted
to
show
show
this
off
now
I'm
going
to
be
working
on
a
blog
post
to
talk
a
little
bit
more
in
depth
of
like
the
process
of
of
building
this,
and
maybe
other
things
that
you
could
do
I'm
like.
A
Maybe
a
more
common
web
hook
pattern,
but
for
now
you
guys
get
the
get
the
cool
demo.
Anybody
have
any
questions.
B
We're
ripping
you
a
little
about
having
a
body
on
your
git.
A
I
was
looking
at
all
that
in
the
chat,
so
the
question
was:
why
do
you
have
a
git
endpoint
with
the
body
which
is
a
good
point
and
I
mean
the
nice
thing?
Is
that
the
one
that's
set
up
with
Azure
is?
Is
a
post,
so
real
real
with
the
body
but
I
could
I
could
change
that?
A
A
Can
you
generate
an
open,
AI
spec
for
me
from
this,
and
it
actually
did
a
pretty
good
job,
so
one
thing
that
I'm
looking
at
experimenting
with
is
or
a
open
API
thank
you
generates
an
open,
API
spec
for
for
this
actor,
which
I
think
would
be
a
pretty
cool
thing
to
include
with
the
the
actor
itself,
because
it's
mostly
an
HTTP
API,
so
we'll.
A
All
right!
Well,
then,
I
guess
if
there
are
no
more
questions-
and
nobody
else
wants
to
rip
me
for
saying
this
wrong
thing
or
setting
up
a
git
endpoint
with
with
a
body
I
think
we
can
move
on
to
Bailey,
which
has
you
know
all
as
usual,
a
much
cooler
demo.
Then
all
of
us
could
put
together
but
Bailey
go
ahead,
not.
B
At
all,
mine
is
a
Hello
World
demo,
but
it's
hello
world
of
stuff.
You
might
not
have
ever
seen
before
so
wasn't
cloud
of
course,
Builds
on
webassembly
and
web
assembly
standards
and
there's
a
new
webassembly
standard
called
the
component
model
that
I've
talked
a
lot
about
through
past
past
Community
calls
and
Roman
has
been
working
towards
having
a
basically
a
a
component,
first
enabled
rest
host,
which
is
really
exciting,
and
we
have
a
RFC
out
there
about
that,
but
he's
pretty
early
in
in
that
exploration.
B
But
we
saw
a
kind
of
a
fun
demo
from
him
just
this
morning,
where
it's
showing
up
now
in
washboard,
which
is
like
a
cool
Milestone.
But
let
me
show
you
a
hello
world
with
components
so
with
the
component
model,
one
of
the
coolest
things
that
it
gives
you
is
the
ability
to
work
across
languages,
so
it
has
basically
ultimate
language.
Interoperability-
and,
you
might
say
oh
I've,
always
had
that
with
jni
or
CF
of
I
bindings
and
that's
kind
of
true.
B
Sometimes
the
way
you
have
to
do
that
is,
you
have
to
have
multiple
processes.
Maybe
you
had
to
manually
create
bindings.
Usually
it
means
it's
a
little
bit
harder
to
debug
and,
and
it's
always
these
separate
boundaries,
and
so
with
the
webassembly
component
model.
We
have
a
basically
in
a
lot
of
ways
like
another
language
that
defines
how
to
go
across
these
boundaries
and
that's
called
lifting
and
learning,
but
I
would
like
to
show
it
running
first,
so
I
am
going
to
go
into
a
host.
This
is
not
blossom
Cloud.
B
This
is
all
pure
by
code.
Alliance,
open
source,
stuff,
I'm
going
to
say,
cargo
run
and
all
it
prints
out
is
a
gopher
that
says
hey
and
crab.
That
says
hello,
so
that
part
is
kind
of
simple,
but
let's
dig
into
a
little
bit
on
the
guts
inside
our
rust
crate
for
the
restation.
B
This
part
might
look
mostly
familiar
for
folks,
because
I
think
a
lot
of
most
of
us
write
in
in
Rust,
so
it
takes
in
a
string
and
it
appends
to
that
string
and
just
says
hello,
and
so
the
purpose
of
this
demo
is
to
show
being
able
to
take
with
ideal
definitions
and
pass
in
high
level
types
like
strings,
which
we
weren't
able
to
do
before
with
webassembly
modules.
B
You
everything
is
basically
a
u32
and
one
assembly
modules
I'm
able
to
pass
that
through
all
the
way,
and
so
I
can
have
a
couple
different
Critters.
This
Critter
is
a
gopher
and
a
little
gopher
says:
hey
so
same
thing
as
the
rest
code,
I'm
able
to
pass
it
in,
and
so
what
I
think
is
pretty
cool
is
that
for
the
most
part,
I'm
writing
idiomatic
go
I'm
using
go
generate
to
generate
these
language
bindings
and
so
the
the
script
for
basically
building
something
like
this.
B
If
I
go
into
I,
guess
side
of
things
and
step
into
Go,
Gopher
Jordan,
this
is
for
you,
I
run,
go
generate
and
then
tiny
go
I,
Target
wazzy,
so
I
Target,
normal
wazzy
preview,
1
stuff,
because
basically
no
language
today
supports
wazzy
preview
to
you
and
wazzy.
Preview
2
is
where
the
component
model
is
implemented
for
the
first
time,
and
so,
if
I
were
to
print
that
out
and
say,
okay,
what
what?
What
did
I
actually
just
do.
Let's
look
at
griffer
Dot,
don't
say
that
go
for
that.
B
What
then
you'll
see
that
the
thing
I
just
built
was
a
module
and,
like
I,
said
with
modules,
a
bunch
of
numbers
in
a
trench
coat
and
now
the
next
step
is
to
take
this
wit
file
that
I
created
this
wit
IDL
definition
of
the
API,
which
is
hello
world,
basically
a
string
print
line,
but
put
this
interface
definition
inside
the
module
that
I
created
and
so
to
do
that.
B
B
Let
me
see
if
this
works,
because
I
don't
think
I
set
the
right
place.
Okay,
cool
takes
a
component
adapter,
so
this
is
actually
a
wazza
module
itself,
but
it
takes
a
wazzy
preview,
one
module
and
adapts
it
to
now
match
the
component
model.
So
if
I
do
the
same
thing,
that
I
did
before
by
doing
Blossom
tools
print
on
my
now
my
component.
Well
as
a
module
wasm
component,
not
a
wazen
module.
C
B
I
open
this
up,
what
I'll
see
is
that
I
actually
got
a
component
out
and
that's
pretty
handy
and
you
can
tell
it's
a
component
because
it
now
has
instances
it
talks
about
using
interfaces
streams,
a
lot
of
new
things
that
are
available
as
part
of
wazzy
preview
2.
B
and
at
the
very
very
bottom
of
this
you'll
see
what
my
exports
are
and
the
export
that
I'm
able
to
call
is
the
component
greeting
example
and
I'm
able
to
call
a
function
called
hello,
and
so
that's
why,
in
my
top
level
component
that
combines
both
the
jump
to
it,
both
the
restation
and
the
Gopher
here
I
am
able
to
call
each
one
of
them.
So
I'm
able
to
call
my
girlfriend
component,
my
restation
component
from
one
top
level
component
for
each
of
those
and
without
really
any
extra
code
inside
my
application
code.
B
That's
able
to
benefit
from
these
libraries
written
in
any
language,
I
can
call
them
seamlessly
and
all
in
the
same
process
and
I
think
that's
that's
Pretty
stinking
goal.
So
here's
your
hello
world
components
which
is
now
available
for
the
first
time
in
lazom
time.
10.
I'll
be
announcing
that
in
the
by
code,
Alliance
Community
stream
on
Tuesday,
but
everybody
here
gets
an
early
preview.
A
Bailey,
thank
you
for
I
mean
I
got
to
see
this
talk
in
person,
so
I've
definitely
taken
a
look
at
this
before,
but
I
really
appreciated
the
you
know.
Actually,
looking
at
what
like
the
web
assembly,
module
looks
like
in
the
text
format
afterwards
and
you
know
getting
a
look
at
the
interfaces
and
you
know
really
what
this
is
low
level
and
I.
A
I
know
that
there's
a
whole
other
discussion
around
what
this
will
look
like
when
you
actually
get
to
when
you
actually
get
to
using
tooling,
to
interact
with
components
but
I
want
to
make
sure
that
I
don't
monopolize
the
time
as
usual,
with
all
the
questions
usually
get
one
in
the
chat
which
looks
like
you
already
responded
to.
B
But
this
is
this
is
my
host
code,
so
wasn't
Cloud
has
a
host
and
it
embeds
a
webassembly
runtime
blasom
time,
as
the
question
already
implies,
and
so
for
this
one
I'm
able
to
show
that
I
I
use
one
config,
I
I
said
a
couple
new
things
like
hey:
the
wasn't
component
model
is
available,
so
you
set
that
to
True
and
then
I
directly
am
passing
in
my
DOT
wasm
here.
I
can
also
show
how
I'm
able
to
do
this
straight
from
what
this
was.
B
The
simplest
watt
that
I
could
come
up
with
for
defining
a
component.
So
touching
back
on
what
Brooks
was
saying.
I
I
think
it's
really
interesting
to
talk
about
how
a
component
is
really
a
bunch
of
webassembly
core
modules
underneath
so
I
call
webassembly
modules,
a
bunch
of
numbers
in
a
trench
coat
and
then
a
component
is
really
a
bunch
of
webassembly
modules
and
trench
codes
pointing
at
each
other,
and
that's
really.
The
trick
is
a
figuring
out.
How
to
lift
and
lower
types
between
something
like
this?
B
That's
adding
five
to
the
thing
that's
passed
in
and
being
able
to
have
a
basically
a
component,
a
and
component
B,
where
I'm
I'm
able
to
add
that
number
to
to
both
of
them,
so
I,
instantiate
and
then
I
run
run.
My
run
function
is
the
thing
that
just
adds
five,
so
this
might
be.
This
might
be
a
little
too
binary
stuff.
B
So
I
didn't
run
this
one
in
the
qcon
demo,
but
the
purpose
of
it
was
to
kind
of
show
that
by
creating
a
single
instance
of
a
component,
it
has
all
of
those
other
components
inside
it.
B
And
so
then,
when
I
I
say,
run
I
run
that
top
level
function
run
and
then
that's
what's
giving
me
that
result
that
prints
out,
and
so,
if
I
jump
back
to
the
rust
crates,
app
you'll
see
that
I
have
this
run
function
and
that's
what
I'm
calling
it
the
top
level,
and
so
my
my
host
code
knows
to
just
directly
call
run
here
for
the
demo
looks
like
we
might.
Is
there
a
remap
for
talking
to
another?
B
Wasn't
time
I
think
if
you
want
to
have
multiple
host
instances
working
with
each
other,
you
should
use
something
like
awesome,
Cloud,
it's
a
really
great
tool
to
distribute
and
orchestrate
having
multiple
webassembly
instances
having
multiple
instances
talk
to
each
other.
Isn't
too
hard
in
that?
If
I
modify
my
host
code
here
right
now,
I
said:
hey
get
get
one
instance
instantiated
with
that
component.
I
could
have
another
one
instincture
with
that
component.
B
A
Bailey,
you
can
correct
me
if
I'm,
if
I'm
wrong,
but
just
along
lines
of
the
same
question,
I,
remember
Luke,
giving
a
talk
last
year
at
kubecon
in
Detroit
and
was
talking
about
the
component
model
and
I
seem
to
remember
him,
saying
that
distributed
components
were
explicitly
out
of
scope
for
the
component
model
proposal.
A
B
That
that
is
explicitly
out
of
the
scope
and
if
you
go
to
the
goals
of
the
component
model
within
the
component
model,
repo
that
that's
stated
as
a
non-goal
like
that's
explicitly
out,
things
that
are
in
is
being
able
to
have
support
for
async
and
streams,
which
is
going
to
come
with
wazzy
preview.
Three,
so
the
stuff
I've
been
talking
about
is
pre
that
that
this
is
preview.
Two.
B
But
there's
no
reason
why
one
host
can't
have
multiple
instances
of
a
component
and
then
figure
out
how
to
wire
them
together
that
that's
not
too
bad.
You
know
a
couple
more
lines
of
my
little
my
little
rest
host
here
and
if,
if
you
want
it
to
play
around
you're
welcome
to
grab
it
I
dropped
it
over
earlier
in
our
chat,
I'm
gonna
drop
again
just
in
case
just
know,
you
know:
hey,
that's!
That's
hello!
A
Okay,
awesome
I
just
wanted
to
make
sure
I
posted
that
on
the
YouTube
as
well,
so
everybody
could
get
that.
A
Let's
see
Vance,
you
had
I'm
actually
not
familiar
with
cxl,
so
maybe
it's
something
that
somebody
else
knows
about
around
linking
different
components
together
or
runtime.
D
It's
about
distributed
memory,
so
it's
a
little
bit
futuristic!
Let's,
let's
leave
that
for
now.
C
Oh
just
a
quick
question
on
that:
would
you
actually
have
to
do
you
have
to
implement
software
I?
Guess?
Because
it's
in
memory
you
would
literally
have
to
implement
it
at
the
software
level.
Does
it
end
up
in
the
kernel
in
Linux?
C
D
What
cxl
does
is
it's
an
extension
to
PCI,
so
it
it
uses
PCI,
it
runs
over
PCI
and
it
distributes
memory,
and
so
what
what
you're
able
to
do
then
is
have
code
executing
on
some
CPUs
over
there
use
memory
that's
available
over
there
right
and,
and
you
can
it's
it's
just
memory,
it's
just
addressable
memory
and
that
that's
how
components
share
right
with
memory.
So
what
you
need
is
a
runtime
that
knows
how
to
orchestrate
that
and
so
that
that's
a
big
if.
A
A
We
have
one
more
thing
left
on
the
agenda
for
today:
I
wanted
to
leave
a
little
bit
of
time
for
people
to
share
their
thoughts
and
kind
of
chip
in
on
a
brainstorm,
around
secrets
and
wasm
glad
applications
I
believe
we
kicked
off
this
discussion
first
on
an
issue
in
the
wadham
repository,
and
you
know
we're
kind
of
talking
about
taking
a
secret,
whether
it's
from
an
environment
variable
when
you
apply
a
like
an
application,
manifest
or
or
just
generally
a
secret
value
that
you
want
to
use
within
wasmcloud
and
I.
A
A
So,
whenever
we
release
gosh,
what
we
do
is
we
publish
a
tag
in
the
wash
repo,
and
then
we
have
two
repositories
for
for
home
brew
and
for
chocolaty,
where
we
basically
have
to
update
a
Shaw,
and
then
you
know,
update
the
version
and
then
push
to
those
package
managers
and
they
both
kind
of
require
their
own
little
special
format
for
the
repository
and
a
special
payload,
and
they
have
their
own
process
and
all
that
and
of
course,
the
people
you
know
all
of
us
are
on
the
maintainer
side
of
quasim
side
are
a
little
more
interested
in
trying
to
work
on
features
and
new
things
for
wasm
cloud
than
you
know,
trying
to
make
the
perfect
way
to
distribute
to
all
the
package
managers.
A
So
when
I
wrote
the
web
hook
thing
for
oci
URLs
I
actually
started
by
trying
to
make
an
actor
that
would
call
the
GitHub
actions
API
to
basically
trigger
an
action
in
a
different
repository.
What
would
be
cool
is
if
I
could
basically
take
the
the
existing
release
process
and
as
soon
as
the
wash
release
finishes,
we
say:
hey
go
call
the
Homebrew
in
the
chocolatey
repos
actions
to
kick
off
a
release
with
the
new
version.
A
Github
doesn't
natively
have
support
to
trigger
an
action
in
a
different
repo,
but
you
can
do
it
with
an
action
with
something
called.
What
is
it
called?
It's
called
the
workflow
dispatch
trigger
I
believe
I'll
have
to
double
check
on
you
know
what
I
started
handling
so
here's
the
actor
that
I
actually
started.
A
Writing
very
creative
name,
wash
releaser
webhook
actor,
but
it
has
a
really
simple,
simple
thing
that
basically,
whenever
it
receives
a
post
request
to
slash
API,
slash
Homebrew,
we
take
the
tag
with
the
ideas
that,
after
we
publish
a
release
in
wash,
we
send
a
request
to
this
actor
and
then
it
will
form
an
HTTP
request
to
say:
hey,
go
in
The,
Homebrew,
wasn't
Cloud
repository
and
kick
off
an
action,
and
the
way
to
do
this
is
really
simple.
I
I
took
the
example
from
the
GitHub
API
docs.
A
You
basically
just
say:
hey
I'm,
going
to
send
you
some
Json,
here's,
the
GitHub
API
version
I'm
using
and
you
can
send
whatever
information
you
want.
With
this
request.
So
I'm
going
to
send
you
know
the
the
body
all
I'm
doing
is
I'm
just
going
to
send
the
tag
you
know.
I
could
send
additional
things
like
whether
or
not
to
just
create
a
pull
request
and
then
or
just
like
dry
run
it
or
something
like
that.
But
the
key
thing
and
exactly
where
I
stopped
was
right
here.
A
So
in
order
to
actually
tell
a
repository
to
kick
off
an
action,
you
have
to
have
workflow
permissions
in
that
repository.
If
even
if
you
could
set
it
up
to
be
public
and
not
require
this
authorization,
that
would
just
mean
that
anybody
could
come
and
kick
off
a
new
release
of
wash
from
you
know
an
arbitrary
tag
which
you
know
at
best
will
just
not
work
and
at
worst
May
release
like
a
new
version
of
watch
that
we
weren't
intending
to
or
a
broken
version
to
Homebrew.
A
So
you
need
a
bearer
token,
and
so
you
know
of
course,
I'm
not
just
just
a
general
know
for
people
who
are
working
in
webassembly.
Who
may
not
know
this.
Whenever
you
create
an
a
webassembly
application,
you
know
you
compile
it
to
webassembly.
Everything
is
included
in
that
app.
So
if
I
were
to
create
like
a
secret,
constant
and
call
lit,
aha
I
am
a
secret
and
we
compile
this
webassembly
module.
I,
don't
actually
know
if
you
can
directly
find
this
out
or
not
I
think
I
have
this
release.
A
If
I
look
at
this
and
the
actual
Watt,
maybe
you
can't
find
the
the
code
directly
but
effectively
whenever
you
it's,
probably
because
it's
not
used,
and
so
it's
getting
compiled
out.
A
So
when
you
add
when,
if
you
put
a
secret
into
the
code
here,
if
I
were
to
just
directly
inject
my
token,
even
if
I
kept
everything
closed
sore
closed
Source,
the
fact
that
this
is
a
web
assembly
module,
anybody
can
download
it.
They
would
be
able
to
see
my
secret.
A
So
you
know
that
kind
of
brings
us
to
the
status
quo
around
okay.
What
do
you
do,
then?
If
you
have
a
secret
value?
Oh,
it's
in
an
i32
form,
okay,
cool!
Thank
you,
Billy
I
figured
that
makes
sense.
So
if
you
actually
have
a
token
here,
my
next
thought
is
okay.
Well,
I'll
just
take
the
token
and
I
can
store
it
in
a
Secrets
provider
like
cash,
core
Vault
and
then
here
right
before
you
know,
I
can
use
a
key
value.
Sender
and
I
can
oh
thanks.
A
Copilot
yeah,
nice
I
I
could
like
fetch
the
secret
from
the
key
value
sender
and
get
it
out
of
a
key,
a
Secret
store
like
Vault
and
then
should
be
good
to
go.
But
one
thing
that
I
noticed
after
that
is
that
even
if
I
were
to
put
the
secret
into
a
Secret
store
and
then
I
fetch
the
secret
out
and
I
use
it
in
this
header,
when
I
send
this
HTTP
request,
it
doesn't
actually
originate
from
this
actor.
A
What
it
does
first
is
it
sends
an
RPC
call
over
Nats,
which
then
makes
it
to
the
HTTP
client
and
then
we'll
send
out
that
HTTP
request
for
me.
So
as
long
as
I
trust
the
HTTP
client
on
the
other
side,
then
that's
fine,
but
it
will
definitely
go.
It
will
transmit
the
secret
over
the
Nats
connection,
which
by
default,
is
really
protected.
When
you
have
the
RPC
Connection
in
wasm
Cloud,
you
know
you
can
enable
TLS,
depending
on
the
setup
that
you
have,
you
can
have
it.
You
know
be
protected
by
keys.
A
So
this
isn't
exactly
a
public
connection
that
you
could
Snoop
on,
but
it
certainly
increases
the
radius
that
that
people
are.
You
know,
moving
a
secret
around
so
I
I
wanted
to
approach
this
from
the
wasm
cloud
developer.
Standpoint
of
you
know:
I
have
this
secret
value
that
I
don't
really
want
to
treat
like
a
config
variable
like
it's,
not
just
a
you.
D
A
Having
a
GitHub
personal
access,
token
is
actually
a
pretty
permissive
token,
depending
on
how
you
restrict
the
Scopes,
and
there
were
a
couple
of
good
ideas.
I
brought
this
up
in
in
slack
briefly,
I
know
that
Kevin
had
a
good
idea
around
how
basically,
what
one
of
the
things
that
I
could
be
asking
for.
One
of
the
possible
solutions
is
taking
something
like
tokenization
and
making
it
a
first
class
aspect
of
the
lattice.
So
you
can
take
a
secret.
A
A
This
is
a
pattern
we
used
to
use
all
the
time
on
one
of
my
old
teams
at
Capital
One,
but
there's
many
different
use
cases
here
and
so
I
wanted
to
open
up
the
a
broader
discussion
around
some
ways
to
solve
this
specific
problem,
and
if
anyone
has
worked
with
an
app
before
in
wasm
cloud
and
tried
to
use
a
secret
in
this
way
and
found
that
it
wasn't
enough.
I
wanted
to
leave
some
some
open
time
to
chat
about
that.
C
Hey
yeah,
so
I
guess
this
has
been
fueled
a
little
bit
more
by
my
experience
with
other
secret
providers.
Other
systems
that
you
know
whether
it's
LastPass
CLI
or
onepass
CLI
and
using
it
with
configuration,
Management
systems
or
it's.
C
You
know
the
kubernetes
I'll
lower
my
hand
since
I'm
talking
working
with
like
the
way
that
kubernetes
used
to
do
secrets
and
then
has
added
support
for
it.
I
started
writing
like
a
little
bit
of
an
RFC
or
just
trying
to
write
down
my
thoughts
on
how
I
think
they
should
work
and
I
guess
the
big
question
that
I
have
for
you
in,
like
your
experience
with
it,
is
like
that
last
thing
that
you
just
said
just
now,
where
you
you've
worked
in
other
teams
where
you
pass
a
reference.
C
Is
that
I
guess
from
the
actor
development
point
of
view
like
looking
at
your
code?
The
way
you
did
it,
it
seems
really
nice.
The
idea
that
you
could
like
like
I,
don't
even
want
to
think
about
I
just
want
to
tell
this
provider
like
when
you're
actually
executing
the
request.
C
For
me,
just
go,
look
up
or
see
if
you
can
get
this
value,
but
but
the
question
that
pops
up
for
me
is
one:
does
that
feel
that
good
that
we
want
it
that
way
and
two
does
that
make
mean
that
we
discover
exceptions
and
missing
Secrets
at
runtime.
A
Yeah,
it's
a
great
it's
a
great
question,
so
maybe
just
a
format
right
around
this
specific
use
case.
Basically,
like
the
exact
permission
that
I
would
want.
Is
you
know
what
this
the
secret
value?
I
I
only
want
it
to
be
present
on
the
HTTP
header,
when
it's
going
out
on
the
HTTP
client
request
like
I?
Don't
want
it
to
be
a
real
value
as
I'm
fetching
it
out
of
The
Secret
store
I,
don't
want
the
actor
to
be
able
to
log
the
real
value.
I!
A
Don't
want
the
provider
to
be
able
to
log
the
real
value.
I
just
want
the
provider
to
be
able
to
take,
take
it
put
it
on
the
header
and
then
send
it
out
and
I
think
actually
controlling
that,
so
that
the
provider
couldn't
access
the
value
directly,
but
could
use
it
for
the
purposes
that
I
intend
is,
is
probably
a
little
harder.
A
I
I
could
see
us
getting
into
really
fine-grained
control
of
Secrets,
which
is
probably
a
good
idea,
but
I
don't
want
it
to
be
too
hard
to
use
I
guess
the
only
other
comment
that
I
would
have
there.
Is
that
specifically
I?
A
Don't
want
to
have
a
some
kind
of
config,
where
I
can
create
a
secret
for
this
actor,
or
maybe
a
collection
of
actors
and
make
it
so
that
every
single
capability
or
every
single
thing
that
can
receive
an
RPC
call
from
this
actor,
can't
access
that
secret
I
feel
like
we
get
into
the
same
problem
with
the
whole
analogy
of
the
the
keys
to
the
kingdom
that
we
have
now
with
capabilities
in
in
open
source
projects,
where,
if
you
give
an
open
source,
Library
the
permission
to
access
files,
then
all
of
the
you
know,
libraries
that
that
Library
depends
on
has
the
same
permissions
that
you
gave
it
and
I
don't
want
to
fall
into
that
track,
because
it's
very
antithetical
to
what
we're
trying
to
do
with
with
webassembly.
C
Yeah,
so
so
my
the
the
RFC
I'm
working
on
or
the
the
are
we.
How
would
we
submit
or
how
should
I,
submit
like
a
stab
to
wasmcloud
at
like
trying
to
define
something.
B
I
really
like
what
Kevin
did
most
recently,
which
is
he
started
with
the
hack,
MD
I
kind
of
shared
that
around,
and
you
know
he
integrated
on
a
whole
bunch.
It
came
with
a
totally
different
solution
than
what
he
initially
proposed.
That's
like
really
simple
and
really
good
and
then
I
think
the
process
is
put
it
in
a
GitHub
issue
on
wasmcloud
wasn't
cloud
and
label
it
RFC,
like
some
of
the
other
ones
that
specifically
Kevin's
been
putting
in
I
really
like
that.
B
Because
then
an
RFC
right
is
is
a
request
for
comments.
So
the
goal
of
putting
that
out
there
is
to
get
more
feedback
from
people
that
are
in
the
community
that
are
using
it
or
thinking
about
using
it,
but
I
find
that
starting
with
a
hack
MD
is
a
lot
easier
way
to
collaborate
for
that
initial
stab
at
something,
because
that
initial
stab
tends
to
evolve
a
lot
before
you
get
to
somewhere,
where
it's
like.
Okay,
this.
Let's
talk
about
this
specific
thing
now.
C
Sweet
yeah
so
I
my
basic
idea,
Brooks
was
like
basic:
have
secret
providers
actually
be
a
first
class?
You
know,
we've
got
link
deaths
that
are
first
class
actors
providers
and
I
think
that
we
need
both
as
I
was
going
through
it
last
week
and
I
was
trying
to
like
just
noodle
on
it
like.
C
Not
only
do
we
need
Secrets
as
a
first
class
thing,
but
I
think
we
actually
need
secret
providers
because
then
you
can
hide
away
stuff,
like
oh,
like
I'm
doing
local
Dev
and
I
just
want
to
access
an
environment,
variable
or
I'm
doing
local
Dev
and
I
want
a
plain,
Tech
secret
that
lives
you
know,
I
can
create
it
and
it
lives.
In
this
single
instance.
C
I
think
this
is
a
this
is
very
similar
to
when
we
did
like
local
file
start
for
the
actor
and
it
was
like.
Oh,
there
is
a
subset
of
this
feature
that,
like
it,
really
makes
sense
for
local
Dev.
It
really
makes
things
move
quicker
for
me,
but
when
you
go
to
prod,
it
should
be
turned
off
by
default.
Like
never
use
this
version
of
that
thing.
C
Unless
maybe
you
know
what
you're
doing
or
you
feel
like,
you
know
what
you're
doing
and
then
yeah
so
I
think
when
you
create
a
like,
if
you
had
first
class
secret
providers
and
then
you
could
create
secrets
that
are
like
of
a
specific
type
in
that
specific
secret
provider,
then
we
could
then
take
that
and
at
linked
up
definition,
time
or
provider
config
definition
time
we
could
effectively
reference
those
and
then
everything
kind
of
like
has
its
own
domain.
A
Yeah
I
think
that
makes
a
lot
of
sense.
Thank
you,
Patrick
for
for
kind
of
running
with
this
I'm
glad
this
was
kind
of
in
the
back.
Your
head,
I
think
you
I
think
you
have
a
lot
of
really
good
thoughts
around
how
we
should
manage
secrets
in
this
way.
A
Yeah
I
really
wanted
to
maybe
I
think
Kevin
is
going
to
probably
talk
about
this,
but
I
think
the
difference
between
you
know
getting
something
working
locally
and
iterating
in
that
way
where
you
know,
maybe,
when
I'm
just
unit
testing
the
actor
or
throwing
something
together,
I'm
just
gonna
put
in
a
fake
GitHub
token
and
I'm
just
gonna
make
sure
the
whole
flow
works
properly.
A
Would
love
to
be
able
to
do
something
like
just
set
up
an
environment
variable
when
I
launch
the
host,
or
you
know
basically
inject
a
secret
into
the
you
know.
Maybe
we
use
something
like
a
Nats
KV
bucket,
for
you
know
basically
like
old,
kubernetes
Secrets,
where
things
were
base64
encoded,
but
not
encrypted,
not
not
really
secrets,
and
then
I
do
want
to
talk
about
in
terms
of
like
when
we
have
secrets
a
Secrets
provider.
E
What
I
think
we
probably
should
make
sure
we
do
is
separate
the
different
types
of
use,
cases
that
we
need
for
secrets,
so
one
that
I
think
we've
been
talking
about
is
where
I've
got
an
actor
that
needs
to
make
an
HTTP
call
to
some
API
and
I
need
a
bearer
token
to
put
on
that
call,
and
so,
where
do
I
get
that
from
as
an
actor
and
in
the
simplest
case
we
can
just
use
the
Vault
provider
that
we
have
that
implements
the
key
value
contract.
E
So
if,
if
your
key
store
is
something
that
can
be
exposed,
as
though
or
if
your
your
Secret
store
is
something
that
can
expose
a
key
value
style
API,
then
that's
a
fairly
easy
thing
for
actors
to
go
query,
because
then
you
set
up
a
link
definition:
the
actor
can
get
the
secret.
Nobody
else
sees
it.
You
can
control
all
the
permissions
based
on
linked
apps,
so
that's
one
type
of
secret.
E
Another
one
is
where
you
need
the
information
as
transmitted
to
remain
secret
and
so
I
think
that's
a
different
problem
with
the
potentially
different
solution
and
so
I
guess
what
I?
What
I'm,
where
I'm,
I'm
trying
to
list
off
use
cases
when
I'm
trying
to
and
Patrick
you
can
probably
enumerate
this
is
when
would
you
need
something
like
a
secret
provider
that
exposes
secrets
to
things
on
the
lattice
versus
a
capability
provider
that
exposes
Secrets
through
one
of
our
already
well-known
contracts.
D
C
Do
you
is
it
cool
if
I
answer
that
Brooks
all
right,
sweet,
so
yeah
I,
guess
it's
you
can
always,
in
my
opinion,
I
think
you
can
always.
You
know.
Implement
Direct
calls
to
a
secret
provider
like
or
yeah
capability
provider
for
a
given
Secret
store,
but
I
think
the
it
gets
away
from
our
boilerplate
free
kind
of
value.
That
I
think
that
we
have
in
Western
cloud,
and
so
you
know
like
to
me
that
it's
that's.
C
The
definition
of
boilerplate
is
like
I
just
need
a
value
that
I
can
talk
to
this
thing
and,
like
I,
want
to
focus
completely
on
talking
to
the
thing
so
I
yeah,
I
I,
don't
disagree
at
all
and
when
I
put
plus
100
in
the
chat
I
totally
like
there's.
No
reason
why
you
can't
do
all
this
stuff
today
with
either
a
custom
capability
provider
or
even
the
Vault
one.
C
You
know
if
you're,
using
Vault,
like
yes
by
all
means,
use
that
to
grab
your
secret
and
then
make
your
call
I,
can't
think
of
any
reason
why
you
could,
if,
like
that,
was
the
pattern
and
like
even
if
you
had
like
amazing
co-generation,
that
just
made
that
trivial,
you
could
always
use
a
capability
provider.
C
C
You
know,
basically,
if
you're
co-located,
with
a
machine
that
has
a
vault,
you
know,
has
the
Vault
secret
provider
configured
and
by
the
way
that
Vault
secret
provider,
because
it
understands
that
caching
is
a
thing.
It
can
cache
that
secret
and
it
knows
that
a
Secret's
going
to
expire
in
30
minutes,
but
by
the
way
like
it's
in
Ram
already.
So
you
can
just
make
this
call
like
I
think
things
get
a
lot
faster
and
it
gives
us
the
ability
to
be
more
performant
in
specific
cases,
but
yeah
there's
nothing.
C
A
I
think
I
think
that
makes
sense,
Patrick
and
along
the
lines
of
what
Jordan
just
put
as
a
comment
is
actually
exactly
what
what
I
wanted
to
talk
about
too.
What
what
he
said,
Jordan
you're,
welcome
to
talk
about
it
too.
It's
talking
about
what
I'm
rescheduling
an
actor
to
another
machine
or
something
like
that.
A
It's
really
important
to
differentiate
between
the
local
development
I'm,
just
trying
to
get
it
done,
I
want
to
test
the
functionality
and
then
move
it
to
prod
later
and
that's
what
wasmcloud
does
so
so
well
and
then
you
know
the
real
solution
when
you're
running
this
application
in
a
production
type
environment,
people
have
so
many
different
solutions
and
vendors
that
they
use
for
a
Secrets
manager.
A
You
know
it's
not
just
Vault
people
use
AWS,
Secrets
manager,
all
the
time
being
able
to
manage
those
permissions
with
your
other
parts
of
your
application,
especially
in
the
cloud
ecosystem,
is
really
important,
and
so
I
know
that
there's
going
to
be
a
little
bit
of
an
inverse
relationship
right
when
we
start
on
just
making
something
work
as
easy
as
possible
locally
for
iterating
and
creating
something
generic
enough.
That
people
can
bring
their
own
Secrets
provider
so,
whether
it's
fault
or
Secrets
manager
or
you
know
other
clouds,
Secrets
manager
or
key
manager.
A
Anything
like
that,
so
it
has
to
plug
into
existing
secret
stores
and
I
just
want
to
be
super
clear,
and
anybody
can
correct
me
if,
if
I'm
wrong
here,
but
wasn't
Cloud,
isn't
really
trying
to
be
in
the
business
of
implementing
a
Secret
store.
We
we
don't
want
to
be
managing
the
complex
details
around
caching,
Secrets,
making
sure
that
they're
super
safe,
like
they're,
very
well
defined
and
very
well
implemented
solutions
for
this
already.
A
So
my
whole
goal
for
this
discussion
is
to
get
exactly
what
I
think
Kevin
is
is
pushing
towards
which
is
let's
write
down.
Let's
get
some
use
cases
down
for
when
we
want
to
be
able
to
use
a
secret
and
see
if
we
can
go
from
there
for
implementing
with
a
Secrets
provider,
maybe
evolved
to
start,
but
having
it.
Generic
in
a
way
would
be
would
be
great.
A
There
was
also
a
comment
on
our
live
stream
about
how
taking
a
secret,
essentially
just
in
time,
from
a
Secrets
provider,
and
then
you
know
making
a
request
to
The
Secret
store
and
then
tokenizing
it
over.
Nats
is
a
pretty
sophisticated
use
case,
and
you
know
as
as
much
as
I
want
to
have
the
most
secure
solution
as
possible.
I
want
to
have
something
that
doesn't
incur
such
a
such
a
penalty
for
for
running
applications,
so
I'm
really
interested
to
see
what
what
we
can
come
up
with
as
we
keep
talking
about
it.
A
B
Yeah
I
mean
I,
think
my
perspective
on
it's
really
similar
to
Patrick's
in
that
I.
You
know,
I
I
have
some
kubernetes
goggles,
sometimes
when
I
look
at
things
and
one
of
the
things
that
I
really
liked
with
kubernetes
was
that
I
had
a
place
where
I
defined
what
my
secrets
were
and
I
see
a
logical
place
for
how
to
do
that
on
some
of
my
linked
definitions.
B
Obviously
I
don't
want
to
put
my
secret
plain
text
in
the
file,
but
I
would
like
to
say:
hey
I
have
a
secret
and
it's
this
key
and
then
something
figures
out
how
to
use
a
secret
manager,
whether
that's
their
capability
provider
or
something
else
but
links
all
of
that
together.
For
me,
as
a
developer,
like
I
want
to
be
able
to
say
what
my
secrets
are
and
I
might
not
even
be
the
person
that
has
the
powers
to
like
mess
around
with
Secrets.
B
C
Yeah
I
think,
as
we
start
to
see
like
changes
in
performance
not
having
to
I,
think
the
overhead
of
calling
out
to
a
provider
which
then
possibly
hits
local
cash
or
possibly
hits
whatever.
You
know,
Secret
store
it's
trying
to
talk
to
which
could
be.
You
know,
I'm
thinking
of
an
annoying
case
where
it's
like
AWS,
CSM
or
I.
Forget,
if
that's
the
right,
the
what
you
call
it
the
right
service
name
but
like
it
reaches
out
to
AWS,
but
oh
wait.
C
It's
in
a
different
region,
and
so
now
you've
got
a
200
400
millisecond
lag
on
just
getting
the
secret
and
by
the
way
that
secret
provider
is,
you
know,
I
I
assume.
If
we
get
more
maintainers,
the
AWS
ones
will
naturally
get
more
attention.
C
Just
because
AWS
is
so
big
but
say
it's
like
you
know,
I,
don't
know,
pick
a
pick,
a
service
that
just
doesn't
have
as
many
users
for
those
folks
that,
like
they
either
have
to
go
Implement
caching
themselves
to
get
benefits
there
and
be
able
to
store
stuff
a
little
bit
closer
or
they're,
literally
eating
200
to
400
milliseconds
across
the
WAN.
Every
time
they
go
to
look
up
a
secret,
so
I
think
I,
don't
know
you!
C
You
can
make
the
argument
that
well,
then,
the
capability
provider
should
Implement
caching
itself,
and
then
we
leave
it
up
to
the
user
to
schedule
a
capability
provider
in
the
right
area,
but
we're
getting
into
like
all
the
the
real
world
like
the
internet
is
not
actually
right.
Next
to
me,
it's
it's
over
there
type
stuff.
Sorry,
my
brain
is
rambling
today,
but
I
I.
Just
think
that
it
would
be
amazing
if
part
of
the
the
the
washboard
was
like.
C
A
I
was
gonna,
say
more
and
then
I
noticed
that
we
were
kind
of
running
low
on
time
here,
we're
even
past
the
time,
but
I
think
that
this
was
a
really
awesome.
Discussion,
really
glad
that
you
were
here
Patrick
to
kind
of
Steward
this
up
and
I'm,
looking
forward
to
seeing
the
kind
of
the
RFC
slash
pre-rfc
that
that
comes
out
of
this
bye
Billy
and
you
know,
I
think
we
can.
A
We
can
chat
more
then
if
anybody
else
has
any
other
feedback
on
the
whole
idea
of
managing
Secrets
or
even
like
config
type
secrets.
Please
feel
free
to
continue
the
discussion
in
slack
or
if
this
is
something
that
you
want
to
keep
talking
about
in
the
community
meeting.
We
can
always
add
it
on
as
another
agenda
item
for
next
week,
but
I
think
for
now.
This
probably
wraps
up
this
community
meeting,
so
I'm
going
to
go
ahead
and
stop
the
stream.