On 18.06.19 13:05, Dave Cridland wrote: > On Mon, 17 Jun 2019 at 17:09, Florian Schmaus <[email protected] > <mailto:[email protected]>> wrote: > > The solution back then was PEP, which is based on PubSub. Why would you > want to build a publish-subscribe mechanism not on XEP-0060 PubSub? > > > It's possible to put everything into XEP-0060 - indeed, XEP-0207 > discusses exactly this, and shows examples of putting the roster and > presence notifications into PubSub.
If XEP-0207 tries to deliver a message within a humorous XEP, then I am not sure which message that is. Of course no one would seriously want to base the Roster on PubSub/PEP at this stage. But if we where to completely design it from scratch in a clean room scenario, then using existing building blocks is always an option (and IMHO a desirable one). > I'm not going that route because the additional semantics of the roster > are useful here - but if you're open to replacing the roster entirely > with a more scalable design, I'm totally open to that. I am curious what additional semantics that are, besides the coupling of some data to a JID and roster pushes (which would probably do more harm than good). > What about entries which are not in the roster? > > > Put them in, and mark them as ad-hoc entries. This could potentially cause UX issues for users with a lot of non-roster chats and clients unaware of the marker. > What about entities > which are not interested in the additional roster metadata? > > > This one is really easy - we really do know how to negotiate extensions > these days. If a client doesn't want to know, we'll just not tell it. And how does it affect roster versioning? Will there be two versions of the roster, one for the clients which did not request the additional metadata and one for the clients which did? Is there a roster push every time some metadata changes? If so, does it contain all the other metadata? I do not believe that this is a desirable approach for the same reason I don't want MIX channels in the roster. Instead we should probably consider creating a generic way to retrieve (and store) arbitrary metadata linked to (bare) JIDs. That metadata could include unread count, which would be server generated. It could act as 'kind' marker for bare JIDs, marking e.g. MIX channels. And could also be used to store user-provided per-jid settings. Additionally, if we design it well, then this allows to perform lookups like: - Return all my MIX channels bare JIDs - Return N bare JIDs with an unread count >0 sorted by last activity - Return N bare JIDs with an unread count >0 sorted by most unread messages I fear that if we would bend the roster into such a thing, we will end up with a very complicated protocol, which causes error prone implementations. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
