►
From YouTube: IETF-MIMI-20230830-1900
Description
MIMI meeting session at IETF
2023/08/30 1900
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
A
A
A
A
A
So
he-
and
he
also
published
a
draft
just
yesterday,
which
he
sent
to
the
list,
so
hopefully
folks
had
a
time
to
take
a
look
at
that.
If
not,
you
can
reference
it
as
we
go
along
we'll
give
that
as
much
time
as
it
needs.
This
is
our
you
know
our
first
set
of
deliverables
I'll
relate
to
this
transport
architecture,
so
we'll
spend
our
time
there
as
as
needed.
A
A
So
we
have
a
bunch
of
different
presenters,
lined
up
for
this
Jonathan
and
Ecker
to
kick
off
and
provide
sort
of
overview
and
sort
of
points
of
discussion
for
for
the
rest
of
the
group
and
then
Giles
and
Vittorio,
who
have
more
specific
proposals
from
their
respective
drafts,
and
we
left
some
time
at
the
end
there
for
discussion.
We
might
need
to
kind
of
rejigger
a
little
bit
based
on
people's
conflicts
and
some
people
having
to
leave
early,
but
we
will
we
will
do
our
best
Giles.
D
A
Okay,
you,
it
looks,
like
you
raised
your
hand
to
be
in
the
queue,
at
least
from
from
my
interface.
That's
what
it
looks
like.
So
if
you,
whenever
you
have
a
question,
you
should
hit
the
hit
the
raise
hand,
button
you'll,
get
in
the
queue
and
and
we'll
run
the
queue
as
normal,
just
like
we
did
in
the
in
the
in-person
meeting.
But
for
now
you
don't
need
to
be
in
the
queue.
If
you
don't
have
a
question
so.
C
E
Okay,
assuming
that
is
a
spurious
in
queuing
from
Rowan
all
right,
so
I
apologize,
I
just
got
into
the
room
here
and
I
missed
the
whole
chairs
intro.
But
what
I
was
gonna
present
here
is
an
update
from
the
design
team
that
we
discussed
back
at
the
ITF
meeting,
give
folks
an
update
on
kind
of
what
the
design
team
has
been
discussing
and
how
far
we've
gotten
and
one
of
the
outputs
of
you
know,
snapshots
of
what
we've
gotten
so
far
is.
Is
this
architecture
concept?
E
Yeah,
so
if
you
cast
your
mind
back,
oh
these,
several
weeks
to
Late
July,
we
had
some
discussion
at
the
ietf
meeting
about
adopting
some
of
the
protocol
drafts
that
existed
then
and
ended
up
not
having
consensus
to
adopt
any
of
the
things
that
were
existing
at
that
time.
And
so
there
was
a
suggestion
from
the
working
group
that
we
get
a
smaller
kind
of
design
team
together.
E
I,
don't
think
it's
an
official
working
group
design
team,
but
I
don't
bothered
much
by
the
process
there,
but
it's
a
group
getting
together
and
trying
to
come
up
with
a
proposal
for
adoption
in
late
September
or
so
that
has
a
little
bit
more
broad
base
of
consents
and
you
know
involved.
You
know
you
know
you
can
see.
E
The
working
group
can
then
can
work
on
and
to
be
clear
and
set
expectations
properly
here,
right,
obviously,
in
the
ITF
adopting
a
document
does
not
mean
the
document's
done,
and
so
these
documents
should
be
you
know.
Even
you
know,
once
we've
been
through
this
design
team
process
should
be
reviewed
as
starting
points
as
points
for
further
refinement.
E
So
we
commissioned
that
design
team
back
in
July.
Since
then,
the
design
team
has
been
diligently
working.
We
had
a
face-to-face
meeting
after
the
Mimi
working
group
meeting
as
it
comes
on
Friday
morning
by
ATF
week
kind
of
had
some
initial
discussion
about
what
an
architecture
looks
like
and
what
the
overall,
how
the
overall
system
fits
together.
E
There's
been
three
design
team
calls,
since
the
ietf
of
which,
in
all
I'm
saying
this
too,
because
I
was
on
vacation
but
I
hear
they
did.
They
got
a
lot
of
work
done
largely
so
far
been
kind
of
discussing
architecture,
approach
and
working
through
some
basic
example
cases.
So
you
know
how
what
should
it
look
like?
What
should
the
operations
be
when
someone
when
the
room
is
created
and
someone's
added
to
the
room?
E
Etc
a
couple
of
General
bounding
concerns
and
desiderata
that
have
come
up
as
I
think
understood
the
goals
of
this
effort.
You
know,
obviously,
as
the
charter
says,
engine
Security
based
on
MLS,
but
we're
trying
to
phrase
things
a
little
more
generally
in
case
folks
want
to
bridge
in
other
stuff.
Not
you
know
not
within
the
context
of
the
working
group,
but
you
know
defining
a
clear
demarc
in
case
someone
else
in
some
other
context
wants
to
wants
to
do
that.
E
An
interesting
concept
that
came
in
I
think
starting
from
the
discussion
with
the
atfd,
was
this
idea
of
object
level
of
authentication
of
protocol
messages,
which
you
know
exists
in
some
protocols
now.
This
is
emphasized
to
different
degrees
in
different
protocols,
but
I
think
this
idea
of
a
very
pervasive
authentication
kind
of
came
in
from
the
New
Media
stuff,
and
this
is
infiltrated
some
of
the
ongoing
ideas.
I'll
say
more
about
that.
F
E
So
those
you
know
kind
of
General
ideas
that
are
guiding
the
discussions
are,
in
the
background
of
discussions
that
you'll
you'll
kind
of
see
coming
up
in
some
different
ways
in
more
details.
So
this
this
draft
I
published
yesterday,
we've
kind
of
had,
is
a
working
document
to
to
Prime
the
discussions.
So
we've
tried
to
capture
areas
where
the
design
team
has
clear
ideas
and
agree.
You
know
things
we
agree
on
and
also
help
Drive
the
discussion
forward
by
making
some
proposals
in
areas
where
there
is
ambiguity
or
disagreement.
E
So
it's
it's
a
mishmash
as
it
stands
right
now.
That's
that's
what
it
means
to
be
a
working
document.
It's
not
the
you
know,
not
authoritative.
It's
just
trying
to
capture
the
state
of
where
the
discussion
is
right
now
and
as
you'll
see.
If
you
look
at
the
document,
there
are
some
things
that
are
clear.
E
There's
some
some
notes
in
there
flagging
areas
where
more
work
is
required
or
whether
there's
a
disagreement
overall
as
and
so
most
of
the
rest
of
the
deck
today
is
kind
of
going
through
the
ideas
in
there
and
teeing
up
some
discussion
around
some
of
those
areas
of
disagreements.
You
can
have
some
design
real
live
design.
Team
discussion,
maybe
in
this
working
group,
called,
hopefully
bring
the
rest
of
the
working
group
in
so
they
can
understand
where
the
design
team's
gotten
to.
E
That's
pointed
in
the
right
direction
and
I'm
hopeful
that
this
having
this
architecture
in
mind,
at
least
with
some
degree
of
fidelity,
will
give
us
some
confidence
in
adopting
these
starting
points,
and
you
know,
because
we'll
have
some
idea-
that
these
starting
points
have
the
right
shape.
They're
pointed
in
the
right
direction,
I
think
that's!
My
last
slide
on
design
team
status.
E
E
So
this
is
a
recap.
You
should
recognize
the
slide.
It
was
in
the
deck
at
the
ITF
meeting,
the
the
design
team
had
some
discussion
about.
You
know
just
confirming
that
we
are
in
this
client
to
server
to
server,
to
server,
to
client
architecture
where
there
is
a
hub
server
and
there
are
followers
or
there's
the
Hub
server
is
where
a
room
you
know
a
room
is
the
organizing
concept
should
be.
D
E
In
you
know
many
many
messaging
systems
room
is
the
organizing
concept.
There
is
a
a
server
to
which
that
room
is
homed.
We've
been
using
the
word
hub
for
that
and
follower
for
other
servers
and
everything
that
happens
in
the
room
gets
routed
through
that
Hub
server,
so
clients
access
the
systems
via
their
servers
by
a
server
for
their
provider
and
then
servers
exchange
events,
objects
or
the
terminologies
a
little
influx.
But
there's
there's
things
that
the
servers
exchange
with
authentication
that
kind
of
make
the
room
go.
E
Some
of
these
things
capture
messages
that
are
the
actual
messaging
functionality.
Other
things
capture
changes
to
the
room
you
know
joins
and
layers,
and
that
sort
of
thing,
so
hopefully,
this
this
client
to
server
to
server
to
server
to
client
architecture,
looks
familiar
to
folks
next
slide.
Please
one
area
of
clarification
that
came
up
in
the
discussions
was
whether
we
really
really
mean
that
everything
goes
via
the
Hub
and
in
particular
the
thing
that
that,
for
that
was
a
little
unclear
when
the
discussion
started.
E
E
E
So
if
server,
a
and
server
B
are
both
interacting
with
server
C,
which
is
the
home
of
the
room,
then
clearly
a
is
what
we
work
with
c
and
b
is
willing
to
work
with
c
and
so
there's
a
communication
path
there,
and
we
should
rely
on
that
communication
path
instead
of
relying
on
also
having
a
communication
path
between
A
and
B,
Because,
A
and
B
might
not
be
willing
to
talk
to
each
other.
If
they've
decided,
you
know
each
other,
you
know.
E
Maybe
a
has
decided
that
b
is
a
spammy
server,
but
it's
willing
to
interact
with
via
server
C
in
that
specific
context.
So
there
may
not
be
a
communication
Channel
server,
a
between
a
and
b,
and
so
everything
really
everything
in
the
channel
goes
via
the
Hub,
really
getting
all
three
of
those
s's
in
there.
Every
time
got
to
make
sure
we
cross
all
the
Hops
next
slide.
Please
and
people
should
feel
free
to
enqueue.
Ask
questions.
Tell
me
I'm
crazy
at
any
point
here.
Hopefully
this
is
all
sounding
pretty
familiar
folks:
yeah,
listen.
A
I
wanted
to
either
ask
or
sort
of
point
out
that,
in
the
case
where
the
the
Hub,
the
recipient
user,
is
actually
attached
to
the
hub,
there's
only
two
servers
involved
so
like
the
number
of
s's
in
the
middle
is
sort
of
less
relevant
than
the
Hub
and
follower
aspect.
I
know
that
we
like
to
talk
about
which
kind
of
protocol
are
we
doing
here,
but
I
think
that's.
E
E
E
We
should
we
should
capture
the
document,
it's
not
in
there
right
now,
but
I
think
the
the
thing
what
people
have
in
mind
is
there
is
at
any
given
time
there
is
a
single
Hub
to
which
the
room
is
home,
so
there's
a
room
does
not
have
multiple
hubs
and
that
the
Hub
is
not
simply
a
blind
forwarder,
but
it
can
all.
It
is
also
acting
as
a
policy
control
Point
as
as
well.
This
was,
as
I
recall,
a
point
of
discussion
at
the.
I
E
G
Right
so
I
guess
I
guess
the
reason
yeah
yeah
right
well
independently
enforce
the
policy,
but
that
right,
I
guess
the
part
of
what
I'm
asking
is
if
it's
possible
first,
is
for
hubs
to
move
then
for
or
for
our
communication.
Then
this
this
point
here
about
this
this
last
last
major
ball
in
the
slide
may
have
may
have
a
real
problem
in
this.
You
know
that,
maybe,
if,
if
a
and
b
are
not
only
talking,
then
the
pub
cannot
move
to
B,
because
it's
bad
news
right
so.
D
I
G
We
will
be
important
to
establish
quite
early,
so
I
think
this
is
a
good
design,
Choice,
but
I
think
that
I
think
I
think
it
has
some
consequences
and
I
think
one
of
them
is
that
portability
plays
more
difficult
and
I'm
perfectly
fine
enough
in
portability,
but
others
may
not
be
so.
I
just
wanted
to
fly
that.
E
G
Well
right,
but
I
guess
what
that
means
is
that
you'll
you'll
then
need
a
mechanism.
You
know,
then
patient
need
to
elect
a
new
Hub.
Not
just
not
just
have
one
stand
up
right
and
you
say
see
it's
like
it's
like
I
mean
starting
like
so
the
sort
of
implied
structure
of
the
current
system
that
I
understand.
G
If
you
think
that,
if
you
think
there's
no
non-requirement
that
every
service,
when
you
touch
every
other
Surfer,
then
it
may
be
Pro.
It
may
be
the
case
that
a
room
can
Decay
to
the
point
where,
where
it
can
no
longer
be
possible
to
have
it
work,
because
if,
if
if,
if
you
say
hubs
are
garbage
collected
when
there's
no
longer
going
to
be
on
them
and
not
everyone,
you
don't
have
a
full
measure.
G
Communication
then
give
a
possible
that,
like
when
the
last
person
from
surface
a
lead,
students
or
C
leaves
like
the
communication
just
falls
apart,
even
though
A
and
B
is
still
in
the
room,
and
so
that's
not
undesirable.
I'm,
sorry
about
outcome,
and
so
I
just
wanted
to
find
that
so
like
so
so
it
may
be
more
complicated.
E
Yes,
I
mean
yeah,
I,
mean
I.
Think
there's
you
know
multiple
ways
that
these
things
can
resolve
right.
Like
hopefully
you
know
in
an
ideal
world
like
we
wouldn't.
Actually
you
know
we
could
design
to
accommodate
these
reachability
problems
and
they
may
not
materialize
in
reality.
Maybe
there's
you
know
that
there's
a
the
community
of
servers
out
there,
that's
officially
large
and
everyone's
willing
to
talk
to
one
another
within
that
space,
and
so
affordability,
just
works
so
yeah
I
think
there's
a
little
bit
of
kind
of
buildings.
E
Well,
I
think
that
is
certainly
what
we
will
build
first,
because
yeah
I
think
just
practically
I
think
the
the
portability
stuff
is
scheduled
behind
getting
the
thing
working.
So
certainly
the
word
world
we
will
build.
First
will
at
least
Define
standards
for
first
will
be
a
world
in
which
the
Hub
doesn't
move.
E
No,
you
know
Zachary
points
out.
You
might
have
all
the
all
the
serversy
users
leave
and
then
you
know
maybe
you're
rely
on
service
use
charity.
Maybe
that's
okay.
Maybe
we
don't
need
portability,
but
I
I.
Think
that's
that's
a
question
for
a
bit
down
the
line.
Travis
did
you
have
comment?
I
saw
you
pop
up
and
back.
H
E
E
E
But
the
folks
agree
that
that
the
creation
of
a
room
is
not
something
that
you
do
using
a
meme
protocol,
because
when
it's
a
room
is
created,
it's
between,
whichever
user
created
the
room
and
its
local
local
provider,
and
so
the
mechanism
to
create
the
room
is,
as
is,
is
local
to
that
provider,
and
so
because
Mimi
is
about
into
provider
relationships,
we
don't
need
any
protocol
to
do
it
now.
The
caveats
of
that
is
that
when
you
create
a
room,
it's
going
to
initialize
the
room
with
some
stuff.
E
It's
going
to
make
some
initial
crypto
State.
Some
initial
policy
State
and
you're
going
to
ultimately
need
to
share
that,
with
with
other
particip
other
providers
who
are
going
to
participate
in
the
room
after
its
creation,
so
there
will
there
will
be
protocol
results.
You
know
the
the
state
that
the
protocols
help
thinks
and
talks
about
will
get
initialized
by
this
creation
operation,
but
there's
no
kind
of
message
that
is
sent
in
the
protocol
to
accomplish
the
operation.
D
G
E
E
G
Yeah
right,
but
if
but
if
but
if
I
was
on
WhatsApp
and
you
were
on
wire
than
us,
then
the
order
of
operations
is
I,
created,
empty
room
or
not
empty
a
room,
a
size
one
in
WhatsApp
and
then
add
you
on
wire
right.
So
this
is
like
an
MLs
question.
Okay,
MLS
groups
only
have
one
have
exactly
one
member.
E
E
E
But
yeah
that
may
be
something
the
document
more
clearly
is.
The
assumption
is
that
this,
the
initial
population
of
the
room
is
local
to
a
specific
provider
and
then
in
other
users,
local
to
other
providers
can
then
be
added
to
the
room
and
I.
Don't
think
it
really
matters
whether
it's
one
person
within
that
provider
or
multiple
users
I
think
this.
E
E
L
Sorry
I
hit
the
wrong
button.
Thank
you.
Yeah,
before
we
move
on
I
think
it
is
important
to
Define
this,
but
it
could
maybe
happen
later.
I
just
see
a
real
problem
with
often
what
happens
say
with
people
who
often
are
communicating
with
one
another
is
that
they
go
to
their
chosen
app
and
then
they
add
in
the
people
they
want
to
talk
to
whether
or
not
they
have
an
open
group
chat,
and
it
would
be
a
vastly
different
experience.
L
E
With
regard
to
kind
of
opening,
your
preferred
app
and
adding
people
I
think
there's
a
little
bit
of
a
separation
here
between
the
user
experience
and
the
protocol
operations.
I
I
think
you
could
have
a
user
experience
where
I
open
up,
say:
WhatsApp
I,
add
you
know
my
friend
Alice
who's
on
wire,
my
friend
Bob
who's
on
Wicker
and
just
hit
make
a
you
know,
start
up.
E
L
That
makes
a
lot
of
sense,
but
it
would
be
frustrating
if,
a
week
ago,
those
same
people
were
talking
and
Alice
had
created
the
room
last
week,
and
that
means
you're
in
two
different
rooms
now
with
the
same
people,
because
Alice
and
you
are
on
different
providers,
and
so
you
have
different
rooms.
That's
all
I'm
trying
to
say
is
that
that
is
often
a
very
common.
In
my
experience,
anyway,
it's
a
it's
a
really
common
mode
of
user
operations,
and
that
could
just
lead
to
a
lot
of
confusion.
E
M
Yeah
just
to
quickly
add
to
that
I
think
it's
a
very
important
point,
but
I
think
providers
are
capable
of
achieving
any
kind
of
ux
that
desire.
In
that
instance,
they
could,
as
you
said,
Richard
promote
an
existing
room
from
an
MLs
perspective.
There
is
no
reason
that
would
stand
against
that
if
they
want
to
instead
clone
a
room
and
I
have
a
different
group.
They
could
also
do
that
so,
but
from
the
protocol
perspective
both
are
possible,
so
it's
not
prohibitive
in
any
way.
I
think.
E
Okay,
cool
all
right,
so
that's
creation
and
ownership
like
I
was
like
messaging,
is
kind
of
the
next
simplest
thing
in
that
server
yeah,
the
messaging
is
presumed
to
be
intent
encrypted.
So
the
actual
contents
of
the
messages
are
only
going
to
be
accessible
to
the
clients,
which
is
why
we
have
a
messaging
format.
Draft.
It's
already
adopted
that
says
what
the
contents
of
those
messages
are.
E
So
at
a
certain
level,
the
servers
are
really
just
forwarding
things
and
it
follows
This
Kiss
pattern
where
you
know
the
user
submits
a
message
to
their
origin:
server,
the
origin
submits
it
to
the
hub,
The
Hub
fans
it
out
to
everybody
else,
who's
in
the
room.
So
basically
the
Hub
needs
to
know
all
the
servers
who
are
involved.
The
servers
need
to
know
all
which
of
their
users
are
involved
in
the
room.
E
Now,
as
we
discussed
a
few
points
up,
the
other
thing
that
servers
can
do
in
addition
to
forwarding
messages
is
apply.
Authorization
policy,
so
I
think
we
are
assuming
that
it
will
be
visible
to
the
servers
who
is
sending
a
message
and
so
an
aspect
of
the
authorization
policy
that
one
could
could
imagine
is
you
know
whether
a
given
user
is
authorized
to
send
messages
into
the
space
or
who
we
receive,
and
so
that
sort
of
policy
can
be
applied
even
outside
of
the
envelope.
E
D
E
Actual
thing
we're
trying
to
do
the
messaging,
the
cool
stuff
we've
been
kind
of
push-offs
inside
so
yeah,
that's
that's
straightforward,
we'll
get
to
it
and
then
let's
focus
on
how
we
maintain
the
state
of
the
room.
So
obviously
a
room
is
going
to
have
some
State
Associated
to
it.
Aside
from
just
the
messages
that
are
sensitive,
it's
going
to
have
you
know
cement
and
encryption
State.
You
know
the
keys
and
credentials
that
are
involved
in
a
group
at
least
the
public.
E
That's
what
the
United
serve
in
the
private
space
will
obviously
be
private
to
the
clients.
It'll
have
authorization
policy,
you
can
imagine
you'll
consent
things
that
would
be
attached
to
it
and
Etc.
So
we,
you
know
I'll
get
into
some
of
the
details
of
the
state,
but
but,
broadly
speaking,
you
know
it's.
The
job
of
the
servers
to
collaborate
in
the
maintenance
of
the
state
I
think
it's
probably
accurate
to
say
that
the
Hub
is
the
authoritative
there's
a
source
of
the
state,
and
other
servers
may
suggest
things.
E
E
So
now,
turning
a
little
bit
to
look
at
the
protocol
stack
and
kind
of
how
we
accomplish
those
jobs,
as
we
we
said
above,
the
Mimi
protocol
is
either
server
to
server
or
client
to
clients.
So
the
stuff
that
is
not
end-to-end
encrypted
is
server
server
and
stuff.
That
is,
and
then
encrypted
is
clients,
quiet
and
we've.
This
is
you
know.
Like
a
a
few
days,
old
we've
only
had
a
little
bit
of
discussion
about
this.
E
E
Encapsulation
and
formats
formats
we
already
have
says
messaging,
which,
like
I
said,
is
pretty
straightforward,
closer
to
the
servers
and
more
more
directly
in
between
the
servers.
Is
this
idea
of
control.
So
this
is
this
goes
the
the
the
job
of
maintaining
the
state
of
the
room.
So
the
idea
is
that
two,
the
word
we
use
for
the
kind
of
sub
protocols
that
manage
the
room
state
are
control
protocols.
E
G
G
Mean
but
the
mechanic
is
what
I'm
supposed
to
be
taking
home.
The
mechanics
is
that
the
control
messages
are
conceptually
end
to
end
routine
provider,
a
and
provider
B,
but
they're,
also
end-to-ending
writer,
a
in
their
hop
is
that
correct.
Is
that
with
atmosphate
getting
in
mind
or
or
even
not
end
end
or
how's?
Everybody
thinking
at
this.
E
Yeah,
this
document
probably
need
this
diagram
probably
needs
some
iteration,
because
I
think
the
the
the
framework
is
Probably
sounds
more
like
I
think
what
I
said
on
the
last
slide,
where
there's
when
a
server
is
submitting
proposals
for
changes
they
get
submitted
to
the
hub
over
some
control
protocol
and
then
the
Hub
distributes
the
changes
to
other
folks.
Other
servers
in
the
room
so
they're
up
to
date
again
using
using
a
control
protocol
but
I.
G
G
E
Idea
here
is
that
in
fact,
we
we
should
authenticate.
You
know
authenticate
messages
according
to
where
they
originated.
So
if
it
is,
if
there
is
a
change
that
is
provide
proposed
by
provider
a
it
is
authenticated
by
provider
a
in
a
way
that
all
of
the
other
servers
can
verify
it,
and,
in
fact,
I
think
one
of
the
active
areas
of
discussion
is
whether
we
we
also
do
that
at
the
at
the
client
there.
H
Sorry
30
second
lie
again
the
control
protocols,
it's
sort
of
described
here,
I
know
on
the
design
team
we've
been
using
some
other
words.
That
may
not
be
totally
understood
by
the
group
here,
but
I
just
want
to
kind
of
confirm.
Is
this
what
we've
been
previously
calling
signaling
or
it's
I
guess
like
handles
some
of
the
encryption,
some
of
the
user
level
stuff.
E
Yeah
so
I
think
in
in
my
intent
here
was
to
have
control
and
Compass
all
of
the
different
State
Management
things
so
control,
maybe
more
as
sort
of
a
layer
encompassing
a
few
different
soap
protocols.
So
you
might
have
so.
We've
been
using
the
word
signaling
I,
think
in
the
design
team,
as
in
terms
of
things
that
control
things
like
policy
things
and
control
things
like
abstract
membership.
E
M
Yeah,
just
a
quick
introduction,
you
said
earlier
that
it's
still
under
discussion,
whether
or
not
it
should
be
clear
to
everybody
when
clients
actually
initiated
something
and
signed
something.
So
that,
of
course,
is
already
the
case
for
MLS,
obviously,
because
those
messages
always
originate
from
the
clients
and
are
signed
by
the
clients
and
they're
visible
to
everyone
along
the
Route,
and
so
for
that
that
part
of
the
protocol.
That
question
is
already
answered.
E
I
I
just
had
a
follow-on
from
Travis
and
Chancellor
trying
to
understand
the
shift
of
signaling
to
control,
which
is
absolutely
fine
in
terms
of
terminology
shift,
but
more
kind
of
what
the
etymology
is
I
mean.
Should
we
be
thinking
of
this
like
media
resource
control,
protocol
stuff,
that
kind
of
is
sitting
on
top
of
other
existing
signaling
protocols
like
sip
in
order
to
orchestrate
things,
or
is
that
coincidence,
or
did
wordges
come
from
kind
of
grasping
for
something
that
wasn't
as
confused
as
people
were
getting
over?
What
the
word
signaling
means.
E
I
Yeah-
and
that
makes
a
lot
of
sense,
specifically,
control,
manipulate
State
messages
sends
actual
messages
and
the
state
that
you
control
with
the
control
protocol
could
be
encryption
state
or
it
could
be
a
metadata
about
the
room
or
it
could
be.
The
membership
of
the
room
or
the
policy
of
the
room.
Etc
sounds
great
yeah.
E
Okay,
so
so
working
through
this
kind
of
from
the
bottom
up
now,
I've
included
some
some
fixed
width
font
stuff
on
the
left
hand
side
just
like
totally
notionally.
This
is
not
how
you
would
actually
do
it,
but
the
idea
of
you
know
I
think
the
functionality
we're
trying
to
wrap
up
in
this
transport
in
the
design
team
book
has
been
calling
kind
of
a
thick
transport
or
chunky
transport,
because
it's
not
just
delivering
fights,
it's
not
just
a
done
pipe.
E
The
idea
here
is
to
basically
provide
an
authenticated
Eventing
framework
that
the
control
and
messaging
layers
can
use
so
Define.
You
know
a
way
to
you
say
what
an
event
is
a
way
that
you
authenticate
who
sent
that
event
and
then
also
yes,
the
physics
of
how
you
get
that
event
from
one
server
to
another.
E
So
if
you
look
at
the
protocols,
there
are
others
from
the
predecessors
that
we
discussed
in
July,
and
this
is
kind
of
like
the
pdu
framework.
You
know
Matrix
has
these
pdus
that
are
assigned
by
their
Origins
these
transactions,
the
passing
pdus
around
the
Mimi
DS
protocol
had
these
DS
requests
that
were
assigned
and
went
across,
so
that
is
to
kind
of
capture
that
functionality
in
this
layer
and
I
believe
in
our
last
call.
E
Oh
yeah
yeah,
absolutely
so
so.
I
think
the
the
idea
of
the
transport
protocol
would
be
so
by
when
I
say
the
transport
protocol
I
mean
some
other
document,
not
the
architecture
that
I
think
some
combination
of
Raphael,
Travis,
Conrad
Etc
will
be.
Writing
will
Define
all
of
these
bits
and
Define
them.
You
know
at
least
a
way
to
do
that
that
the
other
layers
of
the
stack
will
assume.
I
E
Foreign
yeah,
so
if,
if
folks,
like
deniability
they're,
going
to
be
sad
with
really
quite
a
bit
of
you
know
of
of
the
cryptographic
architecture
here,
because
MLS
is
all
based
on
signature,
there's
been
some
very
preliminary
thought
thinking
on
how
to
to
design
a
deniable
flavor
of
MLS.
But
right
now
it's
all
signature
based,
so
I
think
the
Baseline
here
will
be
that
that
you
know
the
not
much
is
going
to
be
deniable
right.
E
I
Yeah
I
mean
I'm,
definitely
obviously
want
to
authenticate
the
servers,
but
you
can
always
talk
here.
It's
a
feature,
if
you
end
up
having
to
trust
the
server
to
claim
the
traffic
on
behalf
of
its
users,
such
that
from
a
deniability
perspective,
a
user
could
always
claim
to
the
surface
in
that
traffic.
However,
if
we're
basically
putting
it
out
of
scope
for
MiMi,
because
MLS
already
eventually
has
a
horoscope,
then
I
mean
that
would
make
sense
on
this,
just
by
extension,
if
nothing
else,
I
just
wanted
to
check.
E
Yeah
I
mean
like
I,
think
what
I,
what
I
meant
to
say
is
like
MLS
is
going
to
make
at
least
the
messaging
non-deniable
so
like
that,
doesn't
necessarily
mean
that
we
should
not
have.
You
know
non-deniable
authentication
in
other
parts
of
Mimi,
but
it
does
mean
that
the
value
of
those
that
deniability
would
be
less
okay,.
B
G
I
I
think
this
is
like
because
it's
actually
fine
conceptions
about
all
I
can
say
at
this
moment:
I
just
wanted
to
flag
that
you're
you're
that
it's
implicitly
importing
A
New
Concept,
which
is
the
of
a
server
a
server
identity,
infrastructure
right
and
yeah.
You
may
just
say
well
pki,
which
may
be
fine
but
like
at
the
you
know
at
the
moment.
G
Until
this
moment,
the
only
Concepts
we
had
or
the
webpki
for
TLS
and
some
sort
of
unspecified
any
architecture
for
users,
and
this
implies
that
in
architecture
for
servers
as
well,
I
think
that's,
probably
fine
and
I.
Think
it
probably
can
be
the
one
pki,
but
I
just
want
to
make
sure.
Like
everybody
remembers,
that's
the
case.
E
G
G
G
C
I
do
think
that
is
going
to
be
important,
so
certain
very
important
players
and
who
might
be
adopting
this
not
Google,
especially
but
and
I'm
wondering
if
designing
this
around
group
level
signatures,
if
that's
the
right
term.
So,
like
you,
have
a
key
that
authenticates
you
as
a
religious
member
of
the
group
rather
than
you
as
an
individual
like.
Maybe
that's
something
that
we
should
design
optionally
into
this
and
I.
Don't
know
if
that's
compatible
with
MLS
as
well,
but.
E
C
E
D
C
O
E
Yeah,
so
I
I
should
have
been
a
little
clearer
on
this
slide.
I
think,
probably
what
we
want
is
actually
two
signatures:
a
signature
from
well
again:
module
of
the
other
conversation,
a
signature
from
the
user.
That
originated
an
event.
So
if
I
send
a
message
or
if
I'm
sending
a
proposal
to
you
know,
Grant
Bob
permissions
I
should
sign
that
message
myself
and
then
my
server
should
also
sign
it
as
originating
from
that
server.
Okay,
so.
O
Let
me
talk
about
the
latter,
which
is
a
server
signatures
which
I
am
unconvinced.
We
need
in
this
protocol,
and
the
reason
is
is
that
we
have
this
notion
that
there's
a
hub
right,
which
is
the
the
Central
Point
through
which
everything
flows,
and
you
could
use
just
polynold
mtls,
to
allow
the
Hub
to
know
who
the
followers
are
and
for
the
followers
to
know
who
the
Hub
is.
The
only
reason
that
that
would
be,
and
then
we'd
be
done
like
we
don't
need
anything
else.
O
What
the
only
reason
I
I
can
see
that
you'd
want
signatures
here.
Is
you
think
that
there
are
authorization
decisions
that
a
follower
will
make
about
another
follower
independent
of
the
decisions
that
the
Hub
has
made
and
I
can't
imagine
what
those
decisions
would
be
I
mean.
So
if
the
Hub
has
made
a
decision
to
accept
the
message,
do
you
really
want
the
follower
to
independently
say:
oh
I,
don't
I,
don't
you
know
yeah
this?
O
N
I
I
can
give
a
specific
example
of
folks,
don't
mind
me,
jumping
the
queue
please
go
ahead.
Yeah
so
keep
claiming
key
packages
and
obtaining
obtaining
user
level.
Consent
are
both
activities
that
may
require
one
follower
to
obtain
this
from
another
follower
through
the
Hub,
and
it's
very
useful
in
this.
In
both
of
these
cases
to
know
what
is
the
origin,
you
know,
what
is
the
origin
follower.
N
Sorry,
this
mute
is
taking
a
long
time.
The
follower,
the
the
the
the
follower
is,
the
one
that's
originating
the
message,
because
the
end
user
is
used
potentially
using
their
own
native
protocol.
In
order
to
do
this
so
there's
you
know,
you're
translating
from
say
the
WhatsApp
protocol.
The
client
clicking
on
I
want
to
do
a
you
know.
N
O
I
understand
the
use
case,
I'm
saying
I
still,
don't
know
why
you
need
the
signature
per
se,
which
is
as
the
there's
two
followers
here
right,
there's
the
one
that
originated
the
connection
request
and
then
the
one
that
received
it,
the
one
that
received
it
like.
Why
do
they
need
to
I'm,
not
saying
they
don't
need
the
we
need
to
know
who
the
originating
user
was
that
sent
the
connection
request.
O
There's
no
dispute
on
that,
because
the
recipient
received
the
connection
request
has
to
make
a
decision,
yes
or
no
right,
but
the
Hub
is
going
to
already
authenticate
and
authorize
the
follower
that
sent
the
connection
request,
and
so,
if
that
was
invalid,
it
would
have
dropped
it
it
didn't
it
forwarded
it
to
the
receiving
follower.
Why
does
the
receiving
follower
need
to
authorize
that
this
has
not
been
tampered
with
as
if
it
was
the
Hub
would
have
rejected
it?
That's
that's
the
that's.
M
Yeah
I
guess
it's
my
turn
anyway,
so
I
think
I
can
speak
to
that.
If
we
just
go
back
a
little
bit,
I'll
first
answer
child's
concern
and
then
I
go
back
to
that
because
usually
it's
me
who
ends
up
speaking
when
it
comes
to
deniability.
So
today
is
not
going
to
be
an
exception,
so
I
think
the
question
Matthew
brought
up
is
really
interesting
and
I
hadn't.
Given
it
a
lot
of
thought
in
the
context
of
Federated
messaging
I
had
a
server
to
server
layer.
M
M
So
yeah
as
Richard
clarified
the
signatures
we
are
talking
about
on
this
slide.
They
are
server
to
server.
So
whether
or
not
we
need
deniability
at
that
level,
the
whole
new
question
my
gut
feeling
is,
we
don't
need
it
and
it's
going
to
be
weird,
but
let's
see
happy
to
discuss
for
the
signatures
used
in
mls
in
in
the
vanilla
core
protocol,
there
is
no
deniability,
as
Richard
already
pointed
at.
M
We
are
looking
into
how
we
can
improve
that
for
those
who
want
it
and
I'm
also
aware
of
this
one
gatekeeper's
requirement
there
and
that
is
sort
of
disconnected
from
the
transport,
in
the
sense
that
it's
a
it's
a
different
kind
of
authentication
that
it's
really
end
to
end
it.
It
could
be
tainted
by
the
transport,
of
course,
because
then
the
transport
gives
you
some
proof
that
a
you
know,
a
message
has
traveled
between
two
servers,
at
least,
but
not
necessarily
between
two
users.
M
So
you
know
that
that's
something
that
is
not
completely
impossible,
but
yeah.
This
is
also
the
place
where
I
say
it
would
be
great
if
the
folks
who
want
deniability
speak
up
and
say
so
on
the
record
now
going
back
to
Jonathan's
question
here.
The
the
whole
motivation
for
the
signature
was
that
between
two
servers,
meaning
a
follower
and
a
hub
or
a
hub
and
the
next
follower,
the
idea
was
to
have
mutual
authentication
and
one
way
of
achieving.
That,
of
course,
is
to
do
mtls.
D
M
G
So,
like
you
know,
I
think
it's
going
to
create
I
think
having
having
things
which
are
authenticated
only
in
One
Direction
and
then
and
then
relying
on
the
signatures
on
the
other
thing
carried
above
them
to
to
provide
authentication,
somehow
implicit
application.
The
connection
seems
bad
remember.
The
signatures
are
not
probably
confidentiality
for
the
data
so
like.
Unless
this
is
done
very
carefully,
we
can
have
a
situation
where
we've
authenticated
one
side
of
the
connection,
but
you're
talking
the
attacker
and
the
attacker.
G
Basically,
the
attacker
is
basically
initiated
Connections
in
both
directions
and
he's
now
proxying
back
and
forth,
and
he
he
can't.
He
can't
adjust
anything,
but
he
can,
but
he
can
see
it
so
people
should
bite.
The
bullet
do
and
do
mgls
not
try
to
not
try
to
work
around
it
with
something
at
the
layer
above,
but
you
need
very
hard
to
talk
about
the
intelligently
about
and
reason
about,
the
security
properties
of
the
system.
If
we
don't
do
that
so
I'm.
D
G
To
do
that,
then
we
should
just
then
we
should.
Then
we
should
do
a
channel
binding
or
something
else
that
binds
the
connection.
What
we
should
not
do
is
use
signatures
at
the
at
the
at
the
not
necessarily-
maybe
maybe
not
Jonathan
Channel
bindings
the
appropriate
technology
here
really,
but
in
any
case,
what
you
should
not
do
is
use
signatures
as
as
as
a
way
to
avoid
avoid
mtls
I'd
assume.
G
The
purpose
of
this
exercise
was
to
I
was
to
distinguish
between
actions
initiated
by
the
by
by
someone
who's,
not
the
Hub
on
the
other
side
of
the
Hub
and
the
Hub
right.
So
it's
a
Concrete
example
say
that
the
say
that
I
know
a
user
of
the
bees,
the
Hub
and
a
user
of
C
reports.
A
message
is
abusive,
Senpai
Sun
by
someone
from
a
and
they
want
to
be
propagated
back
to
a
we
don't
want
B.
G
We
don't
want
the
Hub
being
able
to
pretend
that
something
was
abusive
when
it
actually
was
reported
abused
by
someone
by
user
received
when
it
was
not
that's
what
I
understood
the
technology
has
to
be.
If
we
don't
think
any
of
those
situations
are
are
relevant,
then
we
may
begin
their
way
without
this
integers,
but
I'd
assume
the
situation
was
we
want
to
distinguish
between.
As
I
said
things
initiate
by
the
holidays
issue
by
the
Leafs.
G
K
K
So
what
we're
going
to
do
is
is
move
like
accurate's
presentation
from
the
second
hour
on
Discovery
requirements
to
the
next
interim,
that
we'll
have
to
make
more
room
to
discuss
architecture,
but
we
still,
we
still
intend
to
get
to
the
remainder
of
the
user
Discovery
stuff.
Okay,
so
with
that
I'll
reopen
the
queue.
So
we
can
pursue
discussion
of
this
current
topic.
Thanks.
E
Sure
I
was
hoping
we
could
wrap
up
the
transport
topic,
because
that
was
the
easy
slide.
So
thank
you
Tim
for
and
shares
for
the
the
extra
time
because
we
can
definitely
fill
it.
So
I
think
that
I
appreciate
the
discussion
on
the
transport
stuff.
I
think
that's
a
lot
of
good
input.
I
will
ask
I,
suggest
we
kind
of
take
that
back
to
the
design
team
and
digest
a
little
bit
and
come
back
with
that
with
revisions.
E
So
let's
go
on
to
the
next
slide,
which
is
about
kind
of
these
control
protocols
and
what
those
might
look
like
so
yeah.
The
idea,
as
suggested
above,
is
that
if
you
look
at
a
room,
it's
going
to
have
a
few
few
types
of
state
that
are
mostly
independent
from
each
other
and
mostly
we'll
get
into
a
little
bit
in
the
slide.
The
next
one
right,
at
least
you
know,
end-to-end
encryption
State.
You
know
which
clients
have
the
keys
to
decrypt
and
authorization
policy.
E
You
know
which
users
and
which
servers
are
allowed
to
do
things
in
in
the
context
of
the
room.
So
those
are
pretty
distinct
types
of
State.
You
know
MLS
does
a
lot
to
do
into
an
encryption
state.
Does
nothing
for
policy
there's
some
good.
You
know
policy
management,
stuff
and
Matrix
and
related
protocols
that
this
operates
entirely
independent
in
encryption.
E
So
the
the
con
kind
of
concept
here
is
that,
for
each
type
of
this
state,
Mimi
should
Define
a
corresponding
control
protocol.
That
does
the
stuff
that
is
needed
to
manage
that
state.
So,
on
the
end,
encryption
side,
you'll,
have
you
know,
objects
you'll,
send
via
the
transport
to
go
and
fetch
a
key
package
from
another
provider
via
the
Hub
you'll.
Have
you
know
events
you
send
to
add
and
remove
clients
for
users
who
are
participating
in
the
room?
E
Things
like
that
on
the
policy
side,
you
know
you
know,
there'll
be
some
event
that
articulates
the
creation
of
the
room
with
its
initial
policy.
There
will
be
something
that
declares
the
policy
envelope
for
the
room
the
Hub
sets,
and
then
there
will
be.
You
know,
proposals
to
modify
this
this
this
policy,
as
as
there
evolves,
so
the
grant
capabilities
do
not
capabilities
things
like
that.
E
So
the
idea
is,
you
know,
we'll
have
kind
of
these.
Parallel,
you
know
Proto
sub
protocols,
I've
been
thinking
about
that
use
the
transport
to
move
around,
but
manage
kind
of
independent
types
of
the
room,
State
and
and
this
this
left-hand
example
is
kind
of
an
example
of
one
of
the
things
you
might
see
in
the
M10
encryption
control
protocol,
where
Alice
on
provider
a
is,
is
requesting
a
key
package
for
Bob.
So
if
you
can
add
them
to
the
room-
and
you
know
it's
signed
obviously
one
of
the
controversial
ways.
E
D
E
Would
have
enough
types
of
events
and
enough
information
in
those
events
to
get
done,
whatever
jobs
it
needs
to
do
for
managing
the
state.
It's
in
charge
of
So
and
I've
got
got
some
more
controversial
stuff
on
the
next
slide,
but
any
questions
or
comments
on
this
kind
of
General
approach,
yeah,
listen.
A
Yeah
I
wanted
to
see
if
we
we
still
have
the
notion
of
sort
of
like
two
levels
of
policy.
When
you
talk
about
the
policy
envelope,
that's
like
this
is
the
span
of
policies
that
could
be
applied
to
this
room,
and
then
you
have
a
protocol
that
the
Hub
uses
to
communicate
what
that
is
set
at
initially
and
then
the
followers
to
adjudicate,
whether
that
they
want
to
make
changes
to
it.
H
E
F
E
E
Please
so
something
that
has
we've
gotten
to
has
kind
of
emerged
as
a
an
interesting
point
in
the
design
team
discussions.
Is
this
question
of
whether
you
can
be
a
member
of
a
room
in
some
meaningful
sense
without
having
any
clients
that
are
part
of
the
end-to-end
encryption
state
anchor?
Should
I
go
on
or
do
you
want
to
interject
there.
D
E
All
he
could
he
could
have
no
no
devices
I've,
never
known
him
to
be
that
you
know
without
devices,
but
it's
in
principle
possible
with
accurate,
could
have
no
devices
alive
at
a
given
moment
and
so
there's
no
way
to
join
into
the
intent
encryption
state,
but
I
can
still
kind
of
Mark
him
as
someone
who's
in
this
room.
Who
has
capabilities
in
this
room
as
part
of
the
policy
and
so
yeah
there's
a
question
whether
we
also
have
that
that
notion
of
user
level
membership,
that's
not
derived
from
cryptographic.
E
I
I
E
I,
you
know
log
in
and
use
my
my
web
client
for
some
time
and
then
I
just
delete
all
of
my
browser
State.
All
of
my
private
keys
go
away
and
I
leave
the
encryption
state
like
if
I
do
that
repeatedly,
that's
how
I
interact
with
the
room,
the
other
client
shouldn't,
have
to
be
bothered
with
all
of
that.
They
should
just
see
that
I.
Am
you
know
persistently
part
of
this?
E
That's
that's
one
argument
on
the
other
side,
if
you
don't
have
a
client
joining
the
room,
especially
if
we
have
this
notion
of
user
level
signing
that
we
discussed
in
the
transport
context,
then
you
can't
actually
do
anything
in
the
room.
So
certainly
you
can't
read
messages
if
you're
not
part
of
the
end-to-end
encryption
State.
Maybe
you
can't
even
like
sign
a
policy
message
to
say
you
know.
I
should
join
someone
else.
E
So
if
especially
in
that
case,
where
we're
signing
messages
from
users
like
there's
really
not
the
only
thing
you
can
really
do.
If
you
don't
have
any
clients
already
joined,
is
join
a
client
and
then
take
some
option
and
when
I
propose
level
before
we
start
processing
the
queue
as
a
possible
middle
way
here,
I
think
that
maybe
the
word
membership
is
hanging
up.
Speaking
as
we
were
earlier
of
Tainted
words,
it
seems
like
this.
E
You
know
we
already
I
think
a
pretty
good
agreement
that
there's
a
need
for
a
policy
protocol
independent
of
the
of
the
intent
decryption
right,
because
and
then
encryption
protocol
still
do
policy,
and
so
maybe
the
the
the
closest
thing
we
have
to
membership
outside
of
cryptography.
Is
this
idea
that,
like
this
user,
appears
as
a
subject
in
the
policy,
so
the
example
here
like
if
I
don't
have
any
clients
joined
I'm,
not
an
active
participant
I'm,
not
a
member.
E
If
we're
going
to
use
that
word
of
the
room,
but
if
I
do
show
up,
one
of
my
clients
does
show
up
it.
Has
these
capabilities?
It's
allowed
to
add
people,
but
not
to
send
messages
Etc
so
like
maybe
that's
a
close
enough
notion
to
map
onto
some
precedence,
but
just
let
me
throw
it
out
there.
So
that'll
open
the
queue
anchor.
G
G
So
I
think
that
the
use
case
that
I
think
here
at
two
use
case
I
think
are
important
to
some
degree
or
another
one
is
you
know
one
is
I
lose
all
my
devices
I
should
be
able
to
like
come
back
in
the
room
without
having
some
that
should
happen
automatically
right.
That
should
not.
That
should
not
require
some
some
user.
Some
person
to
be
involved
in
in
re-adding
me
so,
like
that's
I,
think
that's
one
I
I
think
perhaps
less.
G
G
They
should
continue
to
be
in
the
group
by
having
other
people
walk
around
and
so
I,
don't
I,
don't
like
I
can
imagine
eight
different
ways
of
doing
that,
but
but
but
I
think
I
think,
and
this
may
be
a
fine
one,
but
I
think
that's
the
required.
If
you
think
that's
not
a
requirement,
we
can
hear
that
now
because
we
simplify
things
dramatically.
If
we
didn't
have
to
solve
that
problem,.
E
G
N
N
I
agree
that
I
agree
that
you
need
to
be
able
to
have
somebody
who
was
who
was
a
user
who
was
added
and
then
deletes
all
their
clients
that
they
need
to
be
able
to
have
another
client
go
and
join
later
and
I.
Don't
think
that
that
is
membership
I
think
that
that
is
authorization.
They
are
pre-authorized
to
go.
N
That
user
is
pre-authorized
by
virtue
of
the
fact
that
they
were
added
once
so
I
think
by
keeping
these
Notions
separate
I
think
we
get
exactly
the
properties
that
we
want,
and
we
don't
have
this
confusion
about
what
a
member
is.
And,
furthermore,
you
know
having
been
through
quite
a
few
discussions
with
multiple
uses
of
the
word
member
I.
Don't
think
we
should
be
using
membership
to
or
the
word
member
to
be,
describing
anything
to
do
with
rooms
or
users.
N
I
think
we,
since
we
have
a
night
the
concept
of
membership
of
a
member
in
an
MLs
group
that
that
should
be.
That
should
be
reserved
for
that
in
order
to
invo,
to
avoid
even
the
possibility
of
confusion
and
that
we
have
another
perfectly
good
word:
participants
which
we
could
use
for
people
who
are
active
people
who
have
users
who
have
clients
of
whatever,
whatever
end-to-end
encryption,
variety
that
they
want
that
are
in
the
appropriate
and
and
encrypted
messaging.
E
So
Ron,
let
me
ask
a
question
real
quick
about
your
pre-authorization
notion,
which
I
think.
Clearly,
you
know
one
of
the
things
a
someone
who
is
in
the
room
as
Ecker
Point
knows
someone
who
is
in
the
room
and
has
lost
all
of
their
devices
should
be
able
to
add,
should
be
pre-authorized
to
add
new
devices.
E
Would
you
but
I
think
a
corollary
to
ecker's
point
about
durable
durability
of
of
being
in
the
room
would
be
that
any
policy
Notions
about
like
what
I'm
allowed
to
do
should
also
be
durable.
So
would
your
notion
of
a
pre-authorized
you
authorized
clients
user
be
compatible
with,
like
also
having
policy
about
that
user.
N
Yeah
yeah
and
exactly
what
is
written
in
the
in
draft
May
group
chat.
Draft
Mimi
group
chat
like
everything
that's
written.
There
is
consistent
with
that,
including
using
the
term
pre-authorization,
including
the
the
you
know,
the
blob
that's
defined
there
now
I
I
think
that
I
have
I
tend
to
have
this
notion
of
policy
as
being
a
very
narrow
thing.
Not
that
Richard
is
an
admin,
but
an
admin
is
allowed
to
do
this
and
go
consult
whatever
list
that
you
have.
However,
you
got
that
to
figure
out
who
isn't
you
know?
N
N
E
I
Okay,
I'm
trying
to
follow
this,
so
we're
saying
that
I'm
wondering
if
this
whole
explosive
material
thing
might
just
be
a
terminology
Gap
in
the
end,
maybe
possibly
so.
It's
surround
you're
saying
that
participant
is
okay
as
a
way
to
describe
users
who
might
not
have
devices
in
a
room
because
they
could
be
pre-authorized
members
or.
N
N
I
Okay,
so
it's
basically
saying,
rather
than
having
a
long-lived
room
membership
thing
that
lasts
for
as
long
as
that
user
is
associated
with
the
room.
Instead,
they
flip-flop
State
between
either
being
a
pre-or-farosed
user
or
a
participant,
depending
on
whether
they're,
currently
participating
in
the
MLS
group.
H
F
M
Yeah
so
I
think
Ron
said
the
most
important
bits
already
I
think
it
might
also
be
helpful
to
try
and
dissociate
what
the
potential
ux
is
with
the
actual
mechanism
that
we
have
at
our
disposal
with
MLS,
because
we
need
to
make
this
work
first
and
foremost
with
MLS,
and
what
Ron
proposes
to
to
have
this
pre-authorized
list
or
just
a
list,
no
matter
what
we
call.
It
is
exactly
how
that
could
work
with
MLS,
meaning
those
users
are
not
part
of
the
MS
group.
M
And
then
we
have
those
mechanics
locked
down
essentially,
and
the
important
bit
here
is
that
there
is
agreement
among
the
group
of
who
can
rejoin
the
MLS
group
with
that
mechanism
and,
and
once
we
have
that
now
down,
then
we
can
think
about.
You
know
what
the
potential
ux
is.
Do
you
display
these
users
in
the
same
way?
Do
you
display
them
differently?
G
O
O
What's
really
important,
what's
important
to
me
is
to
know
when
I
send
a
message
who
who
could
potentially
see
it,
because
that's
gonna,
it's
important
to
me
because
I'm
gonna
know
how
to
craft
that
message
right
and
so
whether
they
currently
have
a
valid
client
that
has
access
to
the
key
or
whether
they
don't
but
could
obtain
one
in
the
future
is
not
that
important
at
all
from
a
user
decision
making
process.
What
matters
is.
Might
this
person
potentially
see
this
message
and
the
answer
is
yes,
what.
O
Think
it's
important
for
us
to
recognize
that
that
exists
as
a
piece
of
state
that
is
facilitated
by
this
protocol.
In
addition,
it
did
being
used
for
policy
purposes
right.
We
want
to
want
the
Hub
to
say
oh
right
now,
my
policy
is,
is
that
you
know
Rowan
is
blocked
right,
he's
still
in
the
room,
but
he
can't
send
messages.
So
this
is
obviously
going
to
require
that
the
Hub
have
some
notion
of
who
people
are
and
be
able
to
look
at
lists.
G
G
Even
they
were
members
exactly
the
scenario
where
scroll
back
is
like
most
interesting
right.
It's
also
the
case
that
you
know
that.
There's
a
question
of
like
how
these
interface
behaves,
which
I
mean
we
can't
we're
trying
to
detaine's
interface
but
like
there's,
a
conceptual
difference
between
like
this
person
was
in
before
was
like
then,
before
the
machine.
Their
Vice
is
out-
and
you
know,
and
now
they're
back
in
again,
and
this
person
is
like
something
I've
never
seen
before.
G
I
expect
that
I
want
to
know
when
some
new
person
joins.
The
group
in
particular,
maybe
I'm
supposed
to
like
actually
yeah
I,
have
some
real
alerting
about
that.
But
I
don't
want
to
know
a
major
gets,
a
new
phone,
and
so
you
know
I
think
these
are
potentially
all
workable
from
user
interface
perspective.
But
I
think
this
does
tell
us
that
there's
some
mechanism
we
need
here
and
then
we
have
to
give
some
pretty
clear
guidance
to
people
who
are
Building
Systems.
G
D
E
B
B
So
that
should
not
be
a
problem,
because
at
that
point
the
user
has
one
device
in
the
group
already,
and
so
it's
just
a
user
even
on
the
MLS
level
and
the
other
situations
where
the
user
does
not
have
a
client
in
the
group,
which
is
the
situation
where
we're
talking
about.
So
that
would
require
scroll
back
between
users,
and
that
is
something
that
should
be
kind
of
visible
and
agreed
upon
on
the
group
level.
Or
you
have
two
users
who
are
kind
of
weirdly
colluding
without
it
being
part
of
the
group,
configuration
and
I.
B
B
If
we
wanted,
we
could
create
it,
but
that's
kind
of
that
would
open
up
a
whole
design
space
and
so
kind
of
just
having
this
pre-authorized
notion
of
users
that
are
allowed
to
do
a
very
specific
set
of
operations
such
as
rejoin
that
probably
works.
But
if
we
like
really
open
it
up
for
a
user
level,
interaction
where
the
user
can
kind
of
I
don't
know,
do
actions
without
being
a
part
of
the
MLS
group
and
those
without
kind
of
have
a
key
material
to
back
it
up.
B
D
F
D
E
A
B
N
I
think
that
that
is,
that
is
the
right
terminology
that
or
that
is
a
that
is
a
very
understandable
set
of
terminology.
There
could
be
other
good
sets
of.
You
know
terms
for
this
and
saying
that.
Well,
because
a
user
is
pre
just
because
a
user
is
pre-authorized,
they
might
at
any
moment
come
in
later
and
and
do
this,
the
I
I.
N
But
you
know,
as
the
as
the
you
know,
the
commit
arrives
basically
as
I'm
hitting
the
return
key
and
my
client
decrypts
the
the
commit
and
goes
and
sends
a
message
in
the
new
Epic
to
the
new
participant
like
that's,
that's
not
a
problem
that
Mimi
is
going
to
provide
the
answer
to,
and
also
this
idea
that
we
want.
We
want
to
exclusively
Drive
our
our
protocol,
based
on
based
on
the
user
experience.
N
This
is
not
going
to
be
100
possible
because
different
met,
popular
Messengers
have
different
user
experiences,
which
are
not
consistent.
You
just
have
to
look
at
how
how
like
group
DM
works
to
see
that
it's
not
possible
for
us
to
to
do
something.
That
is,
that
is
going
to
be
exactly
the
same
guidance
for
every
for
every
every
client.
There
are
going
to
be
some
variations.
N
So
I
think
the
terminology
that
I
proposed
works
I,
don't
think
it's
the
only
one,
but
I
think
that
it's
well
explained
and
if
you
read
the
the
group
chat
I
think
it
explains
how
to
do
everything
that
we
that
I
think
that
we
want
to
do,
and
nobody
has
said:
hey
I,
don't
think
you
can
do
XYZ
feature
or
this
such
and
such
interaction
Works.
If
you,
if
you
do
it
this
way.
Finally,
the
pre-authorization
rules
they
they
might
not
be
just
for
a
specific
user.
N
They
could
be
for
like
a
department
or
an
entire
domain
name
right,
and
so
we're
we're,
not
it
having
the
the
possibility
that
someone
could
go
and
inspect
that
possibly
using
some
separate
user
interface.
That
would
be
useful,
but
these
features
already
exist
now,
where
people
who
are
not
on
the
roster
can
join,
because
by
virtue
of
the
fact
that
they're
in
a
particular
domain
or
they're
in
somebody's
contact
list
or
what
have
you
or
they
used
a
join
link
that
they
had
and
so
rosters
can
change
quickly.
N
And
if
you
want
to
con,
if
you
want
a
client,
that's
going
to
inform
you
every
time
the
roster
changes.
If
you
were
about,
if
you
started
composing
before
you
sent
that's
a
feature
that
doesn't
exist
in
any
client
at
the
moment,
but
it's
a
valuable
feature.
But
we
can't
base
our
base,
our
protocol
and
our
terminology
on
a
feature
that
we
would
like
to
have
that
doesn't
exist.
Yet.
A
Yeah,
I
guess
I,
don't
know
if
this
agrees
with
what
you
were
saying
or
if
it
disagrees
with
it,
but
the
part
from
what
Jonathan
said
that
I
thought
was
very
useful
and
and
to
Ecker
is
to
sort
of
like
match
the
the
protocol
support
to
The
Entity
that
needs
to
act
on
it
so,
like
I,
do
think.
It's
probably
the
case
and
I'm
happy
for
people
to
disagree
that,
like
I,
really
don't
care.
A
My
question
is:
if
we,
if
we
think
about
this
pre-authorization
state
is,
if
you
can
only
put
yourself
into
it
or
if
it's
possible
for
anybody
else
to
put
you
into
it
I.E.
Obviously
we
want
it
to
be
possible
for
others
to
be
able
to
kick
you
out
of
the
MLS
group,
including
other
users
and
possibly
other
servers.
N
I
went
to
go
and
add,
add
a
user,
but
they
didn't
have
any,
but
their
server
was
down
and
so
I
couldn't
get
their
key
packages
and
then
I
know
that
I'm
going
offline
for
a
couple
weeks,
but
I
want
them
to
be
able
to
participate
in
the
discussion.
So
I
add
that
user
from
that
other
domain,
that's
offline
to
my
pre-authorization
list
for
the
for
the
room
that
I'm
the
admin
of
and
then
when
they
come
online
they
can
join
without
without
further.
D
A
D
L
Okay,
yeah
I,
just
before
we
move
off
of
this
and
go
into
the
discovery,
discussion
I
just
wanted
to
point
out
something.
That's
still
maybe
bugging
me
is
the
right
word
about
the
Assumption
of
this
architecture,
where
there
is
a
host
of
a
group
because
I'm
not
I'm,
not
sure
that
is
the
only
choice,
but
it
is
the
only
choice,
we're
talking
about
and
I'm
starting
the
more
we
talk
about
the
more
I'm
seeing
flaws
of
it
and
so
I'm,
certainly
questioning
that
assumption.
L
So,
if,
if
folks
that
are
going
to
be
implementing
something
sooner
rather
than
later,
they're
just
implementing
something
between
two
people
and
to
and
I
know
that
we've
identified
that
a
group
of
one
is
still
a
room
or
a
group
of
two
is
still
room,
and
then
a
group
of
you
know,
n
plus,
whatever
is
still
a
room.
It
is
definitely
Overkill
when
we
talk
about
all
these
different
features
and
all
these
different
which
I
agree
with
Rowan,
do
not
need
to
be
defined
by
Mimi.
L
F
J
Ahead,
yeah,
just
a
quick
thing
about
I-
think
it's
useful
for
us
to
be
able
to
track
room
membership
separate
from
client
membership
and
kind
of
keep
that
as
a
roster
I,
think
there's
kind
of
a
lot
of
useful
implications
from
it
from
that's,
not
just
for
your
user
at
first
perspective,
but
I
think
you
know,
even
though
we're
not
thinking
too
much
about
it,
but
from
a
transitional
perspective
that
will
make
it
a
lot
easier.
For
you
know,
people
to.
I
Thanks
so
the
thing
that
is
confusing
me
now
on
this
is
the
we
seem
to
be
getting
to
the
same
energy
result,
whether
it's
a
user
whose
state
is
flip-flopping
between
being
a
pre-auth
user
versus
a
participant
user,
or
if
you
just
have
a
roster
item
of
the
user
on
it.
It
has
zero
or
more
than
zero
devices.
I
And
it's
really
not
clear
to
me
why
it's
better
to
have
a
strangeness
where
the
states
of
the
user
is
even
managed
by
the
roster,
presumably
if
they're
pre-offed
and
then,
if
they've
got
MLS
devices,
it's
managed
by
MLS,
and
then
they
log
out
with
their
MLS
devices
and
they
pop
back
to
being
managed
by
the
roster
rather
than
just
having
the
user
managed
by
the
roster
and
the
devices
managed
by
the
MLS
group.
This
question
goes
to
run.
N
So
if
you're
added,
you
know,
you
can
be
both
an
active
participant
and
pre-authorized.
That's
there's
no
like
there's
no
need
for
you
to
be
not
on
a
pre-authorization
list
just
because
you
are
already
an
active
participant.
It's
only
if
you
were
the
only
time
that
you
would
could
not
be
on
a
pre-authorization
list
would
be
if
you
were
added
as
like.
A
temporary
temporary
user.
That
was
supposed
to
have
an
ephemeral
connection.
N
I
D
I
Whilst
they
were
away
because
Samantha
clipped,
they
were
part
of
that
conversation
and
they
could
have
rejoined
that
conversation
at
any
time
so
to
Jonathan's
point
where
no
there's,
eventually
this
race,
that
any
user
could
suddenly
re-pop
up
with
a
valid
device
in
the
room,
and
you
just
don't
know
when
that's
going
to
happen
so
everything
you
say
you
have
to
say
with
the
knowledge
of
that
person
might
just
spring
back
to
life.
Surely
that's.
C
D
N
But
but
I
think
that
the
difference
there
is
that
if
it's,
the
policy
that
you
have
that
you
have
this
collusion,
that
you'd
want
to
be
able
to
describe
that
and
like,
for
example,
in
draft
May
Mimi
group
chat.
There
is
a
place
that
describes
like
logging,
history
and
things
like
that,
and
so,
if
your
history
is
logged,
then
you
then
you
would
know,
even
if
the
user
isn't,
you
know,
isn't
an
if,
even
if
a
particular
user
is
or
is
not
in
a
pre-authorized
list.
N
The
fact
that
that
10
seconds
after
you
send
an
incriminating
message
about
about
Carol
that
Alice
could
go
and
invite
Carol
and
that
she
has
the
ability
to
go
and
do
that
scroll
back
that
that's
the
thing
that's
more
important,
not
whether
not
whether
Bob
has
any
active
clients.
You
know
whether
Bob
has
listed
in
the
roster
or
not.
I
I
I
You've
got
MLS
tracking
what
devices
are
in
the
room,
so
I
think
this
might
just
collapse
to
peer
terminology
sort
of
bike
shedding
in
terms
of
whether
you
call
these
roster
users,
pre-authorized
or
invited,
or
whether
they
are
member
room
members
or
whatever
words
you
choose
to
use
for
it.
I
mean
anyone
feel
free
to
correct
me
if
I'm
wrong,
but
yeah.
E
That
that
was
a
conclusion.
I
was
going
to
try
and
pull
out
of
this
that
a
list
of
pre-authorized
users
sounds
a
lot
like
what
other
people
were
referring
to
as
a
as
a
roster
and
I
realized,
I.
Think
Rowan.
You
were
just
using
raw
Street
to
refer
to
the
list
of
MLS
the
MLS
derived
list
of
users,
but
I
think
you.
E
D
N
So
I
I
I
think
the
place
where
I
disagree
with
Matthew
here
is
that
you
could,
if
you
have
a
bunch
of
specific
features,
enabled
you
could
you
could
make
this?
You
know
make
the
make
a
roster
collapse.
You
could
make
all
the
the
you
know
these
Concepts,
that
I
described
collapse
into
a
single
roster,
but
not
everybody,
not
every
client
is
going
to
go
and
support
those
features,
and
not
every
room
is
going
to
support
scroll
back.
D
E
I
I
Okay,
thanks
Rafael
I
mean
to
clarify
I'm
I'm
wondering
if
we
also
were
talking
about
the
same
thing
with
roster,
so
I'll
just
say
that
you've
got
the
non-cryptographically
linked
room
state
of
the
conversation
and
I'm.
Assuming
that
you
invite
the
user
you
go
and
put
them
in
that
room.
State
saying
this
person
has
been
invited
just
like
you
might
ban
them,
or
even
if
they've
never
been
associated
with
the
room
at
all,
they
then
joined
they've
got
clients.
I
I
In
fact,
that's
the
only
difference,
I
think
in
our
models
that
I'm
proposing
that
you
do
update
the
roster
at
that
point
to
say
that
they
have
actually
accepted
the
sin
vote
so
that
subsequently,
as
the
user
runs
out
to
devices
or
switches
device
or
whatever,
they
don't
get
mistaken
for
being
an
invited
user
and
that
you
just
semantically
differentiate
between
people,
who've
been
invited
and
haven't
joined
versus
those
who
have
joined
that
happen
to
have
run
out
of
devices.
I
think
that
is
the
only
difference
in
the
shape
of
our
approach.
I
I,
don't
see
any
disadvantage
to
tracking
that
membership
in
two
places
effectively
the
at
the
control
level
or
the
room
control
level
they
accepted
an
invite
is
a
useful
thing
to
know,
and
it's
just
totally
semantically
different
to
the
idea
that
they
happen
to
currently
have
a
bunch
of
encrypted
devices.
Hopefully
that
clarifies
or
we're
just
talking
past
each
other.
M
M
If
we
can
have
that
list
as
part
of
an
MLs
extension
like
a
group
context,
extension
or
something
that
has
equivalent
security
guarantees
to
that,
then
it
becomes
sort
of
changeable
in
a
way.
Because
then
the
the
only
distinguishing
factor
is
whether
or
not
a
user
can
read
messages
and-
and
that
has
to
do
with
two
things
were
unset
that
already
it
has
to
do
with
the
fact
that
whether
a
user
has
a
device
in
the
MLS
group
or
whether
they're
scroll
back.
M
So
those
are
the
two
things
that
are
going
to
determine
that.
But
then
we
would
have
the
same
level
of
control
across
this
aggregated
roster
that
we
typically
also
have
by
just
having
an
MLs
group.
But
but
we
should
at
all
cost
avoid
a
situation
where
we
have
unlinked
States
and
what
the
the
source
of
Truth
lies
outside
of
of
this
combination
of
MLS
group
and
and
previous
authorized
users.
N
N
So
if
you,
if
you
don't
like
the
pre-authorization
proposal
and
want
to
convince
me
that
we
should
go
and
use
you
know
a
roster
with
some
attributes,
then
I
would
just
say
you
know
in
a
couple
of
bullet
points,
if
you
could
go
through
the
each
of
the
use
cases
that
I
described
in
group,
chat
and
say
I
would
make
these
I.
This
was
what
would
happen
to
the
roster,
or
this
is
how
I
would
do
this.
N
O
Yeah,
so
I
just
wanted
to
follow
up
on
this
sort
of
source
of
Truth
comic,
because
I
think
that's
actually
the
core
issue
I
think
we're
con
we're
making
we're
using
terminology
and
pretending
it's
a
terminology
problem.
This
isn't
a
terminology
problem,
it's
a
it's
a
pretty
fundamental
design,
question
on!
What's
the
source
of
truth
right
whenever
you
have
two
lists
somewhere
or
two
pieces
of
data,
you
know.
If
you
want
consistency,
you
need
to
Define
one
of
them
as
a
source
of
Truth
and
so
I
think.
There's
two
design
decisions
we
can
make
right.
O
One
is
that
the
source
of
Truth
is
this
notion
of
this
list,
which
I'm
just
gonna
for
call
it
a
roster
for
a
moment
here.
Call
whatever
you
want,
but
I'm
gonna
use.
The
word
roster
for
this
for
just
a
moment
call
out
a
roster.
The
source
of
Truth
is
what
the
Hub
maintains
and
that
bounds
the
lmls
membership
right.
O
The
so
that's
the
source
of
Truth
is
the
Hub
driven
by
Mimi
and
the
proprietary
protocols
inside
of
a
of
a
a
provider
that
we
can't
see
and
then
and
then
the
other
world
view
is
the
opposite,
which
is
that
no,
no,
the
MLS
group
membership
is
the
source
of
truth
and
the
Hub
is
basically
storing
a
like
summary
version
of
it.
I
think
we
should
decide
which
of
those
worldviews
we're
following
and
then
the
terminology
can
come
from.
A
E
I
I
think
I
may
have
to
go
through
the
notes
in
the
audio
recording
but
I
as
I
was
saying
a
minute
ago,
I
think
to
first
order,
I
think
the
the
that
sounds
like
there's
some
agreement
that,
like
we
do
have
these
two
independent
things
to
the
jdr's
part
I,
might
need
to
find
some
ways
to
give
one
priority
or
the
other.
But
there
are
two
track
things:
this
list
of
users
derived
from
the
internet,
encryption
State
and
a
list
of
policy
users,
pre-authorized
users
or,
however,
we're
going
to
call
them.
E
So
we've
got
some
terminology
work
to
do
in
the
design
to
figure
this
out,
but
like
at
least
we
know
what
we're
talking
about
now,
at
least
a
first
order.
The
invite
I
think
we
may
need
to
do
another
iteration
on
this
discussion
invites
and
in
the
exact
run
process,
but
that's
something
we
can
handle
and
design
team,
but
I
I
think
we've
got
the
first
level
of
Concepts.
Now
we
can
kind
of
take
it
to
the
design
team
and
do
the
next
level.
E
Okay,
that's
that's
all
the
content.
So
if
we
can
skip
past
the
next
slide,
I've
got
just
like
one
little
wrap-up
slide
that
says
we're
gonna
go,
do
bring
your
decent
stuff.
I!
Think
that
aligning
you
know
that
taxonomy
of
exactly
what
the
state
is
and
how
we
maintained
it
was
basically
the
last
big
architectural
question.
E
We
had
I'm
sure
there
will
be
more
kind
of
design,
questions
that
come
up
with
the
next
couple
errors,
but
this
kind
of
transport
e
to
e
control
policy,
control,
message,
forwarding
message,
format,
I
think
that's
kind
of
the
constellation
of
protocols.
We've
got
going
in
the
sort
of
relationships
to
one
another
we
discussed
here
so
like
I,
said
the
top
I
think
we're
about
on
track
to
have
something
in
place
in
September.
We
just
need
to
get
our
real
story
on
going
that
and
we'll
discuss
further
in
the
design
team.
E
A
A
This
gives
people
a
little
bit
more
time
to
read
them
I
think
we
will
dedicate
the
entirety
of
the
next
interim,
which
will
be
coming
up
in
a
couple
of
weeks
to
Discovery
requirements,
because
the
design
team
will
still
be
busy
working
at
that
point.
So
we'll
take
the
parts
of
the
agenda
that
we
missed
today
and
shift
them
forward
to
to
the
next
interim
and
then
we'll
come
back
at
the
end
of
September
to
the
to
the
design
team.
A
A
It
would
be
great
to
find
a
recurring
time.
So
I
don't
know
if
people
think
that's
feasible,
but
I'd
love
to
stop
doodling
and
just
say
every
other
week.
We
meet
at
this
time
on
this
day,
but
I
don't
think
it
should
be
necessarily
this
particular
time
of
day
that
we
did
this
time
because
it's
so
late
in
Europe.
A
L
Well,
yeah,
it
was
just
quickly
a
question
to
the
design
team
if
that,
obviously
this
is
the
work
you're
doing
under
this
assumed
architecture,
but
then,
if
the
chair's
perspective
is
that
is
set
or
if
there
are
options
to
reconsider
different
architectures,
what
would
that
look
like?
Is
it
spinning
up
another
design,
team
or
just
coming
up
with
a
competing
draft?
L
A
A
So
for
sure,
like,
as
these
things
come
into
the
working
group
discussion,
everything
is
Up,
For
Debate
and
we
haven't
you
know,
maybe
when
we
get
to
time
for
doing
calls
for
adoption
and
calls
working
with
last
call
and
all
those
things
like
there's
many
additional
opportunities,
so
I
don't
think
anything
is
really
set
in
stone.
At
this
point.
E
This
is
not
a
group
working
on
working
group
deliverables.
At
this
point,
though,
the
idea
of
the
design
team
is
to
design
something
that
is
accessible
to
the
working
group,
and
so,
if
you
have
thoughts
on
what
would
be
if
something
different
would
be
except
more
acceptable
to
working
group,
I
think
we'd
be
about
security.