►
From YouTube: WEBRTC WG interim 2022-01-18
Description
See also the minutes of the meeting at https://www.w3.org/2022/01/18-webrtc-minutes.html
02:17 Recent CfAs and CfCs
03:23 Agenda review
03:42 WebRTC NV Use Cases
30:26 Media Capture Transform
41:33 WebRTC Extensions
51:41 Capture Handle 🎞︎▶⏸︎
A
A
A
A
A
A
D
A
A
We
had
a
discussion
at
the
december
21
interim
tim
submitted
a
pr
which
we
merged
to
address
some
of
the
feedback.
We're
going
to
talk
more
about
that
today
and
hopefully
get
a
little
bit
closer
to
convergence.
We
had
a
cfa
on
region
capture
which
concluded
on
december
13th
and
the
spec
is
now
in
the
w3c
archive,
so
we're
done
with
that.
We
will
talk
a
little
bit
about
a
cfc
on
pr
125,
which
was
for
wherever
c
encoder
transform
or
a
keyframe
api.
A
We'll
talk
more
about
that.
There
was
some
concern
about
race
conditions
and
sinking,
and
then
we
have
a
cfc
on
intent
to
discontinue
media
captured
death
extensions
which
are
will
conclude
on
the
26th.
So
it's
not
done
yet.
Please
express
your
opinion.
I
think
I
saw
one
or
two
more
opinions
come
in,
but
please
send
us
your
thoughts
on
that
all
right.
B
D
B
Further
suggestions
and
I've
removed
the
requirements
and
some
of
them,
I
think,
we'll
end
up
with
new
requirements
that
reflect
the
discussion
that
we
had,
but
for
the
moment
there's
a
couple
of
placeholders
in
there
so
yeah.
Basically,
if
you
can
go
in
and
look
at
that
pr
comment
on
it,
I'd
really
appreciate
it
and
then
the
other
thing
that
we
kind
of
talked
about
last
time
was
like
what
did
decentralized
messaging
mean.
What
did
we
need?
B
What
did
the
people
who
were
trying
to
do
that
need,
and
we
came
to
the
conclusion
that
none
of
us
really
knew,
but
we
thought
there
was
maybe
something
there
and
that
understanding
what
the
minimal
acceptable
changes
were
was
kind
of
the
thing
that
we
didn't
really
have
a
grasp
on.
So
I
invited
keegan
to
come
and
give
us
some
expert
opinions
having
given
that
he's
basically
tried
to
do
this
and
encountered
whatever
the
problems
are.
B
D
Okay,
hello,
my
name
is
keegan.
I'm
a
software
engineer
working
at
matrix,
I'm
going
to
provide
a
little
bit
of
background
on
matrix
first
to
provide
some
context
and
then
go
into
more
detail
about
our
use
case
with
webrtc
and
service
workers.
So
matrix
is
an
open
source
project
for
secure
decentralized
communication.
D
The
mainstream.org
foundation
maintains
a
protocol
specification
similar
to
the
html
living
standard,
along
with
client
and
server
implementations
available
on
github.
The
network
is
federated
and
has
similarities
with
email
and
xmpp
voice,
and
video
messaging
in
browser
uses
webrtc
already
and
matrixes
handles
the
signaling.
For
that.
D
So
one
of
the
problems
matrix
has
is
that
it's
trying
to
be
decentralized
in
practice.
Most
users
will
actually
sign
up
to
one
or
two
main
servers.
For
example
matrix.commatrix.org
that
main
server
resulted
in
a
more
centralized
network
than
we
would
like.
So
one
of
our
goals
is
to
instead
allow
users
to
kind
of
automatically
sign
up
onto
the
network
just
by
visiting
a
website
and
effectively
making
the
service
peer-to-peer.
D
D
Our
core
idea
was
to
compile
a
matrix
server
down
to
webassembly
and
then
run
it
in
a
worker,
a
worker
thread
in
the
browser
we
weren't
the
first
people
to
try
to
do
peer-to-peer
stuff
in
browsers
before
so.
We
made
use
of
protocol
labs
lib
p2p
set
of
libraries,
which
is
also
used
in
services
like
ipfs.
D
Unfortunately,
we
couldn't
get
webrtc
working
in
service
workers,
so
we
ended
up
using
web
sockets
to
a
relay
server
which
not
only
handled
signaling
but
also
handled
all
the
data
packets.
So
no
data
went
directly
between
the
browsers
which
isn't
very
peer-to-peer
at
all,
because
if
the
relay
server
dies,
then
any
existing
sessions
can't
exchange
messages
at
all,
but
it's
the
best
that
we
could
do
at
that
time.
D
D
We're
currently
limited
in
terms
of
which
peer
connections
can
be
established
from
a
browser,
as
we
can
only
really
speak
to
directly
addressable
nodes.
In
this
example,
it's
dendrite.matrix.org,
so
we
can't
direct
speak
directly
to
the
iphone
and
android
nodes
in
this
graph
from
the
browser
because
of
lack
of
web
rtc
support
in
in
workers.
D
Can
we
go
to
the
next
slide?
Please
thank
you.
So
we
have
a
few
requirements
for
any
potential
solution
and
that's
going
to
work
for
us.
We
need
to
run
the
server
in
a
worker,
be
it
web
or
service,
as
we
do
a
lot
of
compute
heavy
tasks
which
would
affect
the
ui
otherwise
we'd
like
workers
to
live
as
long
as
reasonably
possible
as
having
the
server
alive
longer
results
in
less
network
churn
and
creates
a
more
stable,
b2b
network.
We
need
to
intercept
fetch
requests
from
the
browser.
D
D
D
So,
to
clarify
a
few
things,
we
don't
have
any
desire
to
run
a
long-lived
process
on
a
user's
browser.
We
see
this
as
an
anti-goal
and
a
privacy
invasion
in
our
experiments
with
service
workers.
There
are
a
few
inconsistencies
between
browsers
anyway,
on
how
long
the
service
worker
life
cycle
is
so
in
firefox.
It
seems
to
terminate
service
workers
after
30
seconds
of
inactivity,
but
you're,
not
intercepting
any
fetch.
D
Now
the
final
slide,
please
thank
you
so
so
that
hopefully
gives
a
enough
context
to
understand
our
specific
use
case
and
the
proposals
listed
here.
I
think
the
most
acceptable
proposal
is
probably
b
or
c,
though
I'm
not
sure
if
this
committee
has
the
remit
to
support
intercepting
fetch
requests
and
web
workers,
or
anything
like
that.
D
I
don't
know
how
difficult
it
is
to
allow
web
workers
to
create
webrtc
connections,
envisage
that
the
lifetime
of
the
connection
is
still
tied
to
the
lifetime
of
the
tab,
but
effectively
now
the
web
rtc
apis
would
need
to
be
thread
safe
as
the
public
api
can
be
called
from
the
main
window
and
web
workers
simultaneously
and
if
and
when
changes
are
made,
we'll
probably
use
off-the-shelf
libraries
provided
by
the
p2p.
Just
to
try
it
out
and
verify
that
our
use
case
has
been
handled
and
that's
that's
basically
about
it.
D
Yes,
so
so
that's
effectively,
proposals
c
and
d
of
actually
where
workers
can
can
make
web
rcc
connections
or
control
their
control
data
channels.
Making
new
connections
would
be
preferable,
but
yeah
something
along
those
lines
would
would
work.
It'd
still
be
a
little
bit
messy,
but
it
would
be
tractable
at
that
point.
E
Well,
there's
web
workers
most
people,
think
of
a
dedicated
worker,
which
is
a
scope
to
one
page,
a
shared
worker
and
I'm
not
an
expert
either.
I
just
learned
of
them
recently
myself.
My
understanding
is
that
they
allow
you
to
share
between
multiple
tabs
without
becoming
a
full-fledged
service
worker.
I
mean
you
cannot
well
I'm
being
recorded
now,
so
I
would
guess
that
shared
worker
cannot
outlive
the
last
tab,
but
I'm
actually
not
certain
about
that.
It
seems.
F
E
B
Yeah
just
to
try
and
clarify
in
my
mind,
so
that
the
only
real
goal,
the
only
reason
why
you
would
want
data
channels
in
service
workers
is
to
be
able
to
intercept
fetch
and
that's
just
so
that
the
client
doesn't
doesn't
have
to
be
changed
to
support
that
running
a
local
service.
It's
not
that
it
would
be
impossible
to
do
what
you
want.
It's
just
that
it
makes
the
code
tidier.
D
Yeah
and
it
partly
because
also
it's
the
ecosystem
in
which
matrix
exists
right
because
by
all
means
you
know,
we
could
modify
our
own
sdks,
add
a
shim
layer.
So
it
does
like
a
post
message
instead
of
calling
fetch
and
you
know,
post
a
message
to
the
service
worker,
but
that
would
only
then
work
for
that
sdk.
It's
not
going
to
be
like
a
more
general
kind
of
solution,
and
it
would
be
quite
invasive
for
anyone
else,
then
to
want
to
add
in
support
for
for
similar
kind
of
peer-to-peer
capabilities.
B
You
say
you
could
patch
it,
but
that
assumes
that
that
there
aren't
fetches
that
are
being
done
by
the
user
agent
rather
than
in
javascript.
So,
like
you
know,
fetches
for
css
or
something
that
was
actually
in
the
page
service
workers
will
incept
them
as
well
yeah,
whereas
you
know
you
can
obviously
monkey
patch
the
javascript
to
do
whatever
you
want,
but
like
I,
I
suppose
what
I'm
trying
to
get
to
is.
D
E
E
D
I
mean
that
that
wouldn't
be
ideal,
because
it
would
probably
affect
uptake
in
terms
of
how
easy
it
is
to
add
peer-to-peer
support.
You
know
having
to
tell
the
world
okay,
you
need
to
replace
all
instances
of
fetch
with
this
custom
blob,
and
you
know
it
is
much
more
difficult
than
saying
to
shove,
a
service
worker
in
and
it
just
magically
kind
of
happens.
G
C
C
B
G
E
G
In
general,
you
want
long
life.
Long-Lived
objects
like
peer
connection
in
stable
context,
and
service
worker
is
not
really
a
stable
context,
but
still
I
mean
there's
no
harm
in
exposing
it
appear
connection
in
service
worker
either
because,
if
you're
exposing
it
to
a
worker,
it
means
your
implementation
is
ready
to
expose
it
in
service
worker
as
well.
G
E
G
H
G
I
would
say
that
in
in
general,
we
are
reluctant
to
have
push
messages,
triggering
some
javascript
without
a
user-visible
action.
So
if
a
service
worker
is
not
notifying
the
user
with
some
notifications,
then
a
browser
will
say:
there's
something
fishy
there,
so
they
might
throttle
your
post
messages.
They
might
even
stop
sending
push
messages,
because,
if
you're
able
just
for
a
push
message
to
trigger
some
laboratory
code
in
in
a
in
a
device,
that's
a
really
bad
thing.
So
that's
why
it's
really
respected
in
terms
of
security.
I
G
That's
that's
a
good
point.
It
really
depends
on
each
browser
because
each
browser
might
kill
the
service
worker
or
not
with
some
heuristics
that
are
not
shared
currently
and
if
you
and
the
service
worker,
then
you
will
end
the
data
channel
in
practice,
so
you
will
need
to
recreate
one
which
is
better.
That's
true,.
E
E
B
G
B
B
H
B
H
G
B
A
E
B
A
H
H
A
H
H
H
H
H
Memory,
locality
is
a
question
about
really
about
reusing
your
buffers
so
that
we
can
cycle
around
the
buffer
pool
without
ever
having
to
to
rely
on
garbage
collection.
So
I
hope
I
I
have
held
that
as
a
document
as
a
an
issue.
We
need
to
keep
open,
but
it's
kind
of
exploratory
in
nature,
so
we
so
we
don't
need
to
answer
this
before
before
going
to
public
first
public
working
drafts,
34
relationship
to
w
web
gpu
the
same
kind
of
issue.
H
We
have
a
proposed
pro
a
solution
that
is
proposed
in
the
pr
web
codex,
which
might
lead
us
to
to
say
that
okay,
this
is
solved
by
by
ways
to
manipulate
video
frames
and
say
don.
But
again
I
don't
think
this
blocks
first
public
working
drafts
and
there's
65
on
video
rotation,
which
I,
which
I
I
think
is
actually
a
metadata
ac
on
video
frame,
and
I
suggest
we
just
move
it
there.
H
E
All
right,
yeah,
so
yeah.
I
also
looked
at
the
issues
and
I
think
I
agree
with
most
of
what
you
presented
there.
Actually
I
did
open
an
issue
71,
which
is
more
of
a
clarification
about
what
the
consensus
is
or
isn't,
and
so
I
did
a
look
over
media
stream
track.
Processor
introduction
section
still
says:
if
the
track
is
an
audio
track,
the
trunks
will
be
audio
data
objects.
E
G
I
I
think,
they're
in
the
same
vein,
the
use
cases
in
section
one.
They
identify
audio
like
in
in
three
of
the
four
use
cases
that
the
specification
explicitly
aims
to
support.
They
are
based
on
audio
as
well,
which,
if
you
just
read
that
you
think
audio
is,
is
supported,
and
this
should
be
clarified
as
well.
E
Right
and
also
there's
an
open
link
for
whether
audio
applies
just
to
video
track
generator
or
the
absence
of
audio
track
generator
or
if
it
also
means
media
stream
track.
Processor-
and
that's
that's
that'll-
be
helpful
to
have
that
clarification,
and
it's
it's
still
and
bike
sharing.
I
guess
we
can
keep
going
on,
but
it's
still
a
little
awkward,
perhaps
that
you
have
media
steam
track
processor,
and
then
you
have
video
track
generator,
but
medium
track
is
the
name
of
what
we're
processing.
So
I
think
it
makes
sense
it's
a
bit.
E
D
H
G
G
A
H
A
H
A
A
A
A
G
A
G
Yeah-
and
the
question
is
really
we
we
we
need
that,
because
in
general,
what
you
want
to
do
is
you
want
to
apply
the
new,
the
new
key
and
you
want
to
apply
the
new
key
on
the
first
keyframe.
That
happens.
If
it
happens,
that
you
requested
a
keyframe
and
it's
actually
triggering
a
second
keyframe
you,
you
might
still
want
to
start
on
the
first
keyframe
that
you
receive
and
you
wait
to
start
as
soon
as
possible.
D
G
A
Enough,
but
it
should
be
very
close.
Well
I
did.
I
did
want
to
talk
about
that
specifically.
So
one
of
the
problems
for
the
for
the
s
frame
transform
right
was
that
when,
by
the
time
the
keyframe
promise
returned,
as
you
said,
the
corresponding
frame
may
have
already
been
encrypted,
so
it's
kind
of
the
timing
isn't
guaranteed.
A
G
B
G
To
to
to
do
those
things,
so
that's
why,
in
that,
in
that
case
you
really
need
a
script
transform
and
for
the
script
transform
you
you
will.
You
will
be
in
the
same
thread,
so
I'm
I'm
probably
sure
that
this
will
actually
actually
work
there.
You
will
generate
a
keyframe,
you
wait
on
it
and
and
then
you
apply
the
anchor
chunky.
A
G
Yeah,
I
think
that
what
would
be
really
good
is
that
there
are
some
experiments
that
are
done
with
the
current
support,
but
that
will
prove
or
not
whether
that's
good
enough,
there's
already
support
in
safari,
so
people
can
try
javascript
and
try
to
use
it
and
see
whether
in
terms
of
resolution
that
will
work
for
them
or
not.
If
not,
we
can
certainly
try
to
change
the
way.
The
time
the
promise
is
resolved
or
the
type
of
a
promise,
if
that's
really
helping
so
for
script
transformer.
G
E
G
G
A
G
You
need
to
understand
whether
the
s7
transform
should
ask
the
keyframe
and
apply
the
the
new
key
on
right
on
the
on
the
keyframe.
So
so
we
need
some
parameters
or
we
need
to
define
some
behavior
for
the
espn
transform.
So
there's
clearly
something
missing
for
experiment
transform
and
we
need
to
to
add
support
for
it.
A
D
A
G
A
F
F
F
F
Yes,
sorry
about
that,
I'm
having
a
bit
of
technical
difficulties!
Okay,
I'll,
try
like
this!
So
thank
you
very
much.
I'm
going
to
be
presenting
again
again
about
capture
handle
and
I'm
gonna.
First
recap
a
bit
about
what
we've
discussed
previously.
Then
I'm
going
to
make
the
proposals
for
extension
of
the
original
api
and
then
I'm
going
to
if
the
crowd
is
interested,
I'm
going
to
discuss
a
bit
why
we
need
both
and
why
the
new
thing
is
not
enough
to
obviate
the
old
thing.
F
So,
first,
a
recap
of
our
reminder
of
the
premise
so
we're
assuming
that
we've
got
one
application.
That's
a
virtual
conferencing
application,
something
like
mid
zoom
teams
or
we'll
just
call
it
vc
app
and
somebody
is
presenting
something
in
a
tab,
and
you
know
that
tab
can
be
google
slides
or
it
can
be
any
other
application.
F
That
he's
got
open
on
his
browser,
but
the
application
that
the
virtual
conference
in
application
does
not,
and
what
that
leads
to
is
that
if
the,
if
the
user
is
watching
the
virtual
conferencing
application,
he
cannot
actually
interact
with
the
other
application
that
he
is
presenting
so
easily.
So
it
would
be
difficult
for
the
user
to
change
to
the
next
slide
previous
slide,
and
it
would
be
even
more
difficult
to
do
anything
else.
More
robust,
like
maybe
interact
with
the
page
move
around
the
cursor
click
on
links,
etc.
F
Next
slide,
please
so,
as
mentioned
previously,
I
suggested
a
mechanism
that
would
address
this,
and
one
problem
with
that
mechanism
was
that
it
assumed
that
the
two
applications
have
set
up
some
kind
of
collaboration
ahead
of
time.
So,
for
example,
it
would
work
well
for
microsoft
teams
and
microsoft
powerpoint
and
it
would
work
well
for
google
meet
and
google
slides
and
it
could
even
work
in
conjunction
right.
It
could
be
google
me
and
microsoft,
sly
and
microsoft
powerpoint,
but
they
would
have
to
set
up
this.
F
F
So,
in
this
case
we
see
it
says,
expose
origin,
true,
which
means
hey.
I
am
willing
to.
Whoever
captures
me
may
discover
that
you
know
my
origin.
It
sets
a
handle
which
is
free
flow,
freeform
text
and
it
can
put
whatever
there
and
it's
up
to
whatever
is
capturing
it
to
know
how
to
parse
that
and
what
used
to
make
of
it,
and
then
it
says,
sets
permitted
origins
which
basically
is
a
way
to
limit.
Who
can
read
that?
F
F
So
in
that
example,
there
is
a
bit
of
code
here,
but
most
of
it
is
not
so
interesting.
Basically,
once
you've
already
got
the
capture
in
place,
you're
gonna,
first
you're,
gonna,
say
okay.
If
if
there
is
a
change
of
capture
handle,
I
need
to
react
to
that.
But
now
here
is
the
capture
handle
that
I
have.
F
Let's
see
who
that
is
and
oh,
if
it
happens
to
be
one
of
the
origins
that
I'm
ready
to
work
with,
then
I'm
just
gonna
use
the
id,
and
you
know
maybe
I'll-
expose
some
user
facing
controls
next
slide.
Previous
slide
and
whenever
the
user
presses
that,
I
know
that
I
need
to
send
that
to
session
one
two
three
on
whatever
next
slide.
Please
now
the
problem
with
this
mechanism
is
that,
as
mentioned,
it
only
works
when
you're
capturing
something
that
you've
set
up
a
collaboration
with
and
sorry
okay
seems
unrelated
message.
F
So
in
order
to
address
the
the
other
case,
I've
spoken
to
yanivar,
who
was
really
concerned
that
the
original
mechanism
was
only
useful
for
collaborating
applications
and
they
wanted
something
a
bit
more
generic,
albeit
a
little
bit
less
powerful,
or
at
least
less
flexible,
and
so
I
am.
I
split
that
we'll
call
the
old
thing
capture
handle
identity
and
we'll
call
the
new
thing
capture
handle
actions
and,
of
course,
the
names
are
far
from
final
next
slide.
Please
so
one
one
possible
way
to
go
about
this
is
we
could
say?
F
Okay,
there
are
a
list
of
actions
that
we
know
that
capturing
applications
and
captured
applications
might
actually
want
to
pursue
first
slide
previously
next
slide
last
slide.
It
doesn't
actually
have
to
be
a
slide,
because
you
could
also
be
capturing
something
like
youtube
in
which
or
anything
that
has
a
playlist
and
then
those
actions
could
have
slightly
different
meaning.
F
F
F
There
is
an
issue
here
where
basically
it
could
be
that
you're
sending
the
action
exactly
as
the
user
is
navigate.
You
know
I'm
sorry
exactly
as
the
page
is
changing,
but
that
kind
of
thing
kind
of
exists
for
anything
where
the
user
presses
something.
So
I
think,
on
the
one
hand,
it's
not
an
issue
for
the
actions,
but
on
the
other
hand,
I
think
that
it
also
shows
that,
if
you
have
anything
where
you're
interested
in
only
sending
the
message
to
this
particular
capturing,
then
with
identity.
F
C
C
You
embed
from
your
top
webpage,
and
I
don't
want
to
derail
this
very
specific,
narrow
or
maybe
not
narrow,
but
this
is
very
specific
use
case,
but
I
also
don't
want
us
to
miss
an
opportunity
to
achieve
a
greater
bank
for
the
buck.
So
I
guess
I
wanted
to
mention
this.
In
particular,
in
the
past
there
had
been
years
ago
discussions
about
something
called
web
intents,
which
was
a
way
for
a
web
app
to
expose
an
api
for
other
apps
to
use.
F
Understood
and
I
think
that
u.n
actually
brought
to
our
attention
that
there
is
something
called
media
session
where
something
like
that
does
exist,
I'm
not
sure
exactly
about
whether
you
can
also
expose
capabilities
or
not.
But
this
does
exist
for
the
not
where
for
the
case
where
you
don't
actually
capture-
and
you
mentioned
that
we
might
want
to
piggyback
on
that.
And
I
would
like
to
ask
you
and
if
there,
if
he
says
any
way,
that
we
can
piggyback
on
that,
because
it
seems.
G
That
is
that
would
try
to
to
send
the
these
events
to
the
capturing,
and
so
you
probably
need
to
add
information
like
the
capture
or
a
gene,
or
you
need
to
think
about
potential
security
issues
there,
but
from
the
definition
of
the
actions
and
so
on,
it
seems
like
we.
We
should
be
able
to
reuse
as
much
as
possible
the
the
effort
and
add
additional
apis.
G
If
we
need
to
it
seems
potentially
useful
for
youtube
to
be
able
to
say:
hey,
I'm
a
media
station
and
pip
is
working
great
and
I'm
also
allowing
the
same
event.
Handlers
plus
some
security
checks
to
be
called
by
another
app.
If,
if
we
find
some
get
display,
media
being
used
or
some
other
apis
in
the
future,
that
will
be
able
to
hook
up
one
page
with
youtube.
So
that's.
F
I'm
definitely
happy
looking
at
that
and
if
you've
got
a
concrete
suggestion,
I
would
love
to
hear
that.
But
in
terms
of
generally
from
my
own
look
at
that-
and
maybe
I
just
misunderstood
the
your
intention-
it
did
not
look
to
me
to
be
exactly
something
that
I
could
piggyback
onto
for
several
reasons.
One
of
them
already
mentioned
is
the
lack
of
the
fact
that
that
I
want
to
allow
the
application
to
send
the
message
and
not
necessarily
it
doesn't
necessarily
need
to
come
from
the
user.
F
D
G
So
I
think
that's
that's
a
very
good
point.
There's
one
thing
that
we
we
need
to
understand
is
whether
what
we're,
after
is
like
a
predefined
set
of
actions
or
what
we're
after
is
an
application
specific
set
of
actions,
because
this
is
very,
these
are
two
different
use
cases.
If
what
we
are
after
is
like
very
generic
application.
Specific
actions,
then
media
station
is
probably
not
what
we
are
after,
but
what?
If
what
we
are
after
is
the
classic
media
station
controls
kind
of
thing?
G
Then
we
already
have
some
definition
and
there
are
there's
already
some
code,
of
course,
with
this
use
case,
there's
a
need
for
additional
apis.
For
instance,
you
need
in
capture
to
expose
some
proxy
to
the
media
station
and
on
the
media
station
side,
there's
also
a
need
to
say
media
station,
I'm
okay
receiving
orders
from
this
origin
or
this
origin.
G
E
Yes,
so
so
I
would
say
I
like
this
as
its
proposed.
I
also
looked
at
media
session.
It
has
in
particularly
I
looked
at
next
track
previous
track,
but
I
don't
think
google
slides
actually
responds
to
next
track
previous
track,
and
I
could
also
see
a
presenter
might
have
a
slide
with,
for
instance,
youtube
on
it
and
there
is
audio
and
then
it's
actually
confusing.
G
E
G
Would
like
to
implement
both?
Do
you
think
that
if
next
slide
previous
slide
was
in
media
station?
Because
we
might
talk
with
these
guys
and
we
might
say
hey,
we
are
thinking
about
next
slide
projects
like
what
do
you
think
and
they
might
say
no
or
they
might
say
yes,
and
if
they
say
yes,
then
maybe
it
means
there's
something
that
we
should.
E
I
don't
see
why
we
couldn't
have
both
and
why
we
couldn't
explore
both
in
parallel,
because
if
you
have
harder
buttons
for
next
previous
slides,
you
could
push,
though
the
user
could
push
those
or
the
the
application
the
the
vc
app
could
instruct
it,
which
hopefully
would
also
come
from
the
user,
pushing
buttons
in
the
vcr.
But,
of
course,
there's
no
guarantee
about
that.
H
F
F
G
F
C
C
My
own
suggestion
earlier
was
that
it's
actually
a
broader
architectural
situation
of
coordination
between
web
apps,
which
typically
would
be
done
through
post
message.
Today
and
again,
I
sense
that
it
may
be
a
matter
of
defining
a
mechazine
mechanism
for
declaring
that
you
react
to
a
postmessage
set
of
commands
and
maybe
having
a
an
easy
way
for
well
having
a
way
to
standardize
some
of
these
comments,
so
that
you
can
expect
to
find
them
in
some
context.
C
But
again
I
like
there
is
this
trade-off
between
finding
the
best
generic
solution
and
fulfilling
this
specific
use
case.
I
I
don't
think
we've
quite
hit
the
right
middle
point
in
that
trade-off.
I
think
it
needs
more
exploration,
as
has
been
suggested,
but
again,
that's
probably
a
point
where
reasonable
people
can
disagree.
E
I
think,
having
a
couple
of
standardized
enums,
if
you
will
and
then
an
id
with
the
idea,
you
can
bootstrap
your
own
back
channel
using
post
message
and
existing
technology
so
that
we
don't
have
to
create
new
technology.
For
that,
and
I
think
that
is
why,
as
soon
as
you
allow
arbitrary
strings,
you
know
people
can
put
megabytes
into
it.
F
Okay,
I'll
go
next,
so
I
think
that
if
we
can
at
least
agree
that-
and
hopefully
I
can
present
about
that,
if
necessary-
that
both
the
capture
handle
actions
as
well
as
the
capture
handle
identity
are
both
necessary.
Then
maybe
we
can
move
forward
with
capture,
underline
identity
and
keep
capturing
actions
under
discussion.
G
I
think
we
had
this
discussion
in
the
mailing
list
as
well,
and
some
people
express
the
same
points
as
univer
stating
that
as
capturers
they
would
prefer
to
have
like
a
fixed
set
of
actions,
because
this
way
they
feel
that
they
might
be
able
to
use
more
easily
capturing
than
if
capture
you
had
to
run.
Javascript
specifically
on
on
captures
messages,
because
executing
javascript
based
on
capture
input
requires
some
trust
and
websites
will
have
difficulties.
Trusting
like
a
large
amount
of
vc
providers,.
F
In
that
case,
if
I
could
just
if
we
could
go
to
the
next
slide,
I
think
that
I'm
not
sure
what
un
referred
to
as
p1
and
what
is
p2,
but
I
would
like
to
argue
that
capture
handle
identity
is
actually
the
p1.
So
if
we
could
go
exactly
thank
you,
so
I
just
want
to
explain
why
identification
is
necessary,
even
if
we
assume
that
we
standardized
capture,
end
elections
and
that
you
know
it
provides
everything
that
everybody
here
wanted.
F
So,
first
of
all
is
that
with
identification,
the
identification
part,
it
is
sorry
so
you're
able
to
do
two-way
communication.
That's
number
one!
You
cannot
do
that
with
the
actions
number
two
and
the
list
here
is
a
bit
different.
Yeah
number
one
actually
was
that
you
would
be
able
to
actually
send
some
information
from
the
capturer
to
be
the
capturer
without
actually
requiring
the
capture
to
send
the
message
and
therefore
alert
the
capturing
to
the
fact
that
there
is
a
capture.
F
So
if
I'm
a
capturer
and
I
capture
something,
I
can
already
understand
whether
I
want
to
start
communicating
or
not
without
giving
that
piece
of
information
that
you
are
being
captured.
Another
thing
is
that
we
get
the
ultimate
amount
of
flexibility
in
messaging
right,
because
once
you've
got
an
identity,
you
set
up
a
peer
connection.
You
set
up
some,
you
know
shared
some
communication
through
a
rest,
api
or
anything
of
the
sort.
F
Instead
button,
you
are
actually
allowing
the
user
to
let
the
certain
things
follow
you
right,
because
the
moment
you
press
share
this
tab
instead
and
you
start
capturing
the
other
one.
There
is
an
event
fired
that
lets.
The
capturer
know
that
hey
there
is
another
capture
handle
right
now
and
it's
almost
as
if
the
user
can
control
unloading,
the
old
iframe
and
loading
a
new
one
inside,
and
these
are
all
things
that
you
don't
actually
get
with
actions.
F
E
So
since
I
didn't
answer
your
first
question
there,
I
I
see-
and
I
hate
to
be
difficult,
but
I
kind
of
see
the
minimum,
a
minimum
set
of
actions
of
next
slide
and
previous
slide
as
a
blocker
for
identity
in
order
to
because
otherwise
we
can't
rebut
the
notion
of.
We
want
to
be
able
to
rebut
the
notion
that
we're
adding
api
specifically
for
narrow
collaboration
between
sites,
which
I
fear,
will
mostly
benefit
major
sites
with
resources
in
both
vc
app
and
slides.
App.
F
E
E
E
G
Yeah
sorry
for
interpreting
you,
I
was
just
about
to
say
that,
generally,
when
you
have
a
generic
mechanism,
you
need
to
spend
a
lot
of
time
because
it's
very
difficult
to
get
it
right.
So,
what's
appealing
about
this
very
small
set
of
previous
slide
next
slide
is
that
we
can
probably
make
it
work,
hopefully
quite
fast
and
without
getting
it
wrong.
While
with
a
generic
mechanism,
we
really
need
to
to
spend
a
lot
of
time
to
check
all
edge
cases
and
so
on.
F
Okay,
but
I
believe
that
capture
handle,
I
don't
recall
exactly,
but
I
think
that
it
was
first
introduced
first
proposed
and
also
implemented
in
chrome
behind
an
origin
trial
more
than
six
months
ago.
So
there
was
plenty
of
time
for
issues
to
be
surfaced
and
if
you
know
mozilla
and
apple
had
any
concerns,
we
could
have
hashed
them
out
a
long
time
ago.
G
D
G
F
G
H
G
H
H
E
H
E
Well,
I
like
the
slides
that
ella
presented
here,
and
I
have
to
read
with
my
memory
of
capture
handle.
I
understand,
there's
some
other
issues
where
sending
events
when
the
when
the
page
is
navigated
might
have
some
security
issues
that
I
haven't
fully
come
to
peace
with
yet.
But
I
I
feel
like
with
the
next
in
previous
slides
that
elon
have
proposed
it
at
least
addresses
my
concern
for
capture
handle
as
a
concept
and
that
they
can
move
forward
as
a
concept.
H
When
we
try
to
decide
multiple
things
at
once
and
set
up
all
what
I
I
regard
as
rather
arbitrary
linkages
between
them,
the
whole
set
becomes
very
hard
to
make
forward
progress
on.
So
I
would
like
to
see
if
we
can
detach
the
issues
into
pieces
where
it's
cleared,
which
parts
are
relevant
to
which
particular
concern.
G
Yeah
thanks
harold
for
stating
the
two,
the
two
parts.
That's
that's
helpful
for
this
question.
To
me,
the
most
difficult
part
is
the
identification
part,
and
that's
one
where
we
need
to
to
spend
a
lot
of
time
and
do
things
right
and
by
scoping
precisely
the
use
case,
which
is
as
understanding
next
slide
previous
slide
and
getting
it
right
for
the
identification
part
based
on
that,
I'm
hoping
we
can.
G
We
can
have
good
discussion
and
validate
the
model
and
and
be
as
fast
as
we
as
we
can
on
on
that
subject.
So,
that's
why
I
think
it's
it's
good
to
provide
a
good
scope
there
that
you
that
lads
has
done,
which
is
which
is
great,
and
I
would
say
we
use
the
narrow
down
scope
of
actions
as
the
things
we
want
to
support
for
identification
and
we
validate
the
identification
model
based
on
it.
F
You
and
I
have
since
checked,
and
it's
almost
been
a
year
since
we
started
the
discussion
about
identify
identification.
So
if
it's
possible
for
you
to
fast
track
discussions
there
with
me,
so
that
we
could
finish
that
part
relatively
you
know
within
the
near
future.
I
think
that
would
be
preferable.
G
H
C
So,
just
to
provide
a
framework
for
this
additional
discussion,
so
first
I'm
hearing
we
want
to
solve
the
use
case,
I'm
hearing
from
yanivar
that
the
narrow
use
case
needs
to
be
driving.
The
discussion,
in
particular
as
jun,
was
suggesting
the
identity
discussion
need
to
be
compared
to
that
narrow
use
case.
So
I
guess
now.
The
question
is
how
and
where
we
want
to
have
the
conversation
right
now.
Capture
handle
is
a
ycg
committee
group
report.
G
C
But
I
guess
we
we
could
start
the
call
for
adoption
as
a
trigger
for
everyone
to
refresh
their
mind
on
the
specific
proposal
and
whether
they
have
burning
issues
they
feel
need
to
be
addressed.
So
my
real
question
was
not:
are
you
going
to
say
yes
to
the
call
for
adoption,
but
do
we
feel
in
the
rough
right
space
to
start
the
discussion.
G
F
I've
got
two
questions.
One
do
you
ever
want
to
so
in
case
it's
possible
for
you
to
maybe
bring
bring
forth
a
more
detailed
proposal
of
what
you
mean
with
media
session
just
in
case.
We
want
to
go
with
that,
and
if
you
find
that
this
one
is
not
very
easy
to
reduce,
maybe
we
could
go
on
with
the
proposals
is
of
actions.