Hey all,
this topic has been discussed at the summit and in other venues before,
and now a proposal to abolish the devicelist and move all bundles into
separate items in a single PEP node has been submitted. I have raised my
concerns in those abstract discussions in the past, but now we have
something concrete we can discuss.
https://github.com/xsf/xeps/pull/458/files
While I recognize that the way we've been using PEP is somewhat
unorthodox, I see several severe issues with this newly proposed approach.
Most importantly, this change effectively relies on OPTIONAL/MAY
behavior in PEP. PEP/pubsub do not mandate that the server has to keep
around more than one item per node. Therefore, this change will limit
the number of OMEMO devices a user can have active at the same time to
the maximum number of items per PEP node as supported by the server,
which in the general case has to be assumed to be 1. The devicelist is
an absolutely essential component of OMEMO, and it *has to* work
properly. Without it, we not only lose multi-device, but have to deal
with severe reliability issues related to whichever device(s) happen(s)
to be currently announced or not (i.e. messages only arriving at random,
possibly frequently changing subsets of devices without the user being
able to control this at all)
Furthermore, by eliminating the indirection via a separate devicelist
node and subscribing to all bundles directly, a significant increase in
traffic overhead is to be expected. Any time a bundle changes, all
contacts will receive the entire bundle. This happens frequently in
OMEMO. For example, whenever a new session is established, according to
the XEP, the responder SHOULD change their bundle (removing the used-up
prekey). Clients might also rotate their signed prekey regularly. Any
time these things happen, all OMEMO-enabled contacts (and other own
devices) will receive the full bundle. Note that in most cases, these
clients don't care at all about these events. The only times a client
would actually want to be passively informed about changes is when
devices are newly created or removed entirely, which is the vast
minority of these events. (For reference, bundles with the suggested
number of prekeys (100) are around 9-10kb in size.)
This proposal is also internally inconsistent. Some of the prescribed
behavior makes no sense under this new architecture (e.g. there is no
point in explicitly fetching bundles anymore). It is also lacking
business rules describing how to handle the issues I raised above.
In theory, this change does eliminate contention on the devicelist.
Currently, announcing a device requires updating the devicelist to add
the new device, while retaining all old ones in the same item
("read-update-write"), so there might be a situation where devices
overwrite one another if they both attempt to announce themselves at the
same time. But this really isn't as big of an issue as it may seem at
first. First of all, the odds of this happening are very slim. Devices
are not created anew or removed entirely very often in regular use.
There's also a really simple fix for this in the current XEP already:
clients MUST check that their own device is included in the list
whenever they receive an update for their own devicelist, and if not,
add themselves again. We've been doing it this way for 1.5 years now,
and not once has this caused a problem. But more importantly, this
behaviour needs to be in the XEP regardless of this change, because
clients have to ensure that they are currently announced at all times
anyway, because there are numerous other reasons why a device might have
been removed. So it's not like the proposed change would even simplify
anything here.
What's more though, as I described above, the proposed change "fixes"
this theoretical problem at the cost of possibly introducing contention
on the bundles, which is actually a much worse problem. If the server
can't retain several bundles at the same time, this is not something
that the clients can fix by simply publishing again. Best case: you lose
multi-device entirely, and whichever device has last published a bundle
is the only one that can use OMEMO at any moment in time. Worst case:
clients keep overwriting one another in order to re-announce themselves
ad infinitum.
In summary, I understand that the current behavior can seem strange at
first, and I'm certainly not opposed to improving this in some way, I
really don't think this proposal is the way to go here. It breaks the
protocol. If anything, we should maybe think about adding explicit
server-side support for OMEMO. I would be interested to hear what the
wider XMPP community thinks.
Cheers,
Andy
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
