[Standards] Offline Feature Negotiation and Device Lists

Dave Cridland dave at cridland.net
Sun Feb 16 11:58:30 UTC 2020


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

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

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200216/d8437b84/attachment.html>

More information about the Standards mailing list