Hi,

even it's a bit more complicated in the context of MAM and MIX because you are storing conversations which could belongs to users who are not in the system anymore. I mean, if you created a bot, for example, that's an account with specific features, and it's registered to a MIX channel and sent to you some messages (directly and via that channel), if the bot removes its account, you can retrieve the conversations but when you try to obtain information about what was that exactly, you only can figure out that was an user (account) and that's all.

Maybe something like a general record for JIDs, only to store information like features and kind of account (identities) could be a good idea in this case to keep the information about what is/was that JID.

Kind regards.
Manuel Rubio.

El 2018-09-20 09:43, Ralph Meijer escribió:
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:

<iq from='coven@mix.shakespeare.example'
    id='ik3vs715'
    to='hag66@shakespeare.example/UUID-c8y/1573'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='conference'
        name='A Dark Cave'
        type='mix'/>
    <identity
        category='conference'
        name='A Dark Cave'
        type='text'/>
    <feature var='urn:xmpp:mix:core:0'/>
    <feature var='urn:xmpp:mam:2'/>
    <feature var='http://jabber.org/protocol/muc'/>
    <feature var='http://jabber.org/protocol/muc#stable_id'/>
    <feature var='muc_passwordprotected'/>
    <feature var='muc_hidden'/>
    <feature var='muc_temporary'/>
    <feature var='muc_open'/>
    <feature var='muc_unmoderated'/>
    <feature var='muc_nonanonymous'/>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:mix:core:0</value>
      </field>
      <field var='Name'>
        <value>Witches Coven</value>
      </field>
      <field var='Description'>
        <value>A location not far from the blasted heath where
               the three witches meet</value>
      </field>
    </x>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>http://jabber.org/protocol/muc#roominfo</value>
      </field>
      <field var='muc#roominfo_description'
             label='Description'>
        <value>The place for all good witches!</value>
      </field>
    </x>
  </query>
</iq>

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
_______________________________________________

Reply via email to