►
From YouTube: Episode 16: Adding real-time updates to OPA with OPAL
Description
Our Chief Architect Yuval Kohavi has partnered with Or Weis, CEO at Authorizon, and Asaf Cohen, CTO at Authorizon to have a technical discussion about OPAL - a brand new open source project that helps you get the most out of your Open Policy Agents. In all of our live episodes, you will also have the opportunity for live Q&A via chat. Don't miss it!
About us https://www.solo.io
Questions? https://slack.solo.io
Code Samples: https://github.com/solo-io/hoot
Suggest a topic to cover here: https://github.com/solo-io/hoot/issues/new?title=episode+suggestion:
Links from the episode:
https://opal.ac/
https://github.com/authorizon/opal
netflix aggregation and realtime layer that was inspiration for OPAL:
https://www.youtube.com/watch?v=R6tUNpRpdnY
A
B
Thanks,
first
of
all,
it's
great
to
be
here
you've
all.
I
really
love
the
the
hoot.
It's
great
podcast,
video
blog.
I
don't
know
how
you
call
it
and
just
to
give
a
little
bit
of
background,
so
my
name
is
or
wise.
My
background
starts
in
the
intelligence
core.
I
worked
a
lot
in
cyber
security.
As
a
vp
of
r
d,
I
co-founded
a
company
called
rookout
in
the
production
debugging
space
and
now
working
with
us
off
in
the
extremely
hot
authorization
space
on
authorizing
and
as
you've
all
mentioned.
C
A
So,
as
always,
we
have
our
live,
chat,
feel
free
to
ask
question
lives
and
we
will
answer
them
live.
We
do
this
suit
about
every
two
weeks
and
next
week
tune
in
for
the
episode
about
rate
limiting
and
envoy.
So
without
further
ado,
let's
talk
a
little
bit
about
the
open
policy
agent
about
opel.
Why
don't
you
give
us
a
little
bit
of
an
intro?
B
Sure
so,
in
general,
we're
working
in
the
authorization
space
authorization
is
a
huge
problem,
everyone's
rebuilding
authorization
mechanisms
for
their
software,
for
the
infrastructure
level
and
for
the
application
level.
Up
till
now,
you
only
had
solutions
for
authentication
and
you
were
building
authorization
completely
on
your
own.
Recently,
there
are
new
trends,
new
open
source
solutions
that
you
can
use
to
build
the
authorization
for
your
infrastructure
and
for
your
applications,
the
two
leading
ones
as
we're
seeing
it
is
oppa
open
policy
agent
and
also
google
zanzibar,
we'll
focus
on
open
policy
agent.
B
Today,
open
policy
agent
is
a
general
purpose
policy
engine
that
uses
a
specific
dsl
called
rego,
which
allows
you
to
write
specific
authorization
code
for
your
application
and
decouple
it
from
your
microservices.
So
you
have
a
specific
layer
for
authorization
that
you
can
change
dynamically
without
having
to
change
your
code
and
vice
versa,
and
that's
oppa
and
oppa
is
great.
It's
highly
performant,
it's
part
of
the
cncf
ecosystem,
but
it
still
has
some
challenges,
especially
when
you
take
it
to
the
application
level.
B
Currently
oppa
expects
you
to
either
load
data
into
it
or
include
the
data
as
part
of
the
request
that
you're
sending
to
it
and
in
the
infrastructure
level
like
if
you're
just
doing
authorization
for
kubernetes
that
kind
of
works
well
because
things
change
at
the
pace
of
ci
cd
of
deployments,
but
in
the
application
level
or
more
complex
environments.
It
changes
a
lot
faster.
Think
about
you,
inviting
a
new
user
in
in
an
application.
B
You
don't
want
to
wait
for
deployment
to
for
that
user
to
get
access,
so
you
need
something
to
keep
open
up
to
date,
so
it
will
always
be
aware
of
what's
happening
in
the
application
level
and
above
so
that's
one
problem
that
we're
solving
with
opal
and
the
other.
One
is
just
the
overall
data
plane.
B
You
don't
only
have
data
inside
of
opa.
You
have
data
across
your
systems
that
you
might
be
needing
for
authorization,
for
example,
if
you
want
to
have
a
policy
saying
something
like
only
users
that
have
paid
for
the
product
should
have
access
to
it.
The
information
that
for
who
has
paid
usually
sits
today
in
a
service
like
stripe
or
charge.
A
file,
so
we
need
some
way
to
bring
data
from
those
services
into
opa
and
keep
them
in
sync
and,
lastly,
just
managing
the
data
plane.
B
You
have
a
lot
of
data
now
and
loading
a
lot
of
data
into
oppa
can
be
challenging.
With
opel
you
can
apply
sharding.
You
can
essentially
divide
the
different
bits
of
data
that
you
have
between
different
instances
of
oppa.
Keep
that
synced
in
the
background
with
opal
and
just
keep
on
sailing
as
if
nothing's
a
nothing's
different,
that's
kind
of
the
overall
picture.
B
A
B
That,
with
a
real
time
component
that
enables
you
to
sync
your
application
with
your
authorization
layer
with
opa.
I
can
elaborate
on
that.
Maybe
a
little.
The
way
that
works
is
with
a
real-time
web
socket
based
component
that
essentially
does
pub
sub
you
can
have
each
through
opal.
You
can
have
each
open
instance
subscribe
to
update
topics
saying
this
is
the
kind
of
policy
that
I
need.
A
B
A
C
Opel
usually
runs
oppa
for
you
in
the
background
and
syncs
the
data.
So,
for
example,
I
have
a
an
example
repository
here,
with
example:
rego
code,
okay,
very,
very
basic
hardback
policy,
an
example
data
that
it
runs
and
we're
gonna
use
the
opal
docker
compose
playground
that
comes
in
documentation
and
just
deploy
it
very
quickly
and
see
how
real-time
updates
look
like
with
opel.
So,
let's
just
do
it
very
quickly.
C
We
have
this
this
one
command
the
trends
opal
on
your
machine,
so
you
just
run
a
docker
compose
and
now
we'll
wait
to
see
that
opel
is
running.
Essentially,
opal
comes
as
a
server
client
configuration
where
the
server
syncs
all
your
agents
and
pushes
updates
to
the
agents
and
the
clients
are
running
oppa
in
the
background.
C
So,
let's
see
what
happened
here.
Essentially,
opel
client
fetched
fetch
data
from
the
opel
server
and
also
it
runs
oppa
in
the
background.
So
if
I'm
gonna
go
to
postman
and
now
I'm
gonna
go
to
port
8181.
That
is
oppa.
Basically,
and
I
look
at
the
data,
I
can
see
that
the
data
is
pushed.
Can
you
make
the
font
bigger?
C
Okay,
so
essentially
what
you
see
here
is
this
is
oppa
api.
Okay,
this
is
not
opal.
When
opel
client
runs,
it
runs
open
in
the
background
and
exposes
this
port
for
you,
so
you
can
talk
directly
to
open.
This
is
one
of
the
features
of
opel,
where
we
don't
sit
between
the
application
and
opus,
so
performance
of
authorization
queries
is
completely
the
same
as
running
oppa
standalone.
We
don't
come
between
open
the
application.
C
C
Let's
look
at
this
query.
Basically,
what
we
ask
here
is,
if
bob
can
read
a
finance
object
with
this
id.
Basically,
that's
the
that's
the
query.
Now
we
can
push
a
real-time
update
through
opal,
for
example.
Let's
say
it
was
a
billing
application
and
the
billing
data
changed,
so
we
can
push
and
update
with
opel
client.
Basically,
the
update
looks
like
we
published
through
a
topic
called
policy
data
and
we
said
to
oppo:
take
the
user,
slash
bob
location
document
in
open,
replace
it
with
the
data
from
this
url.
C
Basically,
the
api
country
iscro.
What
we
did
here
was
replace
the
user
location,
and
this
policy
declares
that
only
users
logging
in
from
the
us
can
access
documents.
This
is
a
rule
that
we
entered
in
the
example
repo.
Now,
if
you,
if
we
run
the
same
query
through
oppa
again
now,
we
can
see
that
that
the
result
changed
before
the
update
that
was
pushed
through
opel.
The
request
was
allowed,
and
now
it's
not
allowed.
So
this
is
a
very
quick
example
how
you
can
push
updates
via
oppo
to
your
oppa
agents.
B
Emphasize
here
that
you're
not
sending
the
data
directly
to
opel
you're
telling
and
to
the
clients
you're
telling
it
hey,
there
is
an
update
that
update,
sits
in
this
api
server
or
at
this
database
or
at
this
third
party
service
and
you're,
telling
it
go
fetch
the
data
yourself.
This
also
saves
on
heavy
queries
being
pushed
through
the
live
channel
and
also
enables
every
client
to
fetch
the
data
at
its
own
time
kind
of
distributing
the
pressure
across
the
network.
A
So
when
is
a
good
point,
I
have
some
just
to
understand
all
the
components.
When
is
a
good
point
to
ask
a
question:
now
it's
a
great
one,
so
I'm
just
trying
to
understand
that
kind
of
break
down
everything
we
just
saw.
So
we
have
opel
server.
We
have
opel
client
that
talks
with
opel
server
and
then
we
have
the
opel
agent
that
is
kind
of
a
sidecar
for
the
oppa
agent.
A
B
The
yeah,
so
the
opel
client
is
part
of
the
same
sidecar
usually
would
be
part
of
the
same
sidecar
as
the
oppa
agent.
They
would
be
leaving
side
by
side
next
to
the
microservice
that
you're
offering
authorization
to,
and
the
opel
client
talks
with
the
oppa
instance
through
its
regular
api,
the
opel
client-
maybe
it's
a
maybe
I'll,
show
a
quick
slide
on
that.
A
C
B
You
know
so
this
is
kind
of
like
the
overall
architecture,
so
we've
got
the
opal
server.
You
have
your
application
or
micro
services,
and
you
have
the
opa
agent
and
the
opel
client
sitting
next
to
each
other.
The
opel
client
subscribes
over
the
websocket
pub
channel
to
the
opal
server
for
updates
and
the
opel
server
monitors
updates
coming
both
for
policy
and
data
for
data.
B
A
Yeah
go
ahead
so,
with
this
slider's
context,
I'm
trying
to
understand
what
we
saw
now
was
a
command
line
that
happens
to
be
the
client,
but
that
doesn't
really
matter
right.
Talk
to
the
server
and
told
it
to
push
a
live
update
and
the
live
update,
told
the
opel
client
to
fetch
data
from
a
data
source
and
feed
it
to
the
open
policy
agent.
Is
that.
B
Yeah,
so,
in
the
same
way,
we
could
have,
for
example,
apply
charting,
for
example,
if,
instead
of
having
all
the
data
pushed
into
all
the
opel
agents,
you
could
have
said
only
these
specific
clients
and
their
adjacent
opa
agents
should
get
that
data,
and
then
you
can
split
the
data
and
just
constantly
runs
in
the
background.
You
can
constantly
trigger,
updates
and
then
and
have
opal
sync,
your
opa
agents.
B
So
when
your
application
comes
in
for
query,
the
opa
agent
is
already
ready,
and
you
can
also
another
thing
that
is
cool
here
is
that
you
can
have
the
application.
Also
listening,
the
application
can
say.
Oh,
let
me
know
when
the
oppa
agent
is
ready.
Call
me
back
when
I
can
start
performing
queries,
and
it
can
also
actively
ask
the
oppa
agent
with
a
policy
that
we
have.
Are
you
ready
for
to
answer
my
questions.
B
C
B
C
A
C
Yeah,
yes,
definitely
everything
that
you
can
put
in
a
git
repository.
You
can
sync
through
opel
oppa,
essentially
exposes
something
that
we
call
a
dynamic
bundle
which
is
very
similar
to
the
opal
bundle
shape,
but
is
also
geared
toward
towards
delta
bundles
and
also
to
couple
multiple
files
together.
So
yeah.
Definitely
you
can
just
sync
a
completely
complete
git,
repo
or
or
only
some
parts
of
the
repo
and
sync
it
through
oppo.
C
A
While
you
start
maybe
expand
a
little
bit
more,
you
talked
about
opel
oppa
bundles,
and
I
know
oppa
has
a
way
to
remotely
fetch
those
bundles
that
can
contain
data
or
policy.
So
can
I
maybe
pros
and
cons
this
approach
versus
that
approach?
When
would
I
want
to
use
this
or
when
would
bundles
would
just
be
enough.
C
Yeah
sure
so,
basically,
oppa
bundles
are
great
for
the
infrastructure
layer,
because
the
way
it
works
you
set
up
your
bundle,
server
and
then
oppa
agents
are
polling
that
server
every
couple
seconds
and
see
if
a
new
bundle
is
available.
But
this
is
not
so
great
for
an
application,
because
in
an
application,
a
user
action
can
actually
change
the
policy.
C
For
example,
if
I
invite
you
to
a
google
doc
document
now
the
moment
I
press
the
invite
or
the
share
sheet,
and
I
assign
you
a
new
role,
you
expect
to
have
immediately
and
access
to
the
document,
but
if
you
run
with
the
bundle
server,
it
won't
work
because
oppa
will
wait
for
the
next
time.
It
needs
to
pull
a
new
bundle
and
in
the
meanwhile
the
user
will
not
have
access.
B
You
can
always
stretch
opa
to
that
layer,
but
at
some
point
it
becomes
painful.
That's
where
we
decided
that
we
need
to
add
something.
On
top,
we
started
building
our
solution
almost
exclusively
on
opa,
and
we
started
to
feel
the
pain
there
in
the
pace
of
updates
that
we
need
to
face
and
also
the
amount
of
data.
C
And
it's
also
great
to
mention
here
that
the
way
we
model
opel
is
very
similar
to
how
netflix
built
their
authorization
with
oppa,
so
essentially
what
they
did.
There
is
use
the
opa
agents
to
evaluate
their
policy
and
they
actually
expose
some
kind
of
ui,
which
they
don't
show
in
their
talk,
but
we
can
link
it
after
the
after
the
session,
but
essentially
they
push
updates
through
their
aggregation
and
updates
layer
that
they
build
and
they
also
aggregate
multiple
data
sources
through
that
aggregation
layer.
C
A
C
A
B
B
So
you
can
mix
and
match
policies
as
much
as
you
like,
there's
actually
no
limit
here,
and
on
top
of
that,
if,
if
you
want
to
go
in
in
addition
to
what
opal
does
go
and
manually
shove,
more
policies
into
oppa,
you
can
do
that
too.
There's
again,
as
I
said
before,
there's
no
limitation
on
how
you
use
oppa
when
you're,
using
open
aside
from
if
you
specifically
try
and
override
what
you
asked
opal
to
write
for
you.
C
Yeah
so
or
is
correct.
Essentially
we
expose
the
oppa
policy
as
topics
sub
topics,
so
you
can,
in
your
repository,
have
one
directory
for
all
the
common
oppa
policies
that
are
shared
between
all
your
agents.
But
let's
say
you
have
a
multi-tenant
application.
You
want
some
policies
only
for
for
specific
tenants,
so
you
can
have
a
tenants
directory
in
and
inside
the
directory
for
each
tenant,
and
then
you
can
subscribe
to
that
to
that
directory
for
each
specific
agent.
C
So
each
opel
client
goes
up
with
a
list
of
policy
topics,
essentially
that
it
subscribes
to
so
you
can
have
a
different
configuration
for
each
opel
client
and
the
same
opel
server
can
serve
the
this
policy
for
all
the
agents.
So
each
oppo
client
can
decide
what
kind
of
policy
it
needs
through
subscriptions
and
the
opal
server
can
serve
everything
in
any
model
that
you
like.
A
B
B
In
the
end
of
the
day,
the
decision
logs
themselves
are
something
that
oppa
produces
not
oppo
and
you
can
have
whichever
solution
you
want
to
stream.
Those
outside
you
can
use
styro
dust.
You
can
use
something
homebrew
and
maybe
down
the
road,
we'll
also
offer
something
there.
We're
also
constantly
talking
to
the
guys
at
the
styron
oppa
to
co-evolve
the
products
and
trying
to
see
that
we
put
our
efforts
where
they're
based
best.
A
Put
all
right,
very
cool
and
again,
if
there's
more
questions,
feel
free
to
drop
them
in
the
chat.
So
what
I'm?
Let
me
just
summarize
what
I'm
hearing
so
far.
Essentially
it's
a
complementary
tool
to
oppa
that
allows
you
to
do
kind
of
real-time
updates
and
solve
challenges
that
are
present
in
the
application
layer
versus
the
infrastructure
layer.
A
B
Yeah,
so
there
are
a
lot
of
parts
that,
like
you
know,
we
described
this
kind
of
very
quickly,
but
we've
really
designed
a
rather
complex
solution
here
and
we
thought
of
a
lot
of
pain
points
that
you
need
to
tackle
for
this
to
work
correctly.
So
the
positive
side
for
that
is
most
people
don't
have
to
worry
about
it.
They
can
just
use
opal
and
know
that
you've
kind
of
covered
this
for
them.
But
let's
try
and
highlight
some
of
those
friction
points.
B
One
of
them
is
network
conjection
or
the
net
connection
is
being
severed.
So
the
idea
is
because
we're
using
a
live
channel,
we
can
constantly
send
diffs
to
the
opel
clients,
so
they're
constantly
subscribing
to
more
updates
but
they're
tracking
if
they
lose
the
connection
and
if
they
lose
the
connection
they're
aware
of
it.
It's
not
like
it
happens
in
the
background,
then
they
they
forget
about
it.
B
So
when,
when
that
happens,
they
essentially
are
aware
that
they
are
no
longer
updated
and
they
try
to
re-establish
the
connection
and
re-fetch
everything
from
round
zero,
as
if
they
have
nothing
in
the
future.
We'll
also
have
some
diff
mechanism
there,
so
they
can
say
okay,
this
is
where
I
lost
to
and
and
bridge
the
gap.
B
But
for
now,
if
a
connection,
if
the
connection
is
lost,
the
opel
client
will
understand
it
has
been
disconnected
and
re-establish
the
entire
update
sequence
to
that
point
in
terms
of
if,
in
general,
the
network
like
if
your
opal
server
is
no
longer
available,
your
open
instances
can
still
work
in
general.
If
the
opel,
client
and
opel
server
are
down,
the
oppa
instance
itself
can
still
be
functional
and
you
can
still
send
queries
to
it.
B
The
only
thing
is
that
they
might
be
up
to
date
and
you
can
use
opel
to
mark
the.
You
can
essentially
query
oppa
to
know.
When
was
the
last
update
that
it
got,
and
you
can
query
opal
to
know
if
there
are
additional
updates
that
are
incoming,
so
you
can
kind
of
choose.
What's
the
right
solution
for
your
application,
that
point
you
can
say:
okay,
I've
lost
connection
and
I'm
unable
to
retrieve
updates
and
say.
Okay.
B
A
Makes
makes
a
lot
of
sense.
Essentially,
what
I'm
hearing
is
that
you
have
customized
behavior
how
to
behave
on
failure
and
one
of
the
options
that
people
usually
like
is
you
know,
keep
less
known,
good,
config
yeah
until
there's
another
way.
What
about
things
like
observability
like
if,
if
oppa
disconnects,
is
there
like
a
metric?
I
can
watch
or
anything
like
that.
B
A
C
C
I'll,
just
mention
that
when
you
use
the
sas,
you
actually
are
not
aware
of
oppa
or
opal.
It
all
runs
in
the
background
seamlessly
and
you
just
like
integrate
with
a
simple
sdk.
So
we
can
break
down
the
update
once
we
see
it
and
see
that
it
works
through
opal.
So
what
we
see
here
is
a
very
simple
to
do:
application
where
you
can
add
to-do's
and
you
can
delete
them
and
you
can
check
and
uncheck
them.
This
application
is
a
fronted
application
in
react.
C
So
this
application
used
the
authorizing
sdk
to
expose
something
that
we're
call
enforcement
points.
Essentially,
the
points
that
you
want
to
enforce
permissions
on
and
here
in
the
sas
you
can
see
that
we
have
several
roles
in
arba
configuration
where
we
have
tasks
and
board.
Essentially,
each
task
here
is
a
separate
task.
Resource
and
a
board
essentially
holds
several
tasks
together,
and
you
can
add
several
boards
if
you
want,
and
each
one
exposes
different
enforcement
points,
different
actions
essentially
and
we
assign
them
through
to
the
roles.
C
Essentially,
the
admin
has
all
the
permissions
and
the
viewer
has
some
permissions
read
permissions,
so
the
cool
thing
is
that
if
I
want
to
delete
this
task,
I
can
do
it.
The
api
returns
a
standard
standard
response
and
allows
the
request
and
delete
everything
from
the
db,
but
now
I
will
change
the
configuration
and
save
it
in
rs
and
at
the
point
that
I
save
it,
opel
will
push
an
update
in
the
background
to
the
opa
agent,
and
now
the
api
throws
four
free
exception
and
it
seamlessly
works.
C
Another
thing
to
mention
here
is
that
the
configuration
that
you
see
here
for
arbuck
is
essentially,
in
the
background,
a
regular
policy
with
regular
code
and
data,
and
everything
is
flexible.
So
you
can
replace
your
entire
policy
with
something
like
attribute
based
access
control
and
nothing
in
your
application
needs
to
change.
B
B
If
you
want
to
be
able
to
change
your
policy
in
real
time,
which
is
something
that
happens,
for
example,
your
product
manager
or
salesperson
want
to
do
something
on
top
of
the
application
you
want
to
enable
them
to
do
it
for
you
having
to
do
it
and
opel
just
does
all
the
heavy
lifting
here.
We
just
push
an
update
into
a
repo
and
it
propagates
all
the
way
down.
C
And
I
think
the
cool
thing
about
this
is
that
authorize
and
is
all
about
complete
experiences.
So
you're,
not
you,
you
can
always
drop
down
to
code
and
you
can
edit
the
rego
and
you
can
decide.
You
want
a
very
custom
policy,
but
we
also
have
the
templates
where
you
can
just
choose
the
arbuck
template
or
abac
template
and
just
use
a
standard
kind
of
policy,
and
you
can
have.
C
You
can
have
embedded
api
in
sorry
ui
interfaces
where
you
can
have
complete
experiences,
that
are
permission
related
on
top
of
the
infrastructure
that
we
build.
So
essentially
you
have
a
complete
user
management
screen
where
you
can
edit
the
rows,
and
I
can
decide
that
this
email
is
now
a
viewer
and
it
has
no
edit
access
to
this
to
this
board.
C
A
Very
cool,
so,
let's
start
wrapping
up.
I
want
to
see
I
want
to
do
like
a
pop
quiz
to
myself,
see
if
I
I
can
reiterate
of
what
you
said
about
what
opal
does
so
opal
kind
of
gives
you
a
control
plane
for
real
time
updates
for
config
and
data
to
kind
of
and
with
the
with
the
goal
of
enabling
opa
usage
in
an
application
use
case.
A
B
C
C
So,
for
example,
we're
very
interested
in
other
policy
engines
such
as
keto
with
ori
and
stuff
like
that,
and
we
want
to
essentially
bridge
between
different
policy
stores
so
that,
if
you
start
with
one
and
you
want
to
migrate
to
the
other-
and
you
want
to
migrate
back
and
you
want
to
work
with
them
together.
Essentially
you
can
that's
basically
the
vision
for
opel
on.
B
Language,
no,
not
not
at
this
point,
but
you
can
essentially
have
them.
I
don't
want
to
kind
of
spoil
a
lot
of
things
that
we
kind
of
have
for
down
the
road,
but
you
can
essentially
have
them
working
with
one
another.
If
you
plan
for
it,
you
won't
be
able
to
switch
them
out
of
the
box,
but
you'll
be
able
to
have
them
work
alongside
one
another
and
use
one
another
as
kind
of
data
sources
or
additional
places
to
redirect
the
queries.
A
B
So
we
try
to
keep
them
together.
We
currently
have
everything
on
github,
so
you
can
go
to
github.com
authorizing
that's
off
horizon,
as
one
word
slash
oppo,
if
you'll,
google
authorize
and
opel
you'll
also
find
it,
and
it's
also
easy
to
find
on
opel.ac,
which
is
our
basic
documentation
website
and
with
a
clear
description,
a
quick
video.
So
you
can
probably
start
from
there.
That
would
lead
you
to
our
github
repository
and
also
we
have
a
small
slack
community
that
you're
welcome
to
join
and
ask
myself
and
us
off
questions
directly.
A
B
Yeah,
so
you
can
find
us
on
twitter,
you
can
find
you
can
ask
questions
on
our
github.
We
use
both
github
discussions
and
github
issues.
So
if
you
want
like
a
feature
or
you
have
a
problem-
something
that
you
just
want
to
report
get
up
issues
or
get
a
discussion
is
the
way
to
go.
If
you
want
to
ask
more
in-depth
questions,
you
can
find
us
either
in
our
slack
community.
You
can
also
find
us
in
oppa's,
sled,
community
and
yeah.
B
A
A
It's
it's
great
to
see
more
projects
open
source
projects
in
this
opa
ecosystem.
I
know
people
really
love
oppa
and
I
I
think
that
use
case
to
bringing
it
to
the
application
layer
makes
a
lot
of
sense,
and
with
that
I,
I
don't
think
we
have
more
questions
in
the
chat.
If
there
are
now
is
a
good
time
to
to
place
in
your
final
questions,
we'll
start
wrapping
up
and
thank
you
arenas
for
joining
me
today
and
any.
B
C
Yes,
so
the
example,
repo
is
also
under
the
authorized
organization
on
github,
but
basically
go
to
the
oppo
repo
and
we
have
the
entire
thing
as
a
document
as
a
quick
start
guide,
you
can
just
follow
along
the
instructions,
and
everything
is
very
in
a
lot
of
detail.
Essentially,
so
you
can
just
go
to
a
rep
and
you'll
find
everything
there.
All
the.
B
A
A
All
right,
very
cool,
so
with
that
we'll
wrap
up
for
today,
we'll
see
everybody
in
two
weeks
we'll
talk
about
re-limiting
and
envoy
kind
of
decipher.
What's
going
on
there,
it's
sometimes
going
to
be
a
bit
cryptic
a
thank
you
everybody
for
joining
today.
Thank
you.
Thank
you,
asap
and
we'll
see
y'all
in
two
weeks,
bye.