►
From YouTube: 20191217 Kubernetes Multi-tenancy Working Group
Description
Ryan Bezdicek (Cray) reviews the new CoreDNS + OPA plugin model
A
B
Sure
I
need
to
figure
out
how
to
share
my
screen.
Do
I
don't
do
I
have
access?
No,
that's
the
big
green
button,
so
yeah.
So
this
is
on
like
Yukon,
they
kind
of
announced
our
at
least
I
heard
that
they
had
created
a
generic
firewall
plugin
for
cardenas
and
with
that
they
allowed
you
to
use
external
policy
engine
to
make
the
decisions
for
the
firewall
on
plug-in
on
Cortinas
and
so
I
had
promised
last
week.
That
I
would
attempt
to
do
a
PLC
for
this
and
Here
I
am
so.
B
I
literally
did
this
this
morning,
because
I
kind
of
forgot
about
it,
so
it's
a
little
rough,
but
it
does
work
and
we
it
should
be
pretty
easy
to
to
kind
of
polish
out.
So
the
first
thing
I'm
gonna
kind
of
go
over
is
the
actual
OPA
policy
that
we
will
we
will
create.
This
is
basically
straight
from
their
github
example.
B
If
you
know
Rago,
it
kind
of
looks
pretty
straightforward.
If
not
you'll
pick
it
up
pretty
quickly,
then
they
have
an
awesome
playground
here,
where
you
can
actually
put
in
your
policies
on
their
website
and
then
you
can
pass
it
in
inputs
and
then
determine
what's
out
there.
So
we'll
do
a
demo
of
this
in
a
second
but
first
we'll
walk
through
the
policy.
B
So
first
we're
just
basically
gonna
grab
from
the
incoming
request,
the
name
which
is
going
to
be
the
actual
DNS
name,
we're
looking
up
and
then
the
client
IP,
so
the
requester
of
who
is
actually
requesting
that
name
lookup
and
then
will
have
a
default
action
of
allow.
And
then
we
have
kind
of
this
weird
kind
of
for
kind
of
switch
thing.
B
That
kind
of
indicates
of
what
the
action
variable
will
be
set
to
based
off
of
what
was
called
below
and
and
so
we'll
see
so
it'll
be.
There's
allow
refused
block
and
drop,
and
these
all
translate
to
actual
DNS
responses,
and
so
we'll
kind
of
see
that
in
later,
but
you
can
kind
of
guess
or
refuse,
is
actually
saying.
I
refuse
to
actually
answer.
B
This
block
will
basically
just
return
in
an
X
domain
to
say:
I,
don't
really
know
what
it
is
and
then
a
drop
essentially
just
gives
up
and
then
eventually
the
client,
where
we
try
a
couple
of
times
in
the
middle
timeout.
So
that's
basically
what
will
happen
from
a
DNS
perspective?
I
mean
so
you
see
here
we'll
take
a
couple
of
justjan
domain,
so
we'll
block
github.com
will
refuse
kubernetes
at
I/o
and
we'll
drop
google.com.
B
This
is
what
I
call
developing
in
hard
mode
and
then
you'll
see
here
we
can
go
even
further
and
this
is
from
there
they're
examples.
We
can
allow
anything.
So
we
can,
we
can
have
all
this
stuff,
but
then
we
can
allow
anything
to
go
through
if
it's
part
of
this
site
or
block.
So
if
the
incoming
client
IP
is
part
of
this,
we
will
ignore
the--
above
and
what
will
actually
happen
here.
B
Is
it's
going
to
go
through
all
of
these,
and
so
you
can
have
multiple
matches
that
will
get
responded
back
so
some
we
there
is
a
possibility
that
if
you
have,
if
you're
part
of
this
side
or
block
here,
it
will
actually
return
in
the
payload
from
OPA.
The
action
will
be
set
to
allow,
but
then
it'll
actually
have
block
equals.
True,
as
well
as
allow
equals
true,
so
you
can
do
more
complex
things.
The
the
Gordian
is
plug-in
itself.
B
Okay,
so
right
here
with
the
awesome,
Rago
playground
and
we'll
see
that
will
pass
in
the
request
that
will
look
pretty
similar
to
what
core
DNS
will
send
to
OPA
there'll,
be
a
bunch
more
stuff,
that'll
actually
said
metadata.
You
can
actually
have
a
register
and
some
metadata
and
you
can
do
grouping
stuff
and
get
pretty
advanced
with
this,
but
I'm
keeping
this
pretty
basic.
B
So
if
we
do
a
request
for
google.com
and
our
kind
that
he
is
this,
which
is
not
part
of
the
side
of
off
below
you'll,
see
that
we'll
get
an
action,
equals
drop
and
then
drop
equals
true.
So
this
is
what
will
be
returned
back
to
you
or
DNS,
or
the
Cortinas
plugin.
If
we
change
the
cider
to
match
will
actually
give
them
an
allow,
and,
as
I
mentioned
before,
both
of
these
variables
were
returned
is
true.
B
What
coordinates
really
only
cares
about
the
actions
variable
and
this
is
really
just
kind
of
emitted
and
then,
if
we
go
through
anything
anything
else
right.
So
if
we
do
great
calm,
the
allow
is
true
and
everything
else,
because
it
doesn't
actually
match
our
things.
I,
don't
know.
If
we
did
github
you'll
see
that
we'll
have
a
block
as
well
and
then
I
think
and
then
Google
will
be
draw
and
then.
B
B
A
pretty
simple
regular
policy
and
how
it
works
and
how
this
works.
In
the
context
of
actual
the
core
DNS
plug-in,
it's
pretty
straightforward,
there
dots
I'm
going
to
a
little
more
detail
of
some
more
advanced
things
you
could
do
so
this
is
kind
of
the
OPA
setup
and
basically,
what
we're
going
to
deploy
is
we're
going
to
deploy
OPA
with
this
basic
policy
and
have
cárdenas
and
all
all
to
it.
Any
questions
on
the
LP,
a
side.
B
Awesome
cool,
so
then
the
next
thing
we're
gonna
have
is
we're.
Gonna
have
our
core
file
for
DNS,
and
this
is
pretty
simple
as
well.
We
have
the
plugins
as
I
mentioned,
there's
the
generic
firewall
plug-in
that's
new
and
that
basically
says
for
firewall
at
the
query
level.
So
you
can
do
read
query
the
query
and
I
forget
what
the
actual
keyword
is,
but
it's
the
response.
B
And
so
that's
what
dictates
the
URL
there
and
then
action
is
what
is
the
the
the
lookup
or
the
the
response
that
we
care
about
and
that's
where
that
comes
from,
and
so
that's
pretty
straightforward.
One
of
the
gotchas.
That
is
part
of
this
is
because
we're
running
OPA
as
a
sidecar
with
core
DNS
core
DNS
is
default.
Readiness
probe
is
on
port
81
81,
which
is
actually
conflicts
with
OPA.
B
So
in
our
core
file
we
actually
changed
the
readiness
Pro
port
to
80
81
to
remove
that
conflict
and
then
in
the
in
the
readiness
probe
below
we
in
the
actual
config,
we
have
to
make
sure
we
change
it
as
well,
so
they
match,
and
so
that's
a
gotcha
that
we
had
from
there.
It's
pretty
straightforward,
we're
just
going
to
create
a
service
that
is
UDP
and
TCP
of
port
53
for
DNS
and
then,
as
I
mentioned
before,
we're
going
to
deploy
core
DNS
and
OPA
is
a
sidecar
to
it
in
the
same
deployment.
B
We're
mounting
our
policy
as
a
config
map
and
passing
it
in
same
with
our
core
file,
pretty
straight
from
that
perspective,
and
then
that's
kind
of
about
it
from
an
employment
perspective.
The
other
gotcha
that
I've
kind
of
glossed
over
here
is
that
I
actually
have
to
use
my
own
core
DNS
docker
image
and
the
problem
with
that
is
core
Deanna's
plugins.
B
They
are
a
compile
time,
they're
loaded
at
compile
time,
so
we
actually
had
to
enable
the
these
new
third
party
external
plugins,
even
though
they
come
from
Corgi
nests
are
still
technically
external
because
they're,
so
relatively
alpha,
beta
and
so
I
had
to
build.
That
I
mean
it's
actually
pretty
trivial
I'm.
How
to
do
that
and
I'll
talk
about
that
in
a
second
but
yeah.
So
once
we
deploy
this,
it
will
get
deployed
and
then
we
can
test
it
out
any
questions
on
the
actual
llamó
and
Howard,
deploying
core
DNS
and
OPA,
etc.
C
Right,
I
have
a
question,
so
you're
deploying
this
as
a
sidecar.
What,
if
how
does
this
work,
then?
If
I
have
a
service
mission,
it
has
a
sidecar
who
intercepts
the
the
traffic
or
how
does
that
get
routed?
You
know,
as
if
I
have
a
sidecar
and
a
match
and
I
always
come
through
that
proxy.
Does
it
still
be
secure?
What's
that
interaction,
sure.
B
So
yeah,
if
you
have
a
service
mesh
I
mean
it
really
depends
if
you're
doing
a
service,
if
you're
actually
injecting
the
service
measure
sidecar
to
your
DNS.
That
would
regardless,
if
you're
doing
that
or
if
you
are
doing,
if
it
just
on
the
actual
end
services,
the
proxy
is
all
it's
going
to
do.
Is
it's
kind
of
basically
generally
and
I'm
talking
about
HDX,
that's
what
I
know
better
than
the
other
service
meshes,
but
from
an
SEO
perspective
right
all
it
does.
B
Is
it
hijacks
the
incoming
and
egress
calls
to
the
service
mesh
or
to
the
actual
service
itself?
So
let's
say
we
have
just
like
a
a
an
engine,
X
Server,
if
that's
running,
and
it
has
the
sto
sidecar
any
requests
into
that
will
be
sent
to
the
Envoy
proxy
for
hto
first
and
it
will
do
processing
and
then
it
passes
it
through
and
then
the
egress
will
get
then
go
through
the
filtering
so,
depending
on
how
your
filtering
is
set
up.
B
It
shouldn't
really
matter
because,
what's
going
to
happen
is
well
for
one
SEO
doesn't
really
handle
any
UDP
traffic,
so
it
was
assuming
you
using
UDP
or
a
DNS,
it's
not
going
to
matter,
but
regardless,
if
it's
over
TCP,
it's
still
going
to
make
it
to
our
core
DNS
pod.
Eventually,
so
it's
going
to
get
into
the
pod
and
run
through
this
lookup,
and
so
from
this
perspective,
because
this
is
a
sidecar
it's
on
localhost
and
communication
between
localhost,
even
in
it
at
least
the
SEO
service
mesh.
B
So
that's
the
the
setup,
the
actual
the
gotcha
to
creating
your
own
core
DNS
container,
as
I
mentioned
before
it's
not
too
difficult.
So
all
you
have
to
do
is
clone
the
core
dienes
repo
itself
and
in
there
they
have
a
plugin
config
and
actually
have
some
nice
docks
here.
What
you
have
to
do,
since
you
just
have
to
do,
go
generate
after
you,
edit
this
file,
and
then
you
you
follow
their
their
release
process.
B
A
B
And
the
release-
maybe
it's
in
the
actual
firewall
me
I,
better,
give
steps.
It's
basically
you
do
make
release
and
you
pass
it
in
the
Linux
architecture
that
you
want
or
all
of
them
and
the
repo
and
then
basically
what
it
does
is
you
do
the
make
release
and
build
the
docker
image
and
you
push
it
up
and
it
just
it
compiles
it
with
those
plugins
and
then
it's
there.
B
B
Yes,
the
other
got
you
to
that.
I
noticed
it
when
we're
in
our
in
our
core
file,
a
decision
for
refuse
or
a
drop
or
a
block
will
basically
be
omitted.
If
you
turn
a
forwarding
on
because
it
it,
then
it
basically
it
says:
oh
I,
don't
know
how
to
handle
this
locally,
so
I'm
gonna
forward
it
on,
and
then,
if
it
has
an
answer,
then
it
actually
returns.
I'm
not
quite
sure
what
the
intent
of
that
is,
but
basically
so
it
seems.
B
Any
other
questions
before
we
get
to
the
demo
so
Ryan.
Why
do
we
need
that
firewall
in
this?
The
the
firewall
plugin,
so
the
firewall
plugin
is,
is
the
core
DNS
plugin
for
allowing
you
to
refuse
block,
drop
or
allow
dns
lookups
based
off
of
some
sort
of
query
or
some
sort
of
parameters,
and
so
that
is
the
plugin
that
allows
you
to
pass
it
to
OPA.
So
if
we
do.
B
Accordion
as
policy
is
the
is
the
actual
plug-in
structure.
So
this
is
this
implements
the
firewall
as
well
as
core
DNS
and
then
a
couple.
Others
CMAs
is
the
other
one
for
policy,
but
basically
you
don't
have
to
use
OPA
with
the
firewall
plug-in.
You
can
do
any
sort
of
kind
of
like
a
regex
type
of
query,
so
you
can
say
all
of
this
pretty
hard
coded
in
the
actual
core
file
itself.
D
Right
I
have
a
question
as
well
sure,
so
let
me
know
if
the
demo
will
cover
this,
but
I'm
not
sure
how
I
understand
this
working,
but
what
kind
of
multi-tenancy
use
cases
going
to
address?
Is
it
the
case
where
you
have
multiple
completely
independent
users
on
the
same
cluster,
who
don't
even
share
the
same
DNS
service.
B
Potentially
so
I
don't
really
know
the
full
application.
I
just
thought
it
could
be
pretty
useful
for
some
people,
but
one
look
at
this
case
could
potentially
be
you
you
will
either
you
basically
want
to
disallow
any
DNS
lookups
to
a
different
namespace
if
they
are
not
part
of
a
group,
so
you
can,
as
I
mentioned
before,
you
can
do
metadata
in
a
firewall.
Let's
see
if
I
think
it's
in
the
actual
OPA
read
me,
so
you
could
do
metadata
for
go.
B
They
have
too
many
read
Me's
a
so
right
here,
so
you
can
do
metadata
in
the
actual
DNS
request.
So
if
there
is
metadata
added
to
the
DNS
lookup
you
can
you
can
at
refuse
based
off
of
that.
So,
okay,
if
the
dig
call-
or
you
know
the
DNS
lookup
had
I'm
submitted
data
for
tenant
built
into
it,
we
could
then-
and
that
was
signed.
You
can
you
know
with
you-
know
modern
Guinness.
You
can
actually
sign
the
the
request
coming
through.
We
can.
B
We
can
basically
allow
lookups
for
different
services
running
in
in
different
namespaces.
To
prevent,
like
you
know,
just
kind
of
walking.
Oh
is
this.
Is
this
an
actual
pod
in?
Can
I
you
know,
query
it
and
on
these
ports,
I'm
just
kind
of
more
of
a
scanning
perspective
or
I?
Guess
one
one
lookup
or
one
kind
of
use
case
I
can
think
of
I'm,
but
I,
don't
know
of
any
concrete
use
cases
for.
E
B
B
You
just
won't
be
able
to
access
that
that
range,
so
the
DNS
will
still
resolve
that
you
just
want
have
access
to
that
that
system,
so
this
kind
of
helps
prevent
some
metadata
leakage
to
figure
out
what
services
other
teams
may
be
running
in
the
cluster,
and
then
you
know
use
that
that
metadata
to
maybe
find
potential
leaks
like
if
you
find
out
that
using
MongoDB
you
could
be
like.
Oh
I,
know
the
ports
for
that
and
I
know
some
exploits
and
then
potentially
try
to
get
around
it.
B
E
So
so
coordinates
by
itself
is
not
planning
on
adding
any
feature
which
scopes
DNS
responses
to
the
originating
namespace
that'll,
always
so
because
you
can
uncomment
it
with
our
back
either
right.
So
there's
no
our
back
way
to
scope,
DNS
queries
to
the
to
their
own
namespace,
so
DNS
itself
planning
you
know
a
way
of
option
having
a
config
option
to
limit
queries
and
responses
within
the
same
new
space.
That's.
B
It
would
be
useful
for
us
to
I
guess
reach
out
to
the
core
DNS
folks
to
see
what
their
thoughts
are.
The
people
that
are,
that
kind
of
owned
this
plug-in,
but
it's
from
a
DNS
perspective,
it's
kind
of
difficult
to
to
limit
that
from
an
are
back
perspective.
Just
because
then
I
guess:
where
do
you
draw
the
line?
You
know
what
I
mean
is
if
you
don't
have
DNS
outside
of
your
name
space
at
all,
then
how
do
you
ever
talk
to
anyone
outside
of
your
namespace,
especially
like?
E
Saying
for
the
case,
whether
you
know
it's
in
another
namespace,
it
is
on
cluster
dot,
local,
but
it
is
on
another
means
they
start
clustered
or
local.
Anyway.
That's
fine!
Our
back
is
anyway
in
the
EPS
server
and
we're
talking
about
a
data
plane
event
here.
So
it's
not
matching
our
back
anyway,
right.
B
And
so
yeah
and
so
I
mean
yeah.
Everything
is
you
know
it's
cluster
at
local
and
it's
going
to
be
the
service
or
pod
name,
dot,
the
namespace
dot.
You
know
service
star
cluster
at
local,
so
it's
kind
of
well-defined,
and
so
you
could
potentially
lock
it
down
from
that
perspective,
but
I
not
I,
don't
I'm
unaware
of
of
any
work
to
be
done
in
the
kubernetes
perspective.
To
make
that
easier
in
kubernetes
and
I
think
the
answer
would
likely
be.
F
B
Protect
from
a
DDoS
attack,
I'm
not
and
I
mean
not
from
this
perspective.
I
don't
think
I
mean
it
would
basically
mute,
but
you
would
probably
want
to
prevent
against
that
elsewhere.
But
at
the
same
time
you
know
if
it's,
if
UDP
traffic
and
DNS
are
generally
really
quick,
it
kind
of
takes
a
lot
to
take
it
down
and
we
can
always
scale
it
if
we
have
to.
But
if
we're
talking
to
the
point
of
full
DDoS,
then
you
would,
we
would
want
to
use
something
else,
and
you
can
do.
B
Is
you
know
circuit
breakers
or
other
load
balancers?
If
you're
truly
concerned
about
that,
but
I
mean
DNS
is
generally
kind
of
fundamental
to
most
things,
and
so
you
have
to
be
pretty
resilient
and
able
to
handle
significant
amount
of
load
generally
so
I
guess
DDoS
is
certainly
happens
but
I.
It's
I,
guess
one
of
my
my
lower
concerns.
B
G
B
Well
so
core
DNS
right
is
going
is
just
the
DNS
lookup,
so
it's
just
gonna
say:
here's
a
name.
Is
that
values
to
it
and
then
the
network
policy
itself
would
enforce
the
actual
communication
over
those
IDs,
and
so
this
is
kind
of
a
step
in
there
can
say:
oh
you
don't
actually
get
an
IP
address,
that's
associated
I'm
so
prevents
I.
Guess
it
can
help
prevent
against
some
Network
policy
traffic
if
you're
relying
on
DNS.
But
then,
if
you
have
the
IP
address,
you
still
want
that
that
network
policy
and
play
sure.
G
You
know
yes,
so
I
understand
both
are
needed
and
the
separation
of
the
two,
but
it
seems
like
all
the
information
necessary
to
generate
these
firewall
rules
would
also
be
described
in
the
network
policy.
So
perhaps
there,
if
there's
a
way
to
just
create
these
firewall
rules
from
the
network
policy
that
simplifies
having
to
configure
two
things.
Yeah.
B
I
agree
and
I
think
I
mean
it
would
be
nice
if
I
mean
there's
not
really
a
good
way
to
shell
out
a
network
policy
decision
based
off
of
okay
but
yeah.
It's
kind
of
its
kind
of
hard.
From
that
perspective,
to
keep
up
and
I
mean
the
main
problem
with
network
policies
in
general.
Is
most
people
don't
use
core
kubernetes
network
policies
or
many
people
do,
but
many
people
use
other
implementations
from
like
calico
or
sto
or
others.
So
it'd
be
kind
of
difficult
from
that
perspective.
E
I'm
not
sure
how
a
network
policy
would
look
for
this
case
because
you're,
maybe
thinking
of
case
where
you
apply
a
network
policy
to
the
core
DNS
board,
and
it
says
you
know
match.
If
if
the
sources
found
this
namespace,
then
the
DNS
response
which
is
inside
the
packet,
has
constraints
right.
Sorry,
I
think.
B
B
B
Yeah,
that
would
be
interesting,
especially
since
you
know
like
if
you,
if
you've
looked
at
the
external
DNS
core
dns
plug-in
that
can
use
annotations
to
basically
DNS
entries
to
core
DNS
I.
Think
some
sort
of
time
with
that
could
be
could
be
beneficial
of
it
could
read
that
and
then
do
your
core
DNS
Rago
policies
as
well
as
potentially
some
some
network
policies,
so
I,
don't
know
anything
out
there
that
exists,
but
I
definitely
think
it
it'd
be
kind
of
cool.
If
you
can
make
something
like
that
sounds
like
a
break
project
for
someone.
B
B
You
can
see
we
have
a
single
core,
DNS
pod
running
with
two
mark
or
DNS
pod,
as
well
as
our
OPA
pod,
and
so
the
book
below
here
is
the
OPA
pod,
telling
those
logs
the
DNS
logs
aren't
really
that
useful
and
this
kind
of
gives
us
what
we
need.
So
then
I'm
just
going
to
open
up
my
shell
to
a
container
that's
running
in
the
cluster,
just
in
the
default
name
space
just
so
we
can
basically
have
this.
B
B
So
the
first
one
we'll
do
is
we'll
do
a
dig
call
to
kubernetes
at
I/o
and,
as
you
may
remember,
from
Arreaga
policy,
we
told
that
to
be
refused.
You
see,
will
you
on
the
logs,
it
flipped
really
quick,
and
you
can
see
here.
We
had
a
request
come
in
on
a
client,
IP
and
then
the
actual
response
will
be
in
here
response
body
at
the
bottom
here
refused,
and
so
it
Opa
got
the
got
the
request.
B
This
is
a
a
block,
and
so
the
block
is
basically
doing
NX,
Tamina's
and
I.
Don't
really
know
what
to
do
with
this
and
it
doesn't
have
any
authority
and
it
just
returns,
and
that's
basically
about
it
all
the
other
ones.
Right
now,
as
I
mentioned
since
I'm,
not
forwarding
anything
on,
nothing
else
is
really
gonna
work
here,
I'm
will
get
probably
an
extra
main
and
all
of
them
or
a
sorcerer
fail,
because
I
can't
actually
doesn't
know
what
to
look
up
but
yeah,
so
that's
kind
of
it.
B
There's
other
ways
to
do
that
with
transfers
and
all
this
other
stuff,
but
this
would
be
kind
of
I,
think
would
be
helpful
and
that's
kind
of
what
we're
planning
to
use
it
for
is
to
have
validate
site
arranges
for
requests
and
make
sure
that
the
the
response
queries
are
match.
The
actual
ranges
in
the
network
yeah.
So
that's
kind
of
what
we're.
What
we
are
planning
to
use
this
for
eventually,
but
it's
still
pretty
new.
B
The
actual
policy
I,
don't
I,
don't
think
it's
been
even
released.
I
think
it
was
released
like
a
week
before
yeah.
They
don't
even
actually
have
an
official
release.
I
think
it
was
released
like
a
week
before
cute
cons.
So
it's
you
know,
the
initial
commit
was
the
only
you
know,
five
or
so
months
ago.
So
it's
still
new,
but
it
works
pretty
well
and
it
wasn't
too
difficult
to
get
it
running.
B
The
most
difficult
part
was,
you
know,
having
to
create
your
own
core,
DNS
docker
container,
which
is
not
ideal,
but
once
that's
done,
it's
pretty
simple
and
then
the
the
big
advantage
here
is.
You
know
you
can
have
your
Rago
policies,
updated
kind
of
out-of-band
and
based
off
of
other
other
use
cases,
and
then
those
get
propagated
through
and
dns
doesn't
need
to
be
restarted.
B
Are
clearing
any
caches
or
anything
like
that
in
order
to
to
make
those
decisions,
and
that's
kind
of
all
I
had
many
other
questions,
or
does
that
miss
any
of
my
gotchas
and
then
yeah?
So,
as
I
mentioned,
you
can
use
ok,
bundles,
which
is
their
kind
of
service
to
and
to
generate
these
on,
the
fly
instead
of
using
the
config
map.
That's
obviously
the
preferred
method
of
using
OPA,
but
this
is
me
it's
just
for
demo,
but.
G
B
B
So
there
would
definitely
be
some
leniency
for
sure,
especially
compared
to
traditional
DNS,
but,
as
you
know,
as
the
industry
kind
of
transitions
to
DNS
over
TLS
and
using
TCP
we're
gonna
start
seeing
you
know
more
I
think
advancements
in
the
cash
gain
and
the
optimization
layers
there
that
I
think
that
this
might
be
worth
it
and
and
I.
Don't
think
this
is
going
to
be
something
that
everyone
will
use
fully
I'm,
but
I
think
it
could
be
a
tool
that
could
be
beneficial
for
some
certain.
You
know,
use
cases
in
communities
or
elsewhere.