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. > > 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. > Cheers, > Andy > _______________________________________________ > > Standards> mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ Regards, Tim _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
