►
From YouTube: OpenFeature Project Meeting - May 26, 2022
Description
Meeting notes: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/edit?usp=sharing
OpenFeature website: https://open-feature.github.io/
B
A
B
C
B
B
B
Just
pull
up
our
notes
here,
perfect,
so
yeah
ben
thanks
for
volunteering
to
be
described
today
or
valentold,
whatever,
whatever
you
want.
Whatever
way
you
want
to
look
at
it
so
cool,
it
looks
like
we
have
a
couple
of
newcomers
go
ahead
and
do
quick
introductions.
Suppose,
if
you're
new
and
comfortable
introducing
yourself,
please
go
ahead
and
yeah
unmute
and
say
hi.
C
G
Hi
everyone,
my
name,
is
vedic.
I
don't
happen
to
be
working
anywhere
right
now.
I
used
to
work
at
a
company
based
out
of
india
called
rofers,
where
I
was
heading
devops
for
them,
and
I'm
just
hanging
out
trying
to
see
what
this
school
group
is
up
to,
and
you
know
what's
happening
in
this
community.
B
Perfect
welcome
thanks.
Well,
I
think
that
might
be
it
so
appreciate
it.
Thanks
everyone,
we
talked
about
the
roles
for
the
next
meetings.
I
think
we
should
be
good
to
go
there.
So
just
kick
it
off
real
quick,
just
say
thanks.
Everyone
for,
for
the
help
with
the
press
release
went
out
last
week
seemed
to
go
over
pretty
well,
and
so
I
think,
that's
also
probably
part
part
of
the
reason
why
we
have
some
extra
attendees
today,
which
is
really
exciting.
B
B
Next
real
quick
update,
we
did
update
the
website.
I
actually
called
in
a
favor
from
a
friend
he
worked
on
it.
It
is
written
in
react
if
anyone
you
know
wants
to
take
a
look
at
it
contribute
for
anyone
on
this
call.
If
you
want
a
kind
of
a
fun
little
easter
egg
in
the
top
left
corner
of
the
little
open
feature,
logo,
the
o
toggles
only.
A
B
Yeah,
so
it
actually
goes
off
your
browser
preference,
so
the
dark
and
light
mode,
and
then
you
can
toggle
it
in
the
top
left
corner,
so
it's
a
little
hidden,
but
it's
kind
of
a
fun
little
easter
egg
in
there
I
also
wanted
to
do.
I
have
no
affiliation
with
netlify,
but
a
quick
shout
out
to
them.
I
registered
for
the
open
source
license
there
within
like
a
day.
They
gave
it
to
us
so
we're
good
to
go
there,
really
a
really
painless
process
and
pretty
slick.
B
Actually,
I
really
really
enjoyed
using
the
tool,
so
yeah
shout
out
to
them,
for
that
next
thing
was
the
the
logo,
so
part
of
the
rebranding
was
just
like
the
logo.
I
think
the
most
people
seem
to
really
like
the
the
horizontal
one.
I
think
it
actually
is
kind
of
cool
and
a
little
fun
play
on.
You
know:
toggles,
the
the
more
horizontal
one
and
the
the
little
fave
icon.
One
could
potentially
use
some
work.
B
It's
currently,
you
can
find
it
in
the
community
repo,
if
you're
curious,
to
see
where
all
of
these
assets
are.
But
if
you
have
any
recommendations
for
how
we
can
maybe
make
a
more
horizontal
logo
or
a
little
a
smaller
like
fave
icon,
work
a
little
bit
better.
Certainly
let
me
know
it
would
be
maybe
great
to
address
that
at
some
point,
but
we
just
needed
to
get
something
out
there
before
press
releases
and
stuff
came
out.
B
So
that's
why
that's
there
there's
also
a
figma
file
too,
so
I'm
certainly
no
designer,
but
I
was
trying
to
do
different,
like
you
know,
aspect
ratios
and
backgrounds,
and
things
like
that
and
keep
that
tracked
inside
figma.
So
if
you
want
to
go
on
there,
you
can
play
around
with
the
the
vector
versions
of
it
and
then
export
whatever
you
need.
B
Cool
next
thing
was
the
the
road
map.
So
especially
as
the
project
gets
larger
and
larger,
it
becomes
more
difficult
to
track
what
everyone's
working
on.
So
I
took
a
first
crack
at
updating
the
roadmap
in
github,
I'm
using
the
new
beta
projects
and
if
you
go
to
the
the
roadmap
right
now,
you'll
see
that
the
first
tab
is
actually
related
to
the
spec.
Only
and
it's
it's
basically
taking
a
crack
at
what
we're
currently
working
on
and
a
couple
proposals
for
what
we
could
be
working
on.
B
We
can
talk
about
what
the
priority
should
be
there,
cool
yep,
exactly
so
feedback
on
this
would
be
really
really
appreciated.
It's
a
you
know
it's
a
pretty
straightforward
tool,
but
there
seems
to
be
a
number
of
ways
to
kind
of
do
this
in
github
and
so
and
it
seems
to
be
kind
of
maturing
over
time.
It's
relatively
new,
it's
still
labeled
as
beta.
B
So
if
you
have
any
feedback
on
what
would
work
better?
Certainly
let
me
know
next
on.
My
roadmap
would
be
to
add
one
for
research,
so
we
can
know
what
kind
of
research
is
currently
in
flight
and
we
did
create
a
dedicated
repo
for
research
and
I
started
migrating
some
of
our
research
out
of
like
the
spec,
repo
and
stuff
into
the
research
repo
itself,
and
if
there's
any
other
research
topics
feel
free
to
just
open
up
issues
in
that
repo.
B
So
we
can
basically
track
all
of
our
research
in
there
and,
if
there's
any
like
tangible,
like
outcome
for
that,
research
it'd
be
great
to
just
merge
that
in
as
a
markdown
in
that
that
repo
just
so
we
have
the
history
of
it,
also
be
working
on
an
sdk
board
in
the
projects.
Just
so
we
can
track
which
sdks
are
currently
in
flight,
which
ones
have
been
committed
to
but
haven't
started
and
which
ones
are
basically
out
of
scope
right
now.
It
doesn't
mean
that
we
couldn't
work
on
it.
B
If
someone
is
is
willing
to
take
a
crack
at
one
of
these
languages.
That
would
be
great,
but
I
think
we
just
can
be
a
little
bit
more
transparent
about,
what's
currently
being
worked
on
versus
which
ones
haven't
even
been
started.
Yet
so
look
for
that
in
the
next
couple
days,
but
that's
that's
what
I'm
going
to
try
to
spend
some
time
in
terms
of
project
planning
and
take
a
quick
break
there.
Is
there
any
questions
or
feedback
on
any
of
any
of
what
we
just
talked
about
there.
B
B
There
was
actually
some
questions
about
that
and
and
it
it
makes
sense
in
retrospect,
but
just
because
people
gave
like
the
thumbs
up
emoji,
they
have
no
idea
like
where
who
you
are
and
where
that
came
from
so
actually
a
more
valuable
way
of
of
displaying
your
support,
I
suppose,
would
be
to
add
a
comment
and
say
like
who
you
are
and
what
company
you
represent
and
basically
that
way
we
can
make
sure
that
we're.
This
is
like
an
industry
thing.
B
As
soon
as
we're
ready,
it
sounds
like
they're
willing
to
switch
that
to
open
feature
which
then
could
be
a
really
nice,
like
kind
of
joint
collaboration
here
and
a
cool
way
to
show
off
feature
flagging
in
a
pretty
complex
architecture
and
tie
it
into
hotel.
So
it's
a
potentially
really
cool
opportunity
for
us
they're,
actively
working
on
it
right
now
and
they're
just
going
to
roll
with
their
own
simple
feature
flagging
system
for
now,
but
it
does
sound
like
they're
interested.
B
B
We
did
talk
to
the
team
there
as
well.
I
think
there's
more
to
come.
It
is
it's
something
that
they
find
extremely
interesting
as
well.
So
that's
more
of
a
teaser!
I
did
create
a
an
issue
on
the
project
of
related
to
that
as
a
way
to
track
it.
I
don't
think
it's
related
to
the
current
spec.
It
really
is
kind
of
out
of
scope
at
this
point,
but
I
do
think
that's
something
that
we
could
certainly
tap
into.
You
know
beta
or
slightly
later,
which
would
really
unlock
some
interesting.
B
You
know
possibilities
going
forward
so
more
to
come
on
that
one.
It's
more
of
a
kind
of
a
teaser
and
say
that
we
found
the
right
contacts
on
the
open,
telemetry
team
to
make
that
happen,
and
they
seem
to
be
actually
extremely
excited
about
that
possibility,
because
when
they
built
the
the
context
propagation,
like
cross-service
technology,
they
were
hoping
that
it
would
be
used
in
other
projects.
Besides
hotel-
and
currently
that's
not
the
case,
so
it
seems
like
a
good.
You
know
kind
of
joint
partnership.
There.
B
It
is
recording
yeah,
I
think
it
records
automatically.
So
I
think
we're
good
to
go
thanks
and
then
the
last
one
was
the
the
cloud
provider.
So
this
is
where
I
can
kind
of
hand
it
off
in
just
a
few
minutes
to
alex
and
todd,
but
we've
been
talking
about
that
quite
a
bit
and
I
try
to
clean
up
some
of
the
language
on
some
of
the
site
where
it
wasn't
we're
not
talking
about.
Like
you
know,
cloud
native
feature
flagging
and
things
like
that,
because
it
definitely
is
confusing.
B
We
were
trying
to
be
more
a
feature.
Flagging,
spec
is
kind
of
the
goal
behind
open,
telemetry
open
feature,
releasing
this
sdks
as
well.
We
also
wanted
to
provide
a
cloud
native
like
implementation
that
would
allow
people
to
test
these
concepts
out
really
easily.
It
gives
us
something
to
talk
about
it
at
conferences
like
kubecon
and
things
like
that.
It
also
for
the
right
in
the
right
situation.
B
It
could
be
like
a
perfect
technology
fit
for
for
companies
as
well,
and
we
also
had
talked
about
at
kubecon,
potentially
tying
that
back
into
kind
of
the
vendor
ecosystem
as
well,
and
how
you
could
potentially
just
start
moving
evaluation
logic
into
like
this.
You
know
sidecar
process
and
I'll.
Let
alex
kind
of
talk
about
that
in
just
a
second,
but
I
just
wanted
to
give
a
quick
teaser
about
what
that
was
all
about.
You
may
start
seeing
the
word
flag
d
as
well.
B
I
H
No,
I
I
mean
I'm
really
excited
for
like
to
use
the
concept
like
like
mike
said.
I
think
it
opens
up
a
lot
of
a
lot
of
interesting
opportunities
to
kind
of
move
like
evaluation
out
of
out
of
the
actual
process
of
the
application.
That's
doing
flag
evaluation,
and
I
think
this
is
like
a
yeah.
It's
just
a
really
exciting
architecture,
so
go
ahead.
Show
us
your
demo.
I
I
The
idea,
as
michael
was
saying,
is
to
provide
some
sort
of
practical
implementation
so
that
we
could
test
an
incoming
spec
against
the
schema
and
actually
apply
it
into
some
context
where
users
could
actually
do
something
with
it.
So
I'm
just
going
to
talk
through
this
and
take
about
60
seconds
and
I'll
talk
through
some
of
the
components
and
I'll
show
you
it
because
it's
completed
in
a
very
initial
pre-alpha
phase.
I
I
Do
you
want
to
have
a
sidecar
injected
into
you
that
side,
car
what's
interesting
about
it,
is
that
it's
also
flag
d,
so
flag
d
can
run
system
d
in
a
side
car
on
an
edge
device
through
on
on
sort
of
arm,
hf
or
arm
64
amd
64..
It
doesn't
matter
where
it
runs,
it's
just
a
binary,
but
that
can
run
in
this
particular
scenario
as
a
sidecar.
I
What
it
does
is
that
it
does
a
couple
of
things
it
checks
to
see.
If
you
have
a
flag
of
each
flag,
custom
resource
set
up,
and
if
you
do
it
will
synthesize
the
flags
of
that
resource
into
a
conflict
map
and
mount
those
against
the
sidecar.
It
has
a
hot
reloading
system
as
well,
and
the
sidecar
is
able
to
then
read
those
flags,
so
that
sounds
pretty
simple
and
it
doesn't
sound
like
there's
much
secret
source
there
right,
because
all
it's
doing
is
reading
a
conflict
map.
I
If
you
actually
look
at
how
flag
d
works,
I'll
open
it
up
here,
flag
d
is
a
an
implementation
that
I'll
show
you
on
the
screen
here.
That
effect.
Oh,
it's
a
little
bit
big
I'll
show
you
a
bit
smaller.
It's
an
implementation
that
allows
you
to
have
interfaces
between
services
and
syncs.
You
know
so
your
services
are
going
to
be
the
ways
you
present
your
feature
flags
to
users
and
the
syncs
are
the
way
you
pull
them
in
so
think
about
like
file
system
is
a
simple
sync
and
http
is
a
simple
service.
I
This
is
interesting
because
this
is
what
goes
into
that
sidecar
at
the
moment
when
you
start
that
sidecar
it
starts
with
a
bunch
of
default
options,
but
it
will
start
serving
from
that
config
map.
What's
also
really
exciting
about
this,
is
you
can
pull
from
a
remote
vendor?
So
if
you
want
to
say
hey,
I
don't
have
a
local
flag
configuration,
but
I
do
have
the
definition
of
where
my
vendor
is.
Then
you
can
do
that
too.
So,
let's
talk
about
like
a
little
demo
here.
So,
first
and
foremost,
we
talked
about
this
crd.
I
What
are
flags
like
that?
Well,
it
could
look
like
a
bit
like
this,
so
it
could
look
like
that
right.
We've
got
a
simple
json
object.
It
doesn't
really
matter
to
me
what
it
is
or
you
could
define
a
remote
vendor
spec
like
this
now.
This
would
also
tell
flag
d
to
go
off
and
get
that
remote
vendor,
and
this
is
something
that
we're
working
on
just
fleshing
out
right
now.
I
So
let's
pretend
I've
got
my
local
feature:
flag,
spec
I'll,
just
jump
into
my
cluster
here,
where
I've
got
that
cr
available
on
my
left
on
my
screen.
Let
me
know
if
you
can't
see
anything,
so
it's
not
there
at
the
moment,
so
I'm
just
going
to
go,
keep
control,
apply,
config
samples
and
just
put
that
into
the
cluster.
So
now
I
have
that
feature
sample
with
my
feature:
flag,
spec,
which
is
my
json
object
string.
I
Then
what
I
need
to
do
is,
I
need
to
actually
say
hey.
I
want
to
use
that
so
what
I've
got
is
a
very
simple
pod.
This
is
off
the
shelf
right,
it's
just
an
nginx
container
inside
of
this
pod.
Now
what
I've
got
is
annotation
gates,
I've
linked
it
to
the
feature
flyer
configuration
sample
and
I've
set
that
it's
enabled.
I
thought
this
was
a
nice
thing
to
add,
but
we
can
talk
about
the
semantics
later
on.
So
now
I
go.
Cue.
Control
apply
examples
pod.
I
So
what
this
does
is
this
hits
the
mutating
admission
web
hook
in
this
controller
manager,
and
it
then
injects
into
engine
x.
You'll,
see
now
that
nginx
has
two
containers
inside
of
this
pod.
You'll
also
see
that
the
web
hook
has
been
hit
on
the
mutate
of
the
v1
of
the
pod.
If
we
go
up
now
into
conflict
maps,
we'll
also
see
that
we
have
a
default
config
that's
been
created,
we
could
also
talk
about
making
this
a
secret
like
this
is
very
early
days.
We
can
change
all
this
stuff
later
on.
I
It
could
be
a
secret
as
well
so
in
nginx.
We
want
to
jump
into
this
and
say
well,
what's
going
on
here,
I'm
just
going
to
go
quickly
and
app
update
and
grab
curl,
because
for
whatever
reason
they
decided
to
let
you
get
apps
tools
inside
of
this
container,
which
is
useful
for
me
once
I've
got
curl.
I
mentioned
that
I
wrote
the
http
interface
for
this,
so
I'm
going
to
go
off
and
do
a
really
simple
local
host
and
what
we'll
see
is
I
go
curl
local
host
8080
I've
got
foobar.
H
Just
a
point
of
clarification,
I
think
you
mentioned
two
two
kind
of
extensibility
interfaces,
so
I
think
you
call
them
sinks
and
services,
so
the
just
to
make
sure
I
understand
that
I'm
getting
the
verbiage
correct.
The
service
is
basically
the
the
integration
point
that
are
our
cloud
native
sdk
would
would
would
interface
with
to
communicate
with
the
sidecar
it
could
be.
H
Those
are
how
you
would
communicate
with
hypothetically
any
kind
of
feature
flag
control
plane
as
it
were
so
in
this
case
again
we're
talking
about
a
mounted
config
map,
but
it
could
be
launched
darkly
or
it
could
be
a
you
know,
flagsmith
or
could
be
any
connection
to
the
vendor.
So
it
could
be
basically
wrapping
their,
maybe
even
using
open
feature
to
wrap
their
sdk
and
get
information
from
their
api
indirectly.
I
Yeah
that
that's
that's
a
super,
concise
way
of
putting
it.
I
was
just
looking
to
see
if
I
had
an
image
that
showed
it.
I
don't.
I
think
it's
here
actually
so
yeah
one
of
the
core
concepts
that
isn't
in
the
example.
So
you
won't
find
this
if
you
play
around
with
this
yet,
but
one
of
the
core
concepts
is
that
the
feature
operator
can
read
within
the
ammo
file.
I
This
remote
endpoint
object
and
what
it
understands
then,
is
that
when
it
create
when
it
starts
the
agent
inside
the
container,
the
agent
knows
not
to
use
the
local
path,
but
it
will
actually
use
a
remote
endpoint.
There
is
definitely
work
to
be
done
around
making
sure
that
this
is
secure.
We
can
buffer
and
we
can
reset
and
all
those
sorts
of
things
but
yeah.
Fundamentally,
it
then
would
have
a
secret
that
also
is
mounted
with
your
remote
config
and
credentials
and
go
off
and
fetch
directly
into
that
config
map.
I
I
And
actually,
just
to
just
to
extend
that
we
don't
even
need
to
do
that,
we
can
have.
We
can
have
differing
interfaces
per
vendor
right.
So
if
you
have
a
remote
endpoint,
we
can
set
a
type
on
it
rather
than
it
being
http.
If
you're
a
vendor
that
only
does
certain
protocols,
then
we
can
also
support
that
as
well.
Just
by
the
sheer
fact
that
the
flag
d
system
is
fairly
simple
to
extend.
H
Well,
what
we
could
probably
do,
what
we
could
probably
do,
I
imagine,
is
actually
embed
the
open
feature.
Go
sdk
in
here
which
would
wrap
whatever
vendor
sdks
are,
are
available
and
go
so
that
that
could
be
another
way
to
kind
of
abstract
that
and
then,
and
we
can
massage
that
data
exactly
how
we
need
to
present
it
to
the.
I
Yeah,
I
think
that's
a
really
nice
side.
That's
a
really
nice
idea
is
that
we
could,
as
you
say,
have
the
the
interface
to
the
vendor
sdks
directly
inside
of
flag
d,
the
the
thing
that,
as
we
were
saying
earlier
on
the
thing,
the
flag
d
isn't,
is
it's
not
kubernetes
native
right?
It
should
be,
it
should
be
completely
agnostic.
If
you
look
at
the
modules
that
are
actually
used
in
here.
D
So
I
have
a
question
just
kind
of
more
for
open
feature.
Overall,
is
this
kind
of
implementation
expected
to
be
like
the
official
open
feature,
kubernetes
implementation?
Try
to
understand,
you
know
what
parts
are
spec
and
then
what
parts
is
open
future
we're
going
to
say
this
is
the
cloud
native
route.
B
Yeah,
that's
a
good
question
that
was
gonna,
be
I
guess
my
next
point
too.
So
there's
a
couple
things
going
on
here.
I
would
say
what
we're
talking
about
here
would
be
like
a
spec
compliant
provider
that
we
were
tentatively
calling
flag
d.
That's,
I
guess
how
it
would
answer
that
one
so
there's!
No!
This
wouldn't
necessarily
be
built
into
the
the
open
feature
spec
per
se.
B
B
B
It
likely
makes
sense
to
break
this
topic
off
into
like
a
dedicated
like
special
interest
group,
and
so
we
can
kind
of
not
clutter
this
meeting
with
like
kind
of
going
technically
into
this
provider.
Since
we'll
just
follow
the
you
know,
open
feature
spec.
So
that's
something
that
if
ever
you
know
people
are
on
board
with
that
I'll
just
send
out.
B
You
know
like
a
doodle
in
the
slack
channel
just
to
get
people's
availability,
and
we
can
try
to
schedule
that,
maybe
on
the
off
week
or
something
like
that,
and
that
could
be
a
more
technical,
deep
dive
than
what
we're
hoping
to
achieve
there
and
where
the
different
integration
points
could
be.
And
everything.
H
Yeah
and
just
to
just
to
maybe
like
put
things
another
way,
I
agree
with
everything
mike
said:
put
things
another
way.
I
think
we
can
think
of
flag
d
as
very
as
basically
and
just
moving
the
abstraction
up
the
stack
right.
So
it's
really
the
same
kind
of
abstraction
and
ideally,
I
think
we
could
even
use
the
open
feature.
H
Golang
sdk,
like
we
were
talking
about
in
in
flag
d
as
that
kind
of
abstraction
layer
to
various
vendors,
but
essentially,
instead
of
you
know,
instead
of
having
your
adapter
to
any
vendor
or
flag
management
system
within
your
running
application,
we're
just
moving
that
out
into
a
separate
process
and
one
with
some
some
cloud
native
integrations.
I
mean
like,
like
alex
said.
We
we
really
don't
even
particularly
need
to
involve
kubernetes
in
flag
d
itself.
H
Kubernetes
is
just
the
particular
deployment
mechanism
that
you
know
we
know
is:
is
going
to
be
relevant
for
cloud
native
architectures,
but
flag
d
could
run
as
a
system
d
service.
It
could
run
really
anywhere
because
it's
a
separate
process,
but
we're
essentially
moving
that
abstraction
where
we're
doing
the
abstraction
to
on
the
future.
Like
control,
plane
out
of
process
into
a
separate
process,
but
using
all
potentially
using
the
exact
same
mechanisms
and
and
even
using
the
open
feature,
golang
sdk.
B
B
D
I
I
might
be
able
to
take
this,
so
I
I
was
a
little
bit
involved
with
some
of
the
early
hotel
work
and
I
think
the
pattern
that
works
really
well
is
when
you
you
create
a
reference
architecture
but
you're
very
you're,
very,
very,
very
elastic
right
because
there'll
be
suggestions
that
come
in
and
I
think
the
thing
is
that
sometimes
it
can
be
death
by
committee.
So
we
build
a
general
reference
architecture
that
has
components
that
can
be
individually
improved.
I
That
makes
it
a
lot
more
easy
for
people
to
come
in
and
try
and
incrementally
improve
things
rather
than
us
sort
of
having
no
opinion
and
the
project
going.
Nowhere
on
the
cloud
native
side,
in
terms
of
you
know,
ratifying
and
making
sure
that
this
is
a
good
design.
We've
gone
through
a
couple
of
rounds,
and
actually
this
is
totally
why
we
need
that
working
group.
I
You
know
we
might
want
to
throw
this
out
and
say:
oh
no,
we're
going
with
the
message,
bus
approach
or
whatever,
but
I
I
have
fairly
high
confidence
that
we've
had
a
few
passes
on
this,
and
this
is
sort
of
the
kate's
native
architecture
that
is
actually
very
idiomatic
for
for
native
kubernetes.
So
we're
not
really
building
any
components
that
are
that
are
off
the
wall
or
unusual
we're
working
completely
with
kate's,
rather
than
going
upstream
against
it.
B
All
right,
perfect
yeah,
so
I
guess
look
for
the
the
message
in
the
slack
channel.
You
know
I
think,
we'll
try
to
decouple
it.
I
think
it
does
make
sense,
especially
because
those
other
meetings
could
be
more
more
technically
focused,
as
we
kind
of
move
forward
with
that,
but
definitely
if
you're
interested
feel
free
to
join.
That
cool
looks
like
todd's
up
next
todd
and
god
please.
H
Yeah,
so
the
thing
I
really
wanted
to
mention-
and
I
I
should
I
guess,
apologize
for
some
amount
of
thrashing
on
this-
there's-
been
a
pr
open
in
the
spec
repository
for
a
while
now
for
evaluation
context,
and
it's
a
it's
a
obviously
an
important
topic.
It's
something
that
just
about
every
every
vendor,
every
sdk
is
concerned
with.
You
know,
defining
attributes
for
the
basis
of
dynamic
flag
evaluation.
H
Author
person
doing
feature
flag,
evaluation
and
the
provider,
because
the
provider
is
supposed
to
be
something.
That's
that
you
know
we're
able
to
change.
We
don't
want
to
have
too
many
contracts
between
the
application,
author
and
the
provider,
because,
essentially
it
it
brings
back
lack
of
portability
right.
So
so
it
causes
a
cause
of
lack
of
portability.
H
We
really
want
to
have
the
provider
just
be
something
that's
configured
once
and
then
the
application
author
doesn't
have
to
think
about
it.
So,
whether
that's
the
cloud
native
provider
like
we
just
talked
about
or
launched,
darkly
or
or
flagsmith,
you
know
we
really
just
want
to
kind
of
set
that
and
forget
it,
and
so
my
concern
was
if
different
providers
had
different
concepts
of
you
know
what
to
call
these
particular
attributes
where,
within
the
context,
they
might
be
found
the
the
particular
format
of
these
attributes.
H
These
did
define
particular
attributes
kind
of
as
first
class
predefined
attributes,
and
what
I
think
continuing
research
has
found
is
that
providers
which
have
done
that
vendors,
which
have
done
that
actually
seem
to
kind
of
regret
that
decision.
It
seems
that
kind
of
predefining,
particular
attributes
only
gets
you
into
trouble
later.
H
One
of
the
things
it
does
is
almost
encourage
people
to
fill
them
all
out
by
default,
which
can
result
in
a
lot
of
pii
kind
of
just
unnecessarily
being
added
to
the
to
the
library
and
fired
into
the
feature
flagging
system
when
it
wasn't
really
necessary,
because
nobody
was
writing
rules
against
them
actually,
so
that
that's
one
one
downside
that
I've
heard
so
anyway.
All
that
to
say
is
after
a
lot
of
thrashing
and
back
and
forth.
H
I've
since
moved
away
from
the
idea
that
we
should
kind
of
propose
a
bunch
of
predefined
attributes
to
the
fact
that
maybe
we
should
just
provide
a
context
with
some
with
some
semantics
around
it.
Perhaps
later
we'll
talk
about
propagation,
but
just
with
you
know
here
is
here's
kind
of
what
we
expect
to
be
in
the
to
be
in
the
context.
What
we
expect
to
be
used
for
here
the
types
that
we
expect
to
be
able
to
populate
in
the
context.
B
B
H
A
I
think
I
think
I
think,
having
a
goal
of
being
able
to
you
know
seamlessly
swap
from
one
vendor
to
the
next
is
something
that
is
important
as
a
goal,
but
I
feel
it's
possibly
never
going
to
happen
in
it's
just
the
implementations,
the
rules,
just
you
know
the
finer
detail
of
of
how
these
engines
are
different,
means
that
you're
you're,
almost
without
a
spec
like
this
you're,
almost
it's
almost.
I
mean
it's
impossible
to
have
something.
That's
you
know
literally
put
a
different
provider's
package
name
in
and
away
you
go
kind
of
thing.
A
D
I
don't
even
know
how
long
ago,
they're
added
before
I've
been
here
and
like
you're
saying
that
people
just
fill
them
out
of
times
and
then
they
come
back
later
on
and
they're
like
hey,
I
sent
you
pii
that
I
didn't
want
to
so
up
front.
I
feel
like
we
should
probably
have
this
small
of
an
api
service
for
those
being
defined,
and
if
we
see
down
the
line
that
you
know
what
actually
with
using
open
feature,
you
know,
90
of
everyone
is
asking
for
this
field.
B
The
other
thing
that
todd-
and
I
were
talking
about
and
like
to
get
everyone's
thoughts
on
this
is
we
could
say,
if
you're
looking
for
like
a
naming
convention,
perhaps
look
at
like
the
elastic
comma
schema
or
something
like
that.
First,
we
wouldn't
want
to
include
that
as
a
dependency,
it's
actually
quite
large,
but
that
might
be
something
to
keep
in
mind
for
like
a
naming
convention
for
for
certain.
You
know,
context
property
names.
H
Yeah-
and
I
I
do
I
think,
generally
like
like
mike
kind
of
teased
earlier-
and
I
was
hoping
to
get
a
larger
discussion
discussion
on
perhaps
offline
I
mean
it
is,
it
does
come
with
the
in
the
pr
but
like
mike
mentioned,
I
do,
I
think,
probably
we
do
need
to
define
a
targeting
key
just
about.
I
I
think
actually,
every
single
vendor
we've
looked
at
does
require
a
targeting
key,
so
something
to
identify
the
subject
of
the
flag
evaluation.
I
say
subject
because
it
may
be
an
actual
user.
H
It
may
be
a
service,
but
I
I
think
universally
it.
The
concept
exists
in
every
vendor.
The
only
thing
that
is
a
little
bit
tricky
is
some
vendors
require
it
and
some
don't.
I
I
believe
that
we're
going
with
not
requiring
it,
because
we
don't
require
context
at
all
for
the
most
basic
cases,
but
that
presents
some
amount
of
difficulty
in
future
flag
vendors
that
do
require
that
do
require
a
targeting
key
or
some
representation
of
the
user,
and
it
might
just
be
in
some
in
some
vendor's
cases.
H
I
think
that,
particularly
with
with
flagsmith
they
come
to
mind,
the
the
targeting
key
is
only
needed
if
you
want
to
do
attribute-based
evaluation,
but
if
you
don't,
then
you
don't
need
it,
and
so
there's
kinds
of
all
all
different
levels
of
of
requirement
around
the
targeting
key.
So
we'll
have
to
be
careful
with
how
we
implement
that.
I
do
have
a
proposal
for
that
in
the
in
the
spec
currently,
but
I
bring
all
this
up
because
I'd
like
to
get
this
close
soon
later.
H
D
D
B
Yeah
yeah,
so
one
of
the
things
that
we
were
talking
about
here
is
if
we
make
it
optional,
because
I
don't
think
we'd
want
to
have
to
pass
this
in
at
flag
evaluation
time.
I
think
that's
actually
that'd
be
actually
a
bummer
if
we
had
to
do
that,
I'd
prefer
to
be
able
to
do
that
upstream
somewhere,
maybe
even
during,
like
you
know,
client
creation
or
somewhere
up.
H
Yeah,
I
think
I
think,
that's
a
good
point,
so
I
I
hear
what
you're
saying
dan-
and
I
know
that
split
did
have
the
same
concern.
So
you
know
these
are
basically
factors
for
for
differential
evaluation,
whether
it's
based
on
rules
or
based
on
like
percentage
rollout,
that
kind
of
thing.
So
we
just
need
to
decide
okay
like
if,
if
we're
not
going
to
make
it
mandatory
on
the
open
feature
api
level,
how
then
do
we
handle
it
in
providers
when
it's
not
defined
like
like
what
would
be
the
recommendation?
H
What
would
what
would
a
hypothetical
launch
document
provider
do?
What
would
a
hypothetical
split
provider
do
if
it
doesn't
have
a
user
checking
key
and
if
that's
just
too
difficult
a
problem
to
deal
with,
I
mean
it
could
just
be
that
it
defaults.
It
could
just
be
that
it
logs
the
message
and
says:
hey.
You
need
to
provide
a
targeting
key
for
this
provider.
I
don't
know,
but
if,
if
that's
too
tricky
a
problem,
we
may
need
to
think
a
little
bit
more
about
whether
or
not
it
does
become
a
required
parameter.
B
And
I
could
see
it
throwing
like
a
well-known
error.
We
already
have
errors
defined
and
those
would
bubble
up
and
like
be
exported
from
like
the
details
call
anyways.
It
could
also
be
included
in
like
any
kind
of
logging,
hooks
and
stuff.
So
it'd
be
pretty
obvious,
like
you
know,
flag
defaulted,
because
targeting
key
was
undefined
or
something.
D
The
initial
worry
I
had
there,
though,
is
that
it's
kind
of
hidden
unless
you're
already
wired
into
otel
or
something
else
you
know,
because
we're
going
to
return
that
default
flag
value,
a
new
user
coming
in
can
be
confused
or
switching
providers.
It
can
provide
some
confusion
there,
but
we
can
take
this
offline
and
continue
talking
in
the
issue.
B
Yeah
I
mean
perhaps
that's
where,
like
the
logger
potentially
could
come
into
place,
although
of
course
like.
I
think
that
would
require
the
user
to
like
register
a
logger.
I
don't
think
we
would
just
dump
logs
out
so
yeah.
Let's,
let's
chat
about
that,
because,
like
there's
really
not
a
great
answer
most
likely,
I
I'm
really
kind
of
anti-requiring
it
at
flag
evaluation.
Call,
though,
I'd
much
prefer
to
be
able
to
pass
that
information
in
at
a
more
convenient
location
and
how
we
solve
that.
B
H
B
So
I
guess
the
action
item
there
is.
We
should
just
probably
cut
an
issue
specifically
for
this
topic,
so
I
think
it's
probably
slightly
unrelated
to
the
evaluation
context,
spec
definition,
but
maybe
it's
it's
an
issue,
that's
more
or
less
linked
to
that
and
some
of
the
challenges
that
having
an
optional
targeting
key,
you
know
basically
would
lead
to
so
I
can
handle
that
one
I'll,
create
the
issue
and
link
it
to
the
the
pull
request
and
then
I'll
just
put
it
in
our
slack
channel.
J
J
H
So
that's
a
really
interesting
idea
and
it's
not
the
first
time.
I've
heard
it
and
I'll
you
may
want
to
talk
to
pete,
because
pete
specifically
brought
that
up.
In
fact,
he,
according
to
the
term
megaprovider,
I
I'm
not
sure
it
was
a
mega
provider
or
meta
provider,
but
it
was
exactly
what
you
described
so
it
would
be
like
implementing
the
provider
interface
by
composing,
several
existing
providers
together,
or
at
least
several
other
apis
together.
Maybe
even
doing
some
caching
to
you
know
cache
where
this
particular
value
was
resolved.
J
It
so
there
are
some
people
who
want
that
generalized
config,
because
again
we
have
many
versions
of
config,
but
even
for
features
like
whether
a
feature
is
on
or
off
is
like
one.
This
feature
plugging
thing
we're
building
to
like
we
run
experiments
through
an
experimentation
platform
and
that's
another
place
where
on
or
off
could
be
decided
and
then
thirdly,
like
some
people,
so
ebay
has
many
sites
like
germany
and
us,
and
we
may
have
a
config
value
that
we're
like
okay
for
safety.
J
We
want
to
roll
this
out
as
a
feature
flag,
but
then
later
we
know
it's
not
going
to
change
all
the
time,
so
we're
just
going
to
hard
code
that
into
like
flat
file
config
instead,
because
of
the
way
we've
implemented,
our
future
flagging
system
and
so
for
long-lived
feature.
Flaggy
things
put
them
in
a
flat
file
and
that'll
be
a
faster
evaluation.
J
B
Yeah
and
that
that's
a
good
point
too,
that's
one
of
the
things
that
I'm
hoping
to
put
on
the
the
research
planning
board,
but
that's
an
area
that
we
have
not
really
addressed
at
all
is
is
client-side
both
browser
and
mobile
and
really,
like
figuring
out
some
of
these
answers
too,
because
it
seems
like
even
across
vendors
right
now.
They
do
like
you
know,
either
the
flag.
Configs
are
synced,
client-side
and
then
evaluated
locally,
which
has
certain
issues
versus
remote.
B
You
know
flag
evaluation,
which
also
has
issues
so
really
and
we
sort
of
need
to
be
kind
of
unopinionated
there,
but
we'll
have
to
have
some
kind
of
sdk,
that's
capable
of
handling.
You
know
both
as
elegantly
as
possible,
which
may
go
back
to
actually
the
bulk
evaluation
api,
which
also
brings
in
some
other
challenges.
So
I
think
the
research
needs
to
start
as
soon
as
possible.
So
we
can
start
answering
those
questions
and
making
sure
that
you
know
some
of
the
spec
definitions.
Don't
kind
of
collide
with
the
client
goals
and
needs.
J
B
B
A
Just
to
add,
like
one
of
the
things
that
we've
sort
of
come
up
against
using
the
platform
to
do
like
pure
config
is
how
you
know-
and
I
think
this
is
from
the
majority
of
providers
like
there's
no
there's
well.
We
have
no
authentication
against
our
api
for
getting
flags
right.
If
you've
got
the
key
for
the
environment,
you
can
get
the
flags,
and
so
we
have
people
thinking
about
using
the
the
sdk
and
the
platform
for
storing
config
values.
But
then
you,
you
know
you
worry
that
people
might
put
something
that
is.
A
It
should
be
secret
into
an
api.
That's
like
anyone
can
get
it
right
like
and
the
keys
in
your
web
page
or
your
mobile
app,
and
you
can
trivially
get
that
so
we've
we've
kind
of
shot
it.
You
know
and
we're
not
doing
like
hard
proper.
You
know
publicly
encryption
with
the
data
and
all
this
sort
of
stuff,
and
it
opens
this
massive
can
of
worm.
A
A
B
B
B
But
that's
one
aspect
and
then
also
kind
of
the
config
management.
Slash
feature
flagging
is
is
an
interesting
topic
for
sure
as
well
so
yeah,
I
guess
justin
think
about
that
use
case
a
little
bit
more
and
then
and
see,
or
maybe
some
of
the
gaps
are
and
if
without
changing
too
much
of
the
spec.
If
there's
some
way
to
support
this
use
case
better,
I
think
that
it
likely
makes
sense.
A
A
B
That's
a
good
question.
Actually,
I
think
it
was
harness
had
a
really
interesting
way
of
doing
it.
Maybe
dave
could
slightly
talk
about
it,
but
it
was
basically
like
they
had
like
test
cases
in
a
separate
repo
and
then
they
would
basically
mount
it
in
there
and
then
just
make
sure
that
the
tests
kind
of
pass
the
specific
use
cases.
I'm
not
sure
if
that
concept
could
apply
here,
but
that
would
be
maybe
an
interesting
way
of
doing
it.
K
Yeah
that
that's
exactly,
we
had
a
a
test
case,
repo
that
we
sub
module
in
teach
of
our
sdks.
It
works
pretty
well
for
the
server-side
sdks,
it's
a
bit
bit
harder
with
the
client
side.
We
kind
of
have
to
load
it
in
through
a
different
way,
but
effectively
the
sdks
read
in
basically
rules
that
they
would
have
otherwise
got
from
the
server
as
well
as
flags,
and
then
there's
some
extra
metadata
to
say
like
what
what
value
you
should
expect.
K
I
think
we've
played
with
a
few
other
things
like
wrapping
all
the
sdks
in
an
application
like
we
like
the
idea
of
trying
to
have
a
dashboard
where
you
have
like.
I
don't
know,
20
windows,
all
the
different
sdks
and
as
you
toggle
the
flag,
you
would
see
them
all
change
to
the
same
color
or
kind
of
something
that's
fairly
in
your
face.
K
K
That's
it
yeah,
so
we've
kind
of
got
like
if
you'd
imagine
the
metadata
that
would
come
from
the
server
anyway.
If
the
rules
and
flex
information,
it's
basically
that
in
a
yaml
form
or
a
json
form
and
then
a
little
bit
of
extra
data
with
the
expectations
tagged
on
the
end,
we've
got
enough
that
it's
working,
we
kind
of
thought
about.
Could
we
formalize
it
a
bit
more?
We
actually
break
out
those
expectations.
B
B
At
that
point,
you
just
say
like
are
we,
you
know
complying
to
the
spec
and
you
just
kind
of
read
right
down
through
the
through
the
different
topics,
so
I
actually
started
prototyping
that,
but
I'm
not
super
far
along
yet
so,
hopefully
I
can
wrap
that
up
in
the
next
few
days
and
and
that
hopefully
makes
it
a
little
bit
easier
to
test.
You
know
where
we
are
in
in
the
spec
or
where
your
sdk
is.
B
Nope
all
right,
perfect.
Well,
thanks
again
everyone.
I
think
I
guess
the
theme
in
the
next
few
weeks
will
just
be
trying
to
get
that
context
resolved,
probably
in
the
next
day
or
two.
So
certainly,
you
know
monitor
that
as
quickly
or
as
closely
as
possible,
and
then
I
think
we're
getting
very
close
with
having
the
it
sounds
like
the
python
sdk,
the
java
sdk
and
the
node.js
sdk
in
a
state
where
we
can
start
experimenting.
G
B
The
next
step
will
be
figuring
out
how
like
a
contribs
repo
could
work,
which
is
where
you
know
hooks
and
various
provider
wrapping
could
could
live,
and
that's
something
we'll
have
to
discuss
like
how
the
permission
models.
Look.
What
the
release
strategy
looks
like
all
of
that,
so
maybe
start
thinking
about
how
how
you
would
like
to
see
that
work.
It
could
be
a
maybe
a
discussion
point
for
for
the
next
community.
Sync
cool
all
right.
Well,
thanks
everyone
and
then
look
for
that.