I've recently been playing with the new MUC-Sub module in ejabberd - the use case being I need to have WhatsApp-like permanent rooms in my mobile app. Before I go too further into using MUC/Sub, can an ejabberd expert opine on the below concepts please? Is probably a lack of full knowledge of ejabberd on my part, hence the basic questions. Or else do let me know please a good place to start understanding the below better... I did study these two links in detail already (https://blog.process-one.net/xmpp-mobile-groupchat-introducing-muc-subscription/ and https://docs.ejabberd.im/developer/proposed-extensions/muc-sub/). Thanks!
Essentially, if we need an MUC room to stop being destroyed when all users go offline, could we not simply disable that feature - so that the service continues to operate even when participants leave or the room is empty. The service could still be made to continue pointing to the original room participants who joined the room, and in case there is a message sent in the room, the message would get queue up on each participant's stream. If a participant is offline, the message would enter his / her offline messages list (instead of the archive / MAM that MUC-Sub is currently utilizing). Why did we need to rely on the Pub-Sub and MAM model if this problem could have been solved using simply retention of the participant's reference in the room (even after he / she goes offline) and then leveraging the mod_offline module (which should happen automatically).
Am sure there is a fundamental reason here that am overlooking but appreciate if someone can throw some light please!
As the blog post explains, this is not a matter about keeping chat room alive or not. The fact that users cannot receive pushes when offline or when they reconnect, if they do not join again, is because MUC is based on presence. A user that is not present in the room is not an occupant of the room and is not supposed to receive anything.
I recommend you read careful XEP-0045 MUC and MUC Sub blog post again. The issue MUC Sub solves should be more obvious.
If you do that, you will notice that XEP-0045 define the idea of persistent MUC:
Persistent Room
A room that is not destroyed if the last occupant exits; antonym: Temporary Room.
Default in ejabberd is to create the room as temporary when a user joins, but the setting of the room can be changed so that it becomes persistent. In that case, it is not destroyed when the last occupant leave. You need to change room configurations option (same form you used to enable MUC Sub on that room).
You would generally want to combine this option for the room with MUC Sub enabling, so that MUC room are kept around even if no user are present in it.
Related
I'm planning to write a group chat platform to use in crowded situations, like events, parties or shows, for example.
the simple approach would be to put everybody in the same room. but having a thousand people talking in a same room doesn't work. the multiple possible parallel conversations overlap and none can actually be understood or followed.
I'm not talking here about performance issues. I'm looking for design options. I couldn't find any discussion like this out there. if anyone have a link or a suggestion, that would be fine :)
so far, I could think about the following alternatives and corresponding downsides:
I could offer multiple rooms with limited capacity. let's say 50 people per room. each user could explicitly pick a room to join, knowing its current capacity beforehand, or could be randomly put in any non-empty and non-full room.
the problem with having multiple rooms is that someone can be in one room at each time, and so, if I want to talk to the host of the party, I must get into the room he is, or no deal. so... just picking a non-full room to join may just not be good enough.
the same happens to being randomly put in a room. that may be good to keep rooms balanced, but might cause the friend I just invited to join other random room and we get separated.
other possibility would be have a single room, a thousand people inside, but just some messages would be broadcast to everybody in the room. the problem is to choose who is allowed to talk and why would anyone join a chat group to be just an expectator :P
for example, for starters, the 50 initial users to join would be allowed to talk. as long as they live, the next ones in the queue would gaining opportunity to join the conversation.
or maybe only the most active (by some ranking) would be allowed to talk.
other hybrid alternative would be to allow users to create their own rooms and (auto-)close these rooms when they get empty, and only invited people can join their rooms.
this alternative does not solve the problem of trying to talk to the host, but gives the users the responsibility to keep their rooms conversations healthy.
a last hardcore approach would be to use machine learning to put everybody in the same room and broadcast the messages to limited people (selected by the ML algorithm), possibly grouped by interest or part in the conversation.
the problem here is that recently joined users have not enough data to be put in any cohort. actually, most chat messages are just too short and too similar to have a good ML classification applied.
so....
I'm looking for any reference, suggestion, paper, idea or anything that could help this analysis.
those are objective answers. please do not close this question as not constructive. and... in case of unavoidable closing, please tell me the correct place to ask this question (and this would also be an answer to my question, since it would help my analysis by getting me to the right forum).
thanks in advance :D
I'm attempting to build a small app with node.js, express, and socket.io, which involves handling basic social relationships. There are multiple users, you can request to be friends with them, accept these requests, reject them, and unfriend users -- basically, a lot like Facebook. If user A is logged in, and user B requests a friendship with him, I want user A to be informed immediately about the friend request. This is where websockets (and the confusion) come in.
Would each user have three different socket connections, corresponding to the three data collections? (1) Friends, (2) Received Requests, (3) Sent Requests
Upon a user accepting a received request, the other user would need to be informed that his sent request has been accepted. Would this require triggering an event on the other user's socket? What if that socket doesn't exist because the user isn't online?
Apologies if there's confusion, but I'm having difficulty understanding how to conceptualize the relationship between sockets.
All this (including the previous answer) will become a whole lot clearer to you if you read up on the "publish/subscribe pattern" ("pubsub"). The essential aspects of this pattern are:
1) You have "people" ("talkers") who each have "something to say" that might be of interest to others.
2) You have "people" ("listeners") who each "want to listen" to some other "people" (though very rarely to just anybody; most of them are choosy about whom they listen to, if only to keep from being overwhelmed).
The publish/subscribe pattern describes how to "connect" talkers with listeners in such a way that the talkers aren't burdened with having to keep track of who their listeners are, and listeners aren't burdened with having to keep track of which talkers they decided to listen to (i.e. they don't have to "hear" everybody talking and try to filter the ruckus down to what interests them).
As MagicDev pointed out, this generally involves an object whose data portion keeps track of who's listening to which talker and whose methods allow a talker to say "I'm talking about this subject" ("publish") and a listener to say "I want to be notified when (list of talkers, or "anybody") talks about a certain subject (which could possibly be "any subject").
A "friend relationship" generally means that "person" A becomes a "talker" to "person" B as a "listener" and vice-versa. However, there's nothing in the pubsub pattern that mandates this kind of symmetry; a good implementation will let you use the same methods to establish "broadcasts" and "conversations".
You would set up each socket as an object with that socket corresponding to a specific users data. if you're unfamiliar with objects and other structured data this is super important and you wont get very far without that.
You would have an object called users which would contain each users id in an array which would then hold each users information by id including arrays for friends, requests etc.
Because the data is being held on the server side, even if the socket is closed by the user on the client side the data has already been passed to a variable and saved on the server side.
Doing this entirely in node is going to take quite a bit of effort if you're unfamiliar, I would start by building the app with a mysql database first and then play around with holding the data within the app.
I've read all 484 pages of Professional XMPP and read countless forum threads regarding rosters + XMPP and this question is still something I am struggling to solve. I'm looking for insight on best practices, so I at least know which direction to go in.
I'm building a cross-platform (web, iOS & Xbox), turn-based board game. Every player can have up to 100 different matches active at any given moment -- so they could easily skip from one game where it's not there turn to one where it is.
The game will feature a lobby where your list of active games are displayed, along with the name and online status of each opponent for that game (you may have up to 3 opponents, 4 total players per game).
Additionally, each player will have a friends list accessible from a different area which also lists online status.
I am using XMPP behind the scenes, completely transparent to the players, no one will ever sign in with a Jabber client or anything of the sort. I have complete control over how the information is displayed and utilized.
The main aspects I am using XMPP to solve are: notifications when an opponent has made a move, seeing my friends online statuses, and seeing my opponents online statuses, and in-game text chat.
So here's where I start having trouble: obviously your friends list will be contacts in your roster, so you can see their online status. But what about opponents? These are usually random opponents you will only play a single match with and never again -- yet your game with them may last up to 2 weeks.
Keeping in mind that everything is behind the scenes (ex: automatic subscription confirmations, etc) -- would the best course of action be to add each opponent to another group in your roster while the game is in progress and then remove them after the game is complete? That way you get presence notifications when that player is online? Or is this a case where PubSub could be utilized?
I've also considered using multi-user chat so I'd always have access to every users online status without subscriptions, but that seems far from efficient when there could be up to 20k players online at any given moment. Definitely sounds like a battery hog on mobile devices as well.
My other solution is to used share roster lists. Create a roster list for each game and assign that list to each player. Then delete the shared roster list once the game is complete.
I would choose Pubsub here. Of course, this means that you have to do some server side work too.
Send a directed presence to the opponents. This will allow them to see your presence.
I would consider using a multi-user chat for each game, and your own extension to the MUC protocol to handle game-state messages (opponent has made a move). The user can have a roster of their friends at the "global" level, but can still communicate with their opponents (and receive presence) using the MUC level (unless they decide to then add them as a friend).
See also: Advantages of Pubsub versus MUC
I agree that using MUCS (instant) would be better in this scenario. If you need to cleanup pubsub nodes of unwanted subscribers, it will definitely be a pain in the ass.
We are trying to implement a notification module. It allows website internal users to send message to each other. A key feature is that it allows business users to send bulk messages to the users. We are talking about millions of users here.
Currently it is planned to be a publish/subscribe model. Once login, system shall retrieve the relevant messages for the user from a database table. The logic gets more and more complicated when each users are allow to delete and reply to the message he/she received.
Pubsubhub seems to be more server to server. XMPP seems to be too complicated for this scenario.
Anything I miss out? Can I make it simpler? Any existing library to build on? I'm open to any suggestions.
It sounds like a database is actually all you need here. You didn't mention any need for real-time notification. If this is a web application and the user is logging in, a simple relationship between users and messages may be all you need to provide the ability to send any message to one (or millions) of users. Your relationship table can include flags for read and deleted.
One option would be to use something like Joomla.
http://www.joomla.org/
Its open source, and they've solved all the problems you are trying to solve. Alternatively if you have to build it, what language are we talking about here?
Are you seriously saying you have millions of 'internal' employees? Sounds like you might need an email server!
Seriously though, please tell us more..
You're probably a lot to be subscribers to various mailing list, some more updated than others.
What are your best practices to follow all information going by these lists?
What are the best clients you've used to managed that?
I'm sure I'm not the only one trying to get the best signal out of this noisy way of communication :)
I like gmail because of the way it groups messages by conversation so I can just page down through a thread.
Use a rule in GMail to slap a label on and archive all of them. Then they are easily sortable, searchable, and threaded.
I just use Thunderbird. For some lists, in flat mode, for others (the Lua mailing list), in threaded mode. Following is natural for mailing list, the messages are pushed to your client.
At first, I just received the messages and routed them to the right folder with some rules.
Now, I read them as newsgroups using Gmane, which also allow to catch up history (including mails which were sent before my subscription started and those which were sent during a temporary unsubscription).
Sometime, when a thread has no interest for me, I just right click on the first message and select Mark all messages of this thread as read.
Using KDE Ia m using Kontact for my mail and RSS feeds. That gives me a nice command center.