XMPP roster status, custom roster and messaging between unknown users

Question

I am quite new to XMPP and recently decided to try to make an IM on mobile platform. Regarding XMPP I have several problems which I seems unable to find answer after recent's readings (I am thinking of using ejabberd or Tigase as server, so the following questions will be assuming the server side is one of them):

1. I've read that in XMPP, adding another user into roster is done by a client sending a roster set request to the server, then the server will add a roster item with subscription state of 'from' and 'to' to the requesting client and the client being added respectively. In other to have the roster item's subscription value to become 'both', the user being added need to accept the request sent. Is this correct?

2. In my understanding, one user identify and add another user by JID in XMPP, which if I put this into WhatsApp's case, it is the user's phone number. Is this correct?

3. Is it possible to make server customise client's roster? For example, the server would process all client using the IM, and return a roster based on some logic, e.g. people they might know each other, instead of only user's added contacts? To clarify this more clearly, it is like Facebook's people you might know. So in this case, each time a client log in and request roster, the server will return a list of people the user might find they would like to talk to.

4. From the understanding before, is it possible that a user A can see if another user B is online or not, given that A sent a request to add B, but B has not yet accepted? How about sending any message to B before B accepted the request?

Thanks for any help!

Answer 1

I've read that in XMPP, adding another user into roster is done by a client sending a roster set request to the server, then the server will add a roster item with subscription state of 'from' and 'to' to the requesting client and the client being added respectively. In other to have the roster item's subscription value to become 'both', the user being added need to accept the request sent. Is this correct?

There are two bits. One is adding to the roster, the other is getting a presence subscription. Presence subscriptions are established by sending presence subscription requests (and in doing so the contact will be automatically added to the roster). Roster sets, on the other hand, manipulate your roster but don't cause presence subscriptions.

In my understanding, one user identify and add another user by JID in XMPP, which if I put this into WhatsApp's case, it is the user's phone number. Is this correct?

For the XMPP case, yes, addressing is done with JIDs. I have no idea how Whatsapp's addressing works.

Is it possible to make server customise client's roster? For example, the server would process all client using the IM, and return a roster based on some logic, e.g. people they might know each other, instead of only user's added contacts? To clarify this more clearly, it is like Facebook's people you might know. So in this case, each time a client log in and request roster, the server will return a list of people the user might find they would like to talk to.

It would be possible with server customisation in a closed environment. It wouldn't work on the public network because presence subscriptions are two-way and you'd end up with a roster of people you can't see when they're online. On the other hand, you can easily set up a user search service that would return suggestions, and the client could add them at will.

From the understanding before, is it possible that a user A can see if another user B is online or not, given that A sent a request to add B, but B has not yet accepted? How about sending any message to B before B accepted the request?

A can only see if B is online once B has accepted A's presence subscription. In standard XMPP you don't need presence subscriptions to send messages (although some deployments might change this, e.g. Google's does).

For an overview of these types of questions, I'd suggest reading XMPP The Definitive Guide (O'Reilly) (Disclaimer, I'm one of the authors), or the relevant RFCs (6120, 6121, 6122) and the XEP series (naturally, I think the book is more accessible).