►
From YouTube: IETF-MIMI-20230503-1600
Description
MIMI meeting session at IETF
2023/05/03 1600
https://datatracker.ietf.org/meeting//proceedings/
A
Okay,
good
morning,
everyone
or
whatever
time
it
is
in
your
in
your
area,
so
welcome
to
the
first
interim
Mimi
session,
we're
right
at
the
start
time
for
today
by
my
clock,
so
I
think
we
can,
although
I
think
we're
still
waiting
for
at
least
one
of
our
presenters
to
join
I.
Guess
while
we're.
So,
let's
allow
a
little
more
time
for
people
to
join
the
call.
In
the
meantime,
we
do
still
need
a
note
taker
for
today's
session.
B
B
B
Can
you
just
cut
me
off
or
whatever,
when
you
when,
like
I,
think
we
should
do
it
with
the
last
time
where
people
want
to
talk,
they
should
just
get
to
the
line
and
talk
and-
and
you
should
just
like
make
a
face
of
your
thing
like
when
I
stopped
talking
and
we
and
I,
because
I
think
you
know
the
purposes
to
see
if
the
conversation
now
for
me,
like
just
yeah
all
the
time.
So,
let's
go
back
to
where
we
were
I,
think
you
know
you
know,
people
have
used.
B
Where
you
can
basically
send
some
sort
of
you
know
you
can
send
some
sort
of
message
that
says
hey
you
know,
I'd
like
to
be
part
of
your
network
and
and
as
I
said
back
to
like
smbp
reality
see
residence
information,
their
president
seems
to
be
no
longer
to
regret
and
and
then
you
can't
send
a
message
at
all
and
the
president's
message,
typically
only
as
allowed
to
have
some
very
narrow
information.
If
any,
you
know,
maybe
it
says
like
like.
B
We
know
people,
you
know,
having
ability
to
send
messages
means
plam
and
in
the
last
category
we
also
know
is
not
is
not
a
model
Everyone
likes
and
there's
sort
of
intermediate
set
of
categories.
I.
Think
this
sort
of
to
to
the
receiver
looks
like
the
third
category,
but
the
sender
looks
like
the
first,
where
you
can
send
messages,
but
they're,
somehow
quarantined
until
side
accepts.
B
B
You
add
them
to
groups
without
the
permission,
but
I
think
Jr
suggested
that
maybe
that's
not
what
we
want
to
have
all
the
time
so
I'm,
sorry,
I
I,
don't
have
my
own
slides
in
front
of
me.
So
I
think
we
have
a
next
three
next
slide
that
is
relevant
to
this
Tim.
Or
is
this
off
topic?
Okay,
good?
Let's
go
back
then
so
I
think
like
so
yeah.
B
B
B
So
I
think,
like
you
know,
I
I
think
what
we're
we're
back
in
Oklahoma
is
trying
to
get
some
sense
of
what
people
think
is
mandatory
here
and
in
particular
with
mandatory
you
know
in
existing
systems
and
which
which
modes
we
need
to
actually
continue
to
support.
So
I
think
that's
probably
The
Cue
for
people
to
get
in
queue
if
they
want
to.
D
Willing
to
raise
their
hand,
it
seems
like
we've
got
to
support
all
of
these
mechanisms.
An
SMS
type
mechanism
for
the
first
one
seems
utterly
necessary,
and
there
are
systems
that
will
not
stand
for
other
than
mode
two
mode.
Three
sort
of
seems
like
it
falls
out
of
mode
too,
and
some
systems
are
going
to
want
to
introduce
a
you
know,
a
local
permission
mechanism
to
say
Bob
can
say
what
he
wants
to
do,
which
one
of
these
three
I
don't
see
any
way
out
of
doing
a
permissions
mechanism.
E
Yeah
I
I,
so
my
opinion
on
this
is
that
some
systems
have
to
do
one
and
the
set
of
requirements
that
we
have
are
mutually
incompatible
with
doing
one
and
that
those
systems
can
go.
You
know,
go
and
fix
their
systems
because
they
they're
basically
broken
in
a
bunch
of
other
ways
and
that
you
know
like
they.
Basically
don't
do
a
modern
IM
system
right.
Let's
do
something
else.
D
C
D
E
Thank
you,
and
it's
not
you
know.
Alice
who
Bob
hasn't
you
know
doesn't
know
from
Adam,
can
send
a
message
to
Bob
immediately.
I
think
that
those
are
different.
Those
are
different
cases
and
we
need
to
treat
them
differently
and
I.
Don't
think
we
need
to
support
one
I
think
we
need
to
support
two
and
three
and
I
think
we
need
support
three
in
the
case
where
that
consent
has
come
ahead
of
time.
F
The
points
I
was
going
to
make
on
this
is
the
con
we're
not
Implement
one
effectively
on
the
receiving
Side
by
two
and
three
that
if
you
have
an
implementation
that
chooses
to
automatically
accept
the
inbound
stuff,
then
that's
fine.
However,
the
actual
protocol
still
has
that
concept
of
doing
a
handshake
and
it
could
be
an
entire
gatekeeper
or
third
party
who
decides
my
iMessage
and
WhatsApp
to
you
today
that
they
just
always
accept
immediately,
but
that's
fine.
F
B
Could
we
get
away
with
weaker
spam
systems
if
everyone
has
to
consent?
First
and
I,
just
don't
really
answer
that
question,
but
if
that's
that,
that's
so
I
think
you're
right
from
a
perspective,
it's
just
a
narrow
piece,
but
that
basis
makes
it
doesn't
make
it
take
on
a
whole
new
pile
of
work.
In
order
to
do
it,
I
just
don't
know
yeah,
that's.
Why
that's
why?
B
With
the
question
I
was
trying
to
ask
out
one
I
think
one
question
to
be
nice
to
know
would
be
like:
like:
do
we
have
an
inventory
of
what
systems
do?
What
so
I
was
like
thinking
about
this,
like
iMessage
seems
to
do
seems
to
do
one.
Obviously,
my
impression
is
signal.
Does
one
I'm
not
sure
about
I'm
trying
to
remember
what
I
try
to
watch
something?
C
F
H
Yeah
I
first
I
would
be
in
favor
of
supporting
designing
something
that
allows
implementing
all
three
modes.
I
think
there
are
good
reasons
in
different
cases
for
each
one
of
these
modes,
to
Matthew's
suggestion
of
simplifying
by
saying
three
a
special
case
of
three
is
one
where
you
have
automatic
consent
I
like
the
idea
of
simplifying
that
that
way,
I
would
just
say:
if,
if
we
go
with
that
approach,
then
we
should
you
know:
consent
has
to
be
able
to.
We
have
to
be
able
to
give
consent.
H
However,
we
Implement
giving
consent
should
be
also
possible
to
do
that
non.
You
know
when
you're
offline
in
a
sense
the
consension
Mandate
Bob
actually
doing
something
actively
online,
otherwise
kind
of
breaks
down
again
when
we
try
and
get
one
as
a
default,
you
want
to
be
able
to
start
messaging
people
non-interactively
right
when
they're,
not
even
online.
So
that's
just
something
to
keep
in
mind.
If
we
go
with
that
approach,
foreign.
E
Yeah
so
I
think
the
only
service
that
that
does
this
without
any
form
of
consent
is
Apple,
I,
think
everybody
else
uses
presence
of
you
know
of
a
number
and
a
contact
an
address
book
or
you
know
any
any
of
a
number
of
other
things
as
as
a
form
of
consent
and
but
I
think
Apple's,
the
only
one
that
actually
has
oh,
like
you
have
an
out.
You
have
a
phone
number
through
Apple.
Therefore
we
can
set.
I
Certainly,
you
have
to
be
able
to
recognize
the
status
of
a
message
that
you
sent
to
somebody
and
that
it
may
not
be
delivered
yet.
So
that
to
me,
is
you
know
a
critical
interoperability
piece,
but
you
know
in
terms
of
these
three
you
know
I
I,
which
one
you
know
would
the
resulting
work
say:
You
must
support
or
which
one
you
know
would
the
resulting
work
say:
You
must
not
support.
B
The
point
that
I
think
Matthew
made
and
also
drum
made
in
on,
is
you
know.
What
are
the
protocol
implications
here?
So
I
think
one
thing
that
has
been
sort
of
floated
around
is
the
implications
of
both
Discovery
and
and
keep
package
access.
So,
in
particular,
an
important
difference
between
two
and
three
is:
am
I
allowed
to
access
your
key
package
priority
consenting
and
this,
of
course
ties
into
questions
about
key
factors.
B
B
You
know,
potentially
at
some
level
that
doesn't
involve
these
are
consent,
and
especially,
and
especially
if
you
want
to
allow
people
to
send
messages
or
quarantine
to
keep
actually
part
of
consent.
So
sorry,
the
rather
the
dwells
you're,
all
horny
veterans,
Point
hasn't
discovered
more
than
you
keep
talking
about,
but
so
I
just
think
like
and
I
think,
like
I
think
it's
probably
fine
to
like
have
key
packages
available,
basically
without
any
kind
of
consent
and
I.
B
B
I,
just
just
one
more
thing,
I
think
I
think
I
am
hearing
that
like
we
need
to
that
people
think
we
need
to
support
at
least
two
and
three,
and
it's
not
clear
to
me
that
there's
any
material
different
and
given,
given
the
certain
points
Matthew
made
about
you,
know,
I
think
it
was
Matthew
about
you
know,
systems
or
unsubscribed
lawsuit
was
about.
You
know.
B
Some
systems
are
so
opt-in
by
being
part
of
the
system
as
well,
then,
maybe
like
one
distrocities
to
drop
out
of
two,
so
maybe
I
think
I
think
maybe
the
answer
to
all
this
is
like.
No
we're
not
is
you
know
trying
to
sum
it
up
is
well
we're
gonna,
assume
discovery's
out
of
bands,
so
we
don't
we're
not
doing
spin,
at
least
for
now
so
Auto
consent.
So
so
we
don't
have
consent
for
Discovery
We're,
not
gonna,
get
key
package
exhaustion.
B
So
maybe
that
is
about
the
answer
and
then,
as
I
say,
I
think
that
does
mean
and
and
then
maybe
that
lets
you
because
for
the
points
of
Rome
was
making
lets
you
kind
of
Kick,
the
spam
can
down
the
road
a
little
bit
by
saying.
Well,
you
know,
if
you're
a
foolish
enough
to
set
up
a
system
that,
like
is
configured
in
way.
One
then
you're
gonna,
think
also
spam,
because
we
don't
have
yet.
G
E
G
E
G
E
It's
still
conceptually
different
from
like.
Basically
you
clicked,
you
know
you
clicked
on
something
when
you
got
WhatsApp.
That
said
that
you
consented
to
you,
know
people
who
had
your
number
in
their
in
their
address
book,
whereas
with
apple
you
don't
have
any
choice
at
all
and,
and
that
might
change
you
know
with
with
the
dma,
and
it
means
that
it
has
to
be.
J
A
A
B
Suggestion
but
I
just
want
to
follow
the
sentence
in
the
chat,
which
is
that
draft
Rosenberg
transport
has
a
separate
mechanism
for
consenting
to
sentient
consenting
to
membership
in
groups,
namely
I
can
add
you
a
group
and
you've
got
to
be
able
to
agree
to
that
and
I.
Don't
I,
don't
think
we
need
that.
So
someone
thinks
we
need
that
we
should
speak
up
because
that
would
be.
B
That
would
be
I
mean
not
this
difficult
necessarily
but
several
protocol
mechanism,
and
so
I
think
you
know
the
the
the
you
know.
The
model
I
have
in
mind
is
like
once
you're
in
my
effectively
my
contact
list.
I
can
add
you
to
any
group
I
want
and
if
someone
thinks
we
need
a
separate
mechanism
for
that
like
they
should
speak
up
because,
like
it's
lie
down.
B
B
Yeah
next
slide,
please
I,
guess
right!
So
there's
there's
been
a
bunch
of
back
and
forth
in
this
in
several
venues
about
like
the
sort
of
modalities
of
of
or
supporting
and
and
the
fact
about
terminology.
If,
if
people
have
read
Travis's
terminology
document,
so
at
least
conceptually
speaking,
it
seems
to
me
that
there
are
three
separate
like
modes
of
operation.
These
systems
have
there's
like
one-to-one
messages
where,
like
you
and
I,
or
each
other
they're,
like
I,
think
we've
been
trying
this
out
with
Colin.
B
B
They
are
defined
by
the
by
the
contents
of
the
group,
and
so
you
cannot
add
a
new
person
to
the
group
without
changing
effectively
the
group,
and
so
like
you
know,
like
iMessage,
has
this
so
there's
like
slack
and
then
there's
like.
What's
called
and
there's
people
call
like
channels
or
rooms
or
named
groups
right
where,
basically,
the
contest
of
a
group
of
the
contest
group
and
flux
and
people
can
join,
can
get
Adam
be
joined.
B
These
obviously
have
some
overlap.
Conceptually
and
Richard.
Barnes
and
Alyssa
did
some
nice
surveys
like
what
systems
did
and
and
I
worked,
and
it
was
kind
of
a
mess.
So
I
think
you
know
I
guess
you
know
I
think
there's
any
sort
of
the
terminology
question,
which
is
what
terminology
should
we
call
these
things
and
B
you
know,
would
you
be
less
important
and
B
what
we
need
to
support
conceptually
in
terms
of
the
system
and
I
think
I?
B
B
Your
aim
might
be
like
what
happens
or
your
BMI
a,
and
the
same
thing
is
true,
with
these
name
groups
where,
basically,
you
have
the
same
group
participants
and
should
like
is
apparently
like
appear
with
one
thing
or
two
things
like
I
said
for
group.
Her
name
groups
on
that
was
weird
because
her
name
groups
is
like
quite
common
to
have
two
groups
exactly
participants,
but
for
anything
like
we've
only
one-to-one
group,
where
it's
defined
by
the
participants.
B
It's
weird
every
situation
where
you
know
where
you
and
I
are
the
two
participants,
and
yet
we
have
two
different
groups:
two
different
like
contacts
depending
on
on
who
initiated
the
association.
Are
you
in
the
queue,
I
think
or
you're
going
to
be
so
I?
Don't
have
much
more
to
say
about
this,
but
it
sounds
like
we
need
to
like
come
down
our
net.
K
Yeah
I,
don't
think
I
hit
the
Q
button,
but
sure
ad
hoc
join
the
queue
verbally
join
the
queue
yeah.
So
just
a
recap.
What
I
heard
mentioned
also
and
I
did
a
brief
kind
of
ad
hoc
survey
of
whatever
we
had
installed
on
our
phone,
so
it
covered
like
iMessage
and
slack
and
WhatsApp,
and
a
few
others
and
tested
a
you
know
this
standard
set
of
things.
K
You
know
what
happens
if
I
join
and
leave
what
happens
if
I
try
and
set
up
a
second
group
dm
with
the
same
set
of
people
and
on
basically
none
of
those
questions.
Was
there
any
consistent,
Behavior,
so
I
think
that's
kind
of
what
led
us
to
be
disinclined
to
try
and
address
this
group
DM
case
in
in
me,
because
there
doesn't
seem
to
be
any
coherence
model
of
it
across
the
different
Messengers
I
mean.
Ideally,
we
I
think
we
could
get
to
one
basic
primitive
here.
K
You
know
a
a
room
of
some
sort
with
one-to-one
and
maybe
some
sort
of
RPM
contract
as
a
specialization
with
that.
My
understanding
and
the
folks
who
are
more
experienced
in
this
Dimension
should
correct
me
here,
but
my
understanding
is
that's
how
it's,
how
things
are
implemented
in
at
least
some
messaging
systems,
that
the
the
basic
construct
is
a
group
construct
and
then
it
gets
specialized
when
you
need
things
like
when
you
can
select.
One-To-Ones
are
established
as
a
a
two-member
group
thing
and
you
just
have
some
unique
disenforcement.
K
L
Yeah
I
fully
agree
with
what
Richard
just
said
and
I'm
wondering
to
what
extent
we
actually
need
to
look
into
this
further,
because
that's
what
we
have
with
MLS
now,
where
essentially
everything
is
a
group
and
that
can
be
specialized
in
in
one
to
one
or
in
any
other
configuration
you
want,
and
that
was
informed
by
what
Messengers
did
at
the
time.
So
it
was
not
Greenfield
project
so.
L
I'm
wondering
if
it's
not
good
enough
to
agree
that
we
have
this
abstract
concept
of
a
group
that
has
a
clear
identifier
like
some
sort
of
uuid
that
has
a
clear
set
of
of
members,
whether
or
not
they
can
join
or
leave
is
a
detail
that
comes
on
top
of
that
concept.
But
the
underlying
thing
is
always
the
same.
That
would
be
my
proposal
here
to
get
it
started
and,
if
later
on,
we
feel
that
this
is
not
good
enough.
F
Yeah
I'm,
basically
going
to
say
the
same
thing
as
we're
on
the
Matrix
perspective,
the
at
least
the
way
the
Matrix
does.
It
is
that
you
have
a
single,
primitive,
a
room
and
that
room
can
be
configured
via
its
Access
Control
to
either
act
as
a
one-on-one
or
as
a
adult
group
or
as
a
named
group,
to
use
some
eckers
terminology
there.
The
thing
that
scares
me
more
is
interrupt
with
existing
systems.
F
I
think
iMessage
is
the
famous
one
where,
if
you
try
to
create
a
new
group
conversation
with
the
same
end
set
of
people
under
the
hood,
it
is
literally
the
same
IDs
used.
So
you
just
cannot
have
multiple
conversations
with
the
same
set
of
n
people,
whereas
obviously
in
a
MLS,
backed
Mimi,
Matrix
or
even
xmpp
world,
you
can
have
multiple
private
conversations
with
the
same
set
of
end
people
I'm,
assuming
that
we
are
all
collectively
assuming
that
for
something
like
that.
F
K
Actually,
just
a
quick,
quick
point
of
fact:
iMessage
was
one
of
the
systems
that
Alsina
and
tested
and
I
think
we
were
able
to
create
multiple
conversations
with
the
same
sort
of
people.
I
think
that
was
one
of
the
surprising
results,
in
fact,
but
yeah.
There
are
now
like
three
conversations
with
me:
Alyssa
and
Ecker
on
my
phone
and
my
iMessage
queue.
F
K
I'm
not
sure
how
they're
doing
it,
but
it
doesn't
mean
that
there
aren't
other
systems
that
do
have
that
property
so
like
in
slack.
If
you
create
a
group
DM
on
your
group
of
people
and
like
you
and
you
try
and
create
it
again,
then
you'll
end
up
in
the
same
one,
and
even
if
you
leave
the
group
DM
you're
you're
not
actually
evicted,
and
if
you
you
can
then
get
re-added
and
rejoin
it
into
the
same
thing.
It's
it's
odd,
which
is
you
know
this?
B
I
mean
so
sorry,
I
think.
It
certainly
is
true
that,
like
the
most
General
modalities,
sort
of
whatever
you
want
to
call,
these
name
groups
were
like
that
were
like
the
there's,
there's,
no
necessarily
relationship
with
members
of
the
groups
and
the
and
on
and
the
identity.
The
group
and
then
the
assistant
tend
to
bolt
on
some
abstraction
that
pretends
that's
not
the
case.
On
top
of
it,
I
I
do
think
going
back
to
the
requirements.
Question
you
know.
Is
there
some?
B
You
know
when
I
go
to
Crete
when
IMS
goes
and
creates
a
thing,
then
we
have
like
a
single
chat
and
then
the
person
from
WhatsApp
which,
like
you
may
say
why
did
they
just
pick
the
one
that
was
already
in
their
list?
But
they
don't
they
forgotten,
and
so
they
do
something
to
try
to
create
the
group.
And
now
you
have
a
separate
chat
that
is
like
what
is
this?
B
What's
up
like
this
posted
on
WhatsApp
and
talks
to
iMessage,
it's
exactly
the
same,
the
same
two
people
that
seems
pretty
nasty,
even
if
we
don't
solve
like
the
group
problem,
so
I
think
you
know.
Maybe
we're
going
to
live
with
that.
But
I
think
I'd
like
to
hear
someone
defend
that,
like
user
interface
and
if
they
think
that
interface
is
like
cool,
then
okay,
but
if
they
think
that's
not
cool,
then
like
about
it,
nothing
to
credit.
You
know.
B
H
H
Two
Rafael's
comment
about
whether
we
should
even
be
talking
about
this
because
MLS
just
does
name
groups
I
think
for
interop.
Yes,
I
think
it
is
important
that
we
agree
on
the
modality,
because
otherwise
you
know
if
the
behaviors
of
how
the
rules
that
two
different
providers
you
know
impose
on
the
modalities,
don't
sync
up,
then
I
don't
see
how
interrupt
can
work.
Things
can
go
really
wrong.
So
I
think
it
is
important
for
us
to
agree
on
these
modalities
for
real
interop.
H
The
other
thing
I
wanted
to
say
is
that
Rowan
was
was
commenting
that
a
lot
of
this
can
sort
of
boil
down
to
access
control
in
an
MLs
group.
I.
Think
for
that's
true
for
name
groups
implementing
ad
hoc
groups,
not
that
I,
like
I,
said
I,
don't
think
we
should
have
adult
groups,
but
I
think
that
works
I,
think
what
it
doesn't
work
straight
up
for
MLS
out
of
the
box.
H
Mls
is
the
the
well
okay
for
one-on-one
messages
you
expect
to
only
have
I
would
expect
to
only
have
one
one-on-one
message.
In
a
sense,
it's
maybe
a
special
case
of
an
ad
hoc
group
that
I
don't
see
how
you
could
do
that
with
MLS,
because
MLS
doesn't
say,
there's
nothing
about
when
you
create
a
group
that
that
allows
you
to,
you
know
depend
on
the
existence
of
other
groups.
That
say:
oh
now,
you
can't
create
this
group
because
there's
something
else,
some
other
group
that
has
some
other
state.
H
You
know
that
would
be
something
that's
a
layer
up.
That
requires
some
statement
like
some
notion
of
identity
and
which
has
users
and
blah
blah
blah.
So
I,
don't
think
Access
Control
completely
solves
the
problem
here,
like
sort
of
vanilla,
MLS
access
control,
or
maybe
everyone
just
understands
a
different
thing
under
that
term,
but
yeah.
So
those
are
those
are
my
takes
on
what's
been
said
so
far,.
H
Yes,
yes,
I
mean
I,
think
it's
I
think
one-to-one
messages
is
widely
sort
of
accepted,
like
as
in
there's
a
lot
of
precedent
for
that
users.
Understand
that
I
think
that's
a
that's!
That's
a
well
understood
concept
and
I
would
I
would
be
in
favor
of
supporting
that
I
do
think
it's
a
bigger
mess.
What
do
Eric
was
saying
like
if
I
have
a
bunch
of
one-on-ones
with
with
the
same
person
and
they're,
not
like
named
groups
for
a
specific
topic,
I
think
that
does
become
a
bit
of
a
mess.
H
H
J
E
E
That's
how
I
that's
how
I
treat
the
one-on-one
case
and
how
I
how
we
can
treat
the
behavior
of
ad
hoc
groups.
You
know
with
the
same
membership,
if
that's
what
you
want
and
then
ending
up
together,
and
if
you
don't
want
them
together.
Well,
you
could
just
create
a
unique
name
for
each
one,
and
then
they
won't
collide.
M
M
They
have
this
mode
right
of
this
group
message
and
if
we
don't
have
any
way
at
all
to
for
that
to
work,
then
I
just
think
it
sort
of
defeats
the
purpose
of
doing
this
Mimi
exercise.
So
my
opinion
is,
we
probably
need
to
support
a
very
some
version
of
the
whatever
primary
mode
of
group.
Communication
is
supported
by
All,
The,
Gatekeepers,
I.
Think
from
a
protocol.
That's
my
requirement
statement.
So
I
think
we
need
this
idea
of
ad
hoc
I
think
from
a
protocol
perspective.
M
It
can
be
supported
by,
as
others
have
pointed
out.
You
know
the
protocol
itself
only
understands
the
concept
of
a
name
group,
and
we
just
we
just
treat
an
ad
hoc
group
as
like
by
by
hashing
the
participants
and
mapping
them
to
a
name
group.
So
each
set
of
unique
ad
hoc
participants
maps
to
a
singular
name
group
and
then,
as
others,
have
also
commented,
you
know
adding
and
removing
people
would
just
cause
you
to
move
to
another
group,
but
at
least
we
would.
M
K
So
I
think
I
may
be
in
a
sort
of
similar
position
to
where
Jonathan's
ending
up
at
the
end
of
that,
it
seems
to
me
like
the
primary
difference
between
named
groups
and
either
one
to
one
or
ad
hoc.
You
know,
group
DMs
is
this
uniqueness,
property
and
so,
and
otherwise
the
group
mechanics
can
probably
be
the
same.
How
you
join
or
leave
a
group
how
you
set
one
up,
how
you
send
messages
within
a
group
Etc,
so
I
I
think.
K
Basically,
what
I'd
like
to
propose
mechanistically
is
that
we
we
agree
that,
like
in
terms
of
the
an
actual
live
thing
once
it's
set
up,
you
know
we
have
one
thing
which
is,
which
is
a
group
of
folks
communicating
whether
that's
two
people
in
one-on-one,
whether
it's
a
decrypt
DM
or
whether
it's
a
named
thing,
that's
wrong
by
now,
there's
different
policies.
You
might
attach
this
in
terms
of
congratulate
leave,
but
the
only
the
only
difference
between
that
thing
and
the
the
one-on-one
or
group
DM
cases
is
this
unique
and
uniqueness
problem.
K
I.
Think
that
directly
gives
us
one-to-one
support,
because
the
uniqueness
question
in
Wonder
one
is
very
easy
to
solve
like
when
you
get
a
request
to
make
one
of
these
things.
You
see
if
it
exists
with
the
other
side,
and
if
so,
you
use
the
other
sides
off
you
go
so
I
think
we
could
kind
of
do
this
step
wise.
You
know
solve
name
groups
first,
then
solve
uniqueness
to
create
one-on-ones,
because
that
seems
straightforward
and
then
eventually
get
to.
You
know,
group
DMS.
If
that's
something
folks
want
foreign.
N
N
Some
I
mentioned
this
on
the
chat
that
some
notion
of
sort
of
the
higher
level
semantics
that
the
user
is
intending,
because
you
know,
as
I
mentioned
it
would
be
very
bad
if
I
do
something
that
I
intend
to
be
a
one-to-one
chat
and
the
other
person
on
the
other
system
doesn't
know
that
that's
meant
to
be
a
one-to-one
chat.
So
they
see
that
as
a
invitation
to
a
named
group
named
uuid
ad
hoc
group,
Jonathan
and
Eric,
that
would
be
a
terrible
user
experience.
They
want
the
other
side
should
know.
N
This
is
semantically
intended
to
be
one-to-one
chat
or
a
group
chat.
You
can't
add
people
so
I
think
there
needs
to
be
enough,
such
that
the
endpoints
can
agree
on
what
the
you
know.
You
know
the
same
user
experience
and
give
you
know
insofar
as
they
distinguish
the
user
experiences
of
these
different
things
and
hide.
You
know
irrelevant
protocol
details
and
get
to
the
endpoints.
So
that
may
be
sort
of
some
layer
on
top
of
the
named
groups
semantic
at
the
protocol
there,
but
I
think
it
needs
to
exist.
H
H
B
B
What
I've
been
calling
name
groups,
which
is
to
say,
and
then
there
ought
to
be
some
that'll
be,
and
then
we
need
probably
two
extensions
one
way
to
have
a
deterministic
name
from
from
the
participants
in
the
group,
so
that
and
one
way
indicate
that
the
group
is
essentially
immutable
and
that,
if
you
have
those
two,
then
you
can
emulate
ad
hoc
groups
with
one
to
one
and
one-to-one
groups
with
named
groups
and
I.
Think
this,
like
I,
think,
is
roughly
ties
into
like
Rowan.
B
What
Richard
was
saying
about
hashing
and
was
saying
about
the
access,
control
and
and
I
and
I
do
think
that
will
that
that
does
that
doesn't
imply
and-
and
maybe
you
need
some
other
extension
about
life
that
says,
I
really
think
that
like
when
you
try
to
do
things
the
opposite
direction.
They
should
end
up
the
same
way,
but
but
that
may
just
may
just
drop
out
of
of
doing
that
of
doing
the
hashing
and
the
uniqueness.
B
So
so
I
think
probably
there's
something
something
here,
but
I
think
it
would
also
help
if
somebody
actually
wrote
down
and
maybe
Richard
be
willing
to
like
write
down
kind
of
like
how
to
do
what
I
think
you
say:
I'm
just
picking
Richard,
because
I
thought
he
said
he
seemed
that
sort
of
most
completely
worked
out
Theory
but
maybe
also
has
never
worked
out
Theory.
So
maybe
they
do
together
or
something.
B
B
So
I
think
this
is.
This
may
actually
be
much
easier.
Hopefully,
so,
if
you
look
at
like
on
MBC
on
svpn,
you
see
a
matrix.
They
have
like
quite
a
complicated
like
room
management
apparatus
with,
like
you
know,
ownership,
room
ownership
and,
like
Matthew's
maintenance
hierarchy
of
ownership,
you
know
moderation
kick
band,
asking
to
join
tasks,
Etc
et
cetera
and
like
lots
of
systems,
don't
have
that
at
all,
and
this
is
out
of
Charter
scope
for
for
the
charters.
I
read
it
first
of
all.
B
But
if
like
I'm
on,
if
I'm
on
WhatsApp,
then
I
don't
get
to
like
do
any
of
that
I'm
like
I'm,
a
chat
Zone
by
matrix
and
and
so
like,
that
means
that
it's
all
the
operators
is
private,
rather
rather
rather
than
interoperable
public.
So
that
was
that
was
what
I've
heard
being
discussed
privately.
So
maybe
people
maybe
I
misunderstood.
A
F
This
is
from
I
think,
is
a
real
hornet's
nest,
because
if
we
let
every
different
implementation
of
basically
every
Hub
or
boner
server
come
up
with
its
own
access
control
system
in
terms
of
who's
allowed
to
kick.
Who,
and
are
you
allowed
to
speak
if
your
name
has
an
Eminence
and
whatever
other
random
rules?
F
First
of
all,
it's
going
to
be
impossible
to
expose
the
admin
controls
to
Any
Given
app
in
the
room,
because
all
the
apps
will
have
different
ideas
and
the
semantics
of
the
room,
but
secondly,
you
won't
be
able
to
ever
move
the
owner
around.
So
even
a
server
goes
bang
and
you
want
to
have
some
scope
in
future
for
moving
ownership
around
or,
if
you
haven't
forbid,
want
to
decentralize
control
over
the
room.
F
I
really
really
really
think
it's
useful
to
have
a
Common
Language,
not
a
heavyweight
one,
but
at
least
some
basic
way
to
decide
how
room
management
should
work
defined
in
the
broader
and
if
it's
ended
up
being
out
of
javtoscope
I'm
terrified,
because
how
you're
going
to
be
able
to
admin
and
configure
these
rooms
from
a
given
client.
If
you
don't
have
some
protocol
to
Define
how
room
management
works.
E
Yeah
pretty
similar
to
Matthew's
comment.
I
mean
the
way
that
I'm
going
to
express
this
is
that
we
should
Define
the
semantics
of
all
of
these
things,
and
then
we
can
come
up
with
a
list
of
things
that
you
must
do
and
a
way
to
to
figure
out
whether
everybody
else
supports
any
of
these
other
semantics.
M
Can
you
guys
hear
me
this
time
all
right?
Okay,
I
go
back
to
my
fundamental
theory
of
how
to
make
decisions
and
requirements
which
is
if
it's
not
there,
while
The
Gatekeepers
adopted,
and
so
this
is
one
where
the
feature
set
in
the
the
main
Gatekeepers
are
primarily
consumer
I
think
have
much
lower
feature
sets
so
I
do
think
we
should
just
focus
on
doing
a
minimum
that
would
allow
that
to
interoperate
I
know
there
are
people
on
this
call.
M
M
The
second
thing,
I
would
say
is
what
definitely
needs
to
be
in
scope
in
all
cases,
if
you
attempt
to
do
an
operation
that
you're
not
permitted
to
do
like
the
protocols
is
for
rejecting,
because
you're
not
allowed
to
do
that.
So
if
there's
a
like,
add
person,
API
and
I'm,
not
I'm,
not
and
I'm,
not
it's
only
possible
by
moderators,
whose
name
is
Eric
and
and
I'm.
Not
such
a
person
like
I
may
not
know
that.
That's
why
I'm
being
rejected,
but
I
should
be
rejected
in
there.
M
That
I
didn't
have
permission
to
do
something.
So
as
long
as
we
can
express
errors
due
to
permission
problems
for
all
operations
moving
forward,
we
at
least
have
some
ability
for
the
systems
to
work
together,
even
if
we
don't
expose
the
full
set
of
ownership,
moderation
and
other
functionalities
outside
of
the
owning
organization,
so
I.
My
in
conclusion,
I
think
we
need
a
minimum
set
that
Maps
the
consumer
Gatekeepers
and
we
need
a
capabilities
in
the
protocol
to
express
rejection
because
of
lack
of
authorization.
B
G
Right
yeah,
so
one
thing
is
that
I
think
not
everything
on
your
list
here
is
necessarily
in
the
same
bucket
vis-a-vis.
The
charter
in
particular,
I,
think
this.
The
kick
ban
is
to
me,
is
like
kind
of
a
distinct
consideration
from
at
least
from
ownership
and
moderation,
and
also
like
a
very
critical
consumer
feature.
G
I
mean
both
consumer
and
Enterprise
feature,
as
opposed
to
the
other
two
which
are
more
like
Enterprise
features,
my
view.
So
so
that's
one
thing
to
think
about
that.
Maybe
maybe
we
we
treat
different
ones
of
these
differently
and
we've
already
spent
kind
of
some
time
talking
about
you
know
blocking
users
and
reputation
and
whatnot,
so
I
do
think
that
one
is
a
different
case.
G
In
the
original,
you
know
the
first
phase
of
what
was
going
to
be
designed
here,
and
there
are
a
lot
of
other
things
that
are
in
that
first
phase
that
are
really
hard
and-
and
we
need
to
make
progress
against
so
I-
think
we
need
to
prioritize.
And
if
there's
not
much
in
terms
of
design
implications
for
the
things
that
are
in
Phase
zero,
then
we
can.
L
So
yeah
I
just
wanted
to
speak
to
the
last
point
that
visitors
put
up
so
yeah
whether
or
not
we
need
to
recharge.
There
is
an
open
question,
I
guess,
but
I
don't
think
this
is
an
obstacle
for
now,
because
whatever
it
is,
that
we
might
want
to
agree
on
here
is
probably
something
that
mechanically
again
is
on
a
different
layer
and
can
be
built
on
top
of
MLS,
where
we
just
use
the
the
group
agreement
that
we
already
get
for
free
to
agree
on.
F
I'm,
finding
it
quite
hard
to
actually
understand
what
we're
defining
is
in
chartoscope,
okay,
so
Jonathan
says
in
the
chat
that
naming
should
be
in
scope,
but
then,
who
has
permission
to
name?
If
it's
a
group?
Surely
you
don't
need
the
concept
of
an
admin
because
you
don't
want
like
100
group
and
somebody
starts
going
and
renaming
it,
something
abusive,
blah
blah
blah,
which
one
hey
Bristol.
You
need
to
have
some
kind
of
permission
management
system
in
there.
F
B
Next
slide:
okay,
so
the
this
gets
bad
talking.
Another
conceptual
issue,
they're
and
all,
but
one
of
the
proposals
that
I've
seen
here,
there's
a
general
assumption
that
the
room,
whatever
the
channel,
whatever
it
is
lives
on
one
system
and
and
except
for
Matrix
and
so
I
think
it's
and
so,
like
you
know,
for
instance,
in
in
Jeff
Rosenberg.
B
But
it's
like
something
that
won't
administrate
it
anymore,
probably
because
they
don't
own
it,
and
so
Matrix
and
linear
Matrix
does
not
have
this
concept
really
as
much
and
linearized
Matrix
as
I
understand
in
Matthew.
Correct
me
allows
you
know,
channels
to
move
between
between
owning
systems
and
so
I
think
you
know
we
really
have
to
determine
about
that.
B
That
you
want
to
do
or
not
as
I
think
my
understanding
is
that
sort
of
general
has
a
group.
Was
they
didn't
want
to
do
it?
But
but
you
know
we
can
actually
discuss
it.
So
who
knows
what
we
actually
think
so,
I
guess
I
I
think
now
we
could
time
to
have
a
discussion
and
Jonathan
I'm
sure
you're
going
to
want
to
weigh
into
I.
Just
don't
I,
don't
see
you
in
Kia,
but.
F
Now.
I
would
argue,
that's
a
really
valuable
thing,
because
not
only
does
it
solve
the
problem
from
the
previous
slide
that
you
get
a
set
of
consistent
semantics
for
Administration
stuff
and
it
doesn't
matter
what,
where
the
Hub
is,
it
doesn't
matter
to
say
what
server
a
given
user
was
on
when
they
created
the
conversation.
F
I
would
say:
that's
a
horrible
bug,
because
it's
a
user
I
don't
want
to
care
whether
this
group
happens
to
be
hubbed
off
WhatsApp
or
iMessage
or
whatever
I
expect
to
be
able
to
try
to
do
an
operation
and
have
a
consistent
response
rather
than
exposing
that
mess
to
the
user.
So
the
ability,
having
codified
enough
of
the
really
basic
minimum
variable
semantics
for
group
admin
for
things
like
naming
and
access
control,
means
that
you
can
move
the
Hub
around
the
place.
F
Even
if
you
don't
do
it
in
the
first
step,
and
it
also
means
that
effort
provider
goes
bang.
If
you
lose
connectivity
to
the
internet,
it
turns
out
that
some
massive
group
chat
ends
up
being
hubbed
off
some
Raspberry
Pi
somewhere
from
somebody.
Who's
enthusiastically
request
an
interrupt
with
WhatsApp
or
whatever
it
might
happen
to
be.
Then
you
don't
destroy
the
conversation
Integrity
because
somebody
else
can
take
it
over
and
it
also
doesn't
close
the
door
and
decentralization
I
appreciate
this
as
a
possibly
a
bit
of
a
holy
war
thing.
F
But
I
really
think
you
can
have
your
cake
and
eat
it.
You
can
have
something
that
is
super
simple:
to
implement,
there's
minimum
viable
semantics
for
Access
Control
and
allows
you
to
put
the
Hub
around
the
place
without
something
that's
really
complicated
and
the
linearized
Matrix
ID
is
trying
to
concretize
that
without
any
dependencies
on
the
existing
Matrix
prior
art,
but
just
doing
it
Standalone
complete
with
a
working
implementation
to
show
that
we
shouldn't
be
scared
about
doing
it.
That
way,
sorry
for
the
rant.
L
F
M
So
yeah
so
My
worry
is
that
the
reality
is
all
the
hubs
ultimately
will
have
different
behaviors
I
mean
again.
If
we
were
starting
from
A
system
that
was
Green
Field,
it
would
be
different
if
we
were.
You
know,
starting
with
a
system
where
everyone
was
running
a
common
code
base
or
deriving.
The
same
protocol
like
like
Matrix
system
is
where
you
can
have
this
idea
that
it's
fully
portable
and
okay,
but
where
you
know
it's
going
to
be
different
from
vendor
to
vendor
and
that's
that's
the
reality.
M
In
order
for
this
to
be
portable,
we
would
have
to
support
the
superset
of
all
the
functionality
and
also
you
know,
make
the
assumption
that
the
portability
of
the
chat
is
something
that
the
Gatekeepers
even
sort
of
want
to.
Do.
It's
unclear
to
me
that
anyone
anyone
really
wants
to
do
that
so,
but
either
way
it's
hard
for
me
to
I'm,
not
sure
what
we
would
do
in
the
protocol.
M
That
would
make
it
impossible
to
do
in
the
future
or
there's
almost
nothing
you
can
I
could
think
that
would
make
it
impossible
in
the
future
I
just
I.
Just
don't
think
we
should
consider
it
it
now
and
we
can
kick
the
can
down
the
road
if
we
on
whether
we
ever
do
it
or
not,
but
I
certainly
don't
think
we
should
worry
about
it
now.
F
And
so
I
think
we're
agreeing
basically
for
as
long
as
it's
not
designed
out,
it
can
be
kicked
down
the
road
which
is
fine
by
me,
but
I
just
wanted
to
contest
the
point.
The
the
different
Gatekeepers
today
all
have
completely
different
implementations.
Therefore,
it's
an
impossible
problem
or
it's
a
hard
problem.
F
L
Student
to
quickly
reinforce
what
the
message
just
said,
I
think
the
level
of
agreement
we
need
to
be
able
to
interrupt
in
the
first
place
should
be
sufficient
to
also
allow
portability
I,
don't
think
we
have
to
introduce
something
massively
new
because
of
that,
and
so
I
also
don't
really
agree
that
the
systems
of
Gatekeepers
are
so
different
today
that
that
is
a
problem
they
will
have
to
become
compatible.
Obviously,
in
order
to
interrupt
and
again
that
should
be
enough
to
allow
portability
fundamentally,.
B
Is
the
upshot
here
that
everyone's
okay
with
with
doing
this
later
and
we
just
need
to
be
on
the
watch
out
that
we're
avoiding
crazy
durations?
Where
that's
not
the
case?
Is
that
the
bottom
line,
and
then
we
can?
And
if
we
have
the
point
where
someone
was
doing
something
that
versus
Matthew
thinks
we're
portability,
feature
or
Matthew
says
something,
and
then
we
argue
about
it,
then,
or
is
there
something
else,
some
other
follow-ups.
B
B
Okay,
so
so
this
this
is,
this
is
going
to
be
a
long,
a
long
setup
that
I
think
I'm,
not
sure
I'm
doing
great
Jeopardy,
and
this
team
is
one
up
so
I'll.
Try
to
like
see.
I
can
frame
this
and
then
and
then
given
and
not
may
not
put
the
motivational
example
and
when
you
talk
about
the
details,
so
the
the
key
Point
here
is
that
state
exists
at
multiple
levels.
B
So,
as
a
concrete
example,
you
know
you
could
have
the
idea
of
the
transport
level
which
people
are
in
the
room,
that
is
to
say,
when
you
send
a
message
who
it
gets
like
spanned
out
to
and
there's
an
MLs
level
of
which
keys
are
in
the
room,
and
you
know
as
I
say
when
I
encourage
a
message,
and
so
the
transport
information
exists
at
the
services
and
and
the
and
the
key
material
exists.
Some
free
seven
percent
of
the
end
points.
B
Well,
Jonathan
gets
a
message,
but
he
can't
decrypt
it
right
and
so
that's
and
so
and
the
question
becomes,
you
know
how
tightly
in
synced
these
have
to
be
and
they
have
to
be
cryptographically
connected
and
what
I
mean
by
that,
and
this
and
there's
probably
a
security
question
is
because
the
security
properties
the
whole
system
as
a
whole.
So
can
you
can
you
go
on
the
next
slide?
B
B
You
know
with
a
new
key
and
and
I
don't
want
to
detail
the
commit
Works
in
unless
right
now,
but
even
so,
it
doesn't
really
matter
and
and
the
result
is
the
rumorship
hasn't
changed,
but
there's
a
nuke,
but
but
Alice
is
aware
of
a
new
key
of
Bob's
K3.
You
know
intro
and
red.
So
this
is
an
example
of
a
change
that
exists
only
really
at
the
MLS
layer.
B
Conversation
where
you
know
Charlie
gets
added
by
the
service
to
it
by
this
by
the
service
to
a
chat,
and
so
you
know
and
then
so
here
in
where
we
see
just
like
the
ml.
There's
no
MLS
change
just
yet,
and
you
know
so
Charlie's,
you
know
what
mark
would
call
the
roster
and
and
then
in
the
next
slide,.
B
B
But
so
the
key
Point
here
is
an
example.
I
just
showed
you
know,
the
endpoints
have
not
actually
Ascent
to
Charlie
being
added
to
the
group
in
any
meaningful
way.
What
I
mean
by
that
is
they
just
read
the
roster
off
of
the
you
know
off
of
these
servers
and
when
try
asked
to
add
himself
to
the
group,
they
were
like
looks
good
to
me
and
they
took
the
MLS
external
commit
right
and
so
and
so,
and
so
the
question
I
think
becomes.
B
Is
this
an
acceptable
State
of
Affairs,
which
is?
Is
it
suitable,
zero
Affairs
to
have
the
meta
information
which
is
used
to
control
the
MLS,
so
I
mean
the
way
MLS
is
designed
right?
Is
you
get
these
messages
that
say:
do
things
do
various
group
manipulations
and
you
have
access
to
some
unspecified
asset
control
mechanism
that
says
we
accept
them
or
reject
them?
And
so,
and
so
this
and
and
so
like
the
security
of
analysis,
is
something
like
outsourced.
B
The
access
control
list
and
the
analysis
like
make
sure
things
are
visible,
but
it
doesn't
like.
But
you
know
if,
if
you're
told
well,
you
know
here
are
some
key
which
is
actually
published
internet,
but
at
any
way
there's
nothing
like
animals
doesn't
say
what
to
do
about
that
fact,
and
so
you
know
I
think
the
the
question
we
have
at
hand
is,
is,
you
know,
do
we
want
to?
B
You
can
imagine
what
the
assistant
was
differently
constructed
where
everything
was
like
signed
by
some
group
member
and
that
the
action
controllers
were
also
assigned
by
the
group
member
and
and
and
then
so
like
you
would
and
then
and
then
that
would
tie
together
the
the
group
State
and
the
MLS
State
or
the
transportation
MLS
state,
so
I
think
there's
like
a
number
of
possibilities
right.
You
know,
you
know
one
is
you
can
like.
B
Secondly,
you
could
have
a
mechanism
where
you
say
well:
there
is
some
MLS
cryptographic
way
to
say
what
those
policies
are,
but
it's
not
required
as
part
of
the
system
and-
and
finally
you
could
say
well,
there's
there's
a
a
an
MLs.
We
actually
have
ml
specifies
the
whole
thing
so
Jonathan.
What's
your
point?
I,
don't
actually
that's
that's
correct
because
there
are
lots
of
systems
where,
like
externals
and
these
joint
word
or
people
are
not
part
of
the
group
without
people
all
the
time.
B
B
So
so
so
that's
not
real,
so
I
think
the
thought
like
just
generally
is
a
viable
construct
to
just
say
that,
like
the
group
member,
if
doesn't
rumor
online,
to
add
you
so
I
think
like
again,
but
so
I
think
we
have
to
figure
out
what
we're
trying
to
accomplish
here,
but
but
but
I.
Think
that,
like
that,
we
need
to
figure
out.
Like
is
everything
have
to
be
tied
back
to
some
MLS
cryptographic?
L
L
So
you
need
complete
agreement
on
whether
or
not
it
is
okay
for
Alice
to
add
Bob
to
the
group
now,
and
so
this
needs
to
be
distributed.
So
whenever
somebody
joins
a
group,
it
needs
to
be
distributed
ahead
of
time
and
that's
why
we
have
the
the
group
info
object
in
MLS
and
once
you're
part
of
a
group
and
assuming
you
don't
miss
any
messages,
then
you
you
get
these
incremental
updates
that
updates
your
status.
F
L
H
H
I
do
think
also
there's
a
lot
of
we.
We
get
real
mileage
out
of
making
this
making
ACLS
something
that
ties
right
into
the
MLS
State
itself
at
a
cryptographic,
layer,
I
think
agreement
is
important.
You
know
we
don't
want
to
end
up
in
groups
where,
for
whatever
reasons,
bugs
maybe
active
attacks,
whatever
you
know,
clients
in
a
group
don't
even
agree
on
the
ACL
I
think
that's
just
not
a
good
behavior
to
have,
and
by
tying
the
ACL
mechanism
to
the
MLS
State
at
a
cryptographic
layer.
M
C
M
Interface,
are
you
going
to
show
to
a
user
that
joins
a
group?
Are
you
going
to
do
a
screen
pop
and
says
the
access
control
policy
for
this
group
is,
you
know,
only
accept
members
from
you
know.
Only
people
currently
in
the
group
can
authorize
members
or
the
the
service
running
this
server.
This
capability
is
able
to
add
members
if
they're,
yes
or
whatever,
like
you're,
going
to
pop,
that
to
a
user
100
of
users,
will
not
understand
and
click
OK
and
My
worry
is.
M
If
you
do
that,
then
you
introduce
some
easy
Vector
for
people
to
introduce
Access
Control
policies,
which
are
the
service
provider,
can
add
participants
as
soon
as
we
have
that
policy.
I.
Think
a
lot
of
the
promises
and
benefits
that
MLS
brings
to
the
table
are
just
evaporated
and
equipment.
Just
upload
of
smoke,
so
I
think
you
need
like
a
like
we're
going
to
keep
this
simple
use.
You
know
we're
not
relying
on
user
experience
for
people
to
make
sure
the
apple
is
good.
M
We're
just
going
to
have
an
apple
that
is
to
fall
and
and
for
MLS
purposes.
Sorry
for
Mimi
purposes,
I
mean
MLS
can
add
it
for
other
use
cases,
but
I
think
for
you
know,
for
this
at
least
like
I,
think
it
has
to
be
something
that
just
baked
in
and
just
works
and
doesn't
invite
a
recipe
for
disaster.
I
do
think
as
a
conclusion
that
would
rule
out
the
ability
of
someone
to
just
join
a
group
without
being
invited.
M
If
we
want
to
do
that,
we
would
have
to
add
Primitives
at
the
transfer
protocol,
which,
ultimately,
we
do
result
in
a
MLS
primitive,
which
is
someone
in
the
group
has
to
approve
it
and
therefore
they
would
send
a
commit
and
everyone
would
accept
the
commit
becomes
because
it
comes
from
an
existing
member.
That's
that's
at
least
my
view
on
this.
Thank
you.
B
B
Is
impossible,
I
think
I?
Think
we
better
see
some
more
things
too,
which
is
I,
don't
think
anybody's,
assuming
that's
controllers
would
be
enforced
by
humans
like
they're,
assuming
that's
control
by
software,
and
so
the
software
would
say
you
know
if
the
if
a
person
anybody
who's
like
first
name
starts
a
wants
to
join
then
just
go
ahead
and
accept
their
strong,
commit.
B
If
you
receive
an
external
transferable
message,
ask
for
someone
to
your
company
asking
to
join
then
you
should
send
a
commit
adding
them.
Those
are
the
same
thing
from
ml's
perspective.
I
mean
that's
the
same
as
mechanic,
but
the
same
animal
security
guarantee
and
so
I,
don't
think
it
makes
sense
to
sort
of.
If
we're
gonna
allow
that
policy
at
all,
then
the
policy
should
be
acceptable.
B
Joint
not
like
someone
gets
summoned
like
a
randomly
ad
to
randomly
do
a
commit,
because
you're
permitted
so
I
think
I,
guess
well,
I
think
the
same
thing
so
I
think
that,
and
as
soon
as
you
have
two
x
control
policies,
then
you
do
that
they
need
some
language
or
defining
as
control
policies.
So
I
think
what
this
comes
down
to
is
we're
going
to
need
effectively
what
I
think
I
heard
Rafael
and
Jewel
saying
is.
We
need
some
analyst
extension
that
lets
you
define
accidental
season
that
they
are
in
fact
very
simple.
L
F
L
L
The
the
only
requirement
here
is
that
all
the
clients
know
about
this
policy,
and
then
you
can
do
what's
called
an
external
commit
in
MLS
and
then
you
can
just
join
a
group,
but
again
it
comes
down
to
specifying
what
that
policy
is,
and
then
it
will
be
enforced
automatically.
It
doesn't
require
any
sort
of
human
interaction
at
that
level.
So
it's
in
a
way
you
can
think
of
it
as
like,
a
cryptographic
enforcement
of
what
used
to
be
plain
text
ACLS
in
messaging
systems.
Previously
it
does
not
prevent
you
from
doing
anything.
L
In
that
sense,
it
only
means
that
there's
strong
agreement
on
everything
you
do
do
and
I
think
in
in
Practical
terms.
It's
going
to
be
a
lot
more
robust
because
you
have
this
agreement,
like
sure
I
pointed
out
earlier.
If,
if
the
agreement
is
not
there,
you
cannot
decrypt
messages
anymore,
and
that's
probably
what
you
want.
H
Yeah
I
I
guess
I
wanted
to
add
to
to
respond
to
what
Jonathan
was
saying.
What
I
was
saying
was
agnostic
to
you
know
the
particulars
of
how
we
how
we,
what
we
allow
in
terms
of
flexibility
for
the
ACL.
In
fact,
when
I,
when
I
was
talking,
what
I
had
in
mind
was
we're
going
to
define
a
basic
ACL
and
that's
it
and
that'll
be
the
once
and
for
all
ACL,
not
everybody
gets
to
Define
their
own
ACL
per
group,
and
that
has
to
be
displayed
to
users
when
they
join
nothing
like
that.
H
H
M
So,
thank
you
Joel.
That's
super
helpful
that
that
I
think
is
actually
the
source
of
the
disconnect,
because
I
thought
the
only
re
I
thought
the
proposal
was.
We
need
an
ACL
language
in
MLS.
For
this
we
want
to
allow
for
variability
in
the
ACL
from
group
to
group,
which
is
the
thing
that
I'm
strongly
opposing.
M
If
you're
saying
no,
no,
you
understand,
like
MLS,
will
pick
one
and
it's
just
there's
a
bug
or
missing
feature
in
MLS
and
we
don't
have
a
way
for
everyone
to
know
what
that
is
like
I
feel
like
okay,
I
mean
I,
don't
necessarily
have
a
problem
with
that
as
long
as
that's
what
we're
agreeing
like
that
that
we're
not
going
to
allow
for
variability
and
access
control
policies
here,
are
we
right
so
Matthew
says?
What's
the
point,
if
it's
hard
coded
okay,
so
we
still
have
a
discussion.
H
C
G
So
I
well,
yeah
I
was
I,
so
I
was
sitting
here.
Thinking
I
I
had
missed
that
it
was.
It
was
just
one
and
I
was
wondering
if
just
having
one
is
really
gonna
accommodate
the
use
cases
that
people
had
been
contemplating
thus
far
in
the
discussion,
and
it
wasn't
even
obvious
to
me
if
there
was
just
gonna
be
one.
What
is
it
going
to
be?
Is
it
going
to
be
anybody?
B
Yes,
as
I
said,
I,
just
don't
see
how
you
not
how
you
can
not
have
more
than
one
option,
because
we
know
for
a
fact.
There
are
two
different
at
least
two
different
major
configurations,
one
of
which
is
any
new.
Any
group
member
can
add
a
new
member
and
one
of
which
is
that
any
person
who's
already
in
existence
can
join,
and
so
so
those
are
two
options
and
there's
probably
at
least
a
third,
which
is
only
administrators,
got
a
new
member
and
so
like,
like
what
some
people
might
wish
to
have.
L
Then
you
can
use
external
commits
in
MLS,
which
does
not
rely
on
anyone
inviting
you.
You
can
just
join
and-
and
that's
just
going
to
work
essentially
because
all
of
the
clients
know
about
this
particular
rule
for
that
group
and
then
they're
going
to
enforce
it,
and
if
and
the
other
thing
that
I
forgot
to
mention
earlier
is
that
we
don't
actually
necessarily
have
to
rely
only
on
the
clients
to
enforce
this,
because
we
might
say
this:
it's
a
bit
late.
L
You
know
if
something
reaches
a
client
that
that
might
be
spam
like
a
malicious
message,
where
Alice
adds
Bob
and
that's
an
invalid.
We
can
stop
that
at
the
server
level
as
well.
So
in
the
three
proposals
we
currently
have
for
the
delivery
service
and
the
transport,
all
of
them
essentially
would
allow
inspection
at
the
server
level.
Whether
or
not
a
certain
message
is
valid,
a
particular
commit.
B
We
did
say
I
wasn't
sure
how
wide
frame
this
so
I
think
but
I
think
I
think
we
are
closing
into
what
I
would.
What
I
would
claim
is
is
three
which
is.
There
are
some
MLS
attributes
that
says
what
the
policy
is,
that
you're
supposed
to
apply
when
you
receive
an
extra,
an
external,
commit
or
other
or
other
message,
and
that
is
attached
to
the
group
and
and
bound
into
it
in
the
way
that
you
enjoy.
G
G
Confusion,
which
is
you
know,
based
on
what
Raphael
just
said
like
how
does
that
translate
into
facilitating
interop
at
the
application
layer
for
these
different
systems?
I
understand
you
can
support
anything
in
MLS,
but
like
then,
when
it
comes
time
to
trying
to
have
a
consistent
user
experience
across
interoperating
systems
like
how
does
that
that
boundless
set
of
possibilities
get
reduced
to
something
which
is
which
you
can
actually
implement,
such
that
you
get
a
the
same
experience,
regardless
of
of
which
system
you're
using.
L
Maybe
I
can
take
this
one
quickly.
I
mean
yeah.
The
problem
as
such
is
still
unsolved
in
the
sense
that
it's
a
charter
question
or
whether
or
not
we
need
to
recharge
her
to
have
ACLS
and
policy
and
moderation
as
part
of
the
scope,
but
it's
orthogonal
to
mls.
In
that
sense,
if
we
want
interrupt
on
that
level,
we
need
to
specify
that
and
again
whatever
is
the
outcome
of
that
specification
process?
M
Okay,
I
think
I,
think
I'm
next,
so
My
worry
is
all
of
this.
Discussion
on
MLS
protocol
stuff
reduces
this
to
a
previously
unsolved
problem,
which
is
what
I'm
saying
is
like.
Let's,
let's
be
clear
on
where
this
policy
would
come
from.
So,
let's
think
about
it.
From
user
experience,
perspective
I'm
going
to
be
on
a
provider
I'm
going
to
create
a
chat,
room
and
that'll
happen
long
before
Mimi
is
involved
right,
create
this
room
and,
let's
say,
I,
select
this
as
a
moderated
room
and
only
people.
M
O
Servers
and
the
clients,
so
presumably
when
a
client
creates
that
a
group
it's
going
to
use
a
set
of
policy
policies
that
are
allowed
already
by
like
here,
are
the
choices
of
policy
constraints
that
you
can
put
in
place
that
are
presented
by
its
server
and
then
its
server.
You
know
says:
okay,
you
can
have
an
open
group,
you
can
have.
You
can
have
a
you
know,
a
group
that
has
admins.
O
O
Contradiction
here
check
that
clients
all
get
the
E
cryptographic
cryptographic
cryptographically
verified
that
this
was
a.
This
was
a
policy
that
was
placed
by
the
Creator
or
that
was
later
Modified
by
one
of
the
authorized
users
and
they
get
to
cry
foul.
If
something
is
wrong,
the
servers
also
get
to
see
it,
and
presumably,
where
this
all
came
from
was
the
server
on
the
owning.
O
You
know
the
owning
server
told
the
you
know
told
the
Creator
at
some
point
like
this
is
the
kind
of
thing
that
URL
these
are
the
things
you
were
allowed
to
do
and
all
of
these
authorization
rules.
You
know
they
already
their
set
of
these,
which
already
exists.
So
the
semantics
are
pretty
well
understood.
We
just
need
to
write
them
down
into
in
into
a
concrete
syntax
and
stick
them
in
one
of
these
extensions.
M
If
this
is
true
for
any
of
the
existing
systems
that
we're
trying
to
Federate.
All
of
these
are
going
to
start
I
presume
with
the
moderation
rules
and
access
control
rules
defined
on
the
server,
and
thus
the
only
way
for
for
this
to
sort
of
like
interoperate
with
the
you
know,
with
the
current
systems
is
the
server
is
going
to
have
to
hand
the
client
the
rules
for
it
to
construct
the
access
control
list
and
I.
Just
think
that
that
introduces
a
security
vulnerability
that
I'm
worried
about.
H
Okay,
yeah,
so
so,
basically,
I
I
have
the
same
view
as
Rowan
does
right
and
to
Jonathan's
Point.
Here
you
know
how
the
room
gets
set
up.
That's
that's
between
the
client
and
and
its
local
like
vendor,
and
and
they
got
to
negotiate
like
okay.
What
apples
can
I
use-
and
you
know
who
can
I
add
stuff
like
that,
but
eventually
It's
gotta?
It's
got
to
decide
on
some.
It's
got
to
reach
some
point
of
view
of
like
okay.
This
is
what
the
group's
gonna
look
like.
H
This
is
what
the
apple
is
going
to
look
like
at
that
point.
It
creates
the
MLS
group
and
then
it
can
put
whatever
it
ended,
landed
on
into
this
part
of
the
state
of
the
MLS
group,
at
which
point
it
then
signs
that
state
and
that's
the
end
of
any
chance
of
the
vendor,
interjecting
or
modifying
anything
right,
because
now
it's
signed
by
this
user
who's,
creating
the
group
and
and
now
it
becomes
an
end-to-end
thing.
So
that's
one
thing:
I
wanted
to
say
the
other
thing
around
this.
This
sort
of
you
know
this.
H
This,
like
The
Meta,
The,
Meta
I,
like
that
term
Matthew
to
me
this
is
like
a
spec.
This
is
like
basically
like
modality.
It's
the
same
thing
we're
talking
about
as
how
we
want
to
deal
with
modality
of
rooms
right.
So
it's
the
same
conversations
and
and
yeah
to
me
personally.
It
makes
sense
to
maybe
Define
a
couple
like
you
know,
an
unmonitorated
room
in
a
moderated
room.
H
I'm,
not
sure
we,
you
know,
really
need
anything
more
of
that
some
sort
of
common
denominators,
one
two
three
modes,
some
not
more
than
that,
and
that's
it
and
that's
that's
what
that's
what
people
got
to
support
and
that's
it
not
not
anything
more
flexible
than
that,
because
then
it's
just
going
to
become
a
nightmare,
and
then
I
mean
it's
just
too
too
complicated
of
a
ux
problem.
So
that's
maybe
what
needs
to
be
negotiated
at
the
beginning
with
the
vendor.
You
know
with
your
with
your
own
local
host
or
whatever
yeah.
That's
that's.
H
F
H
L
Yeah
I
would
also
like
to
understand
more
about
what
the
potential
security
problem
is
here,
but
if
it
is
that
clients
can
now
dictate
to
a
provider
what
the
policy
is
and
that's
not
the
case,
because
they
don't
get
to
create
a
group
if
they
don't
abide
by
whatever
the
vendor
thinks
the
the
policy
should
be
and
the
so.
The
only
thing
here
is
that,
once
that
is
negotiated
as
the
right
said,
vendors
or
providers
cannot
as
easily
or
not
at
all,
actually
inject
anything
anymore
and
the
whole
thing
becomes
really
transparent.
L
B
Incredible
as
Jonathan
says
that
like
groups
are
going
to
have
some,
you
know
some
dictation
of
what
the
policy
is
from
the
from
the
vendor
for
the
the
owning
server
and
I.
Think,
if
you
think
about
something
like
slack
right
as
I
said,
there
are
two
main
policies
in
slack
one
is
anyone
can
join
a
public
group
and
one
is
the
only
that
the
only
members,
you
know
members
I,
admit
new
members,
a
private
group
right
and
so
I
could
certainly
you
know.
B
I
could
certainly
see
a
situation
where,
where
slack
binds,
you
know
two
different
control
policies
and
when
and
when
the
when
the
group
is
created,
you
know
the
clients
are
told
which
hospital
policy
applies
to
it
and
those,
and
then
that's
how
you
expect
the
client
to
enforce
the
client
would
in
fact
show
you
know.
This
is
a
private
group.
There's
a
public
group
and
a
public
group
has
a
property
that
anyone
can
add.
B
It
I
agree
that,
like,
if
you
allow
public
groups,
there's
no
there's
no
there's
always
a
there's,
always
a
possibility.
That,
like
you,
know
that
that
the
writer
was
a
buddy
which
is
like,
in
any
case
undesirable,
but
I.
Think.
The
purpose
of
of
a
discussion
here
is
to
make
that
manifest
at
the
client
and
the
cryptographic
layer
as
well.
M
Let
me
try
and
describe
the
specific
thread.
I
think
I've
not
done
a
good
job,
so
let
me
put
it
in
attack
terms.
So
let's
say
you
have
a
malicious
provider,
so
my
provider
is
malicious
and
its
main
goal
is
it
wants
to
add.
You
know,
make
sure
that,
like
it
can
have
an
access
control
rule
which
says
add
my
eavesdropper
participant
to
all
rooms,
which
is
the
big
thing
won't
avoid.
So
the
malicious
provider
wants
to
do
that.
M
So
My
worry
is
I
as
a
user
I'm,
a
customer
of
this
malicious
provider,
there's
an
existing
room
in
the
system
and
so
I
had
a
participant
now
outside
of
my
provider,
which
is
where
we
begin
the
Mimi
experience
in
this
proposal.
What
you
know,
because
what
will
happen
is
that
this
room
has
existed
for
a
while.
It
has
an
access
control
policy
which
is
a
moderated
with
two
admins
in
it.
That
is
not.
That
is,
is
known
and
stored
on
the
provider.
M
B
B
If
you
look
at
slack,
they
have
public,
chats
and
private
chats,
and
you
can
tell
what
kind
of
chat
you
are
because
it's
got
like
an
icon
next
to
it,
and
so
that's
the
thing
that
you're
actually
aware
of,
but
the
users
not
to
be
aware
of,
is
when
is
when
someone
attempts
to
join
the
group.
They
don't
like
mechanically
themselves
enforced
with
a
new
person
will
join
the
group
or
not
but
and
like
and
so
yeah
and
so
like.
Could
they
provide?
B
Could
you
design
a
system
where
the
provider
was
allowed
to
change
chats
from
private
to
public
I?
Think
it
depends
on
the
design,
I
feel
like
the
nature
design,
probably
not
the
other
designs.
Maybe
yes,
but,
like
you
know,
it's
just
inherent
the
possibility
of
having
public
groups
that
you
have
like
that.
You
have
the
ability
to
prior
to
add
people
as
public
groups
and
so
the
best
way
to
make
these
either
and
so
I'm
you're
saying
you
can't
have
public
groups
which
means
they're.
B
G
L
G
A
G
G
We
don't
even
get
through
it
all
so
so
I
think
it
is
helping
us
and
we
had
a
little
bit
of
delay
getting
the
first
one
scheduled
after
Yokohama,
but
with
we
can
do
two
weeks
notice
for
the
next
one,
and
you
know
schedule
a
bunch
of
these
out
further
in
advance
and
then,
if
we
don't,
if
we
come
to
a
week
when
we
don't
need
one,
we
can
always
count.
So
that's
kind
of
my
inclination
on
the
scheduling.