Hi,
thanks for giving us your side of the story, Tim.
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.
So I guess you'd just get empty <item/>s with the id being the OMEMO
device id then? That's nice. Is this supported everywhere?
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.
Where? This change would imply quite a few internal incosistencies. Most
importantly, you haven't addressed the problem of what happens when the
server doesn't support multiple items per node, or doesn't support as
many entries as you need. You just kinda hand waved it as "people are
working on it", but tbh that's not nearly good enough. So it just stops
working then, right? A *ton* of people are using this protocol already,
many of whom you'd be breaking this for. Even if this eventually makes
it into releases of every major server software, operators out in the
wild don't always update immediately to the newest version of everthing.
In fact, it's actually really hard to get them to.
I know I'm repeating myself here, but you're not really acknowledging
the very real consequences this change will have for a lot of users.
This *will* break things, there's no way around it. So in the mean time,
what are we supposed to tell users? Change servers? And all of this for
what? A change that doesn't actually fix any real problems? IMO you
really need to come up with a better justification for this than that it
"feels more correct". That's not good enough.
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.
I don't really see how this change simplifies anything in any meaningful
way. You still have to do all the same checks on the client that you had
to do before. So what are we future proofing against here, exactly? What
future effects are you anticipating that will break the current mechanism?
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 my view these are completely separate issues. One is something we
have control over, because it's on the client. The other we don't,
because the blocker are existing server deployments. If a user has a
problem it's significantly easier to tell them to update their software,
than to get their server operator to deploy updates. So I don't think
it's sensible to say this needs to be done before the new OMEMO version
comes out. Your change would be delaying the new version, because it
couldn't be adopted before there is widespread support in existing
server deployments for it.
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.
It's easy for you to say "we can fix it on the clients and the servers"
if you don't have any users that will be impacted by this. Getting
existing server deployments to upgrade is just not that easy. Make no
mistake, this will take time.
So even if we were to go this way, the timeline until we could in good
conscience actually enable this change in the client is on the order of
many, many months. Because I'm not about to break the protocol for my
users. So at that point, I have to ask myself, if we're already in this
for the long haul, why not actually do it right, i.e. explicit server
support?
I'm still not convinced that's really needed, because experience tells
me this isn't really a problem that needs fixing, but it's obviously the
much better solution. If you actually wanted to "future proof" OMEMO,
this is what you'd do, because it fixes many more small annoyances, at
similar cost (i.e. requiring server operators to deploy updates).
Cheers,
Andy
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
