Re: [Standards] MIX (XEP-0369) channel discovery
Ralph, As I vaguely recall, the problem wasn't disco#info clashing between MUC and MIX - as you say, those shouldn't clash. The problem is disco#items, where MIX and MUC use disco#items to yield entirely different information. MUC will respond with room occupants, whereas MIX responds with channel nodes. It's the only clash between the protocols. Seems fair to have the channel nodes be children of an abstract mix node. But this should only be needed for disco#items, not disco#info. Dave. On Thu, 20 Sep 2018 at 08:43, Ralph Meijer wrote: > Hi, > > Recently I have been looking at discovery of entities to determine what > kind of thing it is, knowing nothing more than its JID. The starting > point is a client that shows a list of entities, based on past > conversations (MAM), ordered by last interaction. Entities could be > regular user accounts, bots, group chat rooms, etc. > > The core idea behind XEP-0030 (Service Discovery) is that given a JID, > you can find out what kind of entity it is, by sending a Disco Info > request and getting one or more identities in return. Additional > information like supported features/protocols, and meta-data as Disco > Extension Data Forms (XEP-0128), can be included there, too. > > Reading XEP-0369, section 6.3, on discovering channel information, I see > that it currently requires the node attribute to be set to 'mix'. From > what I understand this is to allow a particular JID to support both MUC > and MIX, and have a way to request the MIX specific information. > > The problem I have with this, is that it requires prior knowledge of a > certain JID (also) being a MIX channel. So you can't find out the > identity (the thing that's telling you what a JID is) without knowing > what the thing is. I do understand this works if you start out with > discovering the MIX service first, but I don't believe that should be > the only entry point. > > I don't see the need for explicitly asking for the MIX information > (only). XEP-0030 and XEP-0128 support returning multiple identities as > well as multiple extension forms. So a Disco Info result, without node, > could look like this: > > id='ik3vs715' > to='hag66@shakespeare.example/UUID-c8y/1573' > type='result'> > >category='conference' > name='A Dark Cave' > type='mix'/> >category='conference' > name='A Dark Cave' > type='text'/> > > > > > > > > > > > > > urn:xmpp:mix:core:0 > > > Witches Coven > > > A location not far from the blasted heath where > the three witches meet > > > > > http://jabber.org/protocol/muc#roominfo > > label='Description'> > The place for all good witches! > > > > > > Note that I included the channel info from section 6.5 here. I was > surprised to find we aren't using XEP-0128 disco extensions instead of > doing a pubsub items request here. I /do/ see the value for having the > pubsub node as way to get notifications on changes, so having both would > be even better. If you have to do a Disco Info request anyway, it saves > one request. > > Finally, section 12, on Registrar Considerations, doesn't mention the > required registration [1] of the identity conference/mix. Unfortunately > one identity can have at most one extension form, so reusing > conference/text is probably not a good idea. > > [1] https://xmpp.org/registrar/disco-categories.html#conference > > -- > ralphm > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] MIX (XEP-0369) channel discovery
On 9/25/18 10:58 AM, Steve Kille wrote: > Ralph, > > >> -Original Message- >> From: Standards On Behalf Of Ralph Meijer >> Sent: 20 September 2018 08:43 >> To: XMPP Standards >> Subject: [Standards] MIX (XEP-0369) channel discovery >> >> Hi, >> >> Recently I have been looking at discovery of entities to determine what > kind of >> thing it is, knowing nothing more than its JID. The starting point is a > client that >> shows a list of entities, based on past conversations (MAM), ordered by > last >> interaction. Entities could be regular user accounts, bots, group chat > rooms, etc. >> >> The core idea behind XEP-0030 (Service Discovery) is that given a JID, you > can >> find out what kind of entity it is, by sending a Disco Info request and > getting one >> or more identities in return. Additional information like supported >> features/protocols, and meta-data as Disco Extension Data Forms > (XEP-0128), >> can be included there, too. >> >> Reading XEP-0369, section 6.3, on discovering channel information, I see > that it >> currently requires the node attribute to be set to 'mix'. From what I > understand >> this is to allow a particular JID to support both MUC and MIX, and have a > way to >> request the MIX specific information. > [Steve Kille] > > Yes, this was the rationale (set out in 6.3). > >> >> The problem I have with this, is that it requires prior knowledge of a > certain JID >> (also) being a MIX channel. So you can't find out the identity (the thing > that's >> telling you what a JID is) without knowing what the thing is. I do > understand this >> works if you start out with discovering the MIX service first, but I don't > believe >> that should be the only entry point. > [Steve Kille] > > Your logic for this extra entry point is spot on. I propose to remove > the specification of node=mix, as you suggest. > > I have checked over, and agree with you that there is no conflicting > information. > > > The consequence of this is that: > 1. A MIX client may see MUC information. This should not be an issue > 2. A MUC client will see new MIX information.Is this going to cause any > significant breakage? It shouldn't cause breakage. > I was specifically asked to make this node=mix change (I cannot remember by > whom, but it was not something that I designed). I could not find any > notes or emails. I'd like confirmation from my co-author before making > this change. > > Can anyone else involved in early MIX discussions think back?This was > put in for a reason, and I'd prefer not to break something by making this > change. The idea behind the 'node' attribute for an information request is to "filter" on desired information for a particular feature supported by the entity; the best example I know of is ad-hoc commands (XEP-0050), where you might want to find more detailed information about a specific command. Such a scenario does not apply in the case of MIX, as far as I can see. >> I don't see the need for explicitly asking for the MIX information (only). > XEP- >> 0030 and XEP-0128 support returning multiple identities as well as > multiple >> extension forms. So a Disco Info result, without node, could look like > this: >> >> > id='ik3vs715' >> to='hag66@shakespeare.example/UUID-c8y/1573' >> type='result'> >> >> > category='conference' >> name='A Dark Cave' >> type='mix'/> >> > category='conference' >> name='A Dark Cave' >> type='text'/> >> >> >> >> >> >> >> >> >> >> >> >> >> urn:xmpp:mix:core:0 >> >> >> Witches Coven >> >> >> A location not far from the blasted heath where >> the three witches meet >> >> >> >> >> http://jabber.org/protocol/muc#roominfo >> >>> label='Description'> >> The place for all good witches! >> >> >> >> >> >> Note that I included the channel info from section 6.5 here. I was > surprised to >> find we aren't using XEP-0128 disco extensions instead of doing a pubsub > items >> request here. I /do/ see the value for having the pubsub node as way to > get >> notifications on changes, so having both would be even better. If you have > to do >> a Disco Info request anyway, it saves one request. >> >> Finally, section 12, on Registrar Considerations, doesn't mention the > required >> registration [1] of the identity conference/mix. Unfortunately one > identity can >> have at most one extension form, so reusing conference/text is probably > not a >> good idea. >> >> [1] https://xmpp.org/registrar/disco-categories.html#conference > [Steve Kille] > > Good catch. Need to put something in registrations section.I agree > that conference/text is a bad idea. > > Does anyone see any issues with conference/mix ?
[Standards] Generalisation of XEP-xxxx: MUC Avatars
I just reviewed the XEP-: MUC Avatars and I would like to discuss some ideas about it before proposing adjustments. The core idea of this XEP is to expose the Vcard hash in the bare MUC JID disco#info and notify it using a message 104. This is a really specific use case that solves a really specific problem. However the method that is used in this XEP to store this hash could be generalized to other cases. I see two things there: - How are we storing the avatar hash (here in a specific field in disco#info) - How this hash is advertised to the subscribers disco#info is a pretty generic feature in XMPP that is actually already applied to most of the resources available on the network including: - MUC JIDs - Users JIDs - Pubsub nodes What I'd like to propose is to generalize this XEP to allow this method to be used across all those resources, this will allow to have a unified method (it maybe sounds like https://xkcd.com/927/) to handle the retrieval of Avatars and also finally allow Pubsub nodes to have an avatar (and Vcard information as well if possible, see my last point). This brings me to the second part of my proposal. How to advertise the change. - For MUC, I'd suggest to stick with the status code='104' even if I'd prefer to use XEP-0153 presences for that - For Users JIDs, simply stick with XEP-0153 - For Pubsub nodes it could also reuse XEP-0153 in a Pubsub notification as a payload Last proposal would not be to mention only Avatar but simply Vcard (vcard-temp in this case) then we could put more metadata in this payload (add an address to a Pubsub node for example) but I'd like to have more feedback on that one. In any cases I'll try to formalize those proposals in a PR to this XEP :) Regards, Timothée Jaussoin ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] MIX (XEP-0369) channel discovery
Ralph, > -Original Message- > From: Standards On Behalf Of Ralph Meijer > Sent: 20 September 2018 08:43 > To: XMPP Standards > Subject: [Standards] MIX (XEP-0369) channel discovery > > Hi, > > Recently I have been looking at discovery of entities to determine what kind of > thing it is, knowing nothing more than its JID. The starting point is a client that > shows a list of entities, based on past conversations (MAM), ordered by last > interaction. Entities could be regular user accounts, bots, group chat rooms, etc. > > The core idea behind XEP-0030 (Service Discovery) is that given a JID, you can > find out what kind of entity it is, by sending a Disco Info request and getting one > or more identities in return. Additional information like supported > features/protocols, and meta-data as Disco Extension Data Forms (XEP-0128), > can be included there, too. > > Reading XEP-0369, section 6.3, on discovering channel information, I see that it > currently requires the node attribute to be set to 'mix'. From what I understand > this is to allow a particular JID to support both MUC and MIX, and have a way to > request the MIX specific information. [Steve Kille] Yes, this was the rationale (set out in 6.3). > > The problem I have with this, is that it requires prior knowledge of a certain JID > (also) being a MIX channel. So you can't find out the identity (the thing that's > telling you what a JID is) without knowing what the thing is. I do understand this > works if you start out with discovering the MIX service first, but I don't believe > that should be the only entry point. [Steve Kille] Your logic for this extra entry point is spot on. I propose to remove the specification of node=mix, as you suggest. I have checked over, and agree with you that there is no conflicting information. The consequence of this is that: 1. A MIX client may see MUC information. This should not be an issue 2. A MUC client will see new MIX information.Is this going to cause any significant breakage? I was specifically asked to make this node=mix change (I cannot remember by whom, but it was not something that I designed). I could not find any notes or emails. I'd like confirmation from my co-author before making this change. Can anyone else involved in early MIX discussions think back?This was put in for a reason, and I'd prefer not to break something by making this change. > > I don't see the need for explicitly asking for the MIX information (only). XEP- > 0030 and XEP-0128 support returning multiple identities as well as multiple > extension forms. So a Disco Info result, without node, could look like this: > > id='ik3vs715' > to='hag66@shakespeare.example/UUID-c8y/1573' > type='result'> > >category='conference' > name='A Dark Cave' > type='mix'/> >category='conference' > name='A Dark Cave' > type='text'/> > > > > > > > > > > > > > urn:xmpp:mix:core:0 > > > Witches Coven > > > A location not far from the blasted heath where > the three witches meet > > > > > http://jabber.org/protocol/muc#roominfo > > label='Description'> > The place for all good witches! > > > > > > Note that I included the channel info from section 6.5 here. I was surprised to > find we aren't using XEP-0128 disco extensions instead of doing a pubsub items > request here. I /do/ see the value for having the pubsub node as way to get > notifications on changes, so having both would be even better. If you have to do > a Disco Info request anyway, it saves one request. > > Finally, section 12, on Registrar Considerations, doesn't mention the required > registration [1] of the identity conference/mix. Unfortunately one identity can > have at most one extension form, so reusing conference/text is probably not a > good idea. > > [1] https://xmpp.org/registrar/disco-categories.html#conference [Steve Kille] Good catch. Need to put something in registrations section.I agree that conference/text is a bad idea. Does anyone see any issues with conference/mix ? I will edit to reflect this, unless anyone suggests a preferable approach > > -- > ralphm [Steve Kille] Steve ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
