►
From YouTube: SES Meeting: Bulk Proxy Revocation
Description
This week we discuss Alex Vincent’s proposal for mass proxy revocation, including Bradley Farias’s development on that proposal using revocation controller and signal pairs.
A
B
Okay,
so,
following
up
on
last
week's
discussion
at
the
end
of
the
meeting,
I
suggested
maybe
it's
time
to
bring
about
a
new
argument
to
proxy
that
revocable
and
maybe
the
new
proxy,
but
I
haven't
decided
that
whether
we
should
do
that
or
not
actually,
we
haven't
decided
to
suggest
that
the
third
argument
could
be
a
structure
or
an
api
for
doing
revocations
of
proxies
as
a
group.
Basically,
my
idea
here
is
have
a
top
level
maker
function.
B
I'm
sorry
a
maker
function
off
of
proxy,
which
I'm
temporarily
calling
revoker
set
and
the
idea
being
you
can
add
a
bunch.
You
can
add
a
when
you're
creating
a
proxy.
You
can
add
it
to
a
bunch
of
revoker
sets
or
revocation
signals
as
bradley
has
suggested,
and
when
you
want
to
revoke
you
send
a
revoked
call
to
the
set
or
one
of
the
sets
that
the
proxy
belongs
to
and
bang
is
gone
so
just
to
walk
through
the
api.
B
Here
I
imagined
proxy
that
revoker
set
would
provide
this
revoker
set
object,
which
had
only
one
public
method,
a
revoked
method,
and
then
you
could
pass
in
as
many
revoker
sets.
As
you
wanted
to
proxy.revocable
as
a
third
argument,
if
tc39
doesn't
allow
that
third
argument,
we
could
ask
them
to
provide
a
an
alternative
method
for
creating
proxies,
which
at
least
here
I'm
calling
revocable
in
sets
bad
name,
but
what
I
haven't
got
anything
better
and
then
I
have
an
example
here
where
we
have
three
revokers
revoker
sets
the
third
being
a
shadow
realm.
B
The
simple
idea
there
is
well,
we
were
thinking
about
having
shadow
realms,
have
a
revoked.
This
is
coming
from
mark's,
original
idea
and
saying.
Okay,
if
we
can
have
proxies
in
the
shadow
realm
might
as
well
make
that
irrevocable
set,
as
well,
so
to
dive
in
just
a
bit
more
here's
a
diagram
that
I
had
created
for
other
purposes,
where
I'm
trying
to
illustrate
what
the
proxies
look
like
when
it
where
each
realm
is
a
plane
on
this
graph
and
the
proxies
themselves
are
hemispheres.
B
B
Excuse
me
the
proxies
that
connect
to
it.
So
when
you
revoke
the
yellow
realm,
the
proxies
for
on
load
on
that
third
column
to
the
right,
they
don't
know
that
the
on
load
is
dead.
At
that
point,
the
the
onload
original
value
so
with
a
revoker
set
tied
to
the
realm
one
for
the
blue
realm
one
for
the
yellow
realm
one
for
the
green
realm.
B
B
C
B
B
C
B
And
that's
a
per
that's
actually
a
really
good
argument
for
bradley's
proposal,
which
again
I
hadn't
considered
that
when
I
wrote
this
up-
and
I
didn't
really
realize
that
that
was
going
to
be
a
potential
problem,
give
me
a
couple
minutes
to
finish
my
presentation
and
then
and
then
I'd
like
to
hand
it
off
to
bradley.
Please
a
few
open
questions
that
I
came
up
with
while
thinking
about
this,
if
you're
looking
at
the
proxy
constructor,
not
proxy.revocable,
but
the
constructor
itself,
there's
basically
there's
two
arguments
for
both
of
those.
B
B
A
There's
an
interesting
thing
that
you
point
out
there,
because
if
a
revocable
set
or
an
array
of
replicability
sets
were
added
as
an
argument
to
the
proxy
constructor
making
any
proxy
revocable
without
really
without
it
would
in
a
way
that
is
not
backward
incompatible,
it
would
be
a
backward
compatible
change
to
the
proxy
constructor
that
would
introduce
revocability
to
the
proxy
itself.
That
would
sort
of
imply
that
proxy
dot,
revoke
revocable
itself
is
superfluous
and
was
a
design
mistake,
which
is
an
interesting,
interesting
shadow
effect
of
it.
E
Yeah,
so
I
would
say
it's
not
so
much
I
mean
so.
The
the
specific
api
design
for
proxy.replicable
would
in
retrospect
either
be
a
mistake
or
be
something
that
could
be
seen
as
syntactic
sugar
particularly
use
pattern
of
the
new
api
to
say
that
the
api
design
could
have
been
a
mistake,
but
proxy
dot
revocable
altogether.
B
My
my
mine
is
just
this
bare
bones
start
the
conversation
document
anyway,
so
I'm
perfectly
fine
with
it,
and
I
should
mention
to
the
group.
I
did
review
bradley's
proposal.
I
thought
it
was
perfectly
fine
from
a
workability
standpoint,
so
my
other
comments
were
between
him
and
me
and
basically
I
think
if
he
wants
to.
If
we
want
to
go
with
israel,
I'm
fine
with
it.
D
D
D
But
yeah,
basically,
you
could
have
a
convenience
method
or
something
there.
Signals
are
interesting
because
you
can
have
multiple
kinds
of
combinators
just
like
promises.
You
could
wait
for
every
all.
The
revocation
signals
to
hit
any
of
them
to
hit
or
other
criteria
doesn't
really
matter.
So
it's
just
to
know
here
we
could
have
like
revocation
signal
dot
any
just
like
promise
dot
any
or
race
or
whatever.
D
D
D
Similar
in
to
how
proxy
dot
revocable
works,
you
get
a
revoke
thing.
You
get
a
signal
here,
instead
of
the
actual
proxy
to
work
with
so
simple.
The
key
important
part
here
is
at
least
when
we've
been
designing
some
stuff
with
a
board
controller.
You
don't
want
to
pass
the
notification
system
around
and
have
that
notification
system
grant
people
the
ability
to
revoke
your
stuff.
You
know,
so
you
want
two
different
things.
You
could
do
it
by
having
a
function.
D
D
With
the
revocation
set
model
in
order
to
observe
or
react
to,
revocation
which
is
their
purpose
to
basically
chain
revocations
across
an
object
graph
yeah,
you
have
to
actually
not
only
give
the
observer,
because
there
isn't
really
one
there's
revocation
sets,
but
there's
no
way
to
do
dot,
observe
or
whatever
on
it.
You
have
to
actually
pass
the
ability
to
revoke
around.
D
Well,
here
you
could,
I
guess
you
could
pass
the
revocation
set
around
for
all
of
yellow,
but
then
it's
really
designed
to
add
every
individual
revocation
function
into
the
set
so
now
you're
getting
into
your
passing
out
round
arrays
of
revocation
sets,
because
I
don't
know
how
they're
going
to
combine,
and
so
you
always
pass
around
arrays
of
revocation
sets
because
you
don't
want
to
pass
around
the
revoke
functions
themselves
with
this
model.
It's
just
you
pass
signals
around
and
signals
can
be
combined.
A
A
The
canonical
use
case
for
this
kind
of
thing
in
go
pardon
it
go
idiomatically
thread
something
analogous
to
this.
Through
anything,
that's
doing
I
o,
and
so,
if
you're
writing
an
http
server
you'll
get
effectively
equivalent
of
an
abort
signal
at
the
beginning
of
your
http
request
and
you
are
obliged
or
you
are
able
to
use
that
as
the
basis
for
all
of
the
work
you
do
on
behalf
of
the
request
such
that
all
of
that
can
be
discontinued.
If
the
request
times
out
right.
C
A
B
I'm
sorry
hypergraph
membrane
approach
where
and
I
tried
to
illustrate
that
in
the
in
the
diagram
that
I
put
up
there,
where
you
had
a
where
you
had
original
values
and
proxies
in
the
same
realm
in
the
same
plane
of
that
graph,
and
if
you
revoke
an
original
object
it
via
the
shadowrealm.revoke
method
that
has
been
proposed,
then
the
proxies
in
the
other
object
graphs
that
point
to
that
original
value
do
not
know
that
they
are
dead.
At
that
point,
they
cannot
know
because
the
realm
revocation
did
not
communicate
to
them.
B
C
C
So
if
I
have
a
realm
who's
trying
to
communicate
with
another
realm
via
membrane-
and
I
have
this
subject
that
happens
to
be
a
revocable
proxy-
the
membrane
would
not
know
about
it.
So
the
job
of
the
membrane
is
simply
to
say
there
is
an
object
in
this
side.
I
will
create
a
proxy
on
the
other
side
and
they
are
somehow
entangled
and,
and
so
I'm
having
a
hard
time
understanding.
C
C
I
I
think
so
I
think
there
is
a
disconnection
too.
I
I
I
think
we
are
in
agreement
that,
when
a
membrane
sees
an
object
in
one
side,
it
creates
a
proxy
on
the
other
side,
and
if
we
have
a
mechanism
to
disconnect
the
whole
the
whole
side
of
the
membrane,
the
membrane
should
be
able
to
do
so,
and
the
revocation
works
pretty
well
there.
C
C
B
C
Is
it
because
you
have
an
object
coming
from
another
realm
that
might
be
disconnected
at
some
point
and
when
I
say
disconnect,
I
mean
revoke
all
the
all
the
proxies
that
this
side
of
the
realm
sees
like
they
say.
The
blue
is
that
the
jello
is
sending
you
an
object,
created
in
yellow
and
is
now
seen
by.
B
C
Okay,
so
if
yellow
creates
an
object
and
give
it
to
blue
and
blue
somehow
share
that
object
with
green,
something
like
that
where
one
of
the
disconnectable
disconnectable
membrane
roms,
might
be
providing
an
object
to
someone
else
through
going
through
the
blue
side.
So
the
from
yellow
to
blue
from
blue
to
green,
and
now
you
decide
that
you're
gonna
kill
jello
revoking
all
the
proxies
there,
and
that
has
consequences
on
blue
and
green,
because
the
object
that
you
provide
to
the
other
side
is
no
longer
available.
C
F
B
C
C
G
I
have
a
question
about.
The
interpretation
of
this
diagram
is,
is
yellow
conceptually
in
between
green
and
blue,
which
is
to
say
if
the
the
proxies
from
from
green,
the
you
have.
The
cylinder
say
that
the
leftmost
one,
for
example,
is
that
is
the
green
proxy,
a
proxy
to
blue,
or
is
it
conceptually
a
proxy
to
yellow
to
blue.
B
C
B
C
F
Yeah
I
so
I
mean
with
either
solution.
I
think
we
have
a
problem
like
if
we
go
by
the
idea
that,
like
yellow
as
the
html
object
that
it
passes
on
to
green,
I
assume
from
this
diagram
if
yellow
is
revoked,
the
green
proxy
might
would
still
be
alive
because
it
would
be
connected
directly
to
blue,
so
that
that's
my
first
question.
B
C
Yeah
but
like
in
our
case,
for
example,
at
software,
we
never
do
that.
We
always
go
through
blue.
So
if
yellow
wants
to
share
something
with
green,
it
goes
through
blue.
So
it
goes
back
to
blue
and
blue.
Give
it
to
green,
because
this
is
the
marshall
realm
and
they're
all
doing
marshalling.
So
in
that
case,
you
kill,
yellow
by
green
still
alive.
There's
no,
no
problem
with
it.
But
if
you,
if
you
have
this
multi-layer
yeah
you
you
but
but
again
like
the
idea
is
always
at
least
in
my
mind.
C
The
mechanics
of
it
is
that
a
realm
is
giving
the
sign
out
to
create
a
proxy
on
the
other
side.
So
in
this
case,
in
that
scenario,
jello
is
telling
green
hey.
I
have
an
object
here,
go
and
create
a
proxy
of
it
and
when
it
does
that
green
itself
will
be
able
to
add
that
proxy
to
a
revocable
set
and
when
green
gets
disconnected.
It
could
revoke
call
this
something
like
that
on
green
itself,
it
doesn't
have
jello,
doesn't
have
a
saying,
I
would
say,
on
that
process.
F
But
where
I
want
to
get
at
it
like
in
either
solution
you
would
need
on
the
proxy
created.
You
would
need
a
a
signal
object
which
would
have
to
come
from
somewhere
else.
That's
the
part
that
I
I
still
don't
know,
and
so
in
in
either
case
they
wouldn't
go
through
the
the
callable
boundary.
So
I
I
don't
see
how
actually
either
design
work
will
work
here.
A
So,
in
summary,
so
in
summary,
there
is
a
possibility
that
this
is
not
workable
when
that
that
broadcast
of
revocation
is
not
workable
in
the
case
of
piercing
a
realm.
However,
I
think
that
if
we
stopped
at
that
that
we
would
not
have
given
service
to
the
proposal,
the
the
the
the
being
able
to
having
a
proc
revocable
realm
was
the
inspiration
of
this
idea,
but
not
the
motivating
use
case
right,
alex.
C
So
so
on
matthew's
point,
I
I
want
to
make
sure
that
at
least
I
will
look
at
it
so
matthew.
I
think
the
disagreement
that
I
have
with
what
you
said
is
that
is
the
the
signal
that
you
mentioned,
that
is
needed
for
by
green
is
not
associated,
at
least
not
in
my
mind.
It's
not
associated
to
the
fact
that
yellow
is
giving
you
an
object.
F
C
It's
about
the
the
creation
of
the
realm
and
the
mechanics
of
that
realm,
like
an
example
will
be
green,
can
be
a
realm
that
has
a
membrane
that
connects
to
yellow
and
blue
and
green,
wants
to
make
sure
that
if
ever
an
error
occur
in
that
realm,
it
will.
It
will
automatically
disappear
yourself.
Something
like
that,
like
there's,
no
sign
up
for
outside
for
green,
to
understand
that
there
is
an
error
going
on
and
wants
to
revoke
all
the
proxies,
because
we
don't
know
the
implications
of
that
error,
so
it
implodes
itself.
C
Basically,
it
could
be
that
it
could
be
that
green
is
being
created
by
someone
else.
Let's
say
the
marshall
in
round
blue
and
the
marshall
realm
decides
when
to
eliminate
green.
Let's
say
that
the
blue
is
just
creating
a
virtualization
of
a
iframe,
so
it
creates
a
round
for
the
iframe
and
somehow,
when
the
disconnection
side,
this
connection
of
the
iframe,
the
virtual
iphone
happens,
it
will
go
ahead
and
revoke
all
the
proxies
created
in
that
realm.
C
Something
like
that,
so
blue
is
in
control
of
giving
the
signal
to
green
and
green
will
have
a
to
track
down.
What
are
all
the
proxies
that
you
want
to
revoke,
or
something
like
that
to
emulate
that's
to
to
emulate
what
the
what
happens
with
the
dom
today
on
the
iphone
like
when
the
iphone
is
disconnected
all
these
objects
are
kind
of
running
like
they
don't
know
what
to
do
like
they're
pseudo-revocable
objects
that
are
platform
objects
like
the
dom
html
stuff.
Like
that
you,
you
will
not
be
able
to
interact
with
them
anymore,.
F
C
A
A
A
Yeah,
so
I
think
that
that
actually
is,
I
think
I
can
speak
to
that,
which
is
so
so
we're
we're
caught
in
attention
here.
Is
that
promises
look
like
and
look
like,
they're
the
right,
primitive
for
a
revocation
signal
or
a
cancellation
signal,
except
for
the
fact
that
they
are
not
synchronously
observable,
and
that
is
by
design.
E
The
the
the
tension
here
is
that
let's
distinguish
three
levels
of
synchronous:
observability,
there's
what
promises
themselves
do
which
have
zero
synchronous,
synchro,
synchronous,
observability,
there's
something
like
promises,
but
where
there
is
a
synchronous
call
you
can
make
to
inquire.
Is
it
revoked,
so
that
has
let's
call
that.
F
E
The
problem,
the
problem
is
that
a
calls
b-
this
is
the
compositional
problem
of.
Am
I
notifying
you
on
my
behalf,
or
am
I
notifying
you
on
your
behalf
that
if
I'm
an
abstraction
buried
down
a
sink,
a
call
stack
and
I'm
aware
of
something
that
some
state
transition
that
I
just
did
that
others
are
interested
in,
and
the
notification
arrangement
that
I'm
involved
in
is
a
synchronous
notification
arrangement.
E
Then
it's
fine
with
me
as
a
local
abstraction
to
sit
to
synchronously,
notify
them,
because
I'm
prepared
for
that.
My
caller,
on
the
other
hand,
that
that
called
me
that
that,
to
which
I
reacted
by
making
my
state
change
it's,
it
might
not
be
prepared
for
synchronous
reentry
by
the
things
that
I
notify.
E
So
you
know
this
goes
back
to
the
distinct.
You
know
the
distinction
in
my
thesis
between
sub
goaling
and
to-do
lists.
There's
I
notifying
you,
because
I
need
you
to
do
something
on
my
behalf
as
as
a
sub-goal
of
what
I'm
doing
to
bring
about
my
end
result,
in
which
case
the
composition
with
my
caller
needs
to
take
that
into
account.
E
My
caller
still
understands
that.
It's
delegating
to
me
performing
some
tasks,
so
I
delegate
to
others
to
perform
subtests
versus.
There
are
just
other
parties
that
are
interested
in
being
notified
and
that's
too
much
of
a
burden
for
my
from
my
caller
to
then
take
that
into
account
that
they
might
happen
synchronously
during
my
action.
E
D
A
Yes,
yes,
yeah,
and
what
that
looks
like
is
if,
if
the
signal
were
asynchronous-
and
we
just
used
promises
instead
of
creating
a
new
thing,
you
would
have
a
cancelled
promise
that
you
would
be
thread
through
to
anybody.
Who's
in
interested
in
observing
cancellation
and
the
the
polling
would
look
something
like
await:
promise.race,
canceled
and
or
undefined,
which
has
the
behavior
of
observing
the
cancellation
immediately.
If
it
has
already
been
cancelled.
D
B
Yes,
I
was
going
to
point
out
that
I
think
I
I
get
this
general
sense
that
people
are
in
favor
of
at
least
exploring
this
idea
in
general.
Absolutely
yes,
what
I'd
like
to
see
is
I'd
like
to
see
and
maybe
I'll
do
it
myself
is
draw
up
a
a
draft
stage,
zero
proposal
in
a
repository
and
then,
let's
continue
to
iterate
on
it.