►
From YouTube: waSCC Community Call (2020-11-18)
Description
WebAssembly Secure Capability Connector (waSCC) weekly community call. waSCC is a dynamic, elastically scalable WebAssembly host runtime for securely connecting actors and capability providers.
A
C
Yeah,
I'm
kevin,
you
know
my
name,
I'm
not
like
kevin
hoffman,
just
the
kevin
john,
so
I
mean
I'm
in
california,
I'm
in
san
jose
and
silicon
valley.
I'm
working
on
a
product
called
the
ttea,
I'm
not
sure
I
post
my
introduction
in
this
outside
channel
a
few
days
ago
and
t
stand
for
the
trusted
computation.
Oh
sorry,
trust
with
execution
and
attestation.
C
C
Then
our
algorithm
can
find
one
node
and
to
execute
the
wasn't
inside
the
16
runtime
and
all
the
whole
process
can
be
protected
by
the
hardware.
The
hardware
is
typically
a
tpm
and
it's
a
kind
of
smart
chip
in
each
computer
and
the
tpm
can
give
us
some
kind
of
signature
or
we
call
the
proof
of
trust.
A
pot
part.
C
C
All
other
nodes
will
disconnect
this
node
so
to
make
sure
that
all
the
housing
node
is
running
and
on
house.
You
know
this
current
thing,
and
so
after
that
the
the
user
can
the
client
can
get
the
result
from
the
node
with
a
series
of
signatures
signatures
on
the
pod,
the
client
can
verify
the
pot
to
make
sure
that
the
the
result
is
correct
and
it
is
the
result
of
the
the
version
he
uploaded
in
the
ipfs.
So
this
is
the
basic
idea
on
what
is
what
it
is
doing.
Oh
it's
a
long
story.
A
Yeah,
the
web
page
is
a
little
slow
to
load,
but
I
think
you've
got
a
great
explanation
here
for
what
all
you're
working
on
well,
it's
great
to
have
you
and
thank
you
for
sharing
what
what
you're
working
on
real
quick.
So
I've
been
attending
the
wasm
time
meetings.
The
notes
are
linked
right
here
from
the
agenda,
but
just
to
link
out
some
highlights.
A
A
decision
was
made
around
language
bindings
to
pin
the
versions
of
language
bindings
to
the
wasn't
on
run
version
so
that
things
don't
get
too
different
from
you
know
like
being
on.
You
know
a
language
binding
for
go,
that's
three
and
wasn't
time
that's
in
a
1x
series
and
while
neither
matsila
nor
fastly
are
you
currently
using
the
rust
creed.
That's
supposed
to
be
the
future
pinpoint
moving
forward
with
you
know,
with
with
the
various
ecosystem.
A
B
So,
specifically
on
crestlet,
nothing
particularly
coming
up
other
than
you
know,
evolutionary
movement.
One
thing
we
do
want
to
call
out.
At
the
community
level
we
had
a
couple
of
weeks
back
a
conversation
in
the
networking
community
public
dev
conversation
in
which
both
both
we
microsoft
doing
the
crestlet
stuff.
On
my
team
and
pat
on
fastly,
we
would
discussed
being
able
to
create
an
experimental
namespace
for
wasting
apis
that
isn't
really
on
the
path
to
acceptance.
B
B
Implementations
and
experiments
to
see
how
it
feels,
for
example,
we
pulled
in
the
bsd
sockets
pr
and
to
make
that
work.
You
have
to
rebuild
the
entire
chain
of
tools
you
have
to
rebuild
rust.
You
have
to
do
a
whole
bunch
of
things
to
make
that
work
so,
but
on
the
one
hand
we
want
people
to
try
that
out
and
see
be
able
to
see
how
it
feels.
B
They
may
have
more
or
less
work
involved
in
order
to
be
able
to
use
them,
but
that
they
existed,
and
we
wanted
to
see
to
show
that
people
that
we
were
doing
that
a
lot
of
people
were
doing
upstream,
work
that
might
be
useful
to
play
with
so
that
the
second
one
was
to
actually
offer
that
functionality,
and
that
requires
a
little
bit
more
work.
So
we
could
write
a
doc
that
says
how
to
consume
the
crustlet
thing.
B
A
A
Yeah
yeah
and
I
have
like
some
documentation
that
I
started
on
it.
I
can
like
link
that
in
okay,
ralph
ebony
help,
I'm
not
sure
if
you
saw
the
you
know
the
tweet
that
we
put
out
for
critical
stack.
But
you
know
there
is
a
super.
You
know
lightweight
here.
It
is,
you
know,
deploying
you
know,
critical
stack
and
a
bunch
of
other
components
into
kubernetes.
A
B
Yeah,
I
think
that
that
kind
of
thing
is
what
we
want
we're
we're
proposing.
I
I
just
captured
the
link.
I
did
see
the
link.
I
didn't
get
a
chance
to
go.
Look
at
it.
My
last
two
weeks
have
been
a
sort
of
hellish
landscape
of
internal
work,
so
you'll
have
to
forgive
me,
but
oh
great,
kevin,
fantastic,
I'd
like
to
I'll
re-up
that
outside
the
world,
so
that
people
get
a
chance
to
see
it.
B
A
A
B
B
I
can't
yeah
so
oh
yeah,
radio,
oh
yeah,
that
one
yeah-
I
did
remember
that
one,
but
I
forgot
it
you're
right
so,
basically,
what's
going
on
is
we're
touching
all
these
little
points
of
technology
and
trying
to
release
information
about
them?
Not
we're
not.
There
is
no
implementation
here.
That
is
a
thing
it's
all
about
like.
If
we
could
do
this,
what
would
it
look
like
and
what
are
the
problems
and
who
else?
Where
did
we
get
the
inspiration?
B
So
what
we're
trying
to
do
is
point
to
all
the
work
doing
and
begin
to
do
a
drum
beat
of
conversation.
So
I
told
this
to
and
we're
gonna
do
that
for
another
two
months
or
so.
We've
got
lots
of
things
to
talk
about
some
of
the
high
level
things,
so
I'm
gonna
do
a
blog
post
about
sort
of
the
whole
ecosystem
where
it
is
now,
as
opposed
to
say
a
year
ago
or
half
a
year
ago,
even
or
maybe
even
three
months
ago,
geez
thanks
for
moving,
so
so
I'll.
B
Do
that
and
then
other
technical
things.
So
at
the
meeting
I
said,
I
suggested
that
what
we'll
do
is
just
post
an
open,
hackmd
and
actually
drop
in
what
our
schedule
of
blog
posts
is
and
for
those
who
want
to
see
what
we're
sort
of
working
on
in
his
experiments,
everybody
can
just
join
up
and
schedule
themselves
as
a
as
a
blog
entry.
So
the
original
thought
was.
I
just
wanted
everybody
to
see
what
we
thought
we
were
doing
and
when
we
thought
we
would
release
it
in
terms
of
publicity
about
geeky
things.
B
I
haven't
done
it
because
the
last
two
weeks,
so
this
was
the
other
thing
as
I
you
know
every
I
I
proposed
just
making
it
open
to
everybody
so
that
we
could
all
just
have
a
drum,
beat
going
about
our
technical
explorations
and
then
the
the
real
point
is
to
draw
in
all
of
the
inspirations
and
point
off
to
other
blogs
and
other
people
doing
work
that
we
consume.
When
we
do
this,
so
we
can
make
sure
that
everybody
realizes
that
this
is
a
huge
collective
engineering
effort.
B
A
A
Okay,
that's
awesome
kevin.
I
know
it's
been
a
ton
of
work
and
then
we've
got
a
couple
other
follow-ups
here,
we'll
get
through
on
the
agenda
in
just
a
second
on
you
know
like
the
docs
and
the
new.
You
know
demo
script
and
all
that
kind
of
stuff,
but
brooks
why
don't
we
head
to
you
with
the
oci
stuff
that
you've
been
working
on.
E
Sure
so,
probably
over
the
last
week,
or
so
I've
been
working
on
a
crate,
that's
embedded
in
crestlet
called
oci
distribution.
Previously
it
had
the
functionality
to
pull
oci
or
artifacts
from
oci
compliant
registries,
and
that
was
great,
but
we
also
desired
the
functionality
with
wash
the
cli
that
we're
going
to
bundle
with
wasc
to
be
able
to
take
provider,
archives
and
wasm
modules
and
and
push
them
up
to
registries
as
well
as
pull
them
down.
E
So
I've
been
working
on
that
pr
up
at
the
top
there
that
liam's
got
for
the
past
week
and
I
just
submitted
it
today.
Build
is
failing
just
because
of
some
ci
an
outdated
thing
in
the
in
the
ci,
but
I'm
pretty
proud
of
it
and
I'm
starting
to
get
that
integrated
into
like
a
proof
of
concept
and
wash
as
the
pr
comments
are
coming
in.
E
A
D
A
E
I
I
don't
have
any
new
functionality
to
show
with
the
klee
quite
yet,
because
I
just
started
working
on
the
oci
stuff
this
morning,
but
it's
in
a
it's
in
a
really
good
place.
Now
we've
got
like
auto-generated
keys
for
when
you
sign
your
wasm
modules
or
when
you
create
your
provider
archives,
which
greatly
improves
the
initial
developer,
experience
of
just
wanting
to
create
a
project
and
then
sign
it
so
that
you
can
run
your
actor
or
run
your
provider
provider
archive.
E
So
once
we
get
the
registry
command
into
wash
that'll
make
it
easier
for
you
to
distribute
your
modules
and
provider.
Archives
and
it'll
be
easier
for
us
to
distribute
our
own
first
party
providers
and
and
modules
so
that
people,
when
they
run
examples
on
the
on
their
laptop,
they
don't
have
to
download
all
the
all
the
artifacts.
They
can
just
run
it
and
we'll
download
it
for
them.
A
So
we've
got
a
few
a
few
in
flight
there
and
then
down
once
we
get
through
those
we'll
also
go
ahead
and
work
on
homebrew
packages
to
make
the
installation
of
the
new
tooling.
You
know,
drop
dead,
simple
and
we've
got
a
new
pack
package
cloud
repository
spun
up
so
that
all
the
packages
will
be
signed
and
distributed.
A
B
I
think
this
is
fantastic,
makes
everything
especially
infrastructure
work,
which
most
people
don't
think
about,
but
it's
it
enables
people
to
get
the
tools
to
try
the
stuff,
and
without
that
you
know
we're
we're
really
delaying
the
excitement
until
there's
enough
people
who
can
build
them
to
do
it
so
that
those
kinds
of
steps
are
miracle
workers.
Even
though.
D
B
To
build
tools
than
it
is
to
build
infrastructure
typically,
but
there
it
is
so
this
is
all
fantastic.
I
also
didn't
mention
the
fact
that
we
have.
I
don't
know
if
we
blogged
about
it,
or
we
certainly
will,
but
we
now
have
the
crestlet
working
on
armed
down
to
little
teeny
things
and
have
done
a
bunch
of
other
experiments
getting
smaller
and
smaller,
and
so
the
actually
pushing
out
edgewise
is
going
at
least
experimentally
is
going
much
much
much
much
faster
than
it
was.
B
We
have
a
wasm
3
running
on
extremely
small
devices,
and
but
the
experience
on
extremely
small
devices
is
sort
of
fundamentally
different,
because
you
can
only
jit
and
so
there's
sort
of
different
what
you
might
call
runtime
implications
like
exactly.
How
do
you
think
about
an
app
or
app
models
in
an
environment
where
you're
super
constrained,
but
you
can't
run
the
module,
so
those
kinds
of
things
are
definitely
there
and
I
love
the
progress
that's
being
made
by.
A
A
A
D
Yeah,
so
the
the
impact
that
that
has
for
for
wesk
is,
like
phil,
said
it's
for
the
first
party
providers.
You
can
just
use
little
tiny
crates
that
have
the
the
schemas
and
stuff
that
you
need.
So
in
the
old
code
base,
all
the
actors
used
all
of
the
other
actors
types
and
so
that's
kind
of
inefficient
and
it
had
update
consequences.
D
So
now,
if
you're,
building
an
actor
that
uses
an
http
server,
you
just
reference
the
http
server
crate,
which
is
generated
underneath
and
if
you
are
creating
your
own
capability
provider,
then
you
just
write
your
schema,
which
is
written
in
whittle
and
then
generate
all
the
code
for
both
the
provider
and
the
actor
and
and
you're
good
to
go
so
now.
There's
we
should
have
a
lot
more
flexibility
when
it
comes
to
creating
all
these
things
and
unless
less
reason
to
do
meaningless
updates,
which
is
what
we
were
kind
of
saddled
with.
A
Ralph
we
ralph
and
kevin
z.
I
mentioned
we're
still
on
or
not
yeah
we've
had
a
oh
we've
got
metrics
for
a
whole
bunch
of
folks
that
have
hopped
on
that
awesome.
You
know
we
have.
We've
had
a
bunch
of
meetings
with
people,
including
some
of
the
core
team
on
you
know.
Why
do
we
need
wpc
and
where
does
it
fit?
I
think
those
conversations
we
had
were
very,
very
productive.
A
You
know
like
it
as
far
as
you
know
the
needs
that
we're
trying
to
address-
and
you
know
how
we're
enabling
other
teams
to
make
progress
and
we
look
forward
to
continued
feedback
from
you
know
ibm
and
some
of
the
other
folks
that
are
building
on
top
of
that
over
the
next
few
months.
As
we
extend
those
the
tooling
and
everything
else
out
there
yeah.
B
I
think
this
fits
in
with
the
general
theme
that
I
I
was
evangelizing,
which
is
that
there
are
things
we
need
to
do
now
right
to
make
things
work,
and
they
don't
mean
anything
for
the
low-level
upstream
specification
until
they
do
right.
That
doing
things
is
not
a
bad
thing
right
and
and
the
real
question
the
real
question
is
it's
only
a
bad
thing.
B
If
the
low
level
specification,
the
core
work
that
they're
doing
doesn't
complete
the
way
it
should,
if
it
does,
then
these
things
now
are
in
a
situation
where
we
can
migrate
to
where
we
want
to
be
on
standards
and
things
like
that.
But
until
it
does,
we
have
to
have
experiments
that
people
can
use.
A
F
I
not
entirely
have
an
update
from
our
end.
I
did
see
the
oci
distribution
stuff,
which
is
fantastic.
I've
already
started,
taking
a
look
and
reviewing
that
code
in
particular
this
it's
fantastic,
because
we've
actually
been
talking
about
how
we
could
make
that
particular
like
we
were
interested
in
making
this
or
implementing
this
functionality.
At
some
point,
it's
just
that
we
have
been
backlogged
with
other
work,
so
this
is
fantastic
brooks
for
implementing
this
in
terms
of
an
update
from
crosslit
side
of
things.
F
I
think,
right
now
what
the
team
has
been
focusing
on
has
been
trying
to
implement
the
rest
of
the
cubelet
api.
I
was
in
like
so
fleshing
out
the
cubelet
crate,
that's
inside
of
crustlet
the
idea
there
being
that,
if
we
have
all
of
the
functionality
available
like
the
container
network
interface,
the
container
storage
interface
any
other
apis
that
the
cubelet
basically
needs
to
handle
and
accept
from
kubernetes,
then
we're
in
a
very
good
position
to
start
kind
of
building
out
a
lot
of
the
demonstrations.
F
Trying
to
reverse
engineer
the
kubernetes
api
in
some
ways,
but
once
we
have
that,
I
think
we
can
come
back
to
the
table
and
figure
out
like
how
do
we
want
to
craft
some
of
these
demonstrations?
How
do
we
want
to,
for
example,
tie
in
the
container
networking
interface
into
wasc
and
to
to
the
wasom
time
and
to
other
providers,
and
then
also?
How
can
we
document
that
so
that
other
people
can
write
their
own
providers?
F
As
far
as
I'm
aware,
I
think
it's
just
running
raw
binaries
and
it's
unpacking
from
a
tarball
and
just
like
running
those
raw
binaries
on
the
node,
so
very
specific
use
case,
but
very
interesting
to
see
where
this
kind
of
technology
is
helping
them
out
in
some
ways.
So
that's
kind
of
where
we're
focused
right
now
is
trying
to
again
trying
to
re-implement
the
kubernetes
api.
So
then
we
can
handle
those
use
cases
and
then
people
with
special
snowflake
use
cases
can
figure
out
how
to
go
and
do
that.
F
F
Nothing
actionable
in
terms
of
wasp
right
now.
The
only
advantage
that
would
allow
wasp
in
terms
of
things
would
be.
We
could
take
external
volumes
from
like
kubernetes,
like
whatever
storage
drivers,
that
they
have
and
then
wasp
will
just
see
that
as
a
volume
mount
which
I
we
already
have
volume
out
capabilities
inside
of
the
wasp
runtime.
F
A
D
I
haven't
really
migrated.
I've
created
a
couple
of
new
issues
that
you
know
just
sort
of
as
I
was
working
in
it.
I
still
need
to
go
through
all
the
old
issues
and
see
which
ones
still
apply
and
which
ones
don't.
So
I
wouldn't
consider
this
this
list
here
complete.
Yet
I
still
have
a
lot
of
work
to
do
in
terms
of
putting
in
the
rest
of
the
roadmap.
A
I
did
pull
it
out
into
a
google
doc,
but
the
formatting
is
kind
of
is
kind
of
a
janky,
but
I
I
will
get
it
shared
with
everybody.
That's
on
this
list,
so
that
you
guys
can
give
us
some
feedback
on
that
and
come
in
now.
I
think
we
already
have
a
couple
feedback
notes,
but
at
a
high
level
kevin
you
maybe
want
to
kind
of
walk
us
through
here.
D
Yeah,
so
the
idea
is
to
this.
This
script
essentially
represents
what
we
want:
the
new
first
contact
between
a
developer
and
mosque
to
look
like,
and
so
once
you
get
the
tools
installed,
which
should
now
or
not
now,
but
fairly
soon.
Those
will
be
easily
installed
through
package
managers
and
whatnot.
D
D
The
same
thing
with
capability
providers,
the
the
new
provider
archive
format
means
that
we
can
pull
a
provider
from
an
oci
registry
and
you'll
get
the
the
version
of
that
provider.
That's
appropriate
for
your
operating
system
and
architecture,
and
because
of
the
the
way
that
lattice
has
been
enhanced.
D
With
the
new
rewrite
the
script
sort
of
shows
that
you
can
start
an
actor
and
you
can
start
a
provider
and
you
can
define
the
the
link
between
the
two
in
any
order
and
the
system
just
magically
makes
that
work
and
also
part
of
this
demo
is.
We
have
a
bunch
of
different
people.
All
connected
are
all
running
their
repels
locally
on
their
laptops
and
we'll
hand
out
some
credentials,
which
will.
D
So
you
can
look
at
the
list
of
hosts
the
list
of
actors,
the
list
of
links
and
and
so
on,
and
the
idea
here
is
that
getting
introduced
to
what
was
does
and
what
it
can
do
for
you
and
all
of
its
benefits
should
be
zero.
Friction
now,
there's!
No!
You
don't
need
to
build
anything.
You
don't
need
to
compile
anything.
D
You
don't
need
to
install
any
tooling
other
than
just
the
one,
cli
and
you're
good
to
go,
and
hopefully,
after
getting
a
taste
of
what
this
feels
like
inside.
The
raffle
you'll
then
go
and
explore
further
and
after
that,
the
ripple
then
becomes
an
incredible
debug
tool
for
as
you're
building
your
own
actors
and
providers
on
your
on
your
workstation.
A
B
So
this
looks
fantastic.
I
love
it.
One
thing
that
we
discover-
and
this
is
a
general
ecosystem,
reuse
of
tool-
thing
which
you
all
be
familiar
with,
but
it's
one
of
those
things
that
you
should
surface
up
kind
of
consciously,
as
opposed
to
just
engineers,
noticing
it
and
complaining
about
it,
which
is
the
rigor
as
they
say
the
with
the
things
like
you
know,
the
the
cri
implementation,
interface
and
so
forth.
We
keep
banging
our
heads
against
container
native
sort
of
experiences.
Oci
is
a
similar
environment.
B
We
went
through
banging
our
heads
against
that
with
with
cnab
and
porter
the
cloud
made
of
application
bundle
stuff
and
we
sort
of
helped
along
with
the
community.
Oci
distribution
modify
to
be
able
to
use
artifacts
and
things
like
this,
so
we
can
do
more
advanced
use,
use
of
oci
that
turns
out
to
be
really
really
network
effective.
B
But
as
we
go
forward,
we
should
kind
of
very
consciously
call
out
where
what
it
does
provide,
which
is
mainly
network
effect
and
ease
of
use
right
and
also
what
it
doesn't
like.
What
are
the
feature
set?
Things
that
we
really
would
like
to
do
that
are
hard
or
not
possible
in
oci,
because
those
will
help
us
decide.
D
Forward
yeah,
that's
a
great
point,
one
of
the
big
things
that
switching
to
oci
bought
us
is
that
we
were
able
to
retire
a
a
huge
pile
of
code
that
we
were
writing
on
our
own.
So
we
had
built
our
own
registry
for
webassembly
modules
called
gantry
right.
It
was
proprietary
and
it
only
held
webassembly
modules.
But
now
that
we
can,
we
have
stuff
working
on
oci,
that's
no
longer
theoretical.
D
B
It's
fantastic
right,
so
what
I'm
specifically
saying
is
I
have
this,
of
course,
in
mind
right.
You
know
there
were
there
were
things
that
you
wanted
to
do
in
gantry
that
were
hard
to
do
in
oci,
but
on
the
other
hand,
you
removed
a
whole
swath
of
your
labor
and
you
increased
the
the
footprint
for
potential
locations
to
store
this
stuff
yeah.
So
that's
that's
super
valuable,
but
I
don't
want
to
lose
sight
of
the
little.
The
feature
sets
that
in
oci
discs
we
lose
our
real
hard.
A
A
When
I
think
about
some
of
the
common
questions
that
we
get,
you
know
kevin
and
I
started
sketching
an
faq,
and
you
know
this
is
sort
of
the
realization
around,
like
you
know,
let's
get
through
15
on
the
way
to
1.0
here
and
do
a
rewrite,
but
we
need
you
know
like
some
architectural
diagrams,
some
shorter,
explainers
and
stuff
like
that,
because
today
it
we've
been
at
least
with
our
project.
We've
really
been,
you
know
having
a
collection
of
lessons
learned
that
showed
up
as
tools,
and
this
is
the
first
time
when
we
are.
A
F
Yeah
exactly
it
touches
largely
on
helm,
because
that's
kind
of
like
the
subject
area
that
we're
obviously
working
in-
and
that
was
like
the
target
audience
that
we
were
discussing
with
this,
but
that
particular
blog
post
does
delve
into
some
of
the
exact
details
that,
like
kevin
and
brooks,
you
probably
are
touching
on
and
getting
some
advantageous
ideas
off
of
with
oci
distribution.
And
so
we
have.
We
have
talked
about
this
with
helm.
We've
talked
about
this
with
other
ideas
as
well,
but
that
kind
of
gets
a
lower
level.
F
A
All
right,
that's
awesome,
I'll
link
that
in
the
meeting
notes
here,
you
know
I
want
to
get
wrapped
up
a
little
early,
because
I
want
to
get
some
feedback
on
the
format
today.
You
know
so
next
week,
which
is
thanksgiving.
We'll
still
do
a
meeting
on
wednesday
if
people
can
make
it
great.
If
not
that's.
Okay,
too,
I
understand
it's
a
a
week
out.
You
know
we're.
A
F
F
F
Excuse
me
a
lot
of
black
magic
to
try
and
build
it,
but
basically
we
just
automated
the
whole
process,
so
we
will
have
arm
64
architecture
available
for
crosslit
in
regards
to
tiny
devices.
That's
a
lot
lot
harder
because
you
have
to
flash
firmware
onto
the
devices
and
then
you
have
to
have
enough
memory
to
actually
both
run
a
webassembly
runtime
to
run
a
module
as
well
as
make
requests
to
and
from
a
kubernetes
api.
F
B
A
Well,
let's,
let's
throw
a
pin
in
this
because
we've,
I
know
chris
you've
spent
a
bunch
of
time,
building,
kubernetes
and
critical
stack
for
you
know
arm.
So
I
think,
let's
put
a
pin
in
this
one
for
now,
we'll
make
it
just
like
a
general
topic
that
we
can
actually
maybe
yeah
put
it
together,
a
larger
update
on
that
anything
else
before
we,
you
know,
stop
recording
all
right.
Thank
you.
Everybody
see
you
next
week.