On 26.03.2017 00:01, Timothée Jaussoin wrote:
Hi,
It seems that this pull request brought some interesting discussions.
I'll try to clarify my position regarding this pull request.
Le vendredi 24 mars 2017 à 17:03 +0100, Andreas Straub a écrit :
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)
I agree with that and I trully think that this behavior needs to be clarified.
It seems indeed that this OPTIONAL/MAY in the PEP
extension brought two points of view on how PEP can be seen. To me, if a server
can store several items per PEP nodes (which is the
case on several XMPP servers already) then I see it as a "Pubsub service"
available under a user JID.
Also, some XEPs like Microblog (0277) and Pubsub-Subscription (0330) are already relying on it and are implemented in clients. The work
that we are currently doing to modernize the Bookmark XEP (0048) also replies
on the fact that each bookmark will be store in different
items under the same PEP node (to prevent the current race-condition issue that
we have today).
As I understood this behavior was mostly crafted like this because it was
working on existing servers implementations, especially for
Prosody that doesn't support persistance of items in its current stable release.
My understanding of this subject from your similar discussion here
https://mail.jabber.org/pipermail/standards/2017-January/031839.html is
that the only protocol-compliant way to determine it is getting/setting
max_items to be more than 1. Which means client needs to identify
following features support - item-ids, persistent-items, config-node and
then from the config get or set max_items to the required number.
Where _required number_ will in this particular case be equal to number
of devices to support. To get number of devices you need to get current
number of items and either find own item there or set to current+1 and
add own item. Or it could be pre-set to certain _reasonable_ number, and
if fully occupied - to execute certain garbage collector and prompt
extension/cleanup from the user.
Now, do I understand it right that this particular sequence of events
and decisions is suggested to be offloaded to the server side as being
too complicated for client to perform?
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.)
See https://xmpp.org/extensions/xep-0060.html#owner-configure.
This behavior can be fixed by setting pubsub#deliver_payloads to false in the
'urn:xmpp:omemo:0' node configuration. The clients will
then only get a small notification and not the whole bundle anymore, it can
then retrieve the bundle manually if he needs it. Again
here we are relying on features that already exists. I can complete my pull
request to enforce this behavior on node creation.
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.
See 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.
Again a totally agree with you and your solution seems to be a perfect way to
figure out this problem for now. But, with my proposal,
I'd like to make this XEP future proof (afaik the Prosody team is planning to
implement the missing behavior in their future release)
and only relies on existing XEPs (PEP and Pubsub) techniques to makes the
results more coherent and simple.
Also, I saw that the current OMEMO implementations (in Gajim and Conversations
for now) are relying on the historical namespace
'eu.siacs.conversations.axolotl' that will break the day they move to the one
defined in the official XEP. Because this can takes a bit
of time I prefer to address those architectural concerns now better than having
to redefine it when we will have proper servers
supports.
In the end the XEP will just define:
- a namespace for the bundles urn:xmpp:omemo:0
- a unique PEP node (urn:xmpp:omemo:0) to store them
- a rule that said that the devices ids are the item ids of the PEP node
The main point of my pull request is to try to keep XMPP coherent and relies on
existing XEPs. If it brings implementations and support
issues, we can fix it on the servers and clients, if there is something unclear
in the PEP XEP, we can also talk about it and try to
figure out why we have different point of views on this part of the extension.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
