[Standards] Offline Feature Negotiation and Device Lists

Dave Cridland dave at cridland.net
Mon Feb 17 08:57:27 UTC 2020

On Sun, 16 Feb 2020 at 12:49, Ralph Meijer <ralphm at ik.nu> wrote:

> Hace 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

> --
> ralphm
> ------------------------------
> *From:* Dave Cridland <dave at cridland.net>
> *Sent:* Sunday, February 16, 2020 12:58
> *To:* XMPP Standards
> *Subject:* [Standards] Offline Feature Negotiation and Device Lists
> Hiya,
> We talked at the Summit about wanting to do device lists and things, but
> we didn't actually get that far. That's fine, of course, we can't discuss
> everything.
> But perhaps we can discuss what we want out of such a thing now.
> I'm thinking there's three potential "consumers" for such a
> feature-cluster:
> 1) Other Clients
> You have multiple devices, running potentially multiple clients. They may
> wish to know about each other on a long-term basis.
> 2) Your Home Server
> Your Home Server might need to know about which clients you're actively
> using in order to offer generalised services and things.
> 3) Other Entities
> Other entities may wish to know what features are, in general, supported
> across all or some of your devices. They may only need to know aggregations
> of this, or may need to know more details in some cases.
> I think - and may be wrong - that (1) and (2) are very closely related
> here. They'd always be non-aggregated, and for things like authentication
> this would be managed by the clients but executed upon by the server.
> (3) is different; I'm unconvinced that we ever want to allow a third party
> to know the details of what clients exist (though ClientInitKeys will
> reveal that to some degree). But we do want to indicate if, for example,
> "all" our clients support encryption, or only "some". We might even want to
> indicate meta-detail - all our clients may support encryption, but we might
> actually prefer things not to be encrypted by default - but perhaps that's
> outside the scope here.
> I think we build (1) and (2) out of a series of private PEP nodes, with
> one item per client. We identify a client by UUIDv4 generated by the
> client. We would have a PEP node containing XEP-0030 disco#info, which
> would then synthesize the information for (3).
> I think we build (3) out of that information as two (or maybe more) PEP
> nodes. A tricky challenge is that clients that don't understand (1)/(2)
> won't be aggregated properly. I suggest, therefore, that use of clients
> that don't support (1)/(2) causes some kind of fallback mechanism in (3) -
> perhaps we assume it's an unknown client and move anything unsupported to
> "some".
> I think entity caps and end-to-end XEP-0030 will drastically reduce as a
> result of this, by the way.
> Does all this sound like a starting point?
> Dave
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200217/cf35a4b6/attachment.html>

More information about the Standards mailing list