►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
we're
recording
this
is
the
service
apis
meeting
for
august
6..
We've
got
lots
to
get
through,
but
if
there's
something
that
isn't
on
the
agenda
right
now
that
you'd
like
to
discuss,
please
go
ahead
and
add
it.
A
We
are
still
hoping,
I'm
still
hoping
to
get
a
alpha
release
out
this
month.
We
are
in
august
now
and
I
had
had
august
as
a
goal
here.
We've
made
some
good
progress
over
the
past
week.
I
know
harry
has
done
some
great
work
for
both
tls,
config
and
routing.
I
will
cover
a
little
bit
on
the
advanced
routing
section
today
and
maybe
even
some
follow-up
on
tls
bowie
is
working
on
service
level.
Config
and
I've
been
working
on
conflict
handling
semantics.
A
I
should
really
add
a
link
here,
there's
a
big
doc
that
could
always
use
feedback
and
james
has
volunteered
to
help
clean
up
status
and
conditions.
So
that's
that's
where
we
are.
We
got
a
couple
new
things
over
into
the
completed
section
in
the
past
week,
and
hopefully
we
can
keep
that
momentum
up
and
get
a
couple
more
over
in
the
next
in
the
coming
week.
A
So
that's
an
update
on
where
we
are,
hopefully,
hopefully
we're
still
on
track
to
get
this
a
alpha
release
out
in
august,
but
at
the
very
least,
I
think
we're
making
some
good
progress
here.
The
other
thing
of
note
is,
I
know.
Last
week
I
discussed
the
idea
of
a
api
review
dock
where
we
basically
had
our
full
api
spec
and
made
it
easy
to
give
feedback
over
the
full
api.
A
Instead
of
the
little
you
know,
we've
we've
been
working
for
a
while
now
in
incremental
updates,
which
has
been
good
and
helpful
for
us,
I
think,
but
it
I
think
it
would
be
helpful
to
step
back
a
second
and
look
at
the
whole
api
all
over
again
and
try
to
see
if
there's
things,
we've
added,
that
we
don't
need
or
don't
make
sense
or
if
there
are
large
gaps
in
the
api.
A
So
part
of
part
of
the
purpose
of
this
dock
was
for
ourselves
to
review
what
we've
done
at
from
a
higher
level
and
and
understand
any
gaps
there
may
be,
but
I
also
wanted
to
have
this
doc
available
for
anyone
in
the
community
who's
interested
in
reviewing
our
api
before
we
commit
to
an
alpha
release
to
be
able
to
review
the
whole
api
and
once
chunk
instead
of
reviewing
the
little
pr's
we
have
as
they
come
in,
so
that
that
was
the
motivation
for
this.
For
this
doc.
A
Please
go
ahead
and
add
comments,
add
anything
you
might
think
to
us.
If
you
see
things
that
don't
make
sense
or
we
should
clean
up
so
far,
I've
just
added
some
comments
for
typos
or
grammatical
things,
but
I'm
sure
there
are
other
things
in
here
that
can
use
feedback.
A
I'm
also
planning
on
sharing
this
with
the
broader
sig
network
community,
so
that
we
can
get
some
broader
api
review.
I
know
tim
is
interested
in
doing
a
full
api
review
on
this,
and
just
before
we
get
to
that
alpha
release.
I'd
like
to
make
sure
that
we've
got
some
some
more
community
buy-in
and
also
broader
api
review.
A
So
that's
the
motivation
here.
I
think
we'll
get
some
good
feedback
out
of
this,
and
I
know
this
is.
It
is
going
to
be
a
pain
to
keep
this
up
to
date
with
with
master
with
what's
in
github,
but
I
will
try
to
keep
it
up
to
date
every
day
or
two
and
I've
volunteered
to
to
maintain
this
myself-
and
there
is
a
last
updated
day
here
in
case
you're
curious
how
up-to-date
it
is
yeah
so
that
that
is.
A
A
Great
okay,
we
briefly
had
some
time
to
cover
this
yesterday
in
office
hours,
but
there's
a
lot
more.
That
needs
to
be
discussed
as
far
as
this
initial
implementation
of
route
filtering
from
harry,
so
I
I
guess
I'll
hand
it
over
to
harry
to
provide
a
bit
of
background
here
and
yeah.
B
Okay,
thanks
rob,
so
this
is
part
of
the
advanced
routing
proposal.
This.
B
Proposal
which
covers
areas
as
traffic
splitting
you
know
traffic
mirroring
doing
you
know
you
know
more
advanced
stuff
like
you
know,
which
are
specific
to
implementation.
Things
like
you
know,
adding
in
support,
for
you
know,
authentication
or
logging.
You
know
things
like
you
know,
concerns
that
are
primarily
performed
at
the
gateway
layer
and
the
features
which
are
shipped.
You
know
in
cloud
vendor
gateways
implementations
as
well.
As
you
know,
gateway
providers
who
sell
these
features
and
open.
B
As
well
so
the
route
filter
is
intended
as
a
sort
of
a
extension
point
from
where
we
can
add
in
some
core
filters
and
some
custom
implementations.
The
idea
here
is
the
route
filter.
Is
it
the
filters
are
part
of
the
api
specification,
and
then
you
can
use
the
filtering
to
extend
for
custom
implementations
and,
as
we
see,
convergence
happening
around
some
specific
implementations,
we'll
pull
those
into
the
core
api
and
have
conformance
testing
for
those.
B
So
if
we
scroll
down
here,
you
can
see
that
the
route
filter
here
is
part
of
the
http
route
rule
resource,
which
means
these
filters
are
executed
whenever
there
is
a
match.
So
whenever
there
is
a
match
and
this
rule
is
being
executed,
these
filters
are
executed
so.
B
You
know
like
adding
headers
or
removing
headers,
or
this
could
be
you
know,
adding
authentication
or
something
like
that.
Now
he
had
a
as
a
comment
that
you
would
call
these
actions.
That's
true.
The
the
proposal
did
calls
for
an
action
I
sort
of
figured
it
would
be
better
to
route
at
http
route
filter
because
I
think
danian
already
had
that
in
the
in
the
master
branch
and
we
already
had
an
action
verb
action
attribute
for
http
route
action,
which
defines
you
know
things
like
forward
two
and
things
like
that.
B
So
that's
why
we
I
we
resorted
to
the
http
route
filter
name.
We
definitely
can
use
a
better
name.
There
are
other
names
proposed,
such
as
plugin
or
an
add-on.
You
know,
filter
and
actions
are
definitely
out
there,
so
we
can
see
what
fits
best
as
to
what
our
intention
is
for
this
extension
point.
So
if
we
scroll
down
here
so
the
idea
here
is
that
you
have
the
route
filter
which
is
of
a
union
type.
B
So,
as
you
can
see
on
line
199,
we
have
the
plus
union
decorator
all
right,
I'm
not
sure
what
is
the
technical
right
term
for
it
to
tag.
I
think
yeah
that
tag
this
is
in
conformance
with
the
the
union
type
cap
that
is
present
in
the
upstream
enhancements
repository.
B
B
So
we,
if
we
scroll
down
here,
we
have
the
type
as
the
as
the
union
discriminator,
meaning
whenever
a
user
uses
or
initializes
this
filter.
The
type
is
a
known
strength
based
on
which
the
controller
can
determine
what
is
the
fill.
What
filter
is
being
configured
here
then
we
have
two
further
extension
points.
One
is
then
extension
ref,
which
can
point
to
a
crd.
B
We
also
have
a
config
which
we
probably
will
remove,
but
this
is
meant
for
an
inline
configuration
similar
to
how
you
know
we
have
annotations
in
the
metadata
core
api.
So
the
the
purpose
here
is
you
use
an
extension
ref
to
define
your
configuration
or
point
to
your
configuration
that
you
know
you
want
to
execute.
Let's
say
an
authentication
plugin
or
maybe
you
know
this
gateway.
Implementation
is
part
of
a
mesh.
So
it's
like
a
service
mission.
You
want
to
execute,
you
know
rate
limiting
or
you
know
some
custom.
B
Some
custom
filtering
logic,
because
most
proxies
are
most
even
gateways
in
cloud
providers.
You
have
like
you,
accept
a
connection.
You
go
through
a
bunch
of
filters
and
then
you
forward
traffic,
that's
more
or
less
generally.
The
way
most
implementation
works,
so
this
is
meant
for
that
and
at
the
bottom,
as
you
can
see,
there
will
be
some
filter
defined,
such
as
http
request,
header
transformer
right.
So
this
defines
concrete
types
for
filters
that
will
be
part
of
the
core
or
the
extended
group,
so
the
core
apis.
B
So
there
will
be
some
filters
which
will
be
supported
by
code
like
adding
a
request
header
to
to
to
a
request
that
is
flowing
through
the
gateway
is
something
that
we
want
to
be
inside
the
core
api
right
and
we
also
want
maybe
traffic
mirroring
in
the
extended
api
extended
api
group
so
for
those
defined
set
of
configuration.
B
B
I
think
that's
an
overall
summary.
I
don't
think
we
have
anything
at
the
bottom,
so
yeah.
One
thing
to
note
is
we
have
this
filtering
struct?
There
are
two
places
for
extensions
that
have
been
introduced
here,
so
if
you
scroll
up
rob
all
the
way
into
the
route,
filter,
yeah
scroll
up
a
little
more-
I
think
yeah.
So
here
we
have
the
filter
at
the
route
rule
level
right,
and
we
want
to
support
this
level
of
applying
filters
as
core
supported.
B
C
B
Target
basis
right
so,
if
somebody
is
doing
traffic
splitting-
and
they
now
want
to
add
any
filters
they
they
can
add.
So
here
right.
So
if
traffic
is
forwarded
to
a
version,
one
of
the
service
and
version
two
different
filters
will
be
applied
and
filtering
at
this
layer,
we
we
are
putting
into
the
custom
conformance
level.
This
is
definitely
a
little
bit
confusing
and
open
to
feedback
here
as
to
how
to
sort
this.
This
is
primarily
introduced,
for
you
know,
like
I
think,
k
native
requires
this.
B
The
way
they
implement
their
sort
of
canary
testing
and
roll
out
implementation.
They
have
so-
and
there
is
value
here,
but
not
all
implementations
can
support
this
yeah.
So
there's
like
filter
definition
itself
and
two
places
where
they
can
be
extended.
A
Yeah
thanks
for
that
great
intro,
and
that's
a
that's
a
great
point
about
where
filters
are
defined
in
the
two
places
here
and
just
to
clarify
exactly
where
these
fit
in
this
first
one
is
part
of
the
forward
two
and
the
the
second
reference
here
would
be
a
level
higher
in
the
actual
rule
right
along
at
the
same
level
as
match.
A
B
A
request
comes
in
you
first
figure
out
which
rule
or
the
proxy
figures
out,
which
rule
is
it
matching
and
based
on
that
it
can
execute
those
filters
and
then
execute
the
actions
return.
Filters
could
also
be
executed
on
response
so
that
you
execute
an
action.
Send
the
traffic
upstream
get
your
request
back
response
back
in.
Maybe
there
are
some
response,
transformation
or
things
need
to
be
logged,
and
then
you
send
that
back
request
to
the
downstream
client.
A
Okay-
and
so
it
seems
like
both
of
these
locations
for
filters
are
very
similar,
then,
if
they're
both
after
matching,
then
you
know
forward,
two
would
come
in
inside
this
action
right.
A
That
is
a
very
weird
robot
sound
today,
but
unfortunately
cannot
make
sense
of
that.
Sorry,
if
you
want
to
drop
something
in
chat
or
rejoin
or
whatever
I
can
try
to
relay
any
messages.
C
B
It
executing
the
filters
and
then
selecting
a
back
end
right
and
so
and
then
the
back
end
can
be
different
right
and
implementations
have
a
hard
time
actually
implementing
like
after
you
select
a
backend
and
then
execute
a
request
right.
So
that's
what
we
refer
to,
as
I
think
inside
forward
to
you
have
two
back
ends.
I
think
bowie,
just
you
just
opened
a
comment.
So
bowie
summarizes
that
particularly
it's
like
post
like
do
you
want
to
do
the
filtering
before
the
back
end
selection
or
after
the
vacuum
selection.
A
Sure,
okay,
so,
okay,
that
that
that
makes
sense,
and
so
the
forward
to
the
the
filters
inside
forward
two
are
going
to
be
defined
after
back
in
selection.
That's
that
is
the
the
key
difference.
So
this
really
only
applies.
If
you
have
multiple
back
ends.
Well,
no,
I
shouldn't
say
it
only
applies,
but
it
seems
most
relevant
when
you
have
multiple
back
ends
for
the
same
match.
B
A
C
Yeah
is
there
an
order
in
terms
of
which
filters
will
be
executed?
First,
like
the
route
level
or
per
target
level.
B
As
we
get
more
experience
with
this,
we
will
get
better
at
executing
that
and
ordering
between
the
two
layers.
I
think
we
should
impose
an
order
there
where
filters
at
the
route
rule
level
execute
first
and
then
filters
at
the
the
for
the
back
end
level
are
executed,
but
then
there
can
also
be
implementations
which
will
override
filters.
B
B
The
purpose
here
is
to
ship,
something
which
is
something
generic
enough
and
extensible
enough,
so
we're
supporting
filters
at
the
route
rule
level
in
the
core
api
right.
So
if
you
have
like
a
request,
header
addition
or
removal
feature
inside
this
api
will
support
it
only
at
the
route
rule
level.
Now
it's
up
to
the
implementations
to
figure
out
how
do
they
want
to
layer
the
ordering
on
in
it
right,
because
we
don't
even
support
filters
in
the
forward
two
level
in
the
core
api.
That's
an
extension
point.
B
So
if
an
implementation
doesn't
actually
support
it,
no
ordering
in
place,
but
if
somebody
does
support
it
and
then
in
that
case
you
that
gets
up
you'll
have
to
resort
to
implementation.
Specific
behavior.
There.
A
Yeah,
that's
awful,
I
I
think,
there's
great
comments
in
chat
as
well
from
bowie,
who,
I
think,
agrees
with
what
you're
saying
I
think
it's
hard
to
impose
order,
except
for
broad
states
such
as
pre-back
and
selection
versus
post
back
end
selection,
and
then
james
is
also
referring
to
example.
Yaml
is
that
is
that
yaml
in
this
pr
further
down.
D
C
E
It
seem
more
obvious
that
I
would
want
to
put
headers
in
there,
because
those
headers
are
specific
to
a
target.
Okay,.
A
A
I
yeah.
I
really
like
your.
I
really
like
this
this
direction.
I
need
a
little
bit
more
time
to
process
it.
One
of
my
comments
here
was
specifically
around
how
how
large
this
type
could
be
if
every
core
transformation
requires
its
own
struct.
Essentially,
here
I
don't
think
there's
a
great
alternative.
I
it's
just
you
know
nature
of
this
kind
of
api,
but
something
to
watch
out
for
that.
If
we
end
up
adding
a
lot
of
core
filters,
this
could
be
a
relatively
complex
type
in
the
future.
E
B
Also
have
to
think
about
the
versioning
there,
because
you
know
in
kubernetes,
api
is
once
you
are
at
v1.
You
can
add
in
features
right
which
are
backwards
compatible
and
we
differentiate
between.
You
know
what
what
are
the
struct
definitions
in
score:
dot
service
inside
kubernetes,
1.16
versus
18.,
like
we
can?
We
know
how
to
differentiate
that
in
this
version,
if
we
hit
v1
and
we
want
to
add
in
more
core
transformers
now
the
users
have
to
go
and
update
their
crds
and
okay.
B
A
E
It's
a
good
point,
so
I
I
commented
on
this
yesterday
and
just
in
in
terms
of
the
I
guess
in
terms
of
the
union,
though
I
seem
to
have
not
quite
realized
that
a
union
was
being
trying
to
be
used,
but
it
sort
of
three
ways:
it
I
think
it
kind
of
comes
out.
I
see
what
you're
doing
and
it
it
does
feel
like.
It
comes
out
awkwardly
in
the
api,
because
it's
sort
of
three
ways
of
doing
the
same
thing
right.
E
You
have
a
should
be
route
filter
and
you
have
here's
a
built-in
one
and
here's
kind
of
an
inline
one
and
here's
an
out-of-line
one,
and
it
feels
a
bit
I
think,
with
it,
without
being
able
to
enforce
the
semantics
of
a
union.
E
It
kind
of
feels
like
okay,
we've
got
three
ways
of
doing
the
same
thing
and
that
ends
up
being
kind
of
complex,
and
I
wonder
if
this
is
a
case
where
raw
extension
makes
sense
to
be
used,
so
raw
extension
would
be
similar
to
the
config
methodology
to
say:
okay,
we
we'll
just
do
that
for
everything.
B
E
So
so
raw
extension
is
just
an
inline,
opaque,
inline,
yaml
chunk
of
yaml.
E
A
What
what
I
couldn't
understand-
and
I
thought
that
was
an
interesting
idea,
and
I
I
also
I'm
not
very
familiar
with
raw
extension,
but
from
what
I
did
look
into
it.
It
wasn't
clear
to
me
if
validation
would
be
possible
or
meaningful
on
something
like
that,
or
is
it
really
just
indistinguishable
from
just
a
map
string?
You
know
interface
kind
of
thing.
E
E
B
E
B
B
A
A
B
A
I
was
just
going
to
say
the
same
thing.
Thank
you
and
yes,
we
have
lots,
lots
and
lots
to
cover
and
the
next
one
is
from
james,
and
it
is
about
a
this
is
a
follow-up
to
something
like
we
discussed
yesterday
and
james.
Do
you
want
to
give
us
some
some
background
here.
E
Sorry
yeah,
so
this
is
something
I
think
rob
you
brought
up
in
the
office
hours
yesterday,
yeah.
C
That
in
the
header
match
you.
E
Kind
of
have
these
matched
pairs
that
you
that
you're
supposed
to
provide
together,
but
there
was
no
validation
on
that.
So
so,
when
you
want
a
path
match,
you
really
need
to
put
both
the
path
match
type
and
the
value,
and
they
should
both
be
provided,
or
none
of
them
should
be.
Neither
of
them
should
be
provided
and
the
same
semantics
footwear
for
header
match.
E
A
Yeah
yeah,
that's
exactly
it
and-
and
I
think
one
of
the
things
that
we
realized
yesterday
was
we
have
this
default
here
on
header
match
type,
so
it
meant
that
anytime,
you
apply
the
crd.
You
are
going
to
get
a
header
match
type
set
in
your
crd.
That
said,
header
matching
is
exact,
but
then
you
know
it
would
it
would
make
it
look
like
you
were
doing
header
matching,
but
then
you
had
no
headers
specified
and
it
just
seemed
overly
confusing
and
maybe
not
helpful.
A
So
I
like
this
idea
of
pulling
this
out
into
a
separate
struct,
so
that
this
default
would
only
actually
apply
if
you
actually
went
out
of
your
way
to
apply
header
matching.
You
have
an
example
down
below
that.
I
think
highlights
this
well,
if
I'm
remembering
the
order
of
this
pr,
yeah,
okay,
so
you've
got
a
match
and
headers
and
you
wouldn't
even
need
to
include
this
line
because
that
would
be
defaulted,
so
you
could
do
match
headers
values
and
etc.
A
That
seems
like
a
reasonable
addition
to
me.
My
only
concern
on
this
one.
Well,
let
me
let
me
stop
and
ask
others
for
feedback,
because
I've
talked
a
lot
here.
B
A
Yeah
yeah,
so
the
one
thing-
and
I
am
open
to
feedback
here
or
ideas
here,
but
one
thing
that
I
was
a
little
hesitant
towards
was
the
way
this
is
defined.
It
also
splits
path
into
its
own,
its
own
struct,
and
that
means
that,
as
as
this
change
is
defined
right
now,
everything
is
optional
inside
match.
Nothing
is
actually
required.
A
A
E
The
reason
is
that
I
think
the
the
the
reason
we
defaulted
path
match
the
reason
we
defaulted.
The
path
matching
originally,
I
think,
was
because
when
you
add
defaults,
there's
no
real
way
to
express
that
you
don't
want
the
match,
so
you
have
to
choose
a
safe
default.
A
I
think
one
of
my
conce
yeah
yeah,
that
is
that
is
a
good
thought.
I
one
of
my
concerns
here
is
that
our
our
simple
use
case
our
simple
api,
just
added
an
extra
level
of
complexity
right
so,
instead
of
match
path
bar,
you
know
the
the
most
simple
use
case
you
can
think
of
you
now
have
match
path
and
then
potentially
type
and
definitely
value
so
you've,
just
you've
added
an
extra
layer.
Maybe
to
the
simple
use
case.
I
I
like
in
this
example
where
you
have
everything
laid
out
it.
A
It
makes
complete
sense,
but
just
if
you're,
using
the
simpler
use
cases
of
just
I
just
want
to
match
a
path.
That's
it.
Then
this
does
add
an
extra
layer,
not
not
necessarily
the
end
of
the
world.
A
Okay,
well,
I
encourage
any
additional
feedback
on
this
pr.
I
know
we're
we're
running
short
on
time
here,
but
thank
you.
Thank
you,
a
bunch
for
actually
going
through
and
cleaning
this
up.
I
am
entirely
on
board
with
the
header
match,
changes
and
just
need
to
think
a
little
bit
more
about
options
for
path
matching,
but
yeah
thanks
for
thanks
for
the
work
on
this
one
and
if
anyone
has
any
additional
thoughts
or
other
ways,
we
could
approach
this,
please
add
comments
whatever
to
this
pr.
A
I'm
going
to.
I
added
a
couple
extra
things
that
are
mine,
but
I'm
going
to
skip
over
them
and
just
briefly
cover
a
couple
things
that
we
wanted
follow-ups
on.
So
harry
is
working
on
tls
config
as
well,
and
we've
already
talked
about
this
dock,
a
reasonable
amount.
A
This
everything
else
in
this
proposal
seemed
to
be
generally,
you
know
everyone.
We
had
a
consensus
around
it.
This
one
was
maybe
a
little
bit
less
less
clear
what
we
wanted
to
do
here.
I
think
one
option
is
to
file
this
in
a
separate
pr
and
have
a
discussion
there,
but
if,
before
we
got
to
that
point,
if
anyone
had
time
to
read
through
this
this
specific
part
of
the
proposal
around
route
and
provide
any
additional
feedback
or
thoughts
on
how
we
could
do
this.
A
A
And
then
the
next
thing
I
wanted
to
call
out
is
I
chatted
with
jeremy
just
a
little
bit
this
morning
and
he
wanted
just
some
clarification
on
what
we
wanted
to
do
with
sni,
this
pr
to
add
sni
to
tcp
route.
There
were
some
mixed
opinions
last
time
that
we
discussed
this.
A
B
Yeah,
I
think
that's
what's
the
conversation
here.
I
do
want
to
note
like
if
we
can
get
our
tls
story
going
and
I'm
going
to
open
up
a
pr
towards
the
end
of
the
week
and
then
you
know
we
settle.
C
B
The
the
things
that
we
already
agree
on
and
we
get
that
worked
in
and
then
if
we
can
approach
sni,
router
and
sni
matching
with
tls
config
in
route
right
there.
They
are
not
completely
the
same
thing,
but
they
definitely
do
relate
a
little
bit.
And
then
we
can
have
like
that
discussion.
If
you
can
hold
until
then.
A
Yeah,
I
think
that
makes
a
lot
of
sense.
Okay,
yeah
I'll
I'll,
add
a
comment
here
to
that.
We
can
just
hold
this
one
until
we
we
get
a
little
bit
more
progress
on
tls,
because
I
can
see
how
there
could
be
overlap.
There.
F
Yeah
I
mean
in
pr
238
you
know,
sni
is,
is
not
tcp
right,
so
I'm
just
basically,
I
guess,
agreeing
and
saying
that
a
tcp
route
match
should
be
matching
based
on
tcp
information
like
tcp
header
information.
F
F
D
F
D
We
should
be
defining
a
new
type
if
we
have
a
different
set
of
rules
for
how
you
match.
Connections
to
that
thing.
So
for
s,
and
I
you
have
server
name,
so
you
would
want
a
distinct
type
where
you
can
say
match.
If
the
server
name
is
this
and
then
I
suppose
you're
asked
and
I
write
route
type
would
also
have
match
on
udp
or
match
on
tcp
right.
You
would
specify
which
transport
layer
protocol
does
that
make
sense.
D
Yeah
that
also
lets
us
kind
of
make
a
map
of
how
do
you
reconcile
when
you
have
a
tcp
route
and
an
sni
route
and
an
http
route
you
can
define.
You
know
it
might
end
up
being
a
little
bit
arbitrary,
but
you
can
define
clear
rules
for
example.
First,
we
look
at
if
there's
a
matching
tcp
route,
and
then
we
look
at
if
there's
a
matching
s9
route,
and
then
we
check,
if
there's
a
matching
http
right
so
right.
A
A
A
A
If
you
have
thoughts
or
comments,
please
go
ahead
and
add
them
to
those
issues,
but
yeah.
That's
that's
all
we
have
today.
Thank
you
so
much.
I
know
we
went
a
little
bit
over,
but
thanks
to
everyone
for
the
great
feedback
and
the
great
momentum
we've
got
here,
excited
to
get
an
alpha
api
out
soon,
all
right
have
a
great.