Hace you considered special disco nodes on the account that get synthesized by
the server based on the disco information from registered devices? Do you think
there's value in the ability to subscribe to this information via PEP?
--
ralphm
From: Dave Cridland
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-unsubscr...@xmpp.org
___
