[Standards] Offline Feature Negotiation and Device Lists

Ralph Meijer 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 
> account.

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 mailing list