[Standards] Offline Feature Negotiation and Device Lists
ralphm at ik.nu
Mon Feb 17 11:12:03 UTC 2020
On 17-02-2020 09:57, Dave Cridland wrote:
> On Sun, 16 Feb 2020 at 12:49, Ralph Meijer <ralphm at ik.nu
> <mailto:ralphm at ik.nu>> wrote:
> > Have you considered special disco nodes on the account that get
> > synthesized by the server based on the disco information from
> > registered devices?
> I wondered about that. We could have a pair of disco nodes as well, yes.
> > Do you think there's value in the ability to subscribe to this
> > information via PEP?
> I think there's severe disadvantages in having the information only
> available via PEP. But PEP remains our best choice for data that needs
> to be public and disseminated around a user's contacts.
> The trouble is that PEP is also limited in the case of anything but a
> two-way presence subscription.
> But using PEP for entity caps (XEP-0390-in-PEP, in effect) seems like a
> useful compromise, with the actual disco being held against the user's
My thinking here was that you'd have two nodes you can access both via
disco as well as publish-subscribe. Notifications for the latter would
be constructed by the server (as only publisher), and an entity could
subscribe either directly (e.g. another server), or via +notify (other
clients). One node for "all registered devices support these things",
one for "at least on registered device supports these things".
A two-way presence subscription would not be needed if the nodes have an
open access model. I haven't really considered in what cases having
either an open access model, or not being able to use +notify, would be
considered a downside.
I'm not sure about the need for CAPS hashes for this, next to the full
disco#info in the payload of a pubsub item. If so, we probably should
have two parallel nodes for subscribing (explicitly or implicitly) to
just the hashes.
One thing I'm concerned about in general is what happens if I start
sending presence to my contacts. I would get a PEP notification for each
of my contacts with their capabilities. Bandwidth-wise having hashes
here helps, but still it is a lot of traffic. Especially for mobile
uses, it might be better to retrieve this information incrementally,
through regular disco or perhaps a new IQ-get exchange for CAPS hash sets.
Crazy idea: a sibling element to the MAM result messages when doing an
inbox request, with the CAPS hash set for the entry's other party.
More information about the Standards