►
From YouTube: GraphQL Working Group - January 6, 2022
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
A
C
C
Hey
how's,
it
going
yeah
not
too
bad.
Happy
happy
new.
B
B
I
thought
to
make
things
easier
for
coffee
and
things
into
the
the
live:
docs
I'll
I'll,
just
load
up
the
page
on
github
and
just
remove
the
style
sheet.
Then
then
I
can
copy
and
paste
it
without
styles,
but
it
will
still
have
all
the
links.
That'll
be
nice,
I'm
just
scrolling
through
github's,
header
and
they've
got
something
in
the
region
of
like
200
script
tags
in
there
nice.
I
just
want
the
style
sheet
like
where
is
it.
C
E
B
G
All
right,
let
me
get
that
link
in
the
agenda
file,
but
at
least
shared
it.
There.
G
Okay,
let's
kick
things
off,
welcome
everybody
to
the
first
working
group
meeting
of
2022
going
through
our
agenda
here,
of
course,
always
a
quick
reminder
that
we
have
the
spec
membership
agreement,
participation,
guidelines,
contribution,
guide
and
code
of
conduct
all
linked
right
there
by
all
showing
up.
We've
agreed
to
all
of
those,
but
there's
links
there
in
case
you
ever
want
a
reminder:
we're
gonna
go
through
a
quick
intro
of
attendees.
G
We've
got
a
lot
of
people
on
the
call
today,
which
is
awesome
so
rather
than
giving
backstory
just
name
that
way,
everyone
can
do
quick
name
to
face,
and
it's
also
a
good
way
to
make
sure
all
of
our
microphones
are
working.
G
J
You
got
alex
here,
sorry
yeah,
orders,
weird,
okay,
yeah,
I'm
alex
hi
rob
hi.
K
O
G
Sweat
all
right
welcome
everyone
thanks
for
doing
that,
keeps
us
on
time.
I
do
have
our
notes
file
up,
I
see
magic
happening.
I
see
a
bunch
of
people
have
opened
that
which
is
fantastic,
but
just
a
reminder
that
while
benji
has
become
our
default
note
taker.
He
also
is
frequently
engaged
in
discussion.
G
So
just
a
reminder
that
if
folks
could
jump
in
there,
especially
in
cases
where
benji
and
and
gabe
and
some
of
the
others
typically
take
notes
for
us-
are
in
discussion
to
make
sure
that
we're
keeping
up
all
right.
Let's
take
a
quick
look
at
our
agenda,
make
sure
there's
a
lot
on
here.
G
I
have
a
suspicion
that
we
might
have
to
move
some
of
these
towards
the
end
to
a
next
meeting,
but
we'll
do
our
best
to
stay
in
the
time
bounce
that
we've
got
and
and
get
through
all
of
it
we're
going
to
take
a
quick
look
through
action
items.
If
there
are
too
many
of
those,
I
might
wait
and
do
some
of
those.
After
the
meeting
we're
going
to
talk
a
bit
about
security,
vulnerabilities
matt
is
going
to
talk
us
through
fragment
modularity.
G
A
very
interesting
thing
about
formatting
the
spec
with
prettier
normalization
force
of
directives,
advancing
default
value,
validation,
coercion
rules
named
lists,
an
update
on
client,
controlled,
nullability
directors
on
directives,
deprecation
of
input
values
and
an
update
on
deferred
stream.
G
That
is
a
bunch
of
stuff,
but
is
that
a
complete
list?
Anything
else
that
we
need
to
talk
about
today?
That's
not
captured
here.
G
Great
question:
I'm
waiting
on
brian
to
round
up
the
vote.
We
put
them
into
a
third-party
tool,
so
I
actually
don't
know
who
it
has
and
has
not
voted
from
the
tsd
members
who
are
voting.
I
think
we
were
missing
one
and
he
was
gonna
like
let
them
take
a
couple
days
to
figure
it
out,
but
we're
gonna
cut
it
today.
G
G
I
do
all
right
off
the
presses.
I'm
literally
reading
the
email
from
brian
for
the
first
time
because
he
sent
it
five
minutes
ago.
The
five
winners
in
alphabetical
order.
Thank
you.
Brian,
are
benji
gillum
ivan
gontrov,
mark
andre
guerrero,
matt,
mahoney
and
michael
stipe.
G
Congratulations
to
the
five
of
you.
You
are
now
burdened
with
the
responsibilities
of
the
tsc
congrats.
All
that's
awesome
and
great
to
see
a
couple
returning
faces,
benji,
yvonne
and
matt
were
in
the
previous
term,
so
you
guys
have
keep
your
seats.
G
That's
our
five!
I
I
will
later
today
go
through
and
update
everything
to
make
sure
that
our
current
tsc
list
is
there
and
we
have
some
github
groups
and
stuff
that
give
people
the
right
access
I'll
get
those
updated.
Good
question
glad
I
looked.
G
B
Yeah,
I
wanted
to
know
who
the
tsc
were,
that
I
was
going
to
be
talking
to
so
yeah.
This
working
group
is
is
a
meeting
for
us
as
the
tsc
and
also
us
as
the
working
group.
So
I
can't
talk
to
you
here
about
the
any
actual
security
vulnerabilities
that
haven't
yet
been
disclosed,
but
what
I
can
say
is
that
we
don't
seem
to
have
a
good
process
for
reporting
and
discussing
security
vulnerabilities.
B
We
do
seem
to
have
a
process
in
place
when
it
comes
to
something
like
graphql
js,
but
when
there's
issues
that
might
affect
the
entire
ecosystem,
we
don't
seem
to
have
a
good
process
in
place.
At
least
I
couldn't
find
it
and
I'm
a
tsc
member,
so
I
should
be
able
to
find
that.
So
I
was
interested
to
know
what
we
should
do
with
regard
to
this
or
who
should
take
charge
of
organizing
that
and
basically
do.
We
have
anything.
G
I
don't
know
that
we've
managed
that
many
security
issues,
the
only
one
that
I
can
think
of
was
from
a
little
bit
earlier.
Last
year
there
was
a
potential
cross-site
scripting
hole
found
in
graphical,
which
the
impact
of
that
ended
up
being
relatively
low,
and
we
managed
it
kind
of
exclusively
through
that
project,
but
that's
not
quite
getting
at
what
you're
talking
about,
which
is,
if
there's
a
broader
security
vulnerability
that
might
impact
multiple
projects
in
similar
ways.
How
we
go
about
managing
that.
G
B
So
what
do
you
think
that
process
should
look
like
I
mean
we
certainly
should
have
a
link
on
an
obvious
web
page
like
graphql.org,
or
something
like
that.
Having
a
link
saying
what
the
process
for
reporting
a
security
vulnerability
is,
I
would
say
that
probably
the
tsc
themselves
should
be
responsible
for
handling
security
issues
and
then,
for
you
know,
delegating
management
of
them
to
the
relevant
places.
Would
you
say
that
that
seems
reasonable?
B
That
seems
reasonable
to
me,
so
there
needs
to
be
a
place
where
people
can
reach
out
either
to
a
tsc
member
or
to
the
tsc
as
a
whole.
I
believe
brian
actually
raised
yeah.
This
should
be
in
the
linked
item,
but
I
don't
have
it
open
right
now,
rfc,
yes,
so
brian
actually
raised
this
paragraph
of
text,
you
can
see
it
in
the
quote
text
in
the
linked
article,
but
it
basically
says
issue.
Sorry.
B
B
G
My
sense
this
is
starting
with
something
is
better
than
starting
with
the
right
thing
and
if
it
doesn't
work,
we
can
iterate
because
not
having
basically
like
if
somebody
wants
to
report
something
and
they
end
up
reporting
it
in
a
public
way
that
ends
up
creating
more
churn
than
anyone
wants,
like
that's,
not
good
I'll.
Have
a
careful
read
over
brian's
in
your
edit,
but
my
sense
is
that
probably
whatever
you
guys
have
assembled
here
is
going
to
be
reasonable.
G
I
don't
know,
there's
a
bunch
of
folks
on
the
calls
anybody
else
set
up
security,
vulner
receiving
processes,
any
advice
from
anyone.
Who's
worked
close
to
this
kind
of
problem
before.
N
I
want
to
give
a
bit
of
context
on
what
we're
discussing
recently.
It
was
like
a
person
could
contact
like
part
of
tc
to
discuss
vulnerability,
but
in
reality
we
had
like
similar
issue
from
time
to
time.
Well,
like
one
of
them
really
you
fixed
like
years
ago,
it's
like
for
a
new
validation
on
the
like
noise
defaults
of
quarry
variables
is
a
way
of
bypassing
like
technically,
it
was
fixed
on
spark.
It
was
fixed
on
implementation,
but
that
never
was
documented
for
ecosystem
as
a
whole.
N
It's
safe
to
say
about
it,
because
it's
like
two
years
past,
so
every
spec
component
implementation
already
budget,
another
even
more
abstract
thing-
is
like
limitation
on
validation
errors.
Like
a
couple
years
ago,
people
start
getting
back
boundaries
for
creating
queries
that
generate
huge
amount
of
errors.
N
So
every
every
popular
graphical
implementation
implement
limited
number
of
errors
independently,
like
I
think,
like
graphql
dress
was
like
two
years
ago
and
drafted
java
like
one
year
ago
or
something
so
sometimes
it's
like
related
to
aspects.
Sometimes
it's
not
related
to
spec,
but
there
is
like
security
stuff,
like
mostly
it's
like
nothing
like.
I
don't
expect
like
arbitrary
code
execution
is
possible
through
a
spark
or
through,
like
it's
probably
implementation,
specific
but
stuff,
denial
of
service
or
bypass
of
like
validation.
It's
happening
like
like
once
in
a
couple
of
months.
N
Somebody
discover
something
or
infinite
recursion
somewhere
and
since
we
kind
of
maintain
reference
implementation,
what
I'm
doing
right
now
is
like
just
fixing
reference
implementation.
N
One
thing
I
want
to
mention
we
have
implementers
group,
I
don't
know
if
it's
like
if
it's
trusted
place,
but
I
think
it
should
be
part
of
the
process.
We
just
wanted
to
give
a
context
of
what
we
mean
by
like
security,
vulnerability
for
entire
ecosystem.
G
Yeah,
no
that's
helpful,
so
I
I
think
there's
a
couple
pieces
here
that
that
we
need
to
do
first
is
a
safe
reporting
and
I
think
benji.
G
What
you
have
here
looks
great,
I
think
probably
the
one
thing
brian
can
help
us
with
is
just
making
it
even
easier,
like
just
saying
like
reach
out
to
one
of
these
people,
it's
like
which
one,
what
if
they
don't
respond-
and
so
I
think
brian-
can
probably
set
up
an
email
alias
for
us
and
that'll,
probably
smooth
things
out
security
at
graphql.org,
or
something
like
that.
G
That
way,
there's
just
like
one
very
clear
place
to
some
stuff,
and
then
we
should
probably
set
up
like
a
step-by-step
process
like
how
do
we?
How
do
we
typically
want
to
go
through
disclosure
where
it's
like
everyone
in
the
tse
figure?
This
out
comes
with
plan.
G
I
like
the
idea
of
first
going
to
that
implementers
group.
We
can
probably
start
private
discussions
amongst
that
github
group
and
then
writing
up
a
cve
if
we
have
to
but
yeah.
If
anybody
else
wants
to
benji's
kind
of
taking
the
lead
here
to
make
some
edits.
Brian's
done
some
good
work
there
as
well.
If
sahaja
yoga,
it
sounds
like
you
guys
have
both
faced
some
of
this.
So
if
you
want
to
participate
in
assembling
the
process,
I
think
that
would
be
super
valuable.
B
The
other
main
question
is:
how
do
we
get
the
tscs
attention
for
actually
dealing
with
this,
like
when
someone's
reported
it
through
security
at
graphql.org,
which
I
think
is
a
fantastic
idea?
Someone
is
going
to
then
take
that
and
put
it
somewhere
to
open
a
discussion.
Where
should
that
be?
Should
that
be
the
tsc
discussions
board
on
github.
G
L
N
Arrest
is
like
vulnerability
in
white
crafty
address
and
like
not
javascript,
not
javascript,
specific
vulnerability
in
reference
implementation,
meaning
like
everybody
else,
basically
doing
the
same
and
recommend
other
people
doing
the
same
so
like
as
far
as
I
personally
know,
there
is
no
way
vulnerability
inspects,
it's
mostly
implementation
details,
but
implementation
details
that
is
like
copy
pasted
in
different
implementations.
Yes,.
I
Yeah
there's
also
situations
where
people
think
there
may
be
a
vulnerability
and
it
turns
out
there
has
not
been
and
like
we.
We
want
a
path
for
that
too,
and
the
tsc
is
probably
the
right
group
to
investigate,
because
presumably
they
should
have
enough
knowledge
without
disclosing
it
to
the
entire
world.
While
the
investigation
is
in
process.
G
Yeah
brian,
I
was
gonna
say
that
I
think
part
of
the
problem
here
is
that
disclosure
is
ambiguous
right
now
because
we
don't
like,
if
you
said
what
are
the
security
vulnerabilities
that
have
been
disclosed
in
the
past,
there's
like
there's
nowhere
to
go,
there's
no,
even
definition
for
what
would
count
as
a
security,
vulnerability
and
so
like
we
don't.
We
don't
really
have
a
good
process
there.
I
think
we
should.
G
D
Yes,
sorry,
I
missed
a
few
notes.
While
I
was
looking
something
up,
so
I
think
yeah,
the
bare
minimum
should
be
to
have
a
security
at
or
abuse.
That's
like
common
practice,
yeah
email,
alias,
but
also
I
linked
it
in
this
chat.
D
I
don't
know
what
the
best
place
is
right
now,
but
github
has
actually
some
infrastructure
for
these
types
of
things
as
well
right
now,
which
might
be
a
good
place
for
people
to
know
where
to
go
rather
than
having
to
wade
through
documents,
and
it
also
allows
for-
I
believe
I
haven't
had
to
use
it
luckily
myself
yet,
but
for
initial
private
discussion
that
can
then
be
promoted
to
public.
G
I
Yeah,
so
this
is
going
to
just
be
basically
a
call
for
volunteers
for
people
who
are
interested.
I
don't
want
to
get
super
into
depth
in
the
actual
discussion,
because
I
think
that
before
we
like
have
a
deep
working
group
discussion,
it's
valuable
to
have
some
iteration
have
some
thought
put
into
it.
Have
some
editing
clarification,
so,
in
short,
the
problem
is
like
multiple
client
implementations,
at
least
within
facebook.
I
Slash
meta
have
found
that
one
of
the
key
issues
we've
had
run
into
over
and
over
and
over
again
in
a
lot
of
different
contexts,
is
that
a
fragment
is
a
facade
in
the
spec.
It
acts
more
as
copy
paste,
as
opposed
to
as
like
its
own
independent
thing
and
there's
not
really
a
way
to
in
a
response
that
you
get
to
like
decompose
that
response
into
individual
fragments,
unless
you
know
everything
about
the
response
up
front.
I
So
this
is
basically
a
call.
I
put
an
rfc
that
benji
merged
into
the
graphql
working
group,
slash
rfcs.
Basically,
we
want
to
explore
we've
we've
got
a
few
ideas
in
a
few
different
areas.
The
wii
is
right.
Now
me
joe
savona
and
jordan
eldridge,
but
it
we
want
it
to
be
a
lot
more
people
I
know
alex
riley
might
want,
might
be
interested
because
this
touches
on
client-controlled
mobility.
I
But
basically,
there's
a
few
different
areas
that
we
would
likely
want
to
explore,
one
of
them
being
what's
the
right
response
format,
one
of
them
being
what's
the
right
syntax,
one
of
them
being.
Is
there
some
way
that
we
can
do
this
completely
with
the
existing
spec
in
a
way
that
feels
clean
and
yeah?
We
basically
want
to
explore
and
iterate
quickly
on
this.
I
So
if
you're
interested
feel
free
to
ping
me
on
discord
or
github
feel
free
to
comment
on
that
rfc
that
I've
posted
in
the
graphql
working
group
agenda
yeah
any
other.
G
Thanks
for
getting
everything
documented
there,
I
know
he's
talked
a
little
bit
about
this
last
time.
He
brought
it
up
in
a
meeting.
I'm
excited
that
we're
coming
back
to
this
problem.
I
think
last
time
we
talked
about.
It
was
joe
and
me
probably
talking
about
this
like
five
years
ago,
and
that
was
right
ended.
P
G
We
don't
know-
and
it's
probably
best
to
keep
things
simple.
Well,
we
don't
know
but
like
we
want
to
come
back
to
it
and
a
lot
of
times
past.
So
now
we
now,
we
know
a
lot
more
time
to
come
back
to
it
and
and
it
touches
on
so
many
other
aspects.
G
Yeah,
the
one
thing
that
I'll
just
press
is
because
I
took
a
quick
read
through
of
the
solution
space
stock
that
you
guys
assembled
is
like,
as
you
explore
the
solution
space
you
find
syntax,
that
you
would
then
see
as
potentially
expanding
beyond
fragments
themselves
so
like
considering
ramifications
of
following
each
of
the
syntax
paths
but
yeah.
I'm
super
excited
about
this,
so
yeah,
please
anyone
interested
take
up,
matt
and
joe's
call
to
participate
in
this
one.
I
For
now
feel
free
to
do
it
on
the
pr
commit.
That's
been
closed,
that's
fine
and
then
probably
all
yeah
I'll
figure
out
some
better.
We.
G
Have
we
have
a
new
feature
turned
on
in
the
wg
repo
called
discussions?
Is
pretty
cool
for
exactly
this
kind
of
thing,
so
I
would
suggest
opening
a
github
discussion
about
this.
This
prompt
you
can
like
stick
links
to
the
stuff
you
want
in
the
top,
and
it
has
like
one
extra
level
of
threading
compared
to
a
typical
issue
and
it
doesn't
get
closed
because
it's
not
a
thing
that
you
complete
in
the
same
way.
So
that's
probably
the
right
way
to
do
that.
The
threading
is
very.
G
Search
in
general
is
so
bad
on
you,
I
don't
understand
it.
It's
never
worked
very
well.
No,
I
just
want
to
like
grab
a
repo
and
it's
just
like
yeah
anyway.
I
don't
want
to
take
up
too
much
time.
Griping.
Okay,
thank
you,
matt,
and
the
folks
who
contributed
to
that
super
excited
to
see
where
that
goes.
Benji.
The
next
agenda
item.
B
Is
yours
all
right
I'll,
be
super
quick
on
this
one.
We've
talked
about
this
a
number
of
times
over
the
past
few
years,
there's
been
a
lot
of
work
done
towards
it
in
little
stints
over
the
last
few
years,
but
I
believe
that
we
are
ready.
The
october
2021
release
is
out.
We
are
ready,
I
think,
to
merge
the
prettier
formatted
spec.
I
updated
that
today.
So
assuming
we
haven't
merged
anything
in
the
last
few
hours,
it
should
be
fine
to
merge
right
now.
B
I
have
done
a
diff,
but
I
would
recommend
that
other
people
check
that
what
I've
done
is
same.
But
basically
I
we've
I
started
by
just
adding
the
tooling.
Then
I've
got
another
commit
after
that
that
actually
runs
prettier
and
formats,
the
the
spec.
If
you
then
build
the
output
html
and
compare
that
to
the
output
html
of
what
was
there
before
they're,
not
exactly
the
same,
because
the
links
change,
because
the
line
numbers
in
the
source
code
change.
B
B
That
said,
it
does
also
format
the
other
documents
like
the
readme,
the
yaml
files
and
various
other
things.
So
it
is
worth
having
a
bit
of
a
look
over.
I
would
read
the
two
commits
separately,
but
yeah,
I'm
keen
to
I'm
keen
to
get
this
merged.
G
Heck
yeah,
the
time
has
come
sorry
for
letting
this
one
sit.
It
was
blocked
on
so
many
different
things
at
any
one
point
in
time,
but
all
right,
I'm
adding
this
to
the
top
of
my
to-do
list
for
after
the
meeting
ends
just
to
do
a
quick
read
through
that,
but
I'm
gonna
assume
that
your
your
diff
is
strong
since
work.
Thank
you
for
that.
Any
anything
else
that
you
want
to
ask
for
there
is
it
just
attention.
G
N
B
The
the
prettier
does
not
change
the
format
of
the
code.
I
mean
the
code
is
already
formatted
according
to
prettier,
so
even
when
a
new
version
of
pretty
it
comes
out,
is
that
what
you're
saying
got
it.
N
Yeah
or
people
like
manually
format
or
people
like
get
text
like
if,
if
we
can
it's
better
to
have
like,
is
as
much
as
as
possible
like
stable
links
and
for
something
like
spark.
We
can
just
require
people
to
name
because
fragments
anyway
like
if
we're
asking
people
to
name
their
kill
queries.
They
can
ask
them
to
name
like
samples
and
set
this
back.
G
I'm
a
little
less
worried
about
that.
Just
because
that's,
I
think,
that's
like
part
of
the
part
of
the
goal
of
doing
this
right.
It's
like
now
there's
fewer
reasons
for
stuff
to
get
changed
out
from
under
us.
I
guess
yeah
prettier's
version
could
change,
but
it.
N
I
G
That
should
generally
be
the
case
based
on
how
the
tool
works
already,
they
only
change
when
the
contents
change,
and
so
I
think
what
the
bond
is
asking
for
is
to
putting
on
some
nominal
markers
that,
even
if
you
change
the
contents,
the
nominal
markers
link
would
stay
nominal
and
therefore
wouldn't
change,
which
is
definitely
a
cool
idea,
but
like
in
general,
they
they
should
be
stable,
but
also.
N
G
Is
you
have
a
immutable
document
that
we
guarantee
we're
not
going
to
go
back
and
change
and
the
draft
can
continue
to
evolve
so,
if
you're
linking
to
the
draft
and
your
link,
all
the
sudden
dies,
because
we've
seriously
edited
the
area
you
linked
to
well,
there's
only
so
much.
We
can
do
about
that,
but
yeah,
it's
a
good
idea.
G
Okay,
merged!
Let's
keep
going
yeah
is
yours
for
normative
force
for
objectives.
F
Thanks
so
I
this
came
up
in
terms
of
the
deferring
stream
directives.
There's
a
whole
discussion
as
to
what
the
normative
force
of
those
directives
should
be,
and
I
just
basically
kind
of
realized
that
it
might
be
confusing
just
in
general
to
newcomers.
It
certainly
was
to
meet
newcomers
to
graphql
that
directives
in
general.
N
F
Different
normative
forces,
meaning
some
of
them
maybe
must
be
followed
by
the
servers
where
some
of
them
should
be,
and
I
think
probably
that's
part
of
what
led
to
my
initial
and
and
maybe
still,
you
know
doubting
whether
whether
we
should
you
know
have
that
normative
force
of
deferring
stream
be
dropped
from
us,
but
to
should,
but
but
partly
it's
because
it's
it's
just
unclear
that
you
know
how
strongly
how
do
directives
direct
things.
F
So
this
is
basically
the
the
pr
that's
linked
in
the
agenda
is
basically
just
to
codify
how
I
believe
the
current
state
of
things
is,
which
is
that
there
is
no
specific,
normative
force
for
a
directive,
and
you
know
it
depends
on
the
directive
and
the
language
I
have
in
there
you
know,
should
you
know,
is
supposed
to
specify
that
even
you
know
give
additional
flexibility
even
that
even
directives
may
have
different
normative
forces,
depending
on
you
know,
whatever
they
want,
really
that
we're
not
really
giving
any
limits
to
that
so
that
basically,
the
the
idea
of
this
is
just
to
clarify
within
the
spec
the
current.
F
G
I
added
a
comment
in
on
that
pr
just
for
posterity,
but
my
only
thought
that
could
make
this
a
little
bit
more
clear
is
that
if
a
directive
is
defined
by
the
spec,
it's
normative.
It's
not
just
extra
information
like
if
you
say
that
a
field
is
at
skip
or
at
include,
or
if
you
say
that
in
an
sdl
that
something
is
deprecated
like
those
things
are
true,
there's
must
language
there
they're
normative,
so
that
goes
beyond
just
providing
extra
information
but
for
custom
directives.
G
Then
I
don't
know
exactly
what
the
best
way
to
phrase
this,
but
I
think
what
you're
getting
at
is
exactly
right,
where,
from
the
specs
point
of
view
at
least
there's
there's
only
so
much
you
can
know
about
it.
It's
just
annotated
information,
but
some
other
spec
may
have
some
normative
understanding
of
that
right,
like
if
you
have
a
tool
that
makes
use
of
it
and
for
diver
and
stream.
G
The
goal
for
those
directives
is
to
be
included
into
the
spec,
so
I
would
expect
those
to
be
have
whatever
normative
semantics
that
the
script
spec
describes.
Does
that
seem
right.
F
Yeah
yeah
I
mean
I
I
think
so,
meaning
the
distinction,
I
think
is
not
well
the
way
I
see
the
distinction
wouldn't
be
between
directives
included
in
the
spec
and
custom
directives,
but
you
know,
meaning
even
the
deferred
stream
directives.
They're
normal.
F
I
mean
they're
at
a
should
level,
or
at
least
in
the
proposal
that
we
have
now
so
that
you
know
if,
when
they
get
merged,
hopefully
very
soon,
some
some
of
our
spec
directors
will
be,
you
know,
must
you
know
they
must
be
honored,
and
some
of
them
should
be
honored
and
it
should
be
as
described
by
the
spec
or
as
described.
You
know
wherever
these
these
custom
directives
are
are
described,
and
so
you
have
to
follow
to
the
extent
you
know
of
that
normative
force.
F
I
think
we
may
have
to
work
on
the
language
of,
but
I
think
we're
all
in
agreement,
and
I
think
this
just
you
know
just
clarifies
that
you
know
directives.
You
know
direct
things,
you
know
to
the
extent
that
they
are
defined
to
do
so.
That's
it.
B
Just
as
a
little
clarification
there,
you
state
that
the
the
deferring
stream
are
should
right
now,
and
I
think
I
know
what
you
mean
by
that
like
the
server
can
choose
to
not
stream
something
if
it
doesn't
want
to,
but
I
think
that's
at
a
different
level
like
it
must
follow
the
rules
of
stream
and
defer
and
the
rules
of
stream
and
defer
are
that
it
may
choose
to
stream
the
result
I.e.
B
The
the
actual
specified
for
behavior
for
defer
and
stream
is
where
the
should
appears,
rather
than
whether
or
not
you
obey
the
directive
like
the
directive
can
be
experienced
in
two
different
ways
like
it
can
do
nothing
or
it
can
do
something
much
like
with
skip.
If
you
say,
skip
false,
then
you're
ignoring
that
directive
right
you're,
not
you're,
not
removing
anything.
It's
not
doing
anything,
it's
not
affecting
the
result,
but
it's
still
being
honored.
B
N
F
D
F
I
think
we
can
do
that
asynchronously
if
offline,
if
everyone
is
okay-
and
I
think
I
guess
the
best
place
would
be
in
that
pr.
G
Yeah
yeah,
thanks
for
for
prodding
at
this,
I
think
getting
things
in
a
clear
state
is
always
a
good
goal
for
us
from
the
discussion
sounds
like
there's
some
extra
clarity.
You
can
even
add
beyond
what
you've
done
here,
but
thanks
for
poking
it,
this
hopefully
it'll
end
up
even
more
clear
than
we
started.
N
I
have
a
small
question,
a
question
and
we
can
continue
it.
I
find
just
like,
because
I
think
what
we're
touching
is
like,
like
we
have
more
and
more
complex
proxies
like
for
different
reasons
for
different,
like
services
like
graph
cdn
or
like
apollo
federation,
or
like
graphql
tools,
bunch
of
fibers
doing
proxy
stuff.
N
E
So
if
you
are
seeing
that
in
your
schema,
then
it
should
be
expected
that
it's
going
to
be
supported
and
if
it's
going
through
a
proxy,
I
don't
think
that
a
proxy
should
like
unwrap
the
deferred
streams,
happening
and
buffer
everything
and
send
it
back
in
one
response.
N
N
I'm
actually
don't
know
what
the
correct
solution,
what
what
if
server,
was
what
this
proxy
2
was
written
like
two
years
ago
and
without
any
knowledge
mostly
so
I
I
don't
know
the
correct
solution,
but
once
we
added
in
this
spec,
we
cannot
like
remove
it
basically.
So
I
would
be
extra
careful
for
rewarding
not
to
not
to
trigger
this
case
of
like
exposing
directives
without
understanding
what
they
doing.
F
Ivan
are
you
talking
about
the
opposite
case?
That
rob
is
talking
about,
meaning
rob
is
talking
about,
if
I
understand
correctly
he's
talking
about
a
proxy
that
sees
the
deferring
stream
directives
but
doesn't
really
pass
them
along.
It
sounded
like
to
me,
like
you,
were
talking
about
the
opposite,
about
a
proxy
that
doesn't
understand,
defer
and
stream
and
and
therefore
can't
pass
them
along.
So
I
think
yeah,
but.
N
F
I
think
your
case
is
much
easier,
meaning
whenever
the
defer,
meaning
the
proxy
shouldn't,
be
exposing
directors,
it
doesn't
understand,
so
it
just
won't
pass
them
along
and
nothing
will
be
deferred
and
streamed
and
all
will
be
well.
If
I.
N
E
G
G
Because
I
know
we
have
a
topic
on
this
later
and
we're
getting
a
little
bit
far
afield
of
the
original
topic,
but
suffice
to
say,
there's
room
for
us
to
clarify
what
to
do
with
directives
at
this
layer.
But
that
sounds
like
it's
much
bigger
than
what
jerkoff
was
exploring.
P
Actually,
if
I
fill
out,
I
mean
I
want
to
make
one
comment
about
it.
Writing
I
write,
wrote
graphql
in
haskell
and
mostly
writing.
Directives
in
the
haskell,
where
you
want
to
be
correct
with
old
type
system,
is
kind
of
hard,
because
it's
too
powerful,
I
would
say
there
is
no
limitations.
For
example,
am
I
allowing
only
just
validation
stuff,
or
am
I
allowing
to
transfer
the
type
information,
or
am
I
allowing
to
also
resolve
this
stuff
and
there
are
too
much
power
inside
and
it
will
be,
I
suppose
it
will
be
beneficial.
G
This
conversation
has
come
up
in
the
past
and
we've
always
sort
of
landed
on
the
knife's
edge
between
generally
agreeing
that
slowly
restricting
what
directives
can
do
over
time
would
be
useful,
but
then
failing
to
find
the
actual
boundary
of
what
should
be
in
or
out
there's
some
more.
I
would
say
creative
uses
of
directives
out
there
that
I
think
most
people
would
look
at
and
say
yeah.
G
That's,
that's,
probably
not
maintainable
or
good
use
of
something
in
production,
but
at
the
same
time
it's
interesting
and
cool
that
people
can
use
directives
to
do
pretty
creative
things
and
explore
ideas,
and
that
was
always
the
original
intent
of
the
directive
is
to
it's
a
way
out.
It's
a
hook
to
allow
for
experimentation,
and,
I
think
actually,
yeah
comes
the
core
of
the
icons.
Additional
note
here
is
is
right
on
what
it
is.
Is
metadata
you're,
adding
metadata
to
your
query.
G
You
can
have
some
tool
downstream
that
interprets
that
metadata
and
does
something
that
might
be
changing
a
type
that
might
be
making
some
radical
transformation
to
the
query
itself.
That
who
knows
as
far
as
the
graphql
spec
knows
it's
metadata.
G
I
don't
know
if
we
can
reasonably
restrict
that
in
the
short
term,
but
you
know
I
think
that
is
we.
Everyone
agrees
that
there's
abuses
of
that
and
no
one
expects
every
tool
to
be
perfect
and
allow
all
possible
variations.
G
I
do
want
to
keep
this
moving
because
we
got
a
lot
of
stuff
to
talk
about
today.
Next
up
is
default,
value,
validation,
coercion,
benji,
you
added
this
one
so
I'll
hand
it
to
you.
B
Oh
yes,
this
is
me
okay
great,
so
we
lee
you
did
a
lot
of
work
yourself
on
this
you've
raised,
I
believe,
a
series
of
pull
requests
to
graphql
js
and
last
I
saw
in
september.
You
said
this
looks
good
to
go
and
asked
for
any
implementers
to
save
those
issues.
There
wasn't
any
issues
listed
below.
I
assume
you
haven't
heard
through
separate
channels
of
problems.
G
I
have
not
heard
of
that.
I
saw
a
couple
thumbs
up
on
that,
but
it
was
just
from
folks
who
are
typically
in
these
meetings
this
for
what
it's
worth
going.
Linking
back
to
our
previous
conversation
about
security
vulnerabilities.
G
G
Which
case
you
can
you
know,
cause
the
service
outage.
That's
the
sort
of
backing
motivation
behind
this
so
yeah.
I
I
definitely
want
to
advance
it
if
I
remember
correctly,
a
primary
reason
why
we
there
were
two
reasons
why
we
were
waiting
on
merging
the
change.
The
reference
implementation
changes
themselves,
the
first
of
which
was
there.
There
was
a
in-flight
migration
to
typescript
and
we
didn't
want
to
collide
with
that,
along
with
an
upcoming
major
release
that
has
now
since
passed.
So
I
think
we're
good
to.
G
I
need
to
make
sure
I
you
know
rebase
all
my
commits
on
top
of
those
and
make
sure
nothing
broke
in
the
process.
The
other
was
that
waiting
for
input.
There
were
a
few,
you
know
lagging
concerns.
People
had
and
the
way
to
resolve.
Those
was
that
we
were
gonna,
ask
for
feedback
and
wait
which
we've
done,
but
this
is
a
good
reminder
for
folks
that
are
maybe
newer
to
this
topic
or
haven't
taken
a
look.
G
Yet
it's
well
worth
reading
through
some
of
the
backstory
here
or
if
you
want
to
just
kind
of
get
a
sense
of
exactly
what
the
outcome
is.
Hopefully
my
pull
request
does
a
reasonable
job
at
that,
because
I've
added
some
graphics
that
explain
a
somewhat
complicated
problem
and
and
make
sure
that
you
you
provide
some
input
because,
yes,
I
would
like
to
prioritize
resuming
this.
B
Okay,
fantastic
and
also
as
an
update
for
you,
I
have
looked
through
what
you've
done
in
graphql
js
and
then
I've
tried
to
rewrite
that
into
spec
text.
We
did
have
spectex
before,
but
you
took
a
slightly
different
approach,
so
I've
tried
to
reflect
that
a
oh
well,
basically,
look
at
it
and
see
whether
I've
done
a
good
job
or
not
edits.
Welcome,
but
yeah
should
should
you
and
I
aim
to
to
advance
this
like
before
the
next
or
maybe
the
one
after
the
next
working
group.
G
Yeah,
let's
see
how
far
we
can
get
before
the
next
one
in
advance.
I
think
that
would
be
great
and
yeah.
Thank
you
for
doing
that.
I
forgot
that
that
was
the
other
like
we,
we
started
with
your
proposal
and
then
I
I
sort
of
took
it
on
a
run
as
I
actually
figured
out
what
the
implementation
ramifications
of
that
were.
Gonna,
be
so
I'm
getting
that
back
into
the
spectex
was
also
a
blocker,
so
my
senses
are
actually
pretty
close
to
advancing
it.
G
P
Okay,
so
sure
I'm
proposing
the
new
feature,
it's
named
lists
it's
kind
of
in
most
of
the
languages.
You
have
some
kind
of
lists
that
have
some
constraint.
For
example,
it
should
not
contain
some
duplicates
or,
for
example,
we
have
also
none
empty,
which
means
that
the
list
cannot
be
empty
or
hypothetically.
P
We
could
also
add
another
additional
constraint
and
we,
for
example,
that
this
has
some
specific
length,
for
example,
for
hdb,
we'll
use
this
international
list
should
we
have,
for
example,
three
elements
or
something
like
that,
and
for
that
reason
now
we
are
just
using
lists,
but
we
don't
signal
anything
to
the
client
client
doesn't
know
that,
for
example,
this
list
should
not
be
non-empty
and
it
still
will
validate
before
it
will
use
it,
for
example,
in
haskell.
P
P
However,
graphql
does
not
yet
does
not
support
this
feature
yet,
and
actually
it's
not
quite
hard
because
nowadays,
at
least
have
an
introspection
at
least
have
a
kind
list,
but
does
not
have
any
name,
and
we
can
add
this
information
name
to
the
lists
and
list
definition.
P
A
No
worry,
if
not
so
what
you
essentially
want
to
do
is
add
semantics
to
this,
like
it's
a
set
or
whatever.
P
Yes-
and
it
will
not
change
anything
for
the
client
who
does
not
support
the
list,
for
example,
and
for
the
newest
clients
who
support
this
functionality.
They
will
get
additional
information
about
the
lists
about
the
constraints.
G
This
is
an
interesting
idea
and
a
part
of
what
I
I
think
is
most
interesting
is
that
you
know
this
is
not
the
first
time
that
we've
proposed
some
sort
of
generic
syntax
and
you
know
with
generics.
My
my
concern
is
always
writing.
A
type
system
that
interprets
generics
throughout
is
quite
hard
and
can
get
very
complicated
and
it's
easy
to
make
mistakes,
and
so
this
actually
is
a
much
simpler
version
of
that.
That
is
restricted
to
a
single
key
and
it's
and
it's
overlapping
an
existing
type.
So
it's
purely
additive,
do
you?
G
G
But
you
know
someone
wants
to
be
able
to
say
I
have
you
know:
map
k,
comma
v
or
the
other
is
connections
or
pagination,
so,
like
relay
style
connections,
to
be
able
to
say
a
connection
of
you
know,
pages
or
a
connection
of
some
object
as
as
a
generic
syntax.
P
Actually,
for
that,
I
have
another
question
about
the
tuples
tuples,
which
actually
I
read
about
just
a
problem
about
the
generics.
Why
you
at
the
start,
you
did
not
support
that.
First,
it's
problematic
with
the
type
name.
So
you
don't
know
how
how
to
name
that.
However,
if
you
have
tuple
with
and
let's
concentrate
it
to
the
just
two
elements,
you
don't
normally
ask
us
the
type
name
to
the
on
the
table
going
to
pull.
P
So
you
will
have
this
tuple
and
it
will
still
use
kind
of
working
syntax
and
it
will
not
make
get
complicated
to
the
type
system
in
for
the
types
and
input
values.
A
So
what
I've
read
your
issue
and
essentially
you're
introducing
new
syntax,
but
in
order
to
get
semantic
lists
that
I
mean
that
that
is
the
base
proposal
here.
To
have
semantic
lists
and
semantics
could
also
be
just
added
with
the
directive
director
here,
but
they
are
not
displayed
to
the
introspection
that
define.
That
depends
on
the
spec.
A
If
we
have
a
new
spec
directive
like
list
semantics
or
whatever
the
naming
is
another
thing,
then
this
displays
in
the
introspection
like,
for
instance,
deprecate
deprecated,
it's
a
directive
and
when
you
build
your
schema,
but
it
it
becomes
available
through
the
introspection.
So
it
could
be
the
same
thing.
Yeah
there's.
G
G
Yeah,
so
I
think
this
is
interesting.
I
think
this
is
definitely
worth
exploring
from
my
point
of
view.
I
think
problems
are
we
can
bike
shed
on
syntax
and
and
try
to
get
a
better
understanding
of
the
ramifications
of
any
syntax
choice
that
we
would
make?
I
think,
especially
the
matt
raised
some
issues
on
the
pull
request
earlier
about
the
colliding
with
the
generic
syntax,
and
I
think
that's
that's
reasonable.
G
The
other
is,
you
know,
go
and
look
back
at
the
discussions
that
happened
around
custom
scalers,
there's
a
lot
of
follow-on
work
around
custom
scalers.
To
get
to
the
point
where
we
felt
like
the
the
schema
had
enough
semantic
information
for
tools
actually
able
to
do
something
with
them.
G
G
What
is
a
client
supposed
to
do
with
that,
and
is
that
the
same,
as
you
know,
something
else
that
that's
kind
of
the
problem
that
that
directive
set
up
to
solve?
This
is
interesting.
I
think,
like
another
thing
that
I
would
love
to
see
is
a
little
bit
more
motivational
motivations
behind
it.
So,
like
you
know,
how
frequently
are
people
going
to
find
themselves
using?
This?
Is
this
something
that
is
a
broad
problem?
Is
this
a
niche
problem,
so
I
think,
like
problem
exploration,
will
also
be
really
helpful.
P
Yes,
I
mean
in
my
case
it
was
some
requests,
pull
pull
requests
in
my
library
and
some
issues
regarding
that
and
after
that,
I
decided
to
explore
how
we
could
support
that
kind
of
collections,
and
I
chose
the
simplest
way.
What
was
possible
before
I
tried
to
put
some
parameters
inside
and
to
more
generalize
and
blah
blah
blah,
but
it
was
too
complicated
at
the
end.
That's
why
I
just
went
for
the
simple
ones.
However,
I
don't
know
in
for
another
languages.
P
G
I
think
that's
probably
right,
though,
generally
we
have
a
very
high
standard
for
new
syntax,
just
because
even
the
simplest
change
often
has
unforeseen
downstream
ramifications,
and
so
we
we
want
to
hold
a
really
high
bar
to
make
sure
every
change
we
add
is
adding
a
lot
of
value.
There's
also
you
know
another
one
of
our
principles
is
that
we
want.
We
want
graphql
to
remain
as
simple
as
possible
and
learnability
is
is,
is
pretty
important
so
anytime
that
we
add
extra
features.
G
We
want
to
make
sure
you
know
at
least
the
plurality
of
people
using
graphql
are
likely
to
encounter
and
use
that
feature.
So
we
don't
end
up
with
like
a
long
tail
of
edge
case
features
for
for
power
users,
where
the
vast
majority
of
people
use.
You
know
a
tiny
set
of
the
features,
so
I
think
that
problem
exploration
is
going
to
really
help
it
also.
G
You
know
it's
not
surprising
to
me
that
you're
coming
from
a
haskell
based
tooling
environment,
where
types
are
the
first
class,
primitive
and
people
are
looking
at
graphql
and
saying
wow.
I
find
graphql's
type
system
quite
lacking
in
comparison
to
haskell.
No
big
surprise:
for
me:
that's
a
little
bit
by
design.
It
is
intentionally
a
dramatically
simpler
type
system
for
a
lot
of
those
reasons,
so
that's
not
to
say
that
it
shouldn't
expand.
G
I
think
these
are
actually
really
interesting
ways
for
it
to
expand,
but
you
know,
even
if
you
end
up
on
something
that
feels
really
polished
and
good,
it
still
leaves
open
this
question
of
how
many
people
are
gonna
actually
use
this
thing,
and
so
I
think
that
that's
my
advice
to
you
is
to
go
explore
that
problem
a
little
bit
more.
G
P
I
mean
I
can
explore
more
generally
or
what
use
cases
can
be,
which
use
cases
could
be
founded
more
than
just
state
and
non-empty.
I
mean
there
is
also
work
around
solution
for
maps
there,
where
the
list
will
require
that
each
object
has
key
with
and
none
duplicate
will
you
or
some
kind
of
homogeneous
tuples
where
the
values
are
same.
However,
the
size
of
the
list
are
always
restricted.
For
example,
color
values,
rgb
will
use
or
vectors
with
points,
for
example,
where
you
have
xyz
values
or
kind
of
stuff.
P
However,
I
don't
know
how
often
they
will
be
used.
That's
why
I
think
there
should
be
some
survey-
or
maybe
I
don't
know-
maybe
some
discussion
now
where
the
people
may
comment
or
make
some
up
or
down.
G
Yeah,
I
think,
opening
this
discussion
is
a
good
idea
and
collecting
use
cases,
and
maybe
another
way
to
think
about.
This
is
to
flip
it
around
and
instead
of
saying,
if
we
had
name
lists,
how
would
people
use
them
and
instead
flip
it
around
and
say
what
are
all
the
ways
in
which
we
want
to
expand
the
type
system
that
are
in
the
same
ballpark
as
the
the
problem
that
nameless
solve
and
then
see
like
which
ones
names
list
solves
well
and
which
ones
it
solves
less?
G
Well,
ideally,
we
don't
end
up
with
like
a
broad
collection
of
tools
within
the
type
system,
but
we
have
a
small
collection
that
are
powerful
and
if
that
sometimes
means
that
things
are
awkward
like
that,
that
might
be
a
reasonable
trade-off,
but
I
think
that's
probably
the
next
step
to
explore.
H
I
see
your
hand
up
yeah,
just
it's
interesting
that
we,
you
know,
we
just
brought
up
that.
You
can't
apply
directives
onto
nested
lists
because
that,
actually
something
that
would
be
solved
by
this,
would
you
know
that
would
you
know
be
something
that
would
be
made
possible
by
kind
of
having
a
name
declaration
for
a
list.
M
Yeah
interesting
thing
to
explore.
I
was
just
going
to
point
out
like
that.
I
think
things
like
maps
and
sets
are
interesting
because
you
it's
not
with,
I
feel
like
with
those
you
wouldn't
just
want
to
be
able
to
express
that,
like
a
type
like
has
that
semantic,
but
you
might
actually
want
like
syntactic
features
like
if
a
field
returns
a
map.
I
want
to
be
able
to
do
like
a
query
that
says:
is
this
key
in
that
map?
And
so
how
do
you
express
that
or
like?
M
I
want
to
fetch
this
like
this,
this
key
of
that
value
and
so
like.
So
it
goes
beyond
just
the
type
system
supporting
it,
but
into
like
syntax
for,
like
queries
consuming
those
types
in
like
in
more
significant
ways
so,
which
I
think
would
be
really
interesting.
I
So
we
we
already
have
ways
that
clients
are
operating
on
generic
types
and
like
we
already
have
work
around
solutions,
so
figuring
out
what
those
existing
workaround
solutions
are
and
if
we
can
collapse
most
of
them
or
ideally
all
of
those
weird
generic
workarounds
into
a
single
like
spec
compliant
solution
would
be
really
really
cool,
but
that
might
be
asking
way
too
much.
G
Nice
thanks
for
presenting
this
to
me.
I
think
this
is
super
interesting.
It's
a
great
first
step
into
the
exploration.
I'm
really
excited
to
see
where
this
goes.
J
Hello,
hello,
hello,
yeah,
so
where
are
we?
Discussion
is
continued
about
the
the
list,
nobility
syntax,
and
what?
What
to
do
with
the
question
mark,
whether
it's
catching
nulls
or
it's
a
it's,
an
error,
catching
mechanism
or
something
jordan
and
joe
just
left
some
feedback
on
the
the
pr
yesterday
yesterday
sure
we'll
go
with
yesterday.
J
I
haven't
gotten
the
chance
to
respond
to
that
yet
other
than
that,
though,
I'm
I'm
I'm
pretty
blocked
at
the
moment
where
we're
waiting
on
a
way
to
release
this
experimentally.
So
we
need,
we
need
experimental
flags
to
be
available
and
graphql
js.
I
don't
really
have
anything
else
I
can
do
until
until
then
yeah.
A
Yeah
we
have
implemented
it
also
now
so
it's
available
at
least
in.net
now
in
the
newest
release.
If
you
want
to
play
from
a
client
side
with
it,
I
can
set
up
your
server
so
that
that's
possible.
We
are
at
the
moment
I'm
looking
into
updating
the
language
server.
We
have.
We've
worked
it
so
that
we
can
play
around
with
nicer
in
something
like
graphical,
and
I
think,
maybe
next
week
we
have
the
syntax
in.
J
Cool
yeah
yeah.
We
can
talk
more
about
that
and
see
about
about
getting
set
up.
The
other
thing
I
have
on
here
is
that
for
list
nullability
syntax,
I
think
it's,
it's
really
just
gonna
come
down
to
a
matter
of
of
taste
like
you
know,
a
personal
preference.
I
don't
wanna
make
like
a
a
a
unilateral
decision
on
the
list
and
tax,
but
like
how
how
are
decisions
on
things
made?
Typically,
when
there
isn't
consensus,
is
there
a
vote
or
or
how
does
that
work?
Typically,.
G
If
we
have
to,
we
will
do
a
tsc
vote
on
something,
but
it's
a
little
bit
unprecedented.
Typically,
our
mode
has
been.
If
we
can't
decide
on
what
the
right
thing
is,
we
just
don't
do
anything
and
that
feels
like
it
sucks,
but
it
like
has
the
really
great
outcome
of
we
don't
put
controversial
things
into
the
language,
and
so
I
think,
that's
probably
a
reasonable
principle
to
continue
to
uphold,
not
to
say
that
this
ends
up
being
deadlocked,
but
to
say
that
we
need
to
explore
some
way
to
find.
G
It
doesn't
have
to
be
consensus,
but
there
should
be
at
least
like
a
small
number
of
detractors
who
are
willing
to
say
you
know,
that's
not
my
favorite
syntax,
but
I
don't
care
about
it
enough
to
sort
of
hold
up
the
process
and
because,
like
I
agree,
a
lot
of
this
comes
down
to
taste.
G
What
might
be
helpful,
especially
for
this
thing
is,
I
feel,
like
we've,
been
exploring
it
in
abstract,
quite
a
lot
of
like
here's,
what
it
looks
like
for
a
list
of
one
here's,
what
it
looks
like
for
a
list
of
depth
four
and
it's
like.
Okay,
what
does
this
look
like
for
a
real
query
that
comes
out
of
someone's
real
project
and
is
that
confusing
or
helpful?
G
And
hopefully
that
resolves
or
at
least
pushes
us
in
a
direction
like
if
we
have
to
like?
Let's,
let's
pull
it
back
to
practicality,
if
we
can
just
to
try
to
add
some
extra
data
point
purely
beyond
taste,
but
that
that
would
be.
My
hope
is
that
we
can
at
least
push
it
to
the
direction
where
you
get
a
majority
opinion
and
one
and
the
remainder
set
of
folks
who,
who
would
prefer
the
other
agree
that
it's
stylistic
and
that
they're
not
willing
to
hold
up
the
process.
B
Do
we
know
of
any
graphql
specs
that
actually
have
doubly
nested
lists,
graphql
schemas,
sorry.
J
A
G
It's
like
it's
gotta,
be
like
log
100
or
something
it's
like.
The
number
of
double
nested
lists
compared
to
the
number
of
lists
is
like
log,
one
turns
with
the
first
one.
Similarly,
so
for
triplets,
it's
like
quad
nested
lists
like
technically
can
exist,
but
there
may
be
like
one
of
them
in
like
a
test
case
somewhere
and
like
that's
the
limit
and
like
that's
just
the
ones
that
exist,
let
alone
the
ones
that
you're
forcing
nullability
changing
rules
on.
G
I
I
think,
like
a
single
like
the
most
important,
is
the
ability
to
say
I
understand
the
difference
between
enforcing
the
null
ability
of
the
thing
inside
a
list
versus
an
older
thing
outside
a
list
and
for
that
syntax
to
at
least
be
able
to
extend
like
it
must
support
nested
lists.
It
doesn't
necessarily
have
to
be
beautiful
and
nested
lists,
because
that
is
not
a
common
case,
but
a
list
and
then
being
able
to
address
the
thing
inside
the
list
and
the
list
itself
separately
is
more
likely
to
be
a
case.
N
It
was
a
big
disagreement
for
one
time,
so
I
am
not
sure
what,
if
something
is,
if
something
is
like
it's
not
if,
like
it's
hard
to
resolve
the
respect
to
solution,
is
awake,
have
a
separate
discussion
for
that,
because
it's
easier
for
people
to
discuss
and
if
not,
we
can
have
like
a
short
call.
I
don't
think
it's
like
as
big
as
input
unions,
but
in
case
of
input
units
it
helped
them
move
it
forward.
N
N
Why
why
I
want
to
resolve
like
it?
I
think
because
it's
like
it's
a
new
ic
node
and
I
still
knows-
can
have
directives
so
another
potential
cool
thing.
If
we
stick
with
square
braces,
we
can
now
allow
directives,
so
we
can
allow
directives
to
be
applied
on
so
imagine
if
we
decide
to
make
a
bank
as
a
directive
and
right
now,
we
cannot
apply
it
arrays
deeper.
But
if
we
introduce
field
name
and
set
of
square
braces,
you
can
specify
you
can
apply
directive
not
on
field
itself,
but
on
some
of
the
national
lists.
G
What
also
might
help
alex
is
just
to
open
some
github
discussions
around
the
remaining
the
remaining
open
issues
around
this.
I
think,
like
part
of
what
makes
this
a
bit
challenging,
is
that
you've
got
you've,
got
everything
sort
of
threaded
in
one
big
roc
list,
and
it's
just.
G
There
are
sort
of
multiple
threads
of
discussion
happening
now
and
it's
it's
hard
for
people
to
keep
up
or
to
understand
like
what
the
state
of
each
one
of
them
is,
which
makes
the
whole
thing
kind
of
feel
ambiguously
in
limbo,
which
it
doesn't
feel
good
in
terms
of
advancing
this.
So
my
like
just
practical
advice
that
you
can
do,
especially
if
you're
blocked
on
other
things,
is
just
to
get
like
a
thread
open
for
each
of
the
major
remaining
pieces.
It
seems,
like
you,
have
a
couple.
G
One
of
them
is
getting
an
implementation
done
behind
an
experimental
flag,
and
it's
just
like
okay,
what
are
the
blocker
like
what
that
should
not
be
blocked
on
any
spec
discussion,
because
the
whole
point
of
that
is
to
get
something
down
that
you
can
play
with
and
and
be
able
to
write
test
cases
around
things
when
people
have
issues
and
that
that
seems
expressly
useful.
G
A
second
one
is
making
sure
the
syntax
is
right.
I
think
getting
the
list
one
or
just
like
exploring
the
options
and
narrowing
it
down
and
then
the
last
one
is
the
relay
team
and
joe
in
particular,
giving
giving
some
feedback
around
the
semantics,
and
I
know
even
beyond
that.
There's
just
been
some
open
questions
around.
G
You
know
it
does
a
question
mark
act
as
an
air
boundary
versus,
as
as
a
making
something
nullable
and
like
these
all
feel
interrelated.
To
me
and
there's
a
larger
problem
at
play
and
just
to
kind
of
stick,
my
one
and
a
half
cents
in
there
is.
G
So
I
think
we
like
we
owe
exploring
that
space
more
clearly,
we
might
end
up
with
something
that's
that's
like
halfway
to
where
we
want
to
be.
I
think
joe's
feedback
pointed
out
that
you
know
the
the
proposal
that
that
he
and
matt
are
putting
up
is
probably
an
important
step
in
the
the
direction
of
getting
to
a
complete
state.
Where
really
can
start
to
remove
some
of
their
compiler
steps
and
rely
on
vanilla
graphql.
G
I
I
don't
know
if
your
proposal
alone
will
get
us
there,
because
of
that,
but
at
least
feeling
like
we
have
the
right
stacked
up
set
of
things
that
each
independently
feel
good
and
then
in
aggregate
feel
like
it's
going
to
solve
the
problems
in
a
way
that
everyone
agrees.
Is
the
right
thing
to
do
that
feels
like
there's
just
we
need
to
have
some
discussion
on
that
and
having
a
space
where
we
can
know
what
we're
talking
about
it's
not
about
the
entire
spec.
G
It's
like
specifically
about
like
the
semantics
of
throwing
and
catching
errors,
will
be
pretty
helpful.
J
Yeah,
I
think
so,
yeah
the
the
single
threaded
thing
is
it's
becoming
wieldy.
It's
not
good.
A
Erupted
also,
or
something
like
that,
like
at
this,
like
discussion
with
multiple
threats
on
github
on
his
ribbon,
it
was
different
stream.
It
was
really
good.
J
I
agreed,
I
think,
that's
everything
I
had
yeah
like
I
said
in
the
in
the
in
the
last
meeting
work
on
this,
for
me
is
gonna
slow
down.
I
gotta
do
some
other
projects
at
work,
but
but
I'm
gonna,
I'm
gonna,
keep
working
at
it.
G
That's
good
to
know,
I
I
think
that's
probably
gonna
work
out
well.
Actually,
I
think
my
sense
is
the
next
phase
for
this.
It's
like
we've
gotten
through
the
initial
exploratory.
This
is
an
exciting
idea.
Everyone
wants
to
see
done
and
we've
gotten
to
the
common
but
frustrating
phase
of
noodling
out
the
exact
semantics
and
and
getting
broad
consensus
that
they're
the
right
ones,
and
that
often
takes
time-
and
it
in
part
of
the
reason
why
it
takes
time
is
that
everyone
needs
to
really
consume.
G
What's
going
on
and
provide
meaningful
feedback,
that's
not
just
like
off
the
cuff,
but
actually
like
factors
in
all
the
context,
and
that
takes
time
so
in
advance.
I
appreciate
your
your
patience
with
that
process.
Hopefully
it
won't
take
forever,
I'm
very
excited
about
seeing
this
one
through.
I
think
this
is
I've
said
it
before,
but
this
is
one
of
the
proposals
I've
been
most
excited
about
in
recent
years,
so
I
think
probably
most
people
would
agree.
G
J
Yeah
for
sure
I'm
can't
wait
to
get
it
get
emerged,
get
to
use
it.
It's
gonna
be
awesome.
M
I
added
a
note
at
the
end
of
my
comment,
but
I
wanted
to
like
kind
of
say
in
person
like
I
know
it
must
be
like
really
frustrating
to
get
like
some
of
the
pushback,
but
I
I
feel
like
this
is
kind
of
really
like
tugging
at
a
like
a
thread
like
a
loose
thread
in
the
design
of
graphql,
where
it's
like,
okay,
client
specified
nullability
is
problematic
because
we
haven't
really
fundamentally
figured
out
the
issues
with
fragments
and
then,
if
you
figure
out
the
issues
with
fragments
that
leads
you
to
like,
oh
well.
M
Actually
the
response
model
is
wrong
and
oh,
and
also
to
fix
the
response
model.
You
need
to
figure
out
the
fact
that
actually,
we
need
object,
identity,
and
so
it's
like
this
long
list
of
things
that
actually
has
to
get
sorted
out
that
are
just
like
missing
and
underspecified
in
graphql
and
and
it's
like.
So
I
think
what
I
suspect
might
happen
is
that
what
this
is
like
just
a
like,
we
all
want.
J
Yeah
we
can
be
super
trying
to
go
to
the
process
with
you.
We
can
talk
more
in
the
in
the
in
the
pr,
but
I
wanted
to
ask
if,
like
there's
this
whole
chain
of
issues,
do
you
do
you
feel
like
they
need
to
be
solved?
You
know
we
need
to
solve.
I
forgot
what
the
last
one
was
on.
The
end.
Object,
identity
or
something
and
inward
or
or
like,
is-
is
client-controlled
nullability
untenable
until
the
fragments
issue
is
fixed.
M
I
don't
know
I
think
like
there
may
be
like,
and
that's
why
I
was
trying
to
express,
like
at
least
like
give
some
some
ideas
of
like
what
we
might
do,
that
like
mitigates,
the
the
concerning
challenges.
I
I
think
we
still
need
to
like
just
work
through
is
is
a
like
variant
of
the
proposal
like
because
what
I'm
really
concerned
about
is
basically
bubbling
past
fragment
boundaries
right
in
a
way
that,
like
just
kind
of
causes,
the
too
much
of
the
the
result
to
get
milled
out.
M
If
we
can
find
a
reasonable
way
to
that,
not
be
the
default
that
doesn't
require
fragment
like
fully
solving
fragment
modularity.
That
would
be
a
great
outcome,
and
so
we
should
try
to
figure
that
out
so
that
we
don't
have
to
like
couple
everything
together.
Yeah.
G
This
is
also
kind
of
what
I
was
hinting
at
before.
I
think
I
I
don't
want
to,
or
I'd
like
to
avoid
a
state
where
we
have
to
solve
all
of
these
in
order,
because
we've
we've
already
taken
a
couple
of
cracks
at
these
problems
before
and
and
and
not
made
the
progress
that
we
wanted
to
make,
and
that's
not
to
say
that
they're
not
solvable.
G
I
think
that
they
probably
are,
but
I
expect
that
they
could
take
a
number
of
additional
cracks
at
them
until
we
finally
figure
it
out
and
and
if
there's
a
bunch
of
downstream
things
that
we
just
can't
do,
because
we
can't
solve
those
first
that
that's,
of
course,
going
to
be
frustrating
and
therefore
something
we
should
avoid.
If
possible.
G
An
outcome
that
I
would
like
to
land
on
is
one
where
we
understand
enough
of
the
design
space
of
those
other
problems
such
that
we
have
confidence,
that
the
thing
that
we
are
advancing
and
putting
into
the
spec
does
not
preclude
exploring
that
space
and
that
space
will
compose
well
with
this.
So,
for
example,
you
know
joe's
motivation
here,
which
is
a
very
reasonable
one.
Is
to
have
all
these
pieces
together
such
that
you
can
provide
client
controlled
nullability
with
modular
fragments
included.
G
There's
joe
and
matt
are
introducing
a
proposal
about
modular
fragments
right,
like
what
I
see
is.
Can
we
end
up
with
something
that
both
syntactically
and
semantically
naturally
extend
to
not
just
like
one
specific
version
of
what
they're
proposing
but,
like
the
whole
design
space
like
we
don't
end
up
with
something
like
up
now
that
we've
landed,
this
we've
ruled
out
the
ability
to
to
extend
to
this
to
modular
fragments.
That
would
be
a
no-go.
G
That
means
that
we
could
end
up
in
a
state
where
you
know
maybe
the
syntax
could
be
consumed
by
relay,
but
they
wouldn't
omit
the
syntax
directly
through
to
a
server.
They
would
still
parse
it
and
do
something
unique
with
it
in
the
same
way
that
they're
doing
without
required-
and
maybe
that's
an
incremental
value.
But
you
know
it's
clearly
not
going
to
be
acceptable
to
for
relay
to
take
on
some
change
which
just
breaks
its
core
functionality
that
that's
not
going
to
work.
G
But
that's
why
I'm
saying
like
there's
just
a
bunch
of
design
space
here,
that
we
need
to
go
explore
and
I
think
our
shared
goal
should
be
to
unlink
these,
to
the
degree
that
we
can
such
that
we
can
advance
the
ones
that
are
ready
and
know
that
they're
that
they
will
eventually
compose
together
and
link
up
once
we
have
them
all.
It's
gonna
be
tough,
but
I
think
that's
that's.
What
I'd
like
to
see.
G
J
G
Good
thanks
again
for
your
hard
work
on
this,
alex
always
exciting
to
see
progress,
and
even
though
you're
blocked
sometimes
sounds
like.
We
do
actually
have
good
next
steps
here
for
sure
all
right
handing
it
to
yvonne
to
talk
about
director
directives.
N
N
First,
the
spark
itself
started
relying
on
directives
more
and
more
so
we
have
like
specified
by.
We
have
deprecated
and
directives
and
it
looks
like
directives
is
a
way
forward,
not
overcomplicated
syntax,
but
it
creates
a
precedent
when
you
cannot
use
directives,
you
you
cannot
duplicate
the
directive
or
you
cannot
like,
for
example,
in
a
pause
specifically
for
federation.
For
other
use
cases.
N
There
is
a
mechanism
to
attach
url
to
directives
and
it's
very
similar
to
specify
by
so
it
would
be
cool
to
have
like
a
way
to
attach
or
specify
by
two
directives,
and
it's
like
there
is
use
case
for
that
it
would
be
greater
standardized
in
word,
but
it's
such
a
bigger
issue,
basically
like
we
can
we
create
new
mechanisms
which
is
not
appliable
in
directives,
and
one
of
the
reason
I
was
supposing
to
there
is
like
kind
of
like
big
problem
with
directives.
N
It's
it's
very
easy
to
validate
directives
inside
queries
because,
like
schema,
is
built
already,
types
is
known,
but
it's
very
hard
to
validate
directives
inside
the
sdl.
N
So
imagine
you
have
directive
definition
inside
this
deal
and
it's
applied
on
a
type
inside
the
same
as
deal
so
it's
happened,
people
defining
directives
and
using
them
in
the
same
file.
So
it's
hard
to
well.
Actually
we
don't
have
validation
in
graphql.js
for
that
right
now,
but
after
reading
the
spec,
I
discovered
that
we
already
paid
the
price.
N
N
N
N
It's
like
directive
side
in
the
end
of
scour
definition,
so
it's
kind
of
fit
spec,
but
before
I
invest
like
more
time
into
like
spec
prs
for
like
alien
exist,
validations
that
we
already
have
on
spec
and
haven't
expected
for
that
one.
I
want
to
hear
a
general
opinion
on
directives
and
directives.
N
Because
in
in
this
issue,
people
discussing
like,
should
we
have
with
validation
limitation
or
not,
I
think
it's
beyond
my
proposal.
It's
already
existing,
I'm
not
proposing
I'm
actually
for
keeping
it.
What
I'm
interested
in
hearing
feedback
for
is
like,
should
we
allow
directives
on
directives.
P
I
have
one
question
regarding
that:
are
we
talking
about
the
high
order
directives,
as
I
understand
kind
of
directives
that
are
played
in
other
directives,
but,
for
example,
if
we
have
some
kind
of
a
list
of
directives,
I
can
at
least
different
directives
to
same
field,
for
example,
how
I.
I
I
P
N
Yeah,
it's
like
you
can
imagine
with
directives.
I
see
more,
can
be
treated
similar
to
decorators
and
most
programming
languages,
decorators
functions
and
you
can
apply
decorators
on
function
itself.
So
it's
not
like
creating
high
order
directive.
It's
like
directly
on
the
same
layer.
You
just
like
you
apply
directive
to
definition,
I'm
I'm
worried
about
stuff
like
duplicating
the
directory,
for
example.
It's
good
example.
N
It's
exposed
to
clients
you
can
like
figure
out
like
you,
don't
want
to
support
it
anymore.
You
want
to
put
duplication
and
you
don't
have
any
good
syntax
for
that.
I
G
We
didn't
always
have
the
ability
to
deprecate
things
within
the
the
other
than
fields.
So,
as
that's
been
expanding,
it
makes
sense
to
expand
it
here
too
yeah,
I
think,
like
the
original
intent
on
not
allowing
directive
directives
was
one
to
avoid
the
recursion
problem
which
exists
now
now
that
we
have
reused
argument
definitions
which
the
arguments
themselves
can
have
can
have
a
directive
or
you
know
nested
within.
G
So
the
fact
that
we
don't
have
an
implementation
for
that
validation
rule
seems
not
great,
and
I
think
this
comes
from
you
know.
Our
validation
of
of
queries
has
always
been
very
good
that
that
code
is,
you
know,
predates
open
source.
Validation
for
schemas
has
always
been
kind
of
plain
catch
up,
and
this
seems
like
one
that
it's
that
it
hasn't
been
implemented.
Yet
one
thing
that
I'd
like
to
know
is
like
just
how
how
challenging
it
is
to
implement
that.
Hopefully,
it's
not
too
bad.
G
It's
a
tree
crawl,
but
if
it's
really,
you
know
part
part
of
the
intent
here
was
to
avoid
having
to
ask
implementers
to
put
in
particularly
complicated
stuff
like
that,
if
you
find
that
it
ends
up
being
not
too
hard
to
implement,
then
that's
maybe
an
argument,
but
that's
not
not
enough
cost
to
keep
it
up,
but
the
other
one
was
confusion.
I
think
even
just
the
you're
looking
at
saying
like
where
would
you
even
put
a
directive
on
the
directive
to
not
end
up
with
something
that
looks
really
confusing?
G
G
But
yeah
that's
at
least
some
historical
context
for
why
we
haven't
had
this
up
until
this
point,
I'm
not
necessarily
opposed.
I
think
we
got
to
get
the
details
right.
N
N
I
Yeah
so
one
point
on
just
like
the
location
getting
kind
of
to
the
confusion.
This
could
be
confusing
is,
for
I
know,
union
type
definitions
have
a
very
similar
syntax
to
directive
definitions
with
the
line
or
bar
whatever
to
separate
things
that
the
types
in
the
same
way
that
the
directive
definition
uses
it
to
separate
locations
and
the
union
type
definition
puts
the
directive
right
after
the
name
which.
I
N
So
if
it's
like
at
full,
it's
like
a
part
of
definition.
If
it's
at
deprecated,
it's
like
duplication
for
directive
with
something,
and
we
in
that
case
we
can
put
it
after
immediately
after
name
because
the
problem
with
why
I
didn't
put
it
after
name
because,
like
arguments
are
optional
and
it
would
be
at
full
at
bar,
so
it
would
be
like
by
confusion.
B
G
I
only
want
to
add
more
punctuation
if
it's
solving
a
language
conflict
issue.
It's
like
you
need
to
read
one
versus
two
s
to
disambiguate
but
like
if
we
got
ourselves
so
far
down
the
syntax
rabbit
hole
that
we
need
to
disambiguate
with
extra
punctuation.
Then
we've
probably
probably
already
failed
to
help
people
understand
what
it
is
we're
doing.
K
Yeah
I
wanted
to
ask
like
is
this:
this
need
for
specifying
directives
on
directives
in
general
or
for
this
use
case
the
deprecated
directive
like
because
I
like
right
now.
I
had
the
idea
that,
for
example,
in
js
stock,
you
also
have
like
this
at
deprecated,
but
instead
of
having
it
as
like
a
language
feature.
It's
more
like
a
comment
in
the
document
string
that
you
write
in
front
of
your
function
or
your
property
or
whatever,
and
I
know
it's
a
crazy
idea
and
we
already
have
the
at
directive.
K
I
It
wouldn't
be
that
big
breaking
change,
because
we
already
have
repeatable
on
the
directive
definition
if
we
put
deprecated
right
after
repeatable
as
an
optional
and
like
made
like
we
could
make
deprecated
a
more
first-class
thing
potentially,
but
no
no.
N
I
want
to
have
like
a
more
more
generic
mechanism
because,
like
a
power
use
course
park
and
like
without
without
directives
and
directors,
we
cannot
even
start
conversation
of
of
like
specified
bio
derivatives
and
so
wait.
We
have
two
use
cases
and
expect
like
in
the
year
somebody
proposed
some
feature
and
we
introduced
like
a
third
directive
based
on
progression.
I
think,
like
more
and
more
features,
we
add
into
spike
will
be
directives
instead
of
syntax
like
caffeine.
Crusher
right
now
is
like
50
50.
or
something
for
choirs.
N
We
don't
add
new
syntax
at
all,
except
like
triple
quotation
and
like
not
a
force,
no
ability,
but
for
a
year
it
was
like
50
50.
repeatable
on
versus,
like
deprecated,
on
more
stuff
specified
by.
So
for
me,
it's
like
generic
issue
of
of.
If
we
use
the
same
one
mechanism
on
on
everything
else
or
other
definitions,
I
would
like
to
use
the
same
features
and
same
mechanism.
Directors.
G
I
think
you
probably
need
to
explore
the
syntax
a
little
bit
more,
but
I
certainly
I
think
that
the
staging
of
this
makes
sense
for
you.
You
know.
First,
you
gotta
make
sure
that
that
so.
N
Based
on
this
place,
like
basically,
I
wanted
consensus
that
it's
something
worth
exploring
right
and
people
cancer
and
I
get
like
with
feedback.
So
thanks
about
this
and
wait
about
staging,
can
I
move
it
stage,
one
to
kind
of
like
start
working
on
pr
and
full
procedures.
G
G
Sounds
like
there's
plenty
of
open
questions.
You've
got
some
good
feedback
on
the
thread,
but
let
this
discussion
be
a
good
reminder
for
anyone
interested
in
this
to
go.
Take
a
look.
G
G
We
have
15
minutes
left
and
two
20-minute
topics
left
so
before
we
move
forward.
Let's
just
have
a
quick
meta
discussion
of
how
we
want
to
proceed.
I
think
we
likely
only
have
time
for
one
of
the
last
two
topics
and
the
other
we'll
have
to
wait
and
talk
about
in
the
next
meeting,
which
of
these
is
gonna,
be
more
pressing
or
is
more
willing
to
wait
until
next
month.
G
Sure,
let's
do
that
rob
will
let
you
go
through
one
of
your
bullet
points,
we'll
we'll
haul
conversation
and
do
conversation
async
just
to
save
some
time
for
stephen
and
then
whatever
we
miss
we'll
pick
back
up
and
next
so
go
ahead.
Rob.
E
Yeah,
so
we
talked
about
this
briefly
in
the
last
meeting,
and
this
is
what
happens
when
you
have
multiple
mutations
in
the
same
operation
right
now,
the
entire
first
tree
gets
executed
before
the
second
one
starts.
What
happens
if
you
have
a
defer
somewhere
nesting
under
here?
E
The
one
thing
that
I
think
everyone
agreed
on
was
that
we
should
not
allow
deferring
the
actual
mutation
field
at
the
root
level
of
the
operation,
so
I've
implemented
that
and
put
it
in
the
spec
draft,
but
otherwise
I
guess
I
just
kind
of
want
to
get
consensus
that
we're
okay
with
what's
listed
here
is
option
two
lee
you
had
said
last
week
that
that's
generally,
what
you
felt
like
was
the
right
option.
A
E
Right
so
I
think
what
we
would
be
saying
is
that,
by
putting
defer
somewhere
in
there,
you're
opting
into
that
being
a
possibility.
G
Yeah,
I
think,
like
another
calling
back
to
our
previous
conversation
around
the
list.
Nullability.
I
think
it's
it's
helpful
for
us
to
be
really
practical
about
the
ramifications
of
this
right.
So
like
option
one,
is
you
essentially
ignore
different
stream
directives?
G
Oh
I
see
you
said
on
all,
but
the
last
mutation
like
even
that
is
like
you,
get
inconsistency
between
whether
they'd
be
followed
or
not,
based
on
where
they're
located
in
the
query.
I
don't
love
that
but
like
even
if
you
decided
to
go
with
some
version
of
option,
one
that
just
you
know
say
like
hey.
We
can't
make
these
guarantees
so
we're
just
gonna
not
do
different
stream.
G
I
suspect
99.999
of
mutations
are
on
a
single
field
and
maybe
that'll
expand
in
the
future.
There
have
been
some
proposals
about
nested
mutations
and
grouped
mutations,
but
certainly
the
the
vast
majority
now
favor
a
single
mutation
per
per
query,
in
which
case
you
know
like
this
whole
conversation
is
kind
of
in
the
weeds.
G
You
know
most
people
are
not
going
to
see
it
and
and
option
two
sort
of
like
captures
that
I
think
somewhat
reasonably
so
it
it
could
be
that
in
the
future,
if
there
are
some
change
to
how
we
do
mutations,
if
we
do
nested
mutations
or
groups
mutations
or
some
of
these
other
proposals
and
then
those
things
come
after
the
fur
and
work
has
completed,
we
may
revisit
some
of
the
semantics
of
deferred
stream
in
the
context
of
those
things.
G
E
All
right
so
I'll
move
forward
with
making
sure
that
it's
adequately
described
in
the
spec
draft.
It's
already
what
the
js
implementation
is
doing.
E
E
Yeah,
the
second
issue
I
was
going
to
discuss
was
about
non-null
fields,
but
I'll.
So
if
anyone
else
would
like
to
look
at
this
discussion
for
the
next
meeting,
we
can
talk
about
it
more
than
I'll
put
in
the
chat.
G
Sounds
good
yeah
thank
you
for
breaking
these
out
into
discussions
and
in
their
own
space.
G
That
is
super
helpful
for
helping
people
dig
through
these
so
yeah
in
the
last
minute,
before
we
move
on
to
stephen
just
to
call
for
action
for
folks
to
go,
take
a
look
at
not
just
these
discussions
but
rob's
whole
repo
is
doing
a
great
job
of
categorizing.
Through
all
the
remaining
open
questions,
all
right,
stephen.
You
get
10
minutes
instead
of
20..
Hopefully
that's
enough
to
talk
about
deprecation
of
input,
values.
H
All
right
good,
thank
you
lee,
so
so
yeah
for
today
a
goal
would
be
getting.
You
know
this
is
a
stage
two
rfc,
and
so
if
we
can
get
concrete
action
items
to
stage
three
first,
let
me
give
just
a
bit
of
context.
What
we're
talking
about
here,
one
of
graphql
strengths,
is
excellent.
H
Support
for
living,
evolving
apis
and
one
of
the
graphql
features
that
helps
api's
evolve
is
first
class
support
for
a
deprecation
flow,
and
now
the
spec
allows
deprecated
directive
on
output
fields
and
enum
values,
but
not
on
arguments
or
input
object
fields
today,
but
it
has
been
proposed
as
early
as
2016
to
extend
deprecated
to
apply
to
inputs
and
the
idea
of
supporting
deprecation
inputs.
It
hasn't
been
particularly
controversial.
I
don't
think,
but,
as
always,
the
devil
is
in
the
details,
and
so
that
brings
us
to
today.
H
There
is
a
pr
in
the
spec
that
has
reached
rc
stage
two.
So
it's
a
draft
and
it's
linked
here
and
this
has
been
implemented
in
graphql,
js
and
and
others
as
well.
Graphql
java,
there's
there's
one
main
outline
question
that
came
up
last
time.
H
This
was
discussed,
and-
and
that
is
the
detail
of
whether
to
permit
marking
required
arguments
and
in
required
input
fields
as
deprecated
and
by
required
we're
saying
non-null
and
without
a
default
value,
and-
and
so
you
know
in
previous
discussion
we
were
talking
about.
This-
should
be
at
least
discouraged
in
the
spec,
but
possibly
disallowed
entirely.
H
And
so
I
I've
submitted
a
pr
on
this
rfc
to
to
make
this
a
should
and
two
main
reasons
for
that
is
that
the
graphql
spec
recommends
hiding
things
that
are
deprecated,
and
so
it
would
make
for
a
confused
confusing
experience
for
for
clients
to
have
a
required
field
that
is
hidden
and
and
then
also.
H
The
other
reason
is
that
it
you
know
if
we
were
to
change
our
mind,
it
would
be,
you
know
a
non-breaking
change
to
relax
the
spec
from
must
to
should,
but
doing
the
inverse
would
potentially
be
breaking
of
apis
in
the
field.
H
So
then,
for
for
today,
for
our
last
eight
minutes,
there's
you
know
is
is:
is
this
controversial
to
to
go
ahead
and
move
forward
with,
must
and
and
then
also
you
know
what
what
what
is
lacking
to
to
get
us
to
stage
three.
G
I'm
trying
to
page
back
into
my
brain
everything
it's
been
a
while,
since
we
talked
about
this
topic.
Do
you
remember
if
there
were
any
other
open
issues
or
open
questions
around
deprecating
input
values?
Aside
from
this
one
that
you
just
talked
about.
H
See
that
was
the
main
thing,
or
at
least
the
kind
of
the
last
thing
there
had
been
some
others.
Let
me
look
back
at
the
I've,
also
linked
notes
from
previous
discussion
18
months
ago.
Here.
N
Yeah,
I
can
provide
context
on
what
initially
it
was
proposed.
I
forget
who
was
initial
champion
when
I
helped
to
move
it.
It
was
merged
into
graphql
s
with,
I
think,
like
as
non-native
speaker,
I'm
not
sure,
like
the
understands
how
different
between
must
and
should,
but
it's
required
in
graphql
js.
N
Moreover,
it's
like
validated
and
nobody
objected,
and
it's
much
for
16
months,
it's
like
was
marched
one
before
typescript
conversion.
It
was
in,
I
send
a
git
blame
and,
like
the
whole
thing,
was
merged
and
like
this
particular
validation
was
merged
like
because
we
had
consensus
on
working
group
six
and
one.
N
N
G
N
Yeah
one
asterisk
wait:
it's
historical
but
graphical
previously
before
except
xss
vulnerability.
It
wouldn't
perform
like
validation
of
a
schema,
so
like
graphical
enforce,
with
this
restriction
only
for
like
a
couple
of
months-
and
I
also
hope,
like
anybody
object,
so
I
think
like
and
people
I
think,
start
using
deprecation
on
arguments.
So
I
think
it's
enough
time.
G
I
don't
know
how
we
missed
that
we
got
this
merged
and
out,
but
we're
just
like
behind
on
the
spec
text.
I
guess:
okay,
yeah
stephen.
H
Yeah,
I
remember
the
the
other
outlying
question
not
really
outlying,
but
was
whether
to
possibly
invert
the
introspection
default
to
include
deprecated
inputs.
But
you
know
once
once
again
the
the
you
know
the
non-inverted
behavior
is
implemented
in
graphql
js
and
you
know
apparently
hasn't
been
controversial.
Non-Inverted
sorry
help
me
remember
the
converted
non-verbal
symmetric,
so
so
meaning
by
default.
Do
you
include
deprecated
input,
arguments
and-
and
I
believe
correctly
from
wrong
yvonne
that
we
went
with
by
default.
They're
not
included
the
same
as
other
deprecated.
N
E
N
It
was
also
fixed
a
year
ago
or
something
cool.
G
Yeah,
I
think
the
behavior
that
we
have
seems
like
the
right
one,
because
the
principle
there
is
you
should
be
able
to
write
an
introspection
query
and
if
you
never
include
the
phrase
include
deprecated
anywhere
in
your
introspection.
Query
you'll
only
ever
get
back,
non-deprecated
schema,
and
so
that
principle
would
be
applied
here
if
we
are
doing
the
not
inverted
behavior
which
it
sounds
like
it's
what
is
implemented.
G
So
in
terms
of
your
question
and
next
steps
to
get
to
stage
three
approved,
it's
a
let's
make
sure
we
do
a
double
check
on
the
reference
implementation
and
like
actually
would
be
the
most
helpful.
So
we
could
pull
links
to
the
unit
tests
that
assert
the
behavior
that
we
have
described
in
the
spec,
because
then,
when
we,
you
know,
publish
it
to
stage
three
and
approved,
we
can
say
like
look
right
here.
There's
here's
the
part
in
the
code
that
you
can
go
read
that
implements
these
things.
G
That
would
be
super
helpful
for
people
who
are
following
along
and
then
the
other
to
do
to
get
to
stage.
Three
is
the
getting
the
spec
text
in
a
final
form
for
editorial
review.
G
H
Sounds
good
so
we'll
go
ahead
and
merge
the
pr
on
the
pr
and
then
then
we
do
final
review
on
the
spec
text
and
and
I'll
take
that
that
first
action
item,
if
yvonne,
you
could
help
me
out
with
with
gathering
those.
You
know
the
links
to
those
particular
unit
tests.
N
G
G
A
very
long
list
of
of
topics
today,
even
though
we
had
to
cut
a
couple
of
them
a
little
shorter
than
we
would
like.
That's
means
more
to
discuss
async
between
now
and
the
next
one,
and
certainly
some
agendas
for
us
to
pick
up
next
time.
Thank
you
all
for
all
your
hard
work.
It's
really
super
exciting,
to
see
just
how
many
things
are
in
flight
right
now.
G
I
think,
even
if
you
just
compare
kind
of
the
status
of
where
we
are
now
to
this
time
last
year,
we're
like
probably
working
on
twice
as
many
things
now
as
we
were
then-
and
that
was
just
a
year
ago,
let
alone
when
this
working
group
first
started,
and
I
think
for
now
on
you're
five,
four
five
for
this
freaking
group,
one
when
was
the
what's
our
oldest
agenda
in
the
file
2017,
so
almost
five
years
since
the
first
of
these.
That's
that's
pretty
amazing!
G
So
thanks
everybody
for
the
hard
work
that
you
do,
and
I
hope
you
all
have
a
great
2022
and
see
you
all
next
month.