JEP-0045 - implementing contact query

Caveat: I'm extremely new to erlang and ejabberd development but I've been developing server software since the dark ages.

I would like to implement support for querying a contact to get a list of conferences that contact is a member of per JEP-0045:

----------
A user may also query a contact regarding which rooms the contact is in. This is done by querying the contact's full JID () while specifying the well-known Service Discovery node 'http://jabber.org/protocol/muc#rooms':

Example 13. User Queries Contact for Current Rooms

<iq from='hag66@shakespeare.lit/pda'
id='rooms1'
to='wiccarocks@shakespeare.lit/laptop'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='http://jabber.org/protocol/muc#rooms'/>
</iq>
----------

So I've figured out how to work with messages sent to the conference through mod_muc but what I am stuck on is how to "hook" a message sent to a user JID so I can work on it from within mod_muc. Contrary to what I thought all messages are not routed through each module. How to get "get at" the message from within mod_muc since the message is actually sent to a contact JID?

Any pointers would be greatly appreciated.

Thanks,

Yermo

Who should answer, the server or the client?

I would like to implement support for querying a contact to get a list of conferences that contact is a member of per JEP-0045

You refer to section 6.2: Discovering Client Support for MUC. That section describes how a client can ask a contact two things: if he supports MUC, and what chatrooms has he joined. When I read it, I understand that a client asks another client, it's not the serve the one responsible to collect information and answer.

Consider this situation:

  • Elements: client1, client2, server1, server2, mucservice1, mucservice2, chatroom1, chatroom2.
  • client1 and client2 are logged on server1.
  • mucservice1 is hosted on server1, and has chatroom1
  • mucservice2 is hosted on server2, and has chatroom2
  • client2 joins chatroom1 and chatroom2
  • client1 wants to know which chatrooms is client2 joined to.

Who can answer the question (is able to answer the question correctly)?

  1. server1
  2. server2
  3. mucservice1
  4. mucservice2
  5. client2

I think that only client2 knows which chatrooms he is joined. His server could spy the packets and collect information, but reading JEP-45 I don't think that's the intention at all.

What do you think?

good point.

That's a very good point. I was thinking too narrowly and had not considered the multi-server case.

We're currently trying to work around the ad-hoc conference creation problem in the jabber protocols. Creation and Joining are the same thing. So if you're trying to join a conference but mistype the name you'll create one. For novice users (and our target audience is very novice) it can cause alot of confusion.

Even bookmarks don't do what we need. If you have a bookmark and the conference no longer exists, a new conference with be created.

We would like to separate creation and joining into separate actions and we would like to create a separate view of conferences, for a given server, that a user belongs to. Unlike bookmarks, this list would automatically be updated as conferences are destroyed.

So we need to be able to query the server for the list of conferences, on a given server, that a contact is a member of.

As I read JEP45, you can send a query to a conference for all the rooms currently defined but not for membership.

Am I missing something?

I don't have knowledge

I don't have knowledge enought to answer about advanced usages of MUC protocol :P

If nobody else gives you an answer on this forum, ask the JDEV mailing list at jabber.org, since it's more of a general Jabber question, and there you will get the attention of JEP45 authors, client and server developers...

Thanks

Thanks.

In ejabberd you can forbid

In ejabberd you can forbid room creation by users. Just look at mod_muc options in the ejabberd guide.

But indeed you're right. Room creation and joining shouldn't be done the same way.

Syndicate content