►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Extending Envoy with WebAssembly - John Plevyak & Dhi Aurrahman, Tetrate
Envoy is a high-performance proxy in the cloud-native landscape designed to be extensible at its core. There are several possible “extension points” in Envoy as outlined in data-saferedirecturl="https://www.google.com/url?q=https://github.com/envoyproxy/envoy/tree/master/source/extensions&source=gmail&ust=1556395125347000&usg=AFQjCNFHQR9CrsgtJI-Xw0wgTplXqCad3w" href="https://github.com/envoyproxy/envoy/tree/master/source/extensions" target="_blank" https://github.com/envoyproxy/envoy/tree/master/source/extensions. However, the currently available approaches to extend it is rather limited. Since Envoy is written in C++, the primary way to introduce new extended functionality in Envoy is by writing an extension (e.g. filters, either network or HTTP filter, as one of the most relevant use-cases in Envoy), in C++. It is also possible to write an extension for Envoy using Lua, but the current scope of this extension is only for HTTP traffic. This talk introduces the possibility to extend Envoy with WebAssembly-based extension and report the current progression of it.
https://sched.co/MPbR
A
A
A
So
this
is
the
today's
agenda.
It's
about
envoy
I
mean
it's
like
a
quick
recap
on
envoy
I
mean
it
will.
So
please
bear
with
me
it's
an
invitation
for
the
for
all
of
you
to
basically
try
to
contribute
to
envoy
and
then,
after
that,
we
will
go
down
to
talk
about
a
little
bit
about
our
FOIA
architecture
itself
and
how
we,
it
can
be
extended.
And
of
course
we
will
go
to
the
core.
Is
the
extending
unemployed
with
Assembly
John?
We
will
do
that
for
us
and
there
will
be
a
demo.
A
It's
hopefully
a
good
demo,
it's
a
live
demo
so
and
then
we
will
do
a
Q&A,
so
the
promise
of
our
voice
network
should
be
transparent
to
application.
So
we
believe
that
developers
should
focus
on
the
business
logic.
I
mean
developers
should
only
deal
with
the
application
logic,
not
thinking
about
network
itself.
So,
but
when,
when
some
problem
occurs,
it
needs
to
be
very
very
apparent:
where
is
the
problem
I
mean
like
if
the
problem
is
the
in
the
application
logic
itself
or
in
the
mapper
layer
so
on
for
itself?
A
A
If
you
we
have
this
XTS
API,
we
call
it
its
LDS
CD
s
and
stuff
like
that
and
no
open
core
pet
premium
version.
It's
all
there
everything
so
in
our
foyer.
We
believe
that
again,
this
is
an
invitation,
so
we
believe
in
community,
so
people
can
come
up
with
ideas,
put
some
proposal
in
our
project
and
we
will
make
it
happen.
A
A
But,
as
you
can
see
here,
you
can
see
our
turbine
laps.
The
turbine
laps
has
this
contribution
on
trif
filters,
so
it's
an
extension
of
armful.
So,
as
you
can
see,
if
you
do
expansion,
basically
you
will
be
on
top
of
the
contributors
so
to
know
alpha
better
I'm,
just
on
Tuesday
you,
you
can
go
to
the
mid
container.
Design
will
be
there
and
then
the
next
day
and
Thursday
as
well.
There
will
be
interest
one
for
you
and
deep
dive
so
again,
so
this
is
the
the
anvil.
Key
texture
envoy
is
structured
like
this.
A
So
basically
there
are
some
workers
running
to
accept
some
to
accept
the
connections
and
then,
after
that,
there
we
go
to
the
listeners.
So
here
the
in
the
listeners
here
is
the
the
first
extension
point
that
you
can
do.
So
if
you
go
to
the
arm
voice
source
code
tree,
there
will
be
an
example
of
listener.
Extension
is
TRS
inspector,
for
example.
A
So
after
that
we
have
these
alpha
rate
filters
and
to
read
the
bytes
in
and
bytes
out,
and
then
we
we
do
have
these
l4
right
filters,
where
you
can
actually
like
mutate,
the
traffic
and
and
here
so
basically
the
l7
itself
is
built
as
a
network
filters
that
were
filled
us
in
all
four
filters.
So
you
can
have
like
all
seven
filters
like
HTTP
or
trip,
or
probably
my
sequel
right
now
we
have
my
C
code,
but
not
as
it's
only
like
grid
the
filter.
A
But
of
course
you
can
do
like
write
filter
for
any
protocol.
You
want
and
then
inside
inside
that
l7
layer
you
can
have
another
another
stack
of
filters.
So
that's
another
extension
point,
so
you
can
write
your
own
l4
filters
and
you
can
also
write
your
own
l7
filters
and
for
itself
has
many
another
components.
Like
auxiliary
components
like
stats,
so
you
basically
can
have
stat
sinks
I
mean
in
alpha.
We
have
many
options
of
how
you
sense.
That's
out
like
stats,
D
or
Prometheus
endpoints
or
many
other
things
we
can.
A
We
have
also
like
ex
DSP
is
I
told
you
before
so
to
emphasize
this,
to
that,
alpha
is
designed
to
be
extensible
with
multiple
extension
points.
As
you
can
see,
the
very
obvious
thing
is:
you
can
put
your
extension
on
Al
for
seven
as
well
for
ins,
our
seven
filters.
You
can
basically
pick
your
date
pick
your
traffic
or
you
can
also
mutate
this
traffic
and
if
I
also
allows
you
to
have
your
own
access
logger.
So
we
have
like
divine
interfaces
for
you
to
build
your
own
access
loggers.
A
We
also
allows
you
to
bring
your
own
tracers.
We
have
Zipkin,
we
have
open
dressing.
We
have
a
couple
of
things
here.
Even
we
do
love
people
to
extend
a
half
Decker's.
The
current
example
right
now
in
in
arm
for
three
is
on
like
readies
health
checker,
but
basically
you
can
build
our
things
and
another
interesting
things,
probably
like
retry
policy,
you're,
probably
in
different
organization.
You
need
a
different
way
of
retrying
request.
A
So,
if
you
go
to
an
for
a
source
code,
github
repository,
you
can
see
that
this
you
can
go
to
an
FOIA
source
of
extensions.
You
can
see
it's
growing
and
growing.
You
can
actually
like
introduce
your
own
if
you
want.
So.
Basically,
this
the
structure
of
an
extension
is
consists
of
business
politics,
the
how
you
read
the
data,
the
bytes
or
in
a
higher
level
like
like
l7
HTTP,
the
how
you
actually
read
the
headers,
the
the
body
or
the
trailers,
and
how
you
actually
manipulate
those
data.
A
A
Currently,
if
only
can
be
introduced
inside
the
Envoy
code
structure,
it
should
be
statically
linked,
but
but
later
we
will
introduce
the
web
apps
umbly,
where
you
can
excel
dynamically
load.
Some
logic
put
in
side
the
envoy
and
then
run
it
to
manipulate
your
data,
so
the
configuration
in
our
voice
is
represented
as
a
proto
tree.
Protobuf
tree
is
very
interesting
technology.
So
so,
basically
you
can,
for
example
like
in
your
organization.
You
need
this
out
service
filter.
Probably
you
don't
want
it
to
be
upstream,
because
it
is
very
specific
to
your
organization.
A
So
yeah
as
I
said
that
the
to
write
your
own
extension.
Currently
we
can
do
it
using
C++
or
Lua,
but
Lua
has
some
limitation.
Currently
this
only
for
a
sativa
traffic.
Of
course
it
can
be
extended
to
all
four,
but
Lua
is
the.
If
you
deal
with
some
kind
of
you
embed
some
another
runtime
inside
inside
another
process,
you
will
have
another
problem,
so
this
is
an
example
of
GZ
filter
in
C++.
A
I
just
want
to
very
quickly
to
go
on
how
we,
what
we
need
to
to
have
your
own
filter
inside
point
soand
is
a
filter.
Basically
we
have
this.
This
is
how
you
plug
in
the
configuration,
as
you
can
see
here
in
the
disable
filter
conflict.
You
get
the
unfold,
the
gzip
specific
configuration
it's
divine
as
product
message,
and
then
you
can
load
the
configuration
that
is
needed,
but
it
is
it
to
be
be
it
to
behave
so
in
the
sed,
be
stream
filter.
Basically,
we
have
several
things
to
be
override
overridden.
A
The
first
one
is
that
they
got
headers.
There
is
the
decode.
The
recode
thing
is
when
the
data
comes
in
inside
and
void.
So,
basically,
when
you
have
this
HTTP
requests
coming
in
inside
envoy,
and
then
you
do
this
decode
headers,
you
basically
see
what
is
inside
the
head
and
then
you
want.
You
can
do
the
decision
on
what
you,
what
to
do.
When
you
see
a
certain
headers
and
then
the
code
data
is
doing
with
the
data
and
the
trails
also
so
in
the
case
of
gzip.
A
A
This
is
the
encode
data
that
basically
send
you
back.
The
compress
information
so
basically
currently
seems
like
we
can
do
better
than
this
right.
So
probably
we
can
introduce
some
some
plugin
mechanism
that
is
dynamic
enough
and
easy
enough
for
us
to
integrate
it
into
our
workflow
in
negotiation.
So
now
I'll
invite
John
to
talk
about
more
about
extending
our
for
with
assembly.
C
Hi
I'm
John
plavix
from
Google
and
I'm,
going
to
tell
you
a
little
bit.
Our
projects
I've
been
working
on,
which
is
to
add
webassembly
VMs
into
envoy
and
stitch
it
in
through
all
the
different
extension
points.
Currently
we
have
several
extension
points
done
and
I'll
tell
you
about
those
and
some
of
our
future
plans
as
well.
So
I'm
gonna
start
by
talking
about
the
overall
architecture,
how
the
VMS
are
placed
within
the
envelope
process.
C
I'm
going
to
talk
about
the
the
different
extension
API
that
we're
supporting
and
how
the
VMA
API
works
and
the
way
that
you
know
anybody
else
could
add
a
new
VM
support,
currently
support,
rabbim
and
v8,
and
what
we
call
the
null
sandbox,
which
is
a
way
to
link
in
your
extensions
directly
but
using
the
same
API.
It
would
use
if
you're
going
to
do
it
in
web
assembly
and
that
will
allow
you
to
put
your
extension
under
a
standard
debugger
and
not
have
to
deal
with
the
the
sandbox
during
your
debugging
phase.
C
So
the
first
question
is
well
why
why
well,
but
Emily
in
the
first
place?
Well,
you
know
it
has
a
bunch
of
advantages.
One
is
it's
portable
and
in
this
sense
I
don't
mean
that
you
can
like
move
the
code
around,
but
that
you
could
take
a
web
assembly
module
and
you
could
run
it
inside
Envoy
or
you
could
build
a
similar
environment.
You
could
run
it
an
inside
node,
for
example.
If
you
wanted
to
test
it
there
or
if
you
wanted
to
use
it
in
a
different
environment,
it's
also
sandbox
machine
code.
C
So
it
has,
you
know,
advantages
there
in
terms
of
protecting
yourself.
It's
a
web
standard.
That's
under
active
development,
there's
a
whole
bunch
of
new
extensions
coming
out
with
threads
huazi
support,
which
is
a
generic
OS.
Api
support.
Different
tool
chains
are
available,
it's
got
good
languages,
a
support,
typescript
C++
rust
and
a
variety
of
other
languages
in
different
states
and
because
it's
being
actively
developed,
we
expect
that
you
know
once,
for
example,
the
GC
support
gets
standardized
that
will
see.
You
know
other
languages
like
you
know,
Java
and
go
fully
supported.
C
So,
let's
consider
what
use
case
you
might
have
for
something
like
this.
Let's
think
about
the
use
case
of
sto,
the
the
service
mesh
so
envoy
is
used
in
the
data
planes
to
enforce
sto
policy.
But
you
know
by
having
web
assembly
extensions,
we
can
avoid
having
to
modify
envoy
itself,
which
is
you
know,
a
real
big
advantage,
because
you
can
run
on
the
standard
Co
base
and
it
also
means
you
can
avoid
a
certain
high
network
hops
during
policy
checks.
C
So
you
can
cache
a
lot
of
data
locally
without
if
they
make
a
G,
RPC
request
to
say
mixer.
You
can
also
avoid
restarting
during
dynamic
reloads.
You
get
some
isolation,
which
is
nice.
So
if
your
extension
crashes,
it
won't
necessarily
take
down
all
of
Envoy
and
if
you've
got
you
know
certain
extensions
that
are
pinned
to
certain
flows.
C
You
know
then
they'll
only
take
down
those
and
also
you
can
do
a/b
testing.
So
I'll
go
over
a
little
bit
of
the
architecture
and
the
api's
that
we
have.
So
there
are
three
types
of
api's:
there's
general
api's
was
the
ones
exported
by
envoy
itself.
Things
like
logging,
stats,
there's
also
extension
api's.
Those
are
like
you
know,
filters,
l4
filters,
l7
filters,
logging
filters
and
finally,
there's
those
vm
the
vm
api.
That
you'd
only
use
if
you're
going
to
add
support
for
another
vm
system
into
this
project.
C
So
you
don't
have
to
really
understand
this
whole
slide.
I'm
gonna
have
different
slides
to
break
it
down,
but
this
is
the
overall
architect
and
the
the
big
area
in
the
center
here
we've
got
envoy,
there's
a
variety
of
vans
in
there
and
subsystems,
and
it's
talking
to
the
other
mesh
nodes
over
here
on
the
left-hand
side
and
the
control
plane.
Now
I'll
break
it
down,
so
this
is
how
we
configure
VMs
in
an
envoy.
C
So
you
can
in
you
can
have
a
lot
of
different
VMs
and
then
later
on,
you
can
pass
in
new
descriptions,
new
configurations,
dynamically
using
X,
Y
s
and
those
descriptions
could
include,
say
URI
and
you
know
a
sha-256.
It
says:
hey
go
out
to
this
code,
repo
pull
down
this
Waze
module.
This
is
the
one
you
want
to
use.
So
initially
we
start
out
with
it
on
disk,
but
you
could
go
get
it
from
another
source
later
on.
Alright.
So
the
the
first
thing
to
understand
about
envoy
is
it
uses
silos.
C
Those
are
single
threads
that
handle
a
dedicated
set
of
streams
and
the
therefore
the
wasm
VMs
that
we
have
are
also
going
to
be
single
threaded.
So
when
we
describe
a
VM
template
in
the
configuration
that
template,
if
it's
used
for
filters
is
not
going
to
be
instantiated,
one
VM
/
silo
that
allows
us
to
be
single
threaded
within
the
silos
and
to
not
have
to
worry
about
locks
or
any
other
sort
of
issue.
So,
as
you
can
see,
a
variety
of
streams
will
come
in
some
subset
of
those
streams.
C
Now
the
question
is
that
how
do
these
things
communicate?
So
we've
got
all
these
different
sand
boxes,
but
we
still
want
to
have
you
know,
potentially
to
have
collective
information.
So
if
you
want
to
have,
for
example,
you
know
collective
stats
or
collected
policies,
you
know
if
the
the
VMS
have
to
make
G
RPC
calls
out
or
HTTP
calls
out
in
order
to
get
specific
information
about.
You
know
particular
paths.
We
want
to
cache
that
information.
We
can
store
it
and
share
data.
C
That's
another
one
of
these
general
api's
we're
providing
to
the
Y's
and
modules
that
allows
us
to
share
data
between
VMs,
and
we
might
also
have
a
situation
where
we
want
to
consolidate
a
variety
of
information,
maybe
stats
or
logs,
and
we
want
to
send
these
out
to
some
other
process,
so
we're
sending
them
out
to
you,
know
sto
air
or
fluid
e
or
whoever,
and
so.
In
order
to
allow
this
to
happen,
we
can
also
have
services,
so
services
are
Singleton's,
so,
as
singleton
would
be
a
single
VM
that
runs
in
the
Envoy
process.
C
C
C
This
set
of
wrappers
these
wrappers
are
provided
just
in
header
files
as
part
of
the
API,
and
in
this
case
you
can
see
that
we've
taken
the
low
level
API,
which
allows
you
to
define
a
metric
which
comes
back
as
an
opaque
integer
and
then
increment
it
by
increment
that
it
by
passing
back
that
opaque,
integer
and
turn
it
into
something
a
lot
nicer.
So
we
have
a
counter
that
is,
has
fully
typed
tags
we
can
increment
based
on
you
know,
providing
the
information
for
the
tags.
C
We
can
also
resolve
that
so
that
it
goes
back
to
this
integer,
which
is
gonna,
be
a
lot
more
efficient.
So
we
don't
have
to
send
the
strength
through
every
time
and
then
that
with
that
resolved
one
we
can
increment
it
directly.
So
this
gives
us
an
example
of
how
all
the
API
is
work.
There's
a
low-level
API,
that's
available
to
all
the
language,
all
the
languages
and
then
a
high-level
API,
it's
specific
to
each
language
that
follows
the
idioms
of
that
language.
Okay.
So
what
what
type
of
extension
API
is?
C
Do
we
have
currently
we're
supporting
HB
filters?
Log
filters
service
Singleton's?
We
have
definite
plans
to
do
TCP
filters
and
log
sinks
we'd
like
to
do
listeners
as
well.
You
know
it
just
comes
down
to
how
much
bandwidth
we
have
who
wants
what
right.
So,
the
API
extensions
are
pretty
easy.
If
you
just
follow
the
template
of
the
code,
it
would
be
really
easy
to
add
another
one.
C
So
here's
an
example
of
what
an
HTTP
filter
looks
like
because
these
filt-
because
this
is
all
callback
related
there's
you
know
no
threading,
so
you're
not
getting
a
situation
like
you
would
in
lua,
where
you
know
it
looks
like
you
have
continued
code.
Instead,
you
just
have
calls
there's
a
context
and
that
context
represents
a
stream.
So
that's
like
one,
you
know
HP
request
and
it
has
the
call-outs
so
like
on
request.
Headers
means
the
request
errors
come
in
and
then
you
can,
you
can
log,
you
can
make
a
debugging
log
call.
C
You
can
get
a
header,
you
can
modify
that
header
and
then
you
can
return.
You
know
your
your
filter
status
and,
as
you
can
see
here,
this
this
supports
actually
both
an
HTTP
filter
and
a
logging
filter
all
in
one.
So
you
know
when
you're
doing
your
configuration,
you
can
figure
both
of
those
things
you'd
vector
into
the
same
VM
and
you'd
handle
them
with
the
same
context,
and
that
gives
you
the
advantage
of
carrying
contacts
through
both
the
HTTP
filter
and
the
logging
filter,
which
is
a
nice
plus.
C
Next
we've
got
the
VM
API.
Is
it's
really
only
important
for
somebody
who
wants
to
add
a
new
VM,
currently
support
watham
v8
and
the
Noll
sandbox,
which
allows
you
to
compile
directly
into
Envoy?
And
if
you
want
to
add
a
new
VM,
for
instance,
you
know
you're
into
crane
left,
and
you
want
to
really
want
to
put
that
one
in
there's
only
a
few
things
that
you
need
to
do.
You
need
to
implement
a
function
to
register
callbacks.
These
are
calls
that
come
out
of
the
VM.
C
All
those
you
know,
general
API,
as
I
was
talking
about.
You
need
to
add
a
function
to
get
functions
from
the
VM,
so
you
can
get
the
handlers
that
the
VM
has
for.
Like
you
know,
when
a
call
comes
into
the
VM
like
the
on
log
call,
you'd
have
to
have
to
have
a
way
for
envoy
to
get
that
call
from
the
VM,
and
then
you
know
you
need
the
general
load
link
and
start.
And
finally,
we
do
everything
by
copying
memory
in
and
out
of
the
VM.
C
That's
because
that's
sort
of
the
lowest
level
simplest
API.
It
also
means
we
can.
You
know
wrap
the
VM
and
a
process,
we
want
to
additional
security,
and
so
you
have
to
add
a
simple
set
memory
and
get
memory
operations,
and
once
you
do
that,
you
could
implement,
you
could
implement
a
new
VM.
So
what's
the
status
think
we've
gone
over
this
before
a
bunch
of
this
stuff
is
done.
We've
got
you
know
several
different
types
of
filters.
C
Several
different
types
of
VMs,
several
different
types
of
general
api's,
metrics
and
logging
HTTP
calls
G
RPC
calls,
and
what
are
we
planning
to
do?
Well,
we
want
to
do
additional
extension.
Api's
we'd
like
to
have
you
know
additional
VMs,
there's
a
bunch
of
new
standards
coming
out
threads
we'd
love
to
have
zero
copy
memory
for
those
cases
that
it's
appropriate
for
and
we'd
like
to
have
support
for
dynamic
loading
and
linking
and,
of
course,
we'd
love
to
up
stream
this
into
the
Envoy
master
branch.
It's
not
there!
C
Yet
you
know
it's
something
we
fully
intend
to
do
so.
In
conclusion,
you
know:
web
assembly
is
good
for
Envoy
yeah.
It's
efficient,
relatively
safe
and
secure
it's
dynamically
upgradeable
and
we've
got
an
issue
to
put
it
in
as
well
as
a
repo
under
on
V
proxy,
but
it's
not
on
the
way
itself.
Its
Envoy
wasum,
it's
a
sort
of
a
sandbox
right
now.
So
it's
a
staging
area
so
that
we
can
get
the
PRS
and
upstream
and
we'd
love
to
get
some
contributions.
So
now
I'm
going
to
try
to
do
a
live
demo.
C
That's
always
a
fun
experience.
Okay,
so
like
a
half,
yeah
I
have
a
few
minutes.
Okay.
So
the
first
thing
is
the
API.
So
there's
a
file
in
sorry
directory,
which
is
API,
wasm,
c
p--
cpp.
So
there's
you
know
additional
languages
in
there
like
API
was
in
rust
and
in
here
you'll
see
that
we've
got
some
dot
BC
files,
those
are
actually
wasm
encoded
bit
code
files
for
support
for
protobufs
that
are
pre-built
for
you,
there's
also
various
header
files,
so
proxy
wasm
extern
over
there.
C
Those
the
external
function
calls
the
general
API
calls
the
imple
dot.
H1
is
the
high
level
API
and
the
enums
over.
There
are
the
enumerations
that
you
might
see.
So,
let's
take
a
look
at
like
say
the
enumeration
one.
You
know
you
can
see
in
here
that
we
have
the
various
log
levels
defined
different
header
status,
messages.
C
C
This
is
envoy
running,
and
this
is
what
happens
when
you
run
example.
So
this
is
the
example
that
we
saw
well.
I'll
show
you
the
example
of
a
second
after
I
make
the
font
bigger.
But,
as
you
can
see
here,
it's
actually
printing
out
the
log
lines
for
the
different
callbacks,
so
on
done
is
when
the
stream
is
done
on.
Log
is
when
the
logs,
when
it
gets
the
on
log
callback
and
on
delete,
is
when
the
context
is
deleted.
C
C
Alright,
so
this
again
is
one
of
those
contexts.
As
you
can
see,
it
has
like
on
done
on
log,
on
delete
on
request,
headers
right
so
in
on
request.
Headers
we're
gonna
well,
actually,
an
on
response.
Headers,
we're
gonna,
modify
the
response
header,
and
so
that's
what
I
printed
out
before,
as
you
saw,
we
added
a
new
header
called
it's
really
hard
to
see.
C
I'm
sorry
called
a
new
header
and
the
value
is
new
header
value
and,
as
you
can
see
up
top
well,
as
you
saw
before,
when
I
printed
it
out,
it
came
back
as
new
header
value.
Gonna,
just
change
it
and
I'll
show
you
what
happens
when
you
have
to
compile
it,
so
you
can
pilot
its
using
the
in
scripting
tool
chain,
so
that's
PM,
plus
plus
for
the
inscription
C++.
All
this,
all
the
additional
parameters
are
coming
out
of
that
make
file.
That
I
showed
you
before
now.
C
Now
you
can
see
that
we've
changed.
The
value
is
now
set
as
new
header
value,
so
we've
compiled
new
code,
we've
uploaded
it
into
envoy
and
we
run
it
modified
it
and
change
the
value.
So
and
it's
you
know,
the
make
file
is
pretty
pretty
straightforward.
It
just
refers
to
the
make
file
in
the
API
directory.
In
this
case
it's
the
lite
version.
So
there's
two
versions
of
the
protocol:
I
bury
one
of
them
files
down
to
about
200k.
That's
the
lite
version,
the
other
one
compiles
to
about
two
two
and
a
half
megabytes.
C
C
C
B
C
C
C
C
We
thought
like
the
code
is
in
is
sitting
in
the
Android
proxy.
You
know
namespace
it's
in
its
own
repo,
though,
because
you
know
we're
talking
to
everybody
over
there
about
up
streaming
it,
but
nobody
wants
to
just
take
the
code
right
I
mean
you
could
take
the
code,
but
but
the
community
needs
to
agree
that
the
code
is
structured
correctly
and
the
api's
are
the
ones
they
want
right
and
once
they
agree
like
we're,
I'm
gonna,
you
know
do
everything
that
they
want
me
to
do
to
get
that
thing
up
stream.
C
It
depends
so
you
know
it
spent
some
time
with
big.
Your
code
is
like
v8
uses
about
2.5
megabytes
per
VM.
So
if
you
have
a
lot
of
threads
a
lot
of
silos,
then
that
you
know
it
could
add
up
most
of
that's
just
because
you
know
you've
got
stacks
in
there.
You've
got,
you
know
a
stack
in
there
and
you've
got
a
heap
in
there
and
you
can
tune
these
things
down
right.
C
C
The
yeah,
the
only
deaf
in
there
is,
if
you
want
to
use
the
null
sandbox,
because
the
null
sandbox
is
actually
compiled
in
so
wasm
itself
as
a
32-bit
standard
right
now
and
the
null
sandbox
is
compiled
into
64-bit
envoy.
So
you
know
there's
a
difference
there
and
in
addition,
an
envoy
you
know
we
have
to
be
in
the
envoy
namespaces
there's
like
a
big
block
of
namespace
logic
that
has
to
go
in
around
your
code,
but
other
than
that
there
are
no
changes,
so
it's
actually
pretty
transparent.