I am new to eJabberd, I am facing the following problem.
There are two users (A and B).
User A sent 10 messages to user B but user B is offline or not in network so he (user B) didn't get messages sent by user A.
so this is the major problem I am facing, please help me how do i resolve this issue.
Thanks,
Chetan
You must enable mod_offline in the configuration to get XEP-0160. The ejabberd documentation covers this.
Minimally:
modules:
mod_offline: {}
Related
I have been struggling to configure a group chat using conversejs and ejabberd. From the documentation I've stumbled across, it seems like it is possible to have a persistent group chat that users can be subscribed to, which will allow them to receive messages from the group chat while not present in the group chat.
For example: I would like to be able to simply close the group chat on my conversejs client, but still get notifications from that group chat.
This is a fresh ejabberd 21.04 and conversejs 7.0.6 install (using websockets).
What I tried to do was create a room through the conversejs client, and then add a subscription through the ejabberd cli:
ejabberdctl subscribe_room user#my.example.com/muc user test_room#conference.my.example.com urn:xmpp:mucsub:nodes:messages
One of the things I'm most confused by is the field in the configuration panel of a group chat that is titled "XMPP URI of Associated Publish-Subscribe Node." I have no clue how to format this, but have found a few clues online... What I have tried is a number of different configurations of something like:
xmpp:my.example.com?;node=messages
but I'm really just grasping at straws here.
If anyone can help me figure out what I'm doing wrong with this URI, or can show me a working example of this, that would be amazing. If what I'm trying to do simply isn't possible with XMPP, please let me know as well.
Thanks!
it is possible to have a persistent group chat that users can be subscribed to, which will allow them to receive messages from the group chat while not present in the group chat.
Exactly.
ejabberdctl create_room room1 conf.localhost localhost
ejabberdctl change_room_option room1 conf.localhost persistent true
ejabberdctl change_room_option room1 conf.localhost allow_subscription true
ejabberdctl subscribe_room user1#localhost User1 room1#conf.localhost urn:xmpp:mucsub:nodes:messages
Now I'll use the send_message API call to send a message to the room. This requires the sender to be online, so for this example register and login to admin#localhost. And of course, login to user1#localhost to receive the notification from the room. Those clients do not need to join the room.
ejabberdctl send_message groupchat admin#localhost room1#conf.localhost Sub Body
We are building a chat app using latest ejabberd and there is a use case where user A blocks user B. the requirement is to hide last seen or user's presence from each other. if A blocks B then its easy to hide these information from user A but how can user B be informed that user A has blocked them ? whats the best approach to tell user B the someone has blocked them on realtime while both are in a conversation , like whatsapp does now.
For presence, you do not have to use block, you can simply remove contacts from roster. That way, the other user is notified and can also stop sharing his presence.
There is XEP-0191: Simple Communications Blocking:
https://xmpp.org/extensions/xep-0191.html
https://xmpp.org/extensions/attic/xep-0191-0.2.html
I think it will give you the answers you need. Now it depends how will you implement this functionality using chosen client library like Smack.
I am developing a xmpp client and currently working on "pubsub".
I created a node in pubsub and subscribed two users to it.
But when a subscriber login(show presence) i get the last published item twice.
I am using ejabberd server.
Can anyone help??
Thank you.
Same here,
There seems to be two different queues. With notification_type=normal, messages are stored offline. When receiver becomes online, it receives the message twice:
from offline spool, without headline attribute
from pubsub send loop (as node is still configured with send_last_published_item = on_sub_and_presence)
As stated here when configuring pubsub node with notification_type=normal, it's best to disable send_last_published_item or set it to on_sub only in order to avoid receiving the message twice.
Currently im trouble shooting some code that I wrote to create a chat room. I will include the code if necessary but for now I just wanted to hear some possibilities for the problem im having. So basically I have client1 that is listening to a channel and then when clien2 sends a message to the server the message is then sent from the server to all available users. What is happening is that client 2 will send the message and it will be displayed on his browser but client 1 will not receive the message until he refreshes the page or types in a message of his own. So I would think that user presence is being detected fine since the message eventually gets sent to all available users but im not sure? Thoughts?
The Google App Engine blog has a nice case study that talks about how to do this.
They store a list of channel ID's in memcache and send update messages to each of them. They mention that race conditions make memcache not ideal, but it worked well enough for their demo.
I made this question over at the Openfire groups, but it seems to be pretty quiet out there. Maybe someone here at SO works with Xiff/Openfire and has a clue about this:
We are using an external database for users and groups, on Openfire 3.6.4 through Xiff 3.0 beta with our own client.
When a user is added on our database, the roster doesn't get updated. I am logged in as "User1". "User2" is added to the database to the same shared group, so I should see him in my roster. User2 can login and see User1 on his roster, but User1's roster hasn't been updated. Even after log out, User2 still doesn't show up on User1's roster.
Apparently the group is being cached or something. Where should I be looking at for a fix to this problem? Xiff? OpenFire? I found about the property "cache.name.maxLifetime" in the docs, but I'm not sure if this is the property I should be using to get groups to update the members.
In case anybody gets here looking for an answer to this question, you can follow it here:
Groups not updated on Roster from Database using custom DB
There's a partial solution over there at the Ignite Realtime forums.
A better approach would be to use roster protocol (see RFC 3921, section 7) to modify the roster, perhaps by writing a component for OpenFire. This will modify the caches in transit, as well as sending notifications to clients that are currently logged in for the user. As well, you won't have issues with your changes getting overwritten.