When User A and User B, both are online and one of them changes the avatar, all the rosters of the User receive a presence stanza with vcard-temp update element with the sha1 hash of the image used as avatar.
<presence from='juliet#capulet.com/balcony'>
<x xmlns='vcard-temp:x:update'>
<photo>sha1-hash-of-image</photo>
</x>
</presence>
However, no such notification/stanza is generated for the users which are offline at that time, So such a client shows no change in the avatar displayed.
How can an offline user can get v-card updates from rosters, when there is any change? I don't wish to ask for vCard for all the rosters, even if there is no change.
I think a client that support the protocol should include the avatar in all presence packet, not just on change. As explained in XEP-0153: vCard-Based Avatars:
If a client supports the protocol defined herein, it MUST include the
update child element in every presence broadcast it sends and SHOULD
also include the update child in directed presence stanzas (e.g.,
directed presence sent when joining Multi-User Chat (XEP-0045) [5]
rooms).
It means offline users will get the correct presence and can update the avatar when they are both online.
Related
Whats is XAMP stanza for get specific(single or multiple) roster presence instead of all ?
I'm using Strophe.js for XAMPP(openfire) communication. As per Openfire didn't provide support for message status(read, received and read) at server side so, I have implemented some extra logic for make it work.
I'm retrieving my rosters by ajax call through querying Openfire db one self and returning rosters, also roster search functionality here. Problem is when I search and get roster through API so I can't get presence of roster. I want presence only for search result rosters instead all users through Strophe.js(XAMP stanza).
I found a partial solution, it's only working when the roster is online. we can take default user status offline and we can update online presence response.
<presence to="JID" type="probe" xmlns="jabber:client"/>
We're implementing an xmpp client and we are using ejabberd as xmpp server.
We've implemented muc (multi user chat) functionalities to our app and everything is working fine , only thing we are having problem is a member to leave the group permanently.
I know in XEP 45 says if you want to leave the group just send the unavailable presence to room but this doesnt work in our case because our admins add users of the group to memberList
by sending the below xml:
<iq from='crone1#shakespeare.lit/desktop'
id='member1'
to='coven#chat.shakespeare.lit'
type='set'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='member'
jid='hag66#shakespeare.lit'
nick='thirdwitch'/>
</query>
</iq>
And when a member send unavailable presence, this doesnt affect the groups member list(Which is working as we wanted)
So we want to find a way for a member to remove himself/herself from group members list permanently so he/she wont be able to receive any messages from that group anymore
Is something like that possible? Can we remove ourself from groups member's list like whatsapp's leave chat functionality.
When user leaves room he will not receive messages anymore - XMPP MUCs are presence-based. "Member lists" are only for administrative purposes and does not control message receiving.
There are some another XMPP extension specifications designed with "persistent" member list in mind, for example MUC Light - it can be more suited for you needs.
As defined in XEP-0045, if the MUC admin added another user as member, that added user cannot remove himself as member.
However, as a default in XEP-0045, MUC members do not receive message. This brings me to think this is not the problem you are hitting.
I suggest that you use MUC/Sub as implemented in ejabberd and defined in this specification for more flexibility. It is 100% compliant with MUC specification, so MUC compliant client and MUC/Sub enhanced client can participate in the same workflow.
In your case, I think that you need to subscribe your users to the events he wants (message, possibly presence or configuration changes). Subscription can be handled by users so that user can also control unsubscribe. It should do exactly what you want.
You need ejabberd 16.09 to use that specification. MUC/Sub is defined here: https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/
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!
We have a site and we developed a chat system for it using strophe.js library and ejabberd XMPP server. We use session attachment that was initiated with PHP (using an in-house library). What we do is get the RID and SID from the PHP script, then use strophe's session attachment. The said RID and SID is stored on a cookie and the RID value on the cookie is updated every update of the RID on strophe.js.
This works fine, after logging in we receive the presence status of each of our contacts. The problem with this is, when you go to another page on the site, and attach using the said RID (we use the incremented value produced by strophe) and SID, the server wouldn't send presence information of your contacts anymore as opposed to when you logged in. This caused our contacts area to appear all invisible even though they are online. They would only appear online if you (or your contact) log out on the chat, then log in again (since you will receive a presence update from the XMPP server).
I have written a workaround where the presence status of your contacts is saved on a cookie (all online contacts will have their JIDs saved on the cookie) when a presence is received from the server. This is checked every page load, if the cookie is set, it will be read, and all JIDs on the cookie will be marked as online. This is working fine but there might be some better ways to solve this, using XMPP's default behaviors.
XMPP servers send presence probes to all your contacts on your behalf when you send your own initial presence to the server. From then on, you will only receive presence status changes from your contacts.
If you lose the presence state of your contacts, you will need to send your own presence probes to re-establish that state. However, this is probably not something you want to do a lot, and passing around the presence state is probably preferred in most cases.
You could try passing the state via XMPP. For example, you could use Private XML Storage (XEP-0049), Pubsub (XEP-0060), or PEP (XEP-0163).
Another option instead of cookies for passing it client side is to use an HTML5 SharedWorker object to hold the state.
I shudder to think of the scale properties associated with storing all of the presence you just received from the server back to the server in private storage. Private storage almost always is backed to long-term storage rather than stored in memory, so you're going to grind your server's disk to dust.
If you want to store more state in the browser, and insulate yourself from browser version, and you're already using jQuery, then jStore is pretty sweet.
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