►
From YouTube: IETF-MIMI-20230517-1600
Description
MIMI meeting session at IETF
2023/05/17 1600
https://datatracker.ietf.org/meeting//proceedings/
A
A
So
I
think
we
should
probably
get
started.
We
do
still
need
a
volunteer
to
take
notes,
since
no
one
has
offered
yet
I
guess:
I'll
try
to
do
it
along
with
the
running
the
meeting
here.
Well,
this
is
not
with
us
today,
she's
traveling
today
so
I'll
be
chairing
on
my
own
okay,
let's
dive
into
the
the
chair
deck
so
right.
First,
we
ask
everyone
to
be
aware
of
the
note
well
and
review
all
of
its
everything
that
it
says
about.
A
So
the
first
thing
up
is
to
wrap
up
the
excuse
me
wrap
up
the
deck
on
transport
requirements
that
we
started
looking
at
back
at
ietf
116
and
then
continued
working
through
at
the
last
interim
session.
So
that's
there's
one
slide
left
on
this
deck.
That's
for
record
to
present,
but
he's
not
with
us
just
yet.
A
The
other
item
on
the
agenda
is
Rafael.
Robert
has
a
deck
on
transport
versus
delivery
service,
so
I
think
what
we
could
do
since
since
Eric
isn't
here
yet
is
start
with
Raphael's
deck
and
then
come
back
to
the
discussion
of
the
last
slide
of
Eric's
deck
afterward
Raphael.
Does
that
sound
all
right
to
you
sounds
good?
Okay,
all
right.
So
with
that
in
mind,
does
anybody
have
anything
else,
they'd
like
to
add
to
the
agenda.
C
B
So
essentially,
this
is
in
response
to
the
discussion
we
had
in
Yokohama,
where
we
now
have
a
total
of
three
proposals
for
various
aspects
of
transport
and
delivery
service
and
the
protocol
between
providers
in
general,
so
I
and-
and
we
don't
really
have
consensus
yet
on
what
the
scope
should
be
exactly
and
what
the
the
architecture
looks
like.
So
in
the
last
interim,
we
discussed
a
lot
about
very
specific
aspects
of
the
architecture
thanks
to
Ecker.
B
So
maybe
some
other
questions
in
this
presentation
are
no
longer
relevant,
so
yeah
in
essence,
I
thought
it
would
make
sense
to
look
at
what
the
status
quo
is.
What
the
general
understanding
is
have
some
discussion
about
it,
and
they
also
try
to
explain
a
bit
more
what
the
understanding
is
regarding
MLS,
specifically
because
we
already
agreed
that
that
is
at
the
core
of
Mimi
but
yeah
at
times
it
feels
like
not
everybody's
on
the
same
page
regarding
the
architectural
requirements
of
MLS.
B
That
being
said,
the
far
fewer
people
here
today
I
think
so
Jonathan
Rosenberg
is
also
not
here.
Where
is
he
let's
see
him,
but
yeah
anyway?
Be
that
as
it
may?
Let's
start
with
a
presentation,
so
next
slide,
please
so
yeah.
So
this
is
the
three
drafts
we
have
currently
so
linearized
Matrix,
which
I
think
at
this
point
replaces
the
original
Matrix
draft,
which
has
also
expired,
I,
think
from
Travis
Ryerson
done
from
Jonathan
Rosenberg.
B
B
B
B
B
The
whole
question
about
the
transport
and
the
delivery
service
is:
how
does
a
client
that
belongs
to
the
guest
provider?
How
does
that
client
get
to
talk
with
the
owning
provider,
because,
ultimately,
an
action
is
initiated
on
that
client
and
it
has?
It
is
reflected
on
the
owning
provider.
So
this
is
what
we're
gonna
look
into
a
bit
more.
This,
of
course,
will
be
a
lot
easier
if
there
was
only
one
provider,
but
then
we
wouldn't
have
Federation
and
we
would
need
interrupt.
B
So
where
do
we
not
agree
just
yet?
It's
not
entirely
clear
what
we
fundamentally
want.
So
there
was
some
discussion
about
a
server
to
server
protocol,
and
there
was
also
some
discussion
about
a
client
server
protocol,
and
so
this
is
where
we
diverge
in
the
sense
that
we
yeah
there
seems
to
be
preferences
and
we
are
not
really
looking
at
what
the
architecture
actually
requires.
Currently,
so
this
is
what
what
we
need
to
look
at
in
more
detail.
B
B
We
also
don't
agree
on
the
fan
up
mechanism
just
yet
so
we
agree
on
on
the
part
where
there
is
a
restful
API
between
other
client
and
the
server
or
server
in
the
server
before
the
fan
out.
But
when
the
funnel
happens,
The
Proposal
in
the
Mimi
protocol
by
Rosenberg
is
for
long
polling,
whereas
what
we
proposed
at
least
was
push
I,
don't
remember
what
Matrix
is
specifically
proposing
that
regard,
so
we
need
to
talk
about
that.
B
B
The
Assumption
here
is
that
a
lot
applies
to
Enterprise
messaging,
simply
because
all
the
people
in
the
room
discussing
it
work
on
Enterprise
Messengers
and
the
question
why
that
is
relevant
is
actually
the
last
slide
that
Echo
was
supposed
to
present
today
regarding
metadata.
So
this
is
the
one
fundamental
difference
that
we
need
to
look
at.
Maybe
there
are
more
operational
things
that
have
not
really
materialized
yet
that
we
will
discover
where
we
have
differences
between
consumer
and
Enterprise
messaging
as
well.
B
Okay,
so
I
try
to
summarize
in
very
broad
Strokes
what
these
three
drafts
mean
and,
of
course,
it's
opinionated
so
feel
free
to
disagree.
So
the
way
I
understand
it.
Linearized
metrics,
essentially
departs
from
this
peer-to-peer
deal.
That
was
in
the
initial
submission
for
Matrix.
So
this
is
definitely
more
aligned
with
the
consensus
that
we
already
have
from
what
I
gather
it
has
a
lot
of
dependencies
from
the
rest
of
the
Matrix
universe,
so
things
that
are
not
actually
defined
in
the
document
itself.
D
B
B
B
B
Yeah
next
slide,
please
so
going
back
to
the
architecture
question.
So
if
there
are
different
ways
of
looking
at
it,
one
would
be
to
look
at
the
providers
and
look
at
what
would
make
sense
from
that
angle.
So
the
that's
not
the
one
we
choose
right
now
and
I
choose
to
look
at
it
purely
from
a
technical
level
and
then
see
if
we
can
make
the
ends
meet.
Somehow
so
MLS
has
this
property
that
it
needs
a
delivery
service
that
orders
messages
and
the
consensus
we
have
around.
B
That
is
that
this
message
ordering
happens
on
the
owning
provider,
so
on
a
very
abstract
level.
That
thing
has
a
counter
and
it
looks
at
commit
messages
that
come
in
and
whenever
the
the
Epic
number
on
the
commit
message
measures
the
counter,
then
it's
incremented
by
one
other
messages
are
rejected
for
that
epic
Etc.
So
this
is
fundamentally
important
and
this
Dynamic
happens
between
the
client
that
created
the
commits
and
the
earning
provider.
B
B
B
B
So
the
the
last
part
would
be
the
fan
out.
So
when
the
client
has
sent
a
commit
to
the
earning
provider
and
the
commit
has
been
accepted
or
any
other
message
for
that
matter,
then
that
message
needs
to
be
delivered
to
all
the
other
clients
and
in
the
first
step
it
will
get
delivered
to
all
the
other
guest
providers
that
are
part
of
this
one
particular
Federated
group
so
essentially
like
conceptually.
B
This
is
a
distinct
second
phase
of
the
protocol,
and
this
is
maybe
a
little
less
controversial,
because
now
clients
are
not
really
involved
anymore.
This
is
truly
a
server
to
server
protocol
and
the
only
question
is
what
shape
should
it
take
so
again,
the
proposal
from
Mimi
protocol
is
to
have
long
polling
here
where
the
guest
provider
would
open
a
connection
to
the
owning
provider,
and
the
argument
for
that
is
that
this
is
very
controlled.
So
it's
good
for
preventing
spam,
because
the
earning
provider
cannot
push
out
stuff
to
anyone.
B
It
needs
to
wait
until
the
connection
comes
in.
The
counter
argument
is:
how
does
that
work
with
open
Federation,
because
you
would
have
to
establish
connections
between
all
of
the
servers
in
the
world
that
want
to
participate
in
this,
so
The
Logical
answer?
Is
this
won't
work
with
open
Federation?
This
only
works
when
you
have
agreement
between
providers
that
they
actually
want
to
Federate,
and
then
they
have
these.
B
Yeah
next
slide,
please
so
we
we
had
it
in
another,
very
small
draft
to
bridge
the
gap
simply
because
the
delivery
service
we're
proposing
is
is
not
really
a
transfer
protocol
at
all.
So
what
we
propose
is
maybe,
over
https
and
I,
understand
that
nobody
had
the
time
to
look
at
it,
and
it's
also
not
super
important,
because
all
it
is
really
is
a
wrapper
for
the
delivery
service
messages
to
go
over
HTTP
again.
The
delivery
service
is
agnostic.
B
B
So
since
we
seem
to
have
consensus
on
HTTP
in
general,
like
all
three
drafts,
at
least
not
against
it
so
https
specifically
and
then
the
question
is:
what
do
we
have
above
hdp
and
so
what?
What
we're
proposing
here
would
be
to
have
this
really
thin
layer
to
wrap
these
messages
over
HTTP
for
the
delivery
service,
which
in
turn
is
a
bit
of
a
wrapper
for
MLS
messages
and
and
Aggregates.
B
A
E
So
the
dimension
of
like
linearize
Matrix,
and
all
that
we
do
have
a
a
sort
of
work
in
progress
draft
it
hasn't
been
published.
Yet
that
removes
all
the
dependencies
from
the
existing
Matrix
system,
because
I
definitely
agreed
it
shouldn't
depend
on
a
lot
of
that.
We're
also
just
working
on
tying
it
to
MLS.
This
is
a
sort
of
brief
update
there,
just
to
sort
of
add
the
additional
context.
E
Yeah
I
guess
at
risk
of
just
also
monologuing
a
bit
I
think
the
sort
of
batteries
included
approach
would
probably
be
a
bit
better
in
that
sort
of
sense,
because
if
it
becomes
too
modular,
then
we
might
end
up
just
trying
to
design
the
world.
You
know
grains
of
sand
at
a
time
sort
of
idea,
whereas
having
a
sort
of
single
or
larger
document,
it
might
be
a
little
bit
easier
to
work
through.
F
A
So
I
remember
this
discussion
of
encoding
permissions
and
apples,
and
so
on
at
the
MLS
layer
and
I
apologize
I'm
personally
I'm,
not
an
expert
on
MLS
or
really
how
it
works.
There's
one
thing
I
was
wondering,
though,
is
that,
like
a
question
of
the
layer
of
the
stack
at
which
apples
are
represented,
or
is
there
some
way
in
which
MLS
can
actually
cryptographically
enforce
that
participants
in
a
group
are
like
complying
with
the
apples
that
are
yeah
expressed
at
the
MLS
layer.
F
Then
you
can
share
that
with
every
member
of
the
MLS
group,
and
you
can
be
assured
that
everybody
in
the
same
epic
sees
the
same
copy
of
that
document
and
then
they
can
enforce.
Then
any
any
individual
person
can
go
and
enforce
that
it
doesn't
say
you
know
it
doesn't
Define
what
the
what
the
semantics
are
of
that
document.
It
just
says
if
you
have
an
extension
and
you
want
to
be
able
to
convey
that
information
and
get
agreement
on
it.
This
is
what
you,
this
is
how
you
do.
A
Okay,
so
it
sounds
like
you
get
like
a
cryptographic
guarantee
that
all
of
the
participants
have
the
same
view
of
what
like
the
agreed
upon
apples
are,
but
of
course,
you
can't
prove
that,
like
individual
clients
or
servers
actually
did
then
go
and
force
those
Acts
exactly
that
makes
sense.
Thank
you.
B
B
Unless
we
specifically,
you
know,
give
the
server
the
right
to
do
so,
but
especially
in
a
Federated
environment,
where
you
have
several
servers,
you
essentially
don't
have
to
rely
on
all
of
them,
but
only
in
those
that
you
specifically
choose
who
can
add
and
remove
people.
So
again
you
have
owning
providers,
your
guest
providers,
the
guest
providers,
for
example.
Then
they
don't
have
the
right
to
add
or
remove
people
from
a
group
because
they're
guest
providers
by
Design,
so
all
of
these
nuances
can
be
expressed
and
actually
enforced.
F
So
Raphael,
maybe
if
you
wanted
to
open
up
the
latest
version
of
the
draft,
since
it's
fairly
new,
does,
does
anybody
object
to
maybe
walking
through
the
top
three
or
four
things
that
are
likely
to
get
someone
who
isn't
doesn't
have
a
lot
of
experience
with
MLS
like
these
are
things
that
you
need
to
be
aware
of?
And
you
know
that
what
the
the
DS
implications
are
in
your
draft.
A
A
While
we're
waiting
on
this
as
it
turns
out,
Eric
rascara
won't
be
able
to
join
us
today,
but
we
still
could
take
a
look
at
that
last
slide
in
the
deck
which
has
to
do
with
privacy
metadata,
since,
after
of
course,
looking
at
this
draft,
Raphael
I
think
you
already
broached
the
topic
of
of
metadata
privacy.
When
you
were
talking
earlier
so
I
think
perhaps
we
could
still
have
a
useful
discussion.
B
B
A
B
B
B
B
B
And
so
this
is
the
mechanism
we're
using
here.
These
requests
from
the
client
to
the
delivery
service
very
simply
signed
with
the
same
key
that
is
also
being
used
in
MLS
and
that
allows
the
delivery
service
that
holds
this.
This
ratcheting
tree
as
a
state
as
group
state
to
actually
identify
clients
and
ascertain
that
they're
indeed
part
of
the
group
and
that
they're
allowed
to
send,
commits
and
send
application
messages
Etc.
B
So
we
we
don't
need
another
layer
of
authentication.
In
that
sense,
it's
a
little
more
fine-grained,
because
not
every
operation
is
necessarily
a
signature,
but
this
gives
you
an
idea
that
the
authentication
is
essentially
completely
decoupled
from
any
other
authentication
you
might
have
on
the
system.
B
Thank
you,
yeah.
If
you
scroll
down
a
bit
further
request
response
scheme
so
yeah,
what
we're
proposing
here
is
to
Simply
mimic
what
we
already
did
in
mls
in
in
terms
of
how
we
structure
these
messages
where
we
use
c-structs,
and
then
we
serialize
them
with
a
TLS
codec
that
has
worked
really
well
for
MLS.
This
is
what
we're
proposing
here,
simply
because
this
is
very
close
to
MLS,
so
the
the
code
of
the
application
that
would
deal
with
the
delivery
service
would
also
be.
B
B
B
C
B
B
So
this
might
yeah
look
surprising.
As
Ron
said,
this
is
really
the
MLS
terminology
and
clicking
in
here,
and
so
when
you
receive
a
welcome
message,
what
you
need
is
the
the
ratcheting
tree
that
is
on
the
server
same
with
external,
commit
there.
You
need
the
tree
first
and
then
you
issue
you
as
a
client,
you
issue
an
external
commit
to
insert
yourself
into
the
group,
and
maybe
I
should
say
a
bit
more
about
the
group
stat
and
the
ratcheting
tree.
B
So
the
server
Hazmat
and
by
observing
messages
that
come
in
and
out
like
commit
specifically
the
server,
can
actually
update
this
ratcheting
tree.
So
every
commit
covers
so-called
proposals
and
the
proposals
then
say
in
what
way
the
tree
should
be
modified.
So
an
ad
proposal,
obviously,
like
the
name
says,
proposes
to
add
someone
to
to
designate
a
location
in
the
tree,
and
the
server
can
essentially
update
the
tree
in
the
same
deterministic
way
that
the
clients
will
also
update
the
tree
when
they
receive
the
commit
later
on.
B
So
there
is
no
reason
that
the
clients
actually
have
to
constantly
update
the
tree
on
the
server.
This
happens
automatically
and
it's
a
very
convenient
mechanism
to
have
whenever
a
client
joins
a
group,
particularly
when
the
group
is
larger.
So
MLS
is
about
scalability,
and
the
question
is
how,
on
a
cryptographic
level.
But
the
question
is,
how
can
we
make
scalability
happen?
What
needs
to
happen
on
the
server
side
and
that's
exactly
it.
B
B
So
yeah,
so
these
are
the
on
a
high
level.
These
are
the
two
operations
on
how
you
can
join
a
group
and
that
can
be
initiated
differently
with
different
proposals.
But,
like
the
joining
client
hand,
it's
either
one
of
the
two.
In
the
end,
the
next
part
is
rather
trivial,
adding
and
removing
users.
So
that's
one
of
the
core
functionalities
of
MLS
is
to
how
to
remove
users
to
the
tree.
B
So
what
happens
here
is
simply
that
the
client,
in
the
case
of
adding
users
they're
added
with
so-called
key
packages,
so
key
packages
and
for
those
who
know
the
signal
protocol
that
used
to
be
called
pre-keys
in
MLS.
It's
called
key
packages
in
pgp.
It's
it's
called
public
keys.
So
essentially
it's
a
public
key
material
of
a
user
that
you
need
here.
So
when,
when
you
add
a
user
to
a
group
you
all
you
do
is
essentially
you
tell
the
group
here
the
key
package
of
the
new
user.
B
Fundamentally
MLS
is
like
full
Anarchy.
Anyone
can
do
anything
unless
we
agree
to
have
specific
rules,
and
now
these
rules
can
be
observed
by
the
clients.
There
can
also
be
observed
by
the
delivery
service
if,
if
they
are
on
clear
text,
if
it's
an
extension
to
MLS
that
isn't
clear
text,
the
server
can
enforce
that
as
well.
Ultimately,
it's
important
that
the
clients
know
about
it,
but
it
can
be
very
convenient
if
a
malformed
ad
proposal
gets
already
stopped
at
the
server
level.
B
Right,
the
next
part
is
adding
and
removing
clients
to
and
from
a
group,
so
MLS
doesn't
care
much
whether
members
are
users
or
their
clients
of
users
they're,
just
members.
At
the
end
of
the
day,
however,
we
care
because
they're
fundamentally
different
rules,
so
you
might
not
be
an
admin,
but
you
are
still
allowed
to
add
a
client
that
belongs
to
you
to
the
group.
So
this
is
why
we
need
to
differentiate
here,
run.
F
B
Clients
can
refresh
the
key
material
by
uploading,
a
new
Leaf
node,
with
fresh
key
material
and
replace
the
older
one
in
the
tree.
This
is
what's
Happening
Here
and
that's
a
dedicated
operation,
because
it
doesn't
really
have
any
any
other
particular
effect,
while
doing
so.
Of
course,
I
can
also
upload
more
stuff.
That's
part
of
the
leaf
node,
not
just
the
key
material
that
could,
you
know,
introduce
a
new
signing
key,
for
example,
if
they
have
a
new
certificate,
they
could
propose
a
new
extension
and
whatnot.
B
But
fundamentally
this
operation
updates
a
relief
node
and
if
nothing
else,
there
is
only
just
new
key
material
resyncing
clients.
So
this
part,
sorry
but
I
believe,
is
going
to
be
very
important
because
we've
heard
from
a
lot
of
people
who
implemented
the
signal
protocol
previously
that
things
just
go
out
of
sync
and
that's
not
specific
to
the
signal
protocol
at
all.
But
it's
the
only
protocol
that
has
been
deployed
at
scale
for
end-to-end
encryption
and
it's
the
first
time
that
we
have
cryptographic
sessions
at
scale
that
last
really
long.
B
A
So
you
say
signal
is
sort
of
the
only
example
we
have
to
look
at
here
but,
like
there
are
other,
you
know,
ewe
encrypted
systems
like
I,
guess
iMessage
off
the
top
of
my
head.
I
guess,
do
you
mean
Signal's
the
one
that
like
where
the
details
of
it
are
public
and
where
there's
maybe
a
substantial
body
of
research
on
people's
experience
running
it.
B
B
Yeah
again,
it
has
nothing
to
do
with
a
specific
protocol.
It
could
be
iMessage,
it
could
be.
You
know
anything
else,
whatever
Freeman
is
using,
for
example,
yeah,
but
the
the
fact
remains
that
you
have
you
know
long-running
sessions
and
you
have
bit
flips
on
devices.
You
have
faulty
memory,
you
have
all
sorts
of
things
that
at
some
point
materialize
and
what
you
need
then,
is
to
be
able
to
restart
the
session
and
the
big
question
is
you
know
how?
B
B
It's
more
granular
like
you,
for
example,
you
don't
you're
not
no
longer
able
to
decrypt
messages
from
a
specific
participant
in
the
group,
but
others
still
work
with
MLS.
It's
pretty
radical.
You
can
quickly
tell
when
you're
out,
because
none
of
the
messages
you
receive
can
be
decrypted.
So
on
story
short,
you
need
a
mechanism
to
actually
recover
from
that,
and
this
is
what
resyncing
clients
stands
for.
B
Right
next
operation
and
and
by
the
way
so
I
strongly
believe
that
resyncing
is
something
that
has
to
be
part
of
of
every
mature
protocol.
I
get
anything
you
want
to
deploy
in
production.
At
some
point
you
have
to
think
about
resync.
You
cannot
really
say
yeah
I.
Will
you
know
we'll
see
when
when
it
happens,
because
it
will
happen
at
some
point
and
then
you
have
nothing
to
recover
from
that.
B
Yeah
next
One
is
updating
client
find
out
information.
So
this
part
is
not
super
signal
interest.
Yet
essentially,
the
delivery
service
can
also
store
information
that
is
relevant
for
the
next
phase.
The
fan
art
phase,
and
it
depends
a
bit
on
how
that
phase
is
going
to
look
like,
but
this
is
to
say
that
the
the
state
required
for
that
can
simply
be
part
of
the
the
delivery
service.
State
and
clients
have
a
way
to
update
themselves.
In
that
sense,
yes,
right.
F
B
Yes,
so
just
to
disambiguate
the
terminology,
re-init
is
like
restarting
the
whole
group
for
everybody
and
discarding
the
old
one
and
the
MLS
terminology,
for
example,
when
you
want
to
I,
don't
know,
upgrade
the
Cyber
Suite,
so
you
re-init
the
group
in
the
sense
that
everybody
gets
added
to
the
new
one.
Everybody
knows
about
it,
everybody
discards,
the
old
one
we
think
is
specific
to
the
client.
B
Right
yeah,
so
yeah,
the
history
and
other
things
are
clearly
out
of
scope.
Here,
that's
a
very
good
point,
so
it
might
be
the
case
that
the
client
missed
a
lot
depending
on
you
know
when
it
got
out
of
sync
and
when
it
took
action
to
get
back
into
sync
or
or
to
Regine
to
use
the
new
term
so
yeah
make
sense
we
can.
We
can
rename
that
share
a
strong
feeling
about
it,
but
I
think
we
agree
on
the
scope
here.
Scope
is
purely
again
on
the
MLS
level.
B
B
That
is
what
the
the
content
format
protocol
is
going
to
determine.
Ultimately,
there's
not
much
to
be
said
about
that.
So
in
the
MLS
jargon,
they're
called
application
messages
just
to
distinguish
them
from
commit
messages,
and
they
contain
free
formats
bits
essentially,
and
they
don't
have
to
be
ordered
within
an
epoch
and
if
applications
agree,
they
can
even
also
be
unordered
outside
of
the
epochs,
meaning
that
you
could
still
receive
application
messages
from
previous
epochs.
B
It's
just
a
matter
of
agreeing
on
that
and
keeping
the
key
material
around
and,
of
course,
their
son
in
O
of
one.
So
a
kind
creates
one
application
message:
hands
it
over
to
the
delivery
service
and
the
delivery
service,
multiplies
that
message
and
sends
it
out
to
everybody.
There
is
no
individual
one-to-one
encryption
anymore.
B
C
B
Next
part
is
the
queuing
service,
so
this
is
probably
there's
probably
going
to
be
more
discussion
on
that.
The
queuing
service
is
the
fan,
art
part,
and
maybe
we
need
to
rename
that
maybe
the
terminology
is
not
good
enough
here,
but
it
it
pretty.
Much
boils
down
to
a
delivery
service
receiving
a
message
whether
it's
commit
or
application,
accepting
it
and
then
looking
at
its
own
State
and
determining
who
it
needs
to
send
it
to,
and
if
it's
local
users,
then
we
don't
need
to
specify
how
that
works.
F
Yeah,
you
know
we
at
ITF,
we
have
people
with
a
bunch
of
experience
in
a
bunch
of
different
domains.
I
think
this
is
one
place
where
this
is
a
great
place
where
we
can
call
on
experience
from
you
know
from
people
who
have
not
been
maybe
like
super
active
in
other
areas,
or
that
you
know
people
on
the
IAB
or
isg
who
have
a
little
bit
more
of
a
broader
view.
There
are
tons
of
these.
You
know
message:
bus
architectures,
you
know
Kafka,
like
jet
stream
Nats.
You
know
there.
B
B
B
B
So
we
might
actually,
you
know,
be
interested
in
this
sort
of
thing
to
get
this
feedback,
because
the
owning
delivery
service
might
not
have
an
accurate
view
at
all
on
what's
happening
on
other
servers,
because
there
is
no
other.
You
know
protocol
to
synchronize
at
this
point,
so
they
it
might
rely
on
feedback
from
other
servers.
Saying
hey,
you
know
this.
This
user
is
gone,
remove
it
from
the
group
or
whatever.
B
B
B
Excellent,
thank
you
yeah.
If
you
can
scroll
down
a
bit
again,
the
boilerplate
stuff,
so
yeah,
this
is
really
small,
and
the
idea
here
is
to
see
what
we
need
in
in
terms
of
standardization
at
the
HTTP
level.
So
this
essentially
has
two
interfaces.
One
for
the
first
phase,
where
you
have
this
client
originated
request
that
comes
in
and
the
other
one
is
for
the
fan
out
phase
for
now.
B
Yeah
process
group
message
in
in
one
three
one,
so
this
is
one
endpoint
that
receives
this
delivery,
dirty
service
message
and
that
does
the
processing
and
and
gives
back
a
response.
So
the
other
endpoints
they're,
essentially
just
to
receive,
for
example,
welcome
information
when
you're
not
yet
part
of
a
group.
So
technically
that's
not
really
interacting
with
the
group
just
yet
and
yeah.
B
G
B
And
so
we
didn't
really
speak
about
the
details
of
one-to-one
groups
versus
regular
groups.
We
did
in
the
last
interim
session
and
they
or
even
the
one
before
I'm,
not
sure,
and
it
seems
like
there's
some
initial
consensus-
that
in
order
to
avoid
abuse
and
spam,
we
want
to
only
be
able
to
add
people
to
groups
if
we
already
have
a
one-to-one
connection
with
them,
and
if
we
don't,
we
cannot
add
them
to
a
group.
B
This
is
something
if
we
come
to
that.
You
know
agreement,
finally,
that
we
can
relatively
easily
represent
with
MLS
by
simply
having
two
categories
of
key
packages,
one
that
is
publicly
available
to
anyone
and
that's
good
enough
for
a
one-to-one
connection
that
needs
to
be
accepted
by
users
and
another
category
that
is
not
available
to
everyone
is
only
available
to
people.
You
have
a
connection
with,
and
those
are
also
marked
with
a
special
extension
so
that
you
can
confuse
the
two
essentially
like
you.
B
You
cannot
take
a
key
package
for
a
one-to-one
request
and
use
that
to
add
someone
to
an
an
actual
group.
So
what
is
in
scope?
Also
for
the
delivery
service
is
to
make
these
key
packages
available,
and
this
is
how
you
can
you
can
retrieve
them
with
the
connection
key
packet
retrieval
and
if
you
scroll
down
a
bit
more,
there
should
be
another
way
to
retrieve
them.
B
Yeah
the
group
key
packet,
retrieval
and
yeah
one
one
more.
One
really
important
point
is
rate
limiting
and
we'll
also
get
back
to
that.
When
we
talk
about
metadata
privacy,
if
we
really
aim
for
open
Federation,
we
need
to
be
really
careful
about
the
ways
the
system
can
be
abused,
and
so
we
already
talked
about
how
the
authentication
works,
and
so
we
have
actually
several
layers
of
Defense
here
in
terms
of
right.
B
B
Furthermore,
within
group
most
of
the
requests
they're
specific
to
a
certain
member
in
the
group,
and
then
we
can
also
rate
limit
on
the
the
leaf
index
of
the
specific
number.
So
you
can
relatively
easily
add
the
DS
Level
have
rate
limiting
for
sending
messages,
because
you
can
say
you
know,
user
X
in
in
group
y,
you
know
has
already
sent
10
messages
in
the
past
five
seconds.
B
B
A
B
Excellent
yeah,
thank
you
yeah.
This
is
a
vast
subject.
It's
a
complicated
subject
and
one
that
I
read
very
early
before
the
charger
was
finalized
to
understand
whether
this
is
in
scope
or
not.
From
my
perspective,
this
is
really
important
when
we
talk
about
consumer
messaging.
This
is
a
lot
less
important
for
Enterprise
messaging
and
since
consumer
messaging
is
very
much
in
scope.
For
me,
I
want
to
say
this
is
also
on
scope
and
it's
something
we
have
to
think
about
so
going
over.
The
bullet
points
here.
B
B
In
addition,
it
has
two
kinds
of
messages
or
two
two
versions
of
messages:
they
can
either
be
public
or
they
can
be
private,
and
that
applies
to
proposals
and
commit
messages
and
the
private
ones
they're
additionally
encrypted
essentially
to
give
some
more
privacy.
So
this
is
one
way
how
MLS
could
be
used
to
have
metadata
protection
at
the
message
level,
because
the
header
is
also
encrypted.
B
So
there's
very
little
you
actually
see
in
clear
text,
it's
the
the
group
ID
for
the
message,
but,
for
example,
you
don't
see
who
the
sender
is
of
message.
You
first
need
to
decrypt
the
header
and
then
in
the
decrypted
header
you
can
see
who
the
sender
is
and
then
you
can
derive
the
key
material
to
decrypt
the
rest
of
the
message.
B
So
this
is
one
one
mode
that
gives
us
a
protection
at
the
message
level,
but
only
having
an
at
the
message.
Level
is
not
good
enough,
because
you
know
by
talking
about
that.
We
conveniently
disregard
that.
We
also
have
two
root
messages
from
A
to
B
and
in
that
context
we
need
metadata
again
so
that
it's
certainly
not
the
full
solution.
B
B
A
channel
membership,
so
group
membership
in
the
MLS
jargon
which
sort
of
overlaps
with
who
is
messaging?
Who,
because,
typically
if
people
are
part
of
a
group
you
can
you
can
already
infer
that
they're
messaging
each
other?
If
the
group
is
not
completely
dead,
contact
lists,
I,
guess
that
is
out
of
the
the
specific
scope
of
groups
and
probably
more
on
a
user
level,
I
assume
where
users
have
contacts
in
general.
You
could
also
see
that
as
the
sum
of
all
the
the
one-to-one
groups
you
have
with
other
users.
B
So
it's
it
greatly
reduces
the
amount
of
metadata
that
a
server
gets
to
see
because
it
it
can
only
anonymously
collect
messaging
patterns
in
that
group.
So
it
still
sees
that
Member
One,
you
know,
is
an
active
member
in
the
group,
whereas
member
two
hardly
ever
sends
any
messages
and
stuff
like
that,
but
it
cannot
really
correlate
that
with
other
identities
like
real
world
identities
or
identities,
from
some
sort
of
an
identity
provider.
B
So
it
would
be
very
similar
to
that.
It
would
also
come
with
yeah
more
explanation
on
the
architecture
as
a
whole.
So
that's
while
we,
you
know
strip
away
some
metadata.
We
don't
add
it
again
later.
For
example,
if
we
end
up
not
really
specifying
how
the
fan
art
works,
then
that
might
be
one
of
the
areas
where
we
need
to
be
more
specific
going
forward
when
we
want
to
do
that.
Yes,
Ron
go
ahead.
F
Do
we
I
I
can
totally
imagine
that
some
people
who
want
to
deploy
a
messaging
system
want
to
have
more
metadata
for
various
reasons
or
may
even
be
required
to
have
some
and
also
you
know
lots
of
services
that
would
be
very
keen
to
have
limited
metadata
or
no,
you
know
the
minimum
possible
amount
of
metadata,
I
guess.
The
question
is:
how
do
these
systems?
F
B
Yeah,
no
that's
a
good
question,
so
the
underlying
assumption
here
is
that
nobody's
forced
to
do
anything
like.
If
you
don't
care
about
the
metadata
minimization
you
you
simply
don't
do
any
of
that
and
two
degrees.
It's
an
open
question
you're
asking,
but
in
the
sense
that
we
cannot
fully
answer
it,
but
my
understanding
so
far
is
that
the
the
interrupt
that
we're
discussing
is
always
on
a
group
level.
B
F
B
B
G
Sorry,
my
microphone
didn't
want
to
cooperate.
Yeah
no
I've
I've
been
paying
attention.
I
think
that
your
draft
has
been
good,
but
I
wanted
to
comment
on
this.
From
my
view
it
it
would
seem
that,
even
though
this
may
be
up
for
debate
among
specific
implementations,
different
use
cases
might
come
forward
with
different
configurations.
I
would
think
that
the
ietfs
work
on
interoperable
messaging
to
Define.
G
What
is
the
sort
of
bare
minimum
requirements
would
be
helpful
so
that,
when
implementations,
kind
of
sort
of
depart
from
that,
that
is
then
sort
of
their
choice
right
or
there's.
A
distinction
between
this
is
the
metadata
that
is
at
minimum,
required
to
run
an
interoperable
messaging
service
and
everything
else
on
top
of
it
isn't
required,
but
is
tied
to
features
or
other
kinds
of
services
that
that
particular
provider
has
chosen
to
implement,
and
so
I
would
because
I
feel
like
this
section.
This.
This
topic
is
so
important.
B
Yeah
thanks
I
personally,
at
this
point
at
least
I
feel
it's
relatively
binary
in
the
sense
that
you
have
to
decide
ahead
of
time,
whether
you
care
about
metadata
protection
or
not,
and
then
pick
that
one
flavor
and
and
instantiate
your
group
I,
don't
think.
But
this
you
know
could
change
over
time,
but
I
don't
think
it
makes
a
lot
of
sense
to
say
the
you
know.
B
A
Thanks
so
it
does
seem
like
perhaps
a
lot
of
the
tension
here
is
introduced
by
the
notion
of
wanting
like
consumer
messaging,
to
interrupt
with
Enterprise
messaging,
because
it's
intuitively
very
just
different
expectations
from
like
the
operators
and
the
users
of
those
systems,
I
think
about
things
like
privacy.
What
I
mean
is
that,
like,
if
I
join,
my
employer,
slack
I
mean
I,
understand
and,
to
some
extent
like
agree
to
having
some
like
either
you
know
the
messages
themselves
or
metadata
about
them,
be
visible
to
my
employer.
F
I
I
have
an
answer
for
you
shoot,
so
one
of
the
reasons
I
mean
this
is
in
fact
one
of
the
reasons
why
the
dma
was
created.
If
you
look
at
the
language
carefully,
it
actually
talks
about
about
provide
your
European
providers
being
able
to
get
access
to
customers
on.
You
know
what
turned
out
to
be
basically
consumer
messaging
systems.
F
But
let's
take
the
case
where
you
have
a
like:
a
a
stock
broker
and
they're
customers,
so
they've
been
getting
in
trouble
because
their
customers
are
contacting
the
stock
Brokers
using
WhatsApp,
for
example,
and
trying
to
do
trades,
and
so
this
is
a
classic
case
where
you
have
a
user
that
is
using
a
consumer
surface.
That
wants
to
talk
to
somebody
who
also
has
a
you
know
an
Enterprise
messaging
system,
because
they
have
a
customer.
You
know,
supplier
or
customer.
You
know
provider
kind
of
a
relationship.
B
B
F
Maybe
it's
the
Mimi
protocol
with
the
right
intersection
of
of
of
settings.
You
know
basically,
what
this
is.
What
I'm
able
to
do?
Are
you
okay
with
that,
and
if
that's
not
what
your
default
allows?
The
consumer
messaging
system
says,
like
hey,
you're,
being
asked
to
go
and
comply
with
this
thing
that
says
that
you're
going
to
be
recorded.
Are
you
okay
with
that.
B
B
B
E
B
B
However,
in
this
particular
instance,
we
don't
we
don't
have
the
luxury
of
having
no
metadata,
simply
because
we
need
the
metadata,
for
you
know,
routing
the
messages
for
preventing
spam
and
abuse,
and
the
question
is
only
whether
the
metadata
is
pseudonymous
anonymous
or
not,
so
that
this
is
the
degree
of
Liberty
we
have
is
to
take
away
like
the
the
real
life
identities
to
take
them
out
of
the
system
and
doing
so
requires
a
bit
of
work
to
make
it
pseudonymous.
So
it
really
doesn't
come
for
free.
B
You
have
to
do
you
know
more
encryption
at
a
certain
level.
You
have
to
do
a
few
more
things,
so,
for
example,
and
I
didn't
go
into
all
the
details
there,
but
rate
limiting
becomes
a
bit
more
challenging
when
you
don't
recognize
for
people
like
you,
don't
recognize
your
attacker
between
two
requests,
because
you
lack
you
know
the
metadata.
You
don't
know
who
it
is
so
one
of
the
properties,
for
example,
is
that
you
never
have
the
same
identity
in
two
different
groups.
B
So
this
is
where
it
gets
more
complicated
to
to
prevent
abuse
and
spam,
and
so
one
of
the
solutions
there
is
to
use
something
like
privacy
pass,
which
gives
you
tokens
that
are
essentially
Anonymous
but
they're
limited.
So
you
can
spend
them
on
operations
without
being
recognized,
but
you
can
only
spend
as
many
tokens
as
you
initially
received
at
a
time
when
you
were
in
fact
not
anonymous
stuff
like
that.
So
we
don't.
We
don't
have
the
luxury
where
we
start
with
very
little
metadata,
and
then
we
we
add
it
for
Enterprise
users.
B
F
F
That
is
perhaps
selective
like
in
the
case
where
somebody
said
I
think
this
is
spam
or
somebody
report
you
know
reported
or
blocked
a
user.
Do
you
see?
Do
you
see
that
finding
it
discovering,
like
you,
know,
basically
re-correlating
a
bunch
of
a
bunch
of
sessions
that
were
pseudonymous
pseudonymous
using
using
different
identifiers?
Do
you
see
that
as
a
sort
of
a
feature
or
a
property
that
may
be
required?
F
B
B
The
user
is
not
going
to
be
pseudonymous
to
you,
and
then
you
can
also
report
that
user
to
the
system,
and
then
the
system
can
do
whatever
it
wants.
With
that
report,
that's
not
really
something
Mimi
should
solve,
but
what
it
can
do
in
Practical
terms.
It
can
you
know,
limit
the
amount
of
privacy
pass
tokens
that
user
gets
or
terminate
the
account
or
whatever.
F
F
B
F
You
know
basically
solving
the
problem
for
a
single
recipient,
isn't
really
very
good
like
we
what
we
want.
Ultimately,
what
what
some
of
these
providers
probably
want
is
the
ability
to
take
information
that
somebody
was
a
that
some
user
account
was
used
for
spam
and
used
that
to
go
and
help
other
people
who
were
who
are
recently
communicating
with
the
same
the
same
real
user.
B
So
yeah
to
transfer
your
question
a
bit
more
from
from
before
on,
we
have
to
do
some
serious
threat,
modeling,
which
we
have
already
done,
but
it's
probably
not.
You
know
exhaustive
and
see
what
all
the
possibilities
are
and
see.
If
we
have
the
right
tools
to
prevent
that
and
understand
if
we
are
in
a
worse
place
than
say
in
a
system
that
had
no
encryption
and
no
metadata
protection
at
all,
we
can
still
do
message
ranking,
for
example,
with
Facebook
Messenger.
A
B
E
B
D
B
B
A
A
A
A
A
Enough
yeah,
it
is
weird
how
long
that
takes
in
and
meet
Echo.
Okay.
Thank
you
Rafael
very
much
for
leading
all
the
conversations
today,
I'm
very
much
appreciated
and
thanks
everybody
for
attending
so
yeah.
We
have
another
one
of
these
scheduled
another
one
of
these
interims
that
is
scheduled
for
June
hang
on.
Where
is
it
sorry
for
Wednesday
May
31st,
since
we
got
through
everything
today
like
there's,
nothing
officially
on
the
agenda
just
now,
but
of
course
feel
free
to
contact
the
chairs
myself
and
Alyssa?