►
From YouTube: OpenFeature - Project Meeting, May 11th, 2023
Description
meeting notes https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ
OpenFeature website: https://open-feature.github.io/
B
C
B
A
D
B
A
All
right,
let's
see
here,
I,
think
we
could
probably
get
started
in
a
second
I
I,
just
shared
the
the
notes
in
the
zoom
chat
and
there's
not
a
ton
of
agenda
items.
If
anyone
has
anything,
please
feel
free
to
do
it
and
then
go
ahead
and
add
yourself
as
a
participant
and
is
there
any
volunteer
for
scribe?
If
not
I'm
happy
to
do
it
today,
I
haven't
done
it
in
a
while,
so
but
I
don't
want
to
take
that
opportunity
away
from
anyone.
E
D
A
E
E
I
I
haven't
heard
a
lot
of
I
haven't
heard
a
lot
of
like
concerns
at
this
point
or
I
guess,
I
should
say
a
lot
of
the
concerns
with
spec
have
been
addressed.
I
think
there
were
some
good
points
brought
up
by
various
people,
late
last,
which
is
probably
cavindu
thanks,
cavindu,
so
but
yeah
I'm,
feeling
pretty
confident
with
what
we
have
now
I.
E
So
I
think
that
we
can
probably
merge
events
at
the
end
of
the
week
like
I
was
thinking
about
doing
it
tomorrow
and
that'll
leave
us
in
a
place
where
we
have
basically
four
big
new
topics
to
release
with
spec
zero.
Six,
zero
and
I've
noted
them
there
in
the
notes.
So
it's
events
in
it
and
shutdown,
multi-provider
support
and
flag
metadata,
so
basically
we'll
be
releasing
spec
zero
six
zero.
E
With
with
all
those
all
those
things
everything
should
be.
Can
you
know
continuing
along
that
with
our
with
our
patterns?
So
far,
everything
should
be
backwards
compatible,
so
providers
that
ideally,
providers
that
were
designed
for
older
versions
of
the
spec
should
work.
Just
fine
with
newer
releases
of
sdks
I
mean
that's
kind
of
up
to
the
SDK
implementer,
but
that's
the
idea.
E
Things
have
kind
of
been
specked
in
that
in
that
with
that
in
mind,
and
that's
how
the
experimental
web
SDK,
which
implements
almost
almost
all
of
this
stuff,
works
so
yeah.
The
plan
is
to
to
merge
the
events
and
then
I'm
going
to
be
creating
issues
in
basically
every
SDK
repo,
with
like
a
with
like
a
high
level
issue
describing
those
kind
of
four
things
that
need
to
be
implemented
and
people
can
just
have
at
it.
E
I've
had
a
number
of
main
of
maintainers
or
contributors
kind
of
volunteer
already
to
take
over
those
issues
or
to
help
with
those
issues.
So
that's
exciting
thanks.
Everybody
who's
who's,
doing
that,
but
yeah,
basically,
zero.
Six,
zero
come
down
the
pipe
probably
next
week,
unless
I
hear
concerns
about
events
or
or
the
release
in
general.
Before
that,
anybody
have
any
comments
or
questions
on
that
topic
concerns
okay,
yeah
and
then
the
last
thing
I
want
to
talk
about,
which
should
be
pretty
quick.
E
The
the
current
playground
demo,
which
is
something
that
we
show
a
lot
at
kubecon.
Sometimes
we
show
it.
Sometimes
we
show
it
in
in
the
community
meetings
every
once
in
a
while.
It
was
kind
of
designed
to
be
a
good
place
to
experiment
with
the
spec
and
providers
and
some
of
our
Concepts
yeah
I
think
from
the
very
beginning.
It
wasn't
really
designed
to
to
be
a
showpiece.
E
So
it
doesn't
look
amazing
right.
It's
not
very
flashy.
It's
designed
really
to
to
allow
us
to
experiment
with
providers
and
functionality
it.
You
know
it's
not.
It's
not
cool.
Looking
I'm
speaking
next
month
at
a
at
a
New,
York
City
devops
days,
and
one
of
the
things
I
wanted
to
do
was
kind
of
do
a
demo
for
a
a
use
case.
E
That
gets
really
good
traction
when
I
talk
about
it
and
it's
a
real
use
case
for
feature
Flags
that
I
experienced
at
one
of
my
past
companies,
which
is
like.
Basically,
you
have
a
whole
bunch
of
countries
or
jurisdictions
with
different
regulations
and
you're
like
slowly
kind
of
onboarding
them
into
onto
a
new
feature,
and
it
it
really
shows
like
user
targeting
well
I.
E
Think
it's
like
an
interesting
use
case
that
really
helps
people
understand
how
a
remote
managed
feature
of
a
remotely
managed
feature
flag
platform
can
really,
you
know,
increase
the
speed
of
delivery
and
also
the
confidence
of
delivery
of
new
features.
So
it
just
really
connects
well,
so
I
I
think.
E
And
that's
feedback
we've
heard
too
from
like
other,
like,
for
example,
one
of
the
hotel
maintainers
was
was
kind
of
talking
to
Mike
and
I
about
about
this
like
how
the
playground
is
is
cool
for
for
playing
around
in
and
Building
Things.
It
doesn't
actually
demo
the
real
benefits
of
feature
Flags
too
well
yeah,
so
so
I,
which
I
think
is
absolutely
true.
So
that's,
basically
what
I'm
working
on
improving.
E
A
You
know,
especially
because
you
could
start
showing
like
I
mean,
if
you
think
of
like
a
a
map
or
whatever
you
show
a
map
of
Europe
and
you're
doing
the
gdbr
stuff,
and
you
see
like
the
little
dots
change
color
as
you're
updating
rule
sets
and
whatever
like
it.
It
could
be
a
really
cool
demo,
but
it
could
be
something
that
we
could
kind
of
collaborate
on
in
some
issues
somewhere,
probably
in
the
demo
app.
E
Yeah,
that's
basically
what
you
described
as
kind
of
what
I'm
thinking
and
I
think
it
will.
Even
we
could
even
build
like
a
little
Tour
on
top
of
it
or
something
where
it's
like.
Okay,
now
enable
the
feature
for
these
GEOS.
Oh,
we
just
got
advice
from
Legos,
it's
legal
that
this
Geo
needs
to
be
added
and
yeah
you'd
see
like
dots
plotted
on
the
map,
some
that
are
in
violation
of
like
some
legal
restriction
that
you
have
to
then
correct
with
a
feature
flag,
and
you
can
see
that
deploy
that
kind
of
thing.
E
A
Cool
sounds
good,
just
a
reminder:
I'm
gonna
paste
in
the
notes
here.
So
if
anyone
has
any
agenda
items
we're
already
halfway
through
it,
so
yeah
definitely
probably
move
fairly
quickly.
The
next
one
I'm
really
trying
to
get
a
sense
of
how
important
others
think
this
would
be
personally
I
think
it's.
A
It
would
be
extremely
useful
or
even
using
it
in
our
playground,
application
right
now
and
it's
the
idea
of
like,
like
request,
scope
like
context
propagation
and
so
basically
like
in
something
like
node
you'd
use
like
a
continuous
local
storage
or
some
technique
like
that
in
Java.
They
have
like
thread
local
storage
and
other
similar
Concepts.
A
These
Concepts
apply
across
a
lot
of
different
tools,
and
so
thinking
about,
like
you
know,
if
you're
thinking
a
targeting
key
or
a
user
identifier
or
something
is
very
important
in
a
feature
flag,
it's
really
unfortunate,
tedious
and
sometimes
not
possible
to
pass
it
into
each
flag
evaluation.
So
if
you
could
basically
shove
it
on
the
request
at
like
in
the
auth
tier
and
have
it
basically
automatically
merged,
as
part
of
like
you
know,
a
flag
evaluation
in
in
the
scope
of
a
single
request,
how
valuable
that
is
to
people.
A
It's
like
I,
said
it's
already
in
the
demo
application
and
we've
already
had
an
oath
approved
for
that.
It's
just
like
making
sure
people
find
it
interesting
and
then
writing
spec
for
it
and
then
basically
implementing
it,
of
course,
in
the
different
languages.
So
the
nice
part
is
then
like
any
vendor
and
tool
would
all
benefit
from
this
and
you
kind
of
get
it
for
free
across
all
different
sdks,
so
kind
of
open
it
up
to
that
one.
A
F
I
guess
my
my
opinion
on
that
in
is:
is
there
kind
of
I
guess
changing
something?
That's
kind
of
explicit
and
too
implicit
right,
like
you're
kind
of
like
changing
this,
like
implicit
thing
where
you
have
to
pass
around
this
user
data
and
and
have
it
available
to
something
that's
kind
of
like
happening
automatically
in
the
background
and
there's
definitely
value
in
that
in
the
higher
level
languages
I'm
not
sure
like.
F
A
I
wonder
if
it's
even
Beyond
demo,
though
it's
just
like
how
like,
if
you
have
to
use
a
feature
flag
in
some
service
right
now,
it
doesn't
have
access
to
user
metadata.
Like
are
you
going
to
update,
like
the
method
signature,
to
pass
that
in
just
for
feature
flagging
purposes?
That,
to
me
seems
unclean
too,
like
I,
hear.
F
What
you're
saying
too
there's
it
depends
on
the
structure
like
a
lot
of
structure,
there's
like
a
request,
request,
scope
right
like
and
a
lot
of
languages.
There's
like
it's
all
handled
around
like
handling
some
HTTP
requests
right,
and
so
it's
like
there's
a
request,
scope,
that's
passed
along
and
that's
kind
of
like
the
global
scope
for
that
request
in
a
lot
of
languages,
but.
C
I'm
I'm
I
have
kind
of
the
same
thoughts
that
Jonathan
had
like,
for
example,
I
was
thinking
about
how
I
would
maybe,
for
example,
use
it,
as
you
said
in
a
note,
and
maybe
with
an
sjs
below
it.
Also
I
was
just
wondering
there.
I
would
personally
I
think
I
would
go
for
something
like
using.
What
nest.js
gives
me
for
that
driving
the
scope
and
getting
it
down
there
and
like,
for
example,
in
a
repository
or
whatever
or
in
a
service
using
it?
A
Basically
use
it
as
a
request,
scoped
thing:
we
also
do
it
as
part
of
like
a
request
scoped
like
merging
so
like
it
shows
kind
of
both
options,
and
this
is
kind
of
like
an
optional
part.
So
I
just
don't
know
how
we
could
well
they're
partially,
like
open
feature,
was
sort
of
designed
like
that,
which
is
why
we
didn't
have
targeting
key
is
like
a
required
argument
at
flag
evaluation,
and
so
you
could
pass
it
in
at
different
tiers.
A
E
Yeah
when
I
first
started
thinking
about
this
proposal,
I
had
this
same
reaction
as
basically
Lucas,
where
I
was
like
well,
I
can
use
whatever
the
ioc
framework
I'm.
You
know
I'm
working
with
provides
right.
So
you
know
if
it's
spring,
you
got
injection
that
way.
If
it's
Nest
like
Lucas
mentioned,
then
you
you
know
you
do
that
way.
E
On
the
other
hand,
if
you're
not
using
any
of
those
Frameworks
it,
it
would
kind
of
be
nice
to
have
the
ability
to
kind
of
Leverage,
built-ins
and
open
feature
to
accomplish.
With
the
same
thing,
I
mean,
certainly
that's
what
open
Telemetry
has
done,
but
there
is
maintenance,
I,
think
it
I'm
not
sure
how
hard
it
would
be
to
spec
out,
because
it's
kind
of
wildly
different
in
a
lot
of
languages
but
I
I
think
you
could
do
it
in
a
general
way.
D
E
I
don't
know,
I
see
the
pros
and
cons,
I
I'm
open,
I'm
open
to
it.
The
baggage
thing
is
particularly
interesting
to
me:
yeah
I,
I'm,
not
sure,
and
maybe
I
don't
know
if
we
merged
the
ofep,
so
I
I'm
not
sure
where,
if
there
was
room
for
more
discussion
on
this
I'm,
not
sure
where
we
would
put
it
but.
F
E
E
D
A
So
I
think
we
just
have
something
to
think
about.
There
is
enough,
it
was
closed
and
merged
at
some
point,
but
like
I
was
just
trying
to
gauge
interest
in
this
partially
because
I
really
want
to
see
if
we
can
explore
the
baggage
propagation
partially,
because
I
really
think
that
that's
an
interesting
use
case
in
in
like
highly
distributed
like
microservice
environments,
that
you
may
need
things
like
you
know,
targeting
keys
or
user
identifiers
and
stuff
that
aren't
available
in
Downstream
services
and
you're,
not
gonna.
A
A
A
And
I'll
add
it
to
the
notes:
cool
the
next
one
that
I
had
is
basically
like
right
now.
We
we're
experimenting
with
using
an
open
Telemetry
hook
to
capture
both
basically
to
extend
a
trace
with
span
events,
so
that
that's
one
and
that
that
works
just
fine
and
also
to
create
some
some
basic
like
impression,
metrics,
and
so
both
of
those
would
be
like
optional
hooks
that
you
can
install
if
you'd
like
to
the
one
thing
that
became
fairly
apparent
to
me
as
we're
going
through.
A
This
is
a
lot
of
tools
have
basically,
you
have
like
your
feature
flag
and
it's
like
a
base
flag.
That's
like
overridden
per
environment,
so
you'd
have
like
I,
don't
know
my
new
feature
and
you'd
say
in
Dev.
It's
enabled
in
hardening
it's
enabled,
but
has
these
rules
and
in
production
it's
off
right,
and
so,
if
we're
collecting
those
metrics
based
on
the
information
that
we
currently
have
access
to
in
the
sdks,
we
don't
have
like
environment
or
project
or
organization
like
awareness,
I,
guess
if
that
makes
sense.
A
So,
as
part
of
the
upcoming
spec
changes,
there's
already
like
a
ability
for
providers
to
provide
excuse,
there's
a
lot
of
a
lot
of
provides
in
that
providers
can
supply
flag
metadata
and
so
theoretically,
like
a
provider
could
say
this
is
part
of
you
know
like
the
manage.
This
is
the
you
know,
unique
identifier
for
this.
E
E
I
mean
that
could
also
correct
me
for
wrong,
but
that
could
also
come
from.
Could
that
also
come
from
the
I
guess?
Well,
the
the
application
author
themselves,
like,
even
if
that
information
is
not
coming
from
the
flag
management
system.
If
the
workload
itself
is
aware
of
what
environment
it's
in,
it
could
populate
that
same
Dimension
and
then
you'd
have
the
same
information,
whether
it's
yeah.
A
Yeah,
it
could
because,
like
I,
think
when
you
think
of
it
from
an
application
author
like
they
would
have
to
PL
Supply,
like
a
SDK
token
or
whatever,
whatever
the
the
tool
you
know
deems
to
call
that,
and
that
has
awareness
of
like
the
project
and
environment
and
all
that
stuff.
So
I
guess
you
could
say
that
is
reasonable
to
say,
like
a
user
should
at
that
point,
know
that
this
is
for
the
dev
environment
and
whatever
we
could
certainly
do
that.
A
It
still
kind
of
goes
back,
though,
like
we'd
have
to
have
that
metadata,
have
some
specific
name
so
that
these
like
different,
like
analytics
Hooks
and
logging,
Hooks
and
stuff
like
if
it
comes
across,
and
it's
name
this
we
can
do
something.
You
know
special
with
it.
You
know
that
similar
to
the
way
hotel
is
doing
it
with
with
their
attributes.
F
A
F
A
F
Yeah,
it's
part
of
the
part
of
the
project
data
that
we
send
back
to
the
sdks
would
have
it
in
part
of
our
configuration
file.
So
it's
not
something
I,
don't
think
we
expose
not
sure
I,
don't
think
we
expose
it
to
the
end
user
right
now,
but
within
the
SDK
we
have
it.
We
could
probably
expose
it
as
part
of
this
to
the
provider
pretty
easily
and
so.
A
Okay,
yeah
I,
guess
just
think
about
that
one,
because
I'm
really,
even
if
we
do
end
up
doing
that,
I
think
the
challenge
would
be.
What
would
we
want
to
call
some
of
those
properties
or,
like
you
know,
because,
like
I
think
that
even
becomes
semi-controversial,
because
not
everyone
has
environments,
not
everyone.
Certainly
not
everyone
used
projects
like
there's
applications
and
work
groups
and
namespaces,
and
all
that
stuff.
C
For
example,
it
treats
me
that
it
makes
much
sense,
but
again
it
feeds
to
me
so
I'm
I'm,
not
100
sure
on
where
to
find
the
trade-off
between
like
defining
something
that
implements
can
rely
on
and
just
going
that
far
how
what
we
generally
handle
that
in
this
case,
for
example,
yeah.
It's
what
you
said
like
we
may
Define
something
like
this,
but
I
think
it's
fine
to
have
an
environment
in
there,
because
it's
something
that
is
pretty
familiar
to
most,
even
if
you're
not
using
it,
but
there.
A
Yeah
I
guess
that
is
the
big
question.
It's
like
I
I
personally,
like
the
idea
of
some
kind
of
like
I.
Think
otel
did
a
really
nice
job
with
semantic
convention.
Honestly,
it's
like
they
allow
you
to
send
like
key
value
pairs.
But
if
you
send
it
in
this
pattern,
it
has
like
special
meaning
and
I
think
we
could
do
something
very
similar
here
and
just
say
like
you
can
send
whatever
you
want.
A
You
know
investigating
seeing
what
we
can
do
and
because
that's
at
least
nudging
people
on
the
right
way
too.
Otherwise,
you're
offloading
a
lot
of
work
on
the
provider
to
come
up
with
like
their
own
names
and
as
most
people
know,
naming
is,
is
difficult
and
if
their
Concepts
roughly
match
to
like
a
project
or
whatever
like
just
use
project
like
I
know,
it
may
not
be
the
same
terminology
that
you
use
in
in
your
tool.
But
I
think
you
know,
people
can
understand
that
you
have
to
have
a
common
mapping
for
these.
So.
C
I
think
that
makes
total
sense,
because
otherwise
you
cannot
rely
on
anything
in
the
end
and
you
could
not
build
such
a
such
a
thing,
but
it
feels
a
bit
like
we
would
do
it
in
a
way.
Then
we
see
a
use
case
for
this.
We
we
yeah
I,
think
you
would
do
this
based
on
use
cases
right
like
if
you
can
say,
okay,
this
this
makes
sense
to,
and
we
think
that
this
is
not
too
special.
It
should
maybe
be
included
right.
A
B
E
I
guess
this
is
a
tag
on
which
yeah
I
don't
know
if
it's
good
to
bring
it
up
or
not,
but
we
could
do
similar
things
with
context.
You
know
it
might
be
the
same
attributes
but
context
is
a
bag
right
now,
with
the
exception
of
targeting
key,
we
could
use
the
same
conventions
for
context.
There's
an
idea.
Yeah.
E
Yeah
and
that's
the
thing
it
would
formalize,
because
not
every
and
not
every
like
flag
management
system
has
special
meanings
like
some
of
them
are
just
bags
and
there's
no
special
things,
and
then
some
have
these
special.
You
know
attributes
and
having
a
kind
of
defined
mapping
for
those
attributes.
Could
it
could
be
helpful
it
would
make
it
would
make
your
job
with
documenting
that
very,
very
clear
right.
F
Yeah-
and
one
thing
we're
working
on
is
like
is
custom
like
being
able
to
define
those
types
for
your
organization.
So
it's
kind
of
outside
of
this,
but
one
thing
we're
working
on
is
like
being
able
to
actually
Define
your
your
your
schemas,
like
using
Json,
schema
a
couple.
Other
schemas
like
be
able
to
Define
your
schemas
for
certain
variable
value
types
or
for
certain
custom,
like
custom
user
data
and
and
actually
being
able
to
enforce
that
like
in
your
application.
F
A
So
that's
why
we
decided
to
just
do
targeting
roles
at
the
moment,
but
maybe
it
could
even
like-
and
this
is
more
in
like
typescript,
but
you
could
easily
make
it
so
you
could
just
Supply
your
own
generic
or
something
on
top
of
that.
Maybe
we
just
have
to
expose
some
like
little.
Like
you
know:
okay,
thanks
Justin,
some
like
little
little
things
depending
on
the
language
right.
A
E
But
we
did
a
lot
of
work
in
research
in
in
kind
of
surveying
the
landscape
for
most
sdks
and
found
that
the
vast
majority
of
the
best,
and
then
we
did
some
surveys
too
also
to
to
get
got
into
the
state.
But
the
vast
majority
of
vendors
have
different
web
versus
node,
sdks
and
there's
a
lot
of
reasons
for
that.
E
One
is
because
they
have
different
dependencies
and
they're
different
runtimes.
That's
pretty
obvious,
like
local
storage
exists
in
the
browser,
it
doesn't
exist
in
node
and
there's
a
million
similar
examples.
Vice
versa,
or
you
know
in
the
same
way,
or
vice
versa,
and
the
other
thing
is
fundamentally,
the
the
client
is
just
different.
It's
usually
a
single
user
context,
so
you're
operating
in
the
context
of
one
kind
of
person,
generally
speaking,
whereas
in
the
server
every
like.
C
C
E
Paradigm,
which
is
what
we
Implement
on
the
server
and
then
a
more
static
context,
Paradigm,
which
is
what
we
would
be
encouraging
clients
to
implement
and
that's
what
the
web
SDK
implements
and
there's
an
ofep
that
details
this,
as
well
as
a
blog
post
by
by
Pete
Hodgson
from
open
feature
about
about
our
thinking
around
this
like,
philosophically,
it's
basically
what
I
just
described
practically
from
the
JavaScript
side.
I,
don't
know!
If
you've
looked
at
the
SDK,
we
do
have.
E
On
it,
but
the
way
it
exists
is
there's
some
common
types
and
then
there's
basically
like
two
sub
modules
that
inherit
from
those
that
that
you
know,
extend
those
common
types.
So
we
publish
it
all,
basically
from
one
repo,
they
share
the
common
bases
and
what's
gonna,
what
would
have
to
happen.
You
know
when
we
release
6.0,
because
a
lot
of
this
is
implemented
in
the
web
DK
web
SDK
right
now,
the
experimental
one
is
we'd,
be
pulling
a
lot
of
the
stuff.
That's
already
implemented
there
into
the
common
bits.
C
C
F
A
I
linked
the
blog
post,
there
was
one
other
question
that
Jonathan
brought
up
that
I
linked
in
here.
Basically,
we
have
a
JS
SDK
and
a
web
SDK,
and
that's
come
up
a
few
times
like
the
logic
originally
I
think
we
from
the
very
get-go
we
called
it
the
node
SDK,
but
then
it
was
like
well
node's,
not
the
only
server
runtime
and
it's
like.
Do
we
create
a
bun
one
eventually
do
we
create
a.
A
F
And
prove
examples
as
a
provider
like
we're
working
on
like
a
serverless
one
SDK
too,
but
it
may
have
to
be.
It
may
make
sense
for
it
to
be
a
different
SDK
for
us
like
to
package
it
differently,
because
it
might
be
cleaner
for
us
to
package
that
as
a
separate
SDK
for
our
customers
we're
using
it
that
way.
And
then
the
question
is
like:
how
do
we
make
that
work
with
like
like
the
provider?
F
C
No,
therefore,
that
one
I
actually
had
in
mind
that
it
may
make
sense
to
have
them
the
providers
being
maybe
more
technology
specific
about
the
SDK
note.
But
the
other
rest
of
the
explanation
like
makes
it
irrelevant
like
because
that
makes
sense
then
anyways,
even
if
you
could
could
do
it
on
the
provider
side.
E
The
web
SDK
like
subfolder
in
the
JS
repo,
like
sub
module
and
and
the
npm
module,
which
again
is
experimental,
like
it's
being
published
as
a
dash
experimental
version
now,
because
it
basically
implements
a
lot
of
the
stuff
in
the
spec
that
isn't
official,
yet
and
I'm
sure
there's
going
to
be
breaking
changes
and
stuff
like
that.
But
we
do
have
some
providers
some
even
in
production.
For
this.
A
B
A
Do
think
it's
something
to
think
about,
though
it's
come
up
quite
a
few
times
the
kind
of
confusion
there.
It's
like
I
think
the
repo
being
JS
SDK
is
probably
totally
fine,
but
maybe
they
the
artifacts
or
something
could
be
more
like
you
know,
if
we're
only
going
to
test
for
node,
we
should
probably
just
call
it
node,
maybe
potentially
in
the
artifact,
so
something
to
talk.
E
F
For
example,
we
have
we
have
a
mono
repo
for
our
JS
sdks,
that,
like
has
like
outputs,
node
and
now
the
open
feature
provider
and
like
react,
react
native,
like
JS,
like
I,
think
there's
six
different
packages,
all
from
One
jssdk
Mono
repo,
which
is
fine.
But
it's
just
like
yeah
like
the
repo
could
be
one
thing
but
like
yeah
having
multiple
like
outputs
is
like
okay,.
A
Yeah,
it
makes
sense
something
we'll
have
to
think
about
Todd,
I
I,
don't
know
it.
It's
just
tricky
I
I,
think
in
in
terms
of
like,
because
it's
probably
like
the
demo
one
potentially
could
be
exactly
the
same
and
so
figuring
out
like
do
we
just
like
publish
the
same
artifact
twice
or
what?
But
something
to
consider,
especially
if
it's
going
to
be
another
kind
of
point
of
confusion,.
A
E
What
one
more
point
of
Interest
I
wanted
to
add
on
to
this
discussion
just
for
anybody
here,
who's
interested
the
kind
of
static
context
that
the
web
SDK
implements
is
is
already
in
the
draft
spec
PR,
but
very
very
soon,
once
we've
merged
all
the
existing
PR
changes
and
released
them
like
I
was
talking
about.
I
will
open
an
actual
spec
PR
talking
about
static
context
which
won't
affect
any
of
the
server-side
sdks,
but
would
be
the
kind
of
the
basis
for
building
more.