First of all, I'd like to provide some background information: I want to exchange unstructured data between various clients using XMPP. Data sources are supposed to publish their data simply to Mulit-User-Chat rooms (XEP-0045) so that any interested client can register.
XMPP MUC services can have various chat rooms and in order to find the ones my data sources push information to, I'd like to set some custom identification for that room. I figured muc#roominfo_<custom_ident> with some custom value would be great to accomplish that.
For testing purposes I wrote an application that creates a MUC on an XMPP service. Authentication etc. all works fine. I am using Smack to communicate with the XMPP server and to create the room. When I create the room, I am adding a field to the form field I requested before containing my custom information. The MUC is created and accessible. Yet the created custom field is not returned when I perform a disco#info on the room's JID.
I tested this with a local installation of (3.8.2).
I just wonder, if this is an issue of Openfire, that custom form fields (XEP-0068 used here in XEP-0045) are not stored when the MUC is created or if it is just not allowed according to XEP-0045? I read the specification for MUCs and crucially the respective section but couldn't find any evidence that convinced me, that it is explicitly not possible to create such custom form fields for a MUC.
Maybe I just misunderstand something in the specification? Has anyone tried something similar and it's working? If it is an issue of Openfire, I could try a different XMPP server.
Related
Imagine that a database connected to an XMPP server stores users, it also stores an extra data column (let's call it dataId) for each user. The data column can take on three values: 1, 2, or 3.
In an XMPP client that logs in to the server, a list of users is displayed along with their XMPP presence status. The list displays users that all have the same value of of dataId. The client can change the dataId value that is displayed, meaning that if he switches the value, then the user is now somehow subscribed to the presence of the new list of users, but not to the old list of users.
I wonder if someone with experience with XMPP has a suggestion as to which XEPs or corresponding eJabberd (or Prosody) modules could be used or are best suited for this type of functionality.
I am slowly going through the XEPs, but there are a lot of them, and it's not clear as of yet which modules could be used, or if I would perhaps need to set up some custom code on my XMPP server to handle this.
You can take a look at XEP-0140. This behaves similar to rosters except that all users in a shared roster group will be able to see all other users in the group. You can create multiple shared roster groups and easily switch a user between them by adding or removing the user from the group. You can also have nested groups. You can look at the example on using shared roster groups for different cases here, using ejabberd.
I'm creating (yet another) mobile chat app, using Smack and ejabberd. I'm trying to ascertain the best way to implement user avatars for use in multi-user chat rooms, and also of course for roster members. Looking at possible solutions, I can see:
XEP-0008 IQ based avatars - avatars are limited to 64 by 64 pixels, too small.
XEP-0153 vCard based avatars - Easy to implement for both users in the roster and MUC rooms, however (a) sources such as this seem to indicate that one's own vcard needs to be downloaded on every login (is this strictly true? I can't see this in the specs), and (b) should be less than 96 by 96 pixels (still pretty small)
XEP-0084 User Avatar based on Personal Eventing Protocol - I'm not clear how I can retrieve avatars for all users in a multi-user chat room based on this protocol. After joining the chat room, I would need to subscribe to the metadata node of all users, and any subsequently joining users? And also unsubscribe when they leave the room? I figure this would be pretty ugly and clumsy to implement.
Can someone kindly point me in the right direction, or indicate where I may have misunderstood? Thanks.
I guess the best way to address this issue may be to store/load the images Out of band via a HTTP server. Images could be stored with a filename such as "username_imagehash.xxx". For users not in one's roster (eg strangers in a multi-user chat), we pull their avatar via a URI retrieved from their vCard PHOTO field. Each time a stranger is re/encountered, we reload their vCard, and can identify the need to redownload their photo via a change in the URI in the vCard.
Once the user is added to one's roster, we subscribe to their avatar updates via XEP-0084, publishing the same URI (see example 4. in XEP-0084).
I think this addresses all requirements, I will find out once I've implemented. I can understand that it is not done this way in standard XMPP clients as it depends on an HTTP server separate to the XMPP service (and need to handle HTTP server security - user authorization/authentication).
Feedback welcome!
Generally in messenger services, user adds or deletes contacts and let knows server about it. Server then takes necessary actions.
However, our requirement is "server decides contacts list, makes roster changes accordingly and clients receives updates about the same". How can we achieve this in Tigase?
There is a dedicated API in the Tigase just for that. It is called a DynamicRoster. Maybe the name is the most accurate. Dynamic because it is managed by the server and it can change any time user requests the roster.
Anyway, there are code examples in the Tigase main code repository. You can have multiple dynamic rosters active at the same time and they can retrieve contacts from different locations.
There is also a roster protocol extension which allows you to keep extra information for the contacts in the dynamic roster such as phone numbers, etc... More info about this o the Tigase.org website in the devel guide section.
Hope this helps.
I wonder if there is a way to query the XMPP server (passing user JID?) to find out what chat room(s) this user is currently in? If not, can we query jabber server to get a list of all active chat rooms?
BTW we're running ejabber enabled for multiuser chat. A solution using a java library (smack?) would be ideal.
As mentioned by Joe Hildebrand, there is no such a standard feature as it is a privacy violation to allow that over XMPP, so you cannot expect to do that from Smack. Maybe with admin privilege you could have a custom protocol extension that does that but that seems risky.
However, at the server level, you should be able to write a custom module for ejabberd that will query or index all rooms users are in. This is not standard and there is plugin development involved.
There are two (maybe three) XMPP entities that have that information:
the XMPP MUC component which provides the MUC room
the users XMPP client (or better the XMPP library used by the user)
maybe the XMPP server(s) (but let's ignore that)
At the time of writing this, there is no standardized way (in terms of XMPP XEPs) to query that information. As Joe Hildebrand pointed out, this would result in a information leak which is not what we want in most cases.
But you can either extend the MUC component to provide that information (remember XMPP is easily extendable) or the XMPP client library. The usual approach would be via an iq get query. For example:
<iq type='get' from='juliet#capulet.lit/balcony' to='capulet.lit' id='q1'>
<query xmlns='http://jabber.org/protocol/muc#joinedrooms'/>
</iq>
The entities which support that query would then report back the joined rooms of the requested entity. Also they would may announce the http://jabber.org/protocol/muc#joinedrooms feature in their service discovery information.
Note that this is a fictional protocol extension meant as example. I have never seen it in real use
If the MUC component provides this feature then it's not controllable by the client if this information is exposed. But if the client provides this feature then of course he can control who can retrieve this information. You may decide what's the better approach in your case.
Getting all chat rooms is no problem, just use this query.
There seems to be already a question on how to retrieve rooms with smack. Look here.
I have got an Openfire Jabber server with in excess of 75,000 users listed. Of those, 150 or more can be online at any one time.
Is there anywhere that I can collect the JIDs (usernames) of the currently logged in users? I have full database access to the underlying data, but the server does not appear to write the current status back to the DB. Because of the number of users, rosters are not being used.
A very useful set of data being returned would be from a simple (password protected) webpage with one JID per line, optionally with the login time, and maybe also the last time that account performed an action [like send a message]. The latter two are not as essential, but would be useful if the data is available, as well as any other information that was available regarding the user session.
dont know if this will help but I ran into it looking for similar functionality. As defined in XEP-0045 http://xmpp.org/extensions/xep-0045.html#disco-roominfo :
An implementation MAY return a list of existing occupants if that information is publicly
available, or return no list at all if this information is kept private. Implementations
and deployments are advised to turn off such information sharing by default.
So you would need to ensure it works as advertised on Openfire (all xmpp servers ive come across have a bug or two in them), and I imagine you would need to code some logic to get the results.
Good luck.
Not a perfect answer, but the query you want is probably embedded in the session-summary.jsp page. I got to it on a locally hosted server at http://localhost:9090/session-summary.jsp. What I don't know is if that is then stored in the database where it is query-able, or if it is stored internally to the client. The latter is more likely.
The data that page displays is Name, Resource, Status, Presence, Priority, Client IP, and Close Connection.