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.
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!
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.
I'm learning XMPP and I repeatedly see the word "Roster" but I have no idea what it is.
contact list (in XMPP this is called a "roster")
Source: XMPP-IM - RFC 6121 ยง 1.3: Requirements
In XMPP, one's contact list is called a roster, which consists of any number of specific roster items, each roster item being identified by a unique JID (usually of the form contact#domain). A user's roster is stored by the user's server on the user's behalf so that the user may access roster information from any resource.
Note: There are important interactions between rosters and subscriptions; these are defined under Integration of Roster Items and Presence Subscriptions, and the reader must refer to that section for a complete understanding of roster management.
See http://xmpp.org/rfcs/rfc6121.html#intro-requirements
Let me know if anybody have any queries regarding xmpp/chat app in Android.
Roster is the name given to the list of contacts which appears in one's chat client
http://www.adarshr.com/fun-with-xmpp-and-google-talk-part-2
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.