What are the best practices for sending system message/s to group/ user, while using XMPP protocol? All the users at at the group should receive the message.
How can I achieve it?
Possible solutions that might be useful:
The announce - I have encountered with the announce and more
specifically this module.
Publish-Subscribe http://www.xmpp.org/extensions/xep-0060.html
There is always the
option of creating an admin user that will send messages.
Thanks in advance.
The best approach depends on your constrain and especially if you control the client. For example, if you use a client you did not develop, it may not render the pubsub messages fine.
The second thing to consider if how are the group defined. Are users registering for alerts ? In that case in seems to match the pubsub case. Otherwise, if groups are not too large, you may use an admin user to send to the list of user you want. You can even send a single message to multiple users using XEP-0033: Extended Stanza Addressing (Sometimes called "multicast").
mod_announce can only target all users or all online users, so it does not seem to match your need in terms of "groups".
I explained most of the option in a talk (video and slides): https://blog.process-one.net/implementing-state-of-the-art-one-to-many-chat-services-with-ejabberd-ejabberd-workshop-1/
It is broader as it not only cover broadcast but also groupchat, but it should help clarifying your choice.
Related
From the spec —
7.14 Exiting a Room
In order to exit a multi-user chat room, an occupant sends a presence
stanza of type "unavailable" to the <room#service/nick> it is
currently using in the room.
Example 80. Occupant Exits a Room
<presence
from='hag66#shakespeare.lit/pda'
to='coven#chat.shakespeare.lit/thirdwitch'
type='unavailable'/>
This implies that as soon as the user disconnects from the XMPP server, he is removed from the group on the server side. The issue is simple — I don't want this behavior; I want a behavior that is similar to what Whatsapp does, i.e. even if the user goes offline, he is still part of the MUC room (which is configured to be persistent on the server side) and will receive messages from other occupants.
Given the spec and the documentation for XEP-0045 and XMPPFramework for iOS, I have no idea how to accomplish this or if it's possible to accomplish this in the traditional ejabberd server.
XEP-45 was designed more then 10 years ago. Back then, the designers had something like IRC channels in mind. Everything of XEP-45 is designed based on the assumption that a user enters and leaves a room when he/she starts/terminates its client.
WhatsApp Groupchats are different: A user joins a groupchat is is able to view the (complete) history of that chat. Even if the users client is offline/unavailable, he is still considered part of the groupchat.
The XMPP community currently works on a new XEP that provides such functionality. It is called XEP-0369: Mediated Information eXchange. It is the spiritual successor of XEP-0045, providing the features one would expect from modern groupchats.
You could emulate something quite like this by using server-side history of the MUC (Message Archive Management, XEP-0313), so that when a client logs in they're able to request the history of the MUC while they weren't in it.
If you also want to be able to show the offline pseudo-occupants of a room, the easiest way to do this is probably to map a pubsub node per room to store the list of these pseudo-occupants that clients could read to supplement the usual occupancy list.
There are probably other solutions here, but those that come immediately to mind for me involve changing the behaviour of the server in non-standard ways, such as allowing normal occupants to query a membership list, which normally only admins can do.
The Whatsapp model is much simpler than you imagine - they just maintain user session online even if user disconnects, and re-sends messages when he "reattach" session. XEP-0198 introduce similar concept to traditional XMPP sessions. You only need to configure longer inactivity period (typically XEP-0198 assume 300 seconds, but whatsapp-like messengers holds session 24+ hours)
Yes you can make your group persistent by setting its configurations this way:
NSString *var = [field attributeStringValueForName:#"var"];
if ([var isEqualToString:#"muc#roomconfig_persistentroom"])
{
[field removeChildAtIndex:0];
[field addChild:[NSXMLElement elementWithName:#"value" stringValue:#"1"]];
}
Using OpenFire 3.71, I have a couple of different conference services, each has a couple of chat rooms in it.
Now I want to broadcast messages to all the MUC ROOMS within one of the services and not as "private messages" to the individual users in those rooms/services. (It should more or less look like as if I entered every single room, sent a message, and left...)
Is that possible in some way? Is there a plugin already? Or is at least possible to write such an plugin? I'm not really sure how the MUC's work...If somebody knows a good source for that, that would be nice to read too...
Thanks,
Jens
I figured out a workaround, in case anybody needs something similar:
I implemented the clients now in the way that they will automatically join a default (per service) muc in addition to the room they join manually. In this default room, only the "owner" can send messages and once the client receives a message in this chat it is displayed within the room that s/he is "actually" in...
As usual for "workarounds" it's surely not the best solution, but it works for my purpose...
If you know of a better solution please let me know.
I'm using XMPP to drive a notification system. Basically I will have a set of services, some of which will broadcast to all users and some which are directed to a specific client (full JID).
For a service that broadcasts to all users a PubSub node seems the obvious choice but for a service that targets its messages to a specific client, I'm unsure of the best mechanism to use.
Do I represent these services as other client users and create bespoke implementations for them? The problem I see with this is how will they be discovered? Do I group them into a chat room and discover that. It feels like a bit of a hack. I could also define my own bespoke type of service, but then I have to define my own XML tags and maintain that.
I know there are plenty of standard extensions to XMPP but I cant see anything useful in this case.
Even in the pubsub case, the publisher (i.e. your service) is still a "user", so this configuration will be pretty standard. We simply create service accounts to represent those "users".
I am unsure of what you mean by "how will they be discovered". Why do the services need to be discovered? Your scenario only gives the use case of services sending messages to the users. Assuming the service already knows who the message is to be sent to, then you don't need any other information to send a message.
I'd like to use XMPP as the message bus for a desktop application. As the application would use the users existing XMPP account (GTalk or the like) and doesn't provide IM service I would like to make instances of my client invisible to other XMPP clients.
To do this I'm considering using client service discovery and privacy lists to block outgoing presence notifications to the full JIDs of clients other my own. I do however doubt the scalability and robustness of this approach. Is there a better way of accomplishing this?
EDIT:
I'm now thinking the closest I can get to this behaviour is to set a presence of away with a negative priority. This will hopefully minimise user confusion and work fairly universally.
XEP-0126 doesn't have the tools you need, since there's no way you'll find out about the other clients to which you have to direct presence... because they're invisible.
How about if all of your clients join a MUC room?
I am not sure if pubsub or multiuserchat is the way to go?
What I think I need is pubsub, but with the added ability for subscribers to broadcast messages to the feed as well. Bidirectional information flow, if you will.
The use case is such that subscribers will be subscribed to on average 1000 different feeds, but each individual feed only broadcasts information on average once per week. So, lots of feeds, but low activity in each one. However, b/c there are 1000 different active subscriptions, a subscriber might still be notified of 100 messages per day, and they should be able to "reply" aka post content to any one of those feeds.
It seems like what I need is a pubsub/multiuserchat hybrid. But that doesn't exist, or does it? Any ideas or pointers?
Thanks a bunch!
If a subscriber is publishing data then they are not just a subscriber, they are a publisher. And there is no reason the same entity can't be a publisher and a subscriber at the same time.
As for your more general question about pubsub vs. MUC, that's a question that I find comes up a lot nowadays.
Obviously at first glance MUC and pubsub are very similar, they are both about broadcasting to a group. Many applications could easily use one or the other with no trouble.
To help decide which fits best with your applications, let's go through some of the differences between the two protocols.
MUC:
Is absolutely good for standard chatrooms of online users communicating with each other. If this is what you're doing, use it.
Includes presence, i.e. notifying other occupants about joining, leaving and changing status.
Allows for anonymous private communication between occupants.
Works out of the box with practically any standard XMPP client (for standard chat messages).
Automatic leaving of the room when the user goes offline or disconnects.
Messages with custom payloads are supported, meaning you are limited to routing standard chat messages.
Pubsub:
One or a few publishers transmitting to many read-only subscribers is core pubsub territory. In contrast to MUC the subscribers are not publishing, and are not receiving information about other subscribers.
Server implementations tend to have much more flexible access control for pubsub.
Custom payloads only, no standard chat messages.
Optionally has full item persistence.
A node can be managed as a list of items (ie. add/remove with notification) rather than just simple broadcast.
Subscriptions can persist through being offline.
The points above are just a guide. A lot can typically be achieved through server configuration. As an example, the MUC specification allows for rooms withholding presence broadcasts for certain classes of occupants based on configuration. The catch here is in the implementations... since this is an uncommon usage of MUC, you will find it may not be supported in many MUC implementations. The point being that as MUC was designed for chatting and not generic pubsub, you will largely find all the implementations and tooling around MUC to focus on that kind usage.
Not sure what the problem is. The subscriber simply needs to be a publisher as well. There is nothing stopping them from publishing as well as subscribing (unless the nodes are configured to disallow it).
This appears to be a very typical pubsub case.