I'm working on this chat type scenario and the need is to track presence -
Note: every client in this scenario will subscribe with option withPresence set to true.
Pubnub cofig-
Max announce is set to 1, so i rely on interval event type.
phoneA will ask server for a channel name, Server will generate a unique channel name (lets say ch-chat) and return to PhoneA.
Now both phoneA and server will add the channel to their own channel groups (cg-phoneA and cg-server)and subscribe to their own channel groups.
PhoneA shares the channel name with phoneB and phoneC and they both add the channel to their own channel groups, cg-phoneB and cg-phoneC. Bkth B and C are also subscribed to their own channel group.
Now,
When phoneA removes channel (ch-chat) from its own channel group (cg-phoneA), server does not gets phobeA in leave uuids list of interval event. But after ~5mins server gets timeout event for phoneA.
What i want -
phoneA should present in the leave list of the interval event since phoneA removed the channel from its own channel group, theres no way it should be subscribed anymore to it.
Presence Modes: Announce vs Interval
One issue is that your Announce Max setting of 1 will mute all presence events except for state-change. In other words, you are in Interval mode all the time for every channel. Read more about Presence Event Modes here.
When channels are added to a channel group, you should receive the join event (if in Announce mode and not Interval), if you are subscribed to the channel group withPresence: true. Be sure you want to receive presence events for all channels in that channel group though. You can create a second channel group for channels you do not need to receive presence events.
Managing Channel Groups
As for managing Channels in your Channel Groups, be sure that only your Server is the one adding/removing channels for all channel groups. This has to do with security when you enable Access Manager (and everyone should be enabled/implementing Access Manager to protect your keys and your users).
Presence Webhooks
As for Presence Webhooks, this is the best way for your Server to monitor presence events. It is not recommended that you subscribe from your server. It will be difficult/complex to scale to multiple server instances. This is why the Presence Webhooks exist. And your clients and POST directly to the Server for any requests it needs, like your "generate new channel" request. And your server and reply to those posts and then publish all further updates to the channel the client is subscribed to.
Channel Naming Conventions
It is great that you are using "generated channel names" (like a UUID pattern) but prefix your channels to identity them to provide a means to group them with pattern match through regex. I would recommend using a "dot" so that you can also potentially take advantage of PubNub wildcarding features:
PubNub Functions channel binding
Presence ACLs (custom presence channel behavior configuration)
Access Manager wildcard granting
Wildcard Subscribe
For example:
chat.4849-ut83-83jd...
notify.tuy7-87er-27fn...
NOTE: Channel Groups do not allow "dots" in the name and do not have any wildcarding features.
Related
We have an enterprise installation of QuickBlox (which implements XMPP), and would like to create mirrored accounts for all of our users on our QuickBlox server install. We also want to sync the networks our system's users have created using relationships (eg, "client and provider") that have been built on our system.
In a nutshell, we want to export whitelists that limit chat "opponents" to only those users with whom each of our users already have relationships. If User1 has an existing relationship in our system with User2 and User3 but not User4 through User40, we want to be able to use the QuickBlox API to enforce that within chat by creating a whitelist through the QuickBlox API.
EDIT: We can't use an "honor system" whitelist. That is, the enforcement must be server-side using a method the client cannot circumvent. There must be a hard, unavoidable block between users for privacy concerns.
Use case:
A QuickBlox (or XMPP) server has User1 through User40, inclusive.
User1's whitelist is comprised of [User2, User3] only.
If User1 attempts to contact User15, we want QuickBlox/XMPP to note that User15 is not on User1's whitelist and block that communication as if User1 had bidirectionally blocked that user.
Privacy lists, aka blacklists
I have found places in QB's docs that refer to the XMPP specification docs, and have found the concept of privacy lists, which seem to operate as blacklists:
https://quickblox.com/developers/Web_XMPP_Chat_Sample#Privacy_lists
https://xmpp.org/extensions/xep-0016.html#protocol-syntax
These only provide two styles of blacklist privacy:
You can choose a type of blocked logic (Privacy List). There are 2
types:
Block in one way. You are blocked, but you can write to
blocked user.
Block in two ways. You are blocked and you also can't
write to blocked user.
Server Whitelist (dialog-level, not user)
I've also found documentation on whitelists for servers, which appear to operate at a dialog/jid, not user, level:
https://xmpp.org/extensions/xep-0133.html#edit-whitelist
An entity added to a whitelist MAY be a JID of any form as specified in RFC 6120... a whitelist may prevent inbound communications, outbound communications, or both...
Rosters -- "presence" detail only?
There are also rosters, which are close to whitelists, but they do not seem in my testing to restrict communication between any two users that might not be on each other's roster.
https://quickblox.com/developers/Web_XMPP_Chat_Sample#Get_the_roster
That is to say, I haven't set up a roster in my testing application, and users are able to create group and 1-on-1 chat dialogs in spite of not having explicitly accepted any roster requests. In the Android docs, I found the following on rosters: "[A roster] is the collection of users a person receives presence updates for." That's not blocking in any way outside of presence alerts, I don't believe.
Question
Is there a suggested way to create a pessimistic whitelist for each user, which only contain those users with whom communication is allowed? Or are we forced to create and maintain "inverse blacklists", where we automate the creation of privacy lists for every new user blocking every other user and then use the API to remove those with which each user should be able to communicate?
If we do have to use "inverse blacklists", is there a way to have a default blacklist apply to every new user that initially blocks communication with every other user already in our QuickBlox system?
(Again, we can't use "honor system" lists. If the client must request a whitelist to be active before it can be used, can freely discover and then change active whitelists, or if the client can decline to use a list, that's not secure enough.)
XMPP Clients
XMPP clients will need a way to ask another clients if they support receiving pushes via a relay. Since pushes can be sent from anywhere, clients will also be able to send pushes directly to other clients through the relay as long as they have their friend’s whitelist token. They will also need to respond to XMPP server inquiries for whitelist tokens to allow pushes to be sent by the server if a message is sent by a client not supporting direct push.
XMPP Servers
XMPP servers can ask their connected clients if they support push relays and, if so, forward messages they receive to the push relay server when the client is offline. This will require the XMPP server to obtain a whitelist token from the user as well.
Help:see this link
If we are talking about XMPP protocol - there is an ability to block any communications from/to (see example 48)
So, by default, you can set it for each user for example.
Then, if we need to allow to communicate with someone specific,
then you can add this user to your privacy list with action=allow and order greater than 'full block'. Here is actually a good example of whitelist implementation via Privacy Lists, see example 8:
and (3) 'special', which allows communications only with three
specific entities.
This is my scenario:
I dial into a VoIP call using SIP (e.g., 11234567890#10.0.100.200)
As the first caller, I get placed on hold
Another user dials into that same conference
The conference call starts
Does SIP or RTP provide for a way for me to view the other participants (their name or number) on the call?
Yes, if your UAC and your conference provider supports RFC 4575: A Session Initiation Protocol (SIP) Event Package for Conference State
In that case you would be able to establish a subscription (SUBSCRIBE) with the conference event package and (subject to appropriate permissions, authorizations, etc. at the discretion of the conference provider) you will get NOTIFYed about conference events. What events to notify is at the discretion of the conference provider (note the language in the RFC, no MUSTs, some SHOULDs and MAYs):
3.6. Notifier Generation of NOTIFY Requests
Notifications SHOULD be generated for the conference state when a new
participant joins (i.e., gets "connected" to) or a participant leaves
(i.e., gets "disconnected" from) the conference.
Subject to a local focus policy, additional changes in participants'
status, changes in their media types, and other optional information
MAY be reported by the focus.
Changes in sidebar rosters SHOULD be reported by the focus to their
participants and MAY be reported to others, subject to local policy.
Changes in conference identifiers and service URIs SHOULD be reported
by the focus to the conference package subscribers.
Changes in other conference state information MAY be reported by the
focus to the conference package subscribers.
You can probably expect it from IMS CONF service according to 3GPP TS 24.605 and 3GPP TS 24.147
You can also use RestComm to simplify this, it provides a demo on conferencing out of the box. (Dial 3010 or 3011). RestComm use SIP and RTP for the initial conference setup but then you can query the conference via REST for managing participants (mute/unmute, add/remove from conference, ...)
When building a social application it's common to follow other users or topics as an indication of interest in updates by the user or topic. For example, following other users on Twitter, Friending other people on Facebook or liking a product or brand on Facebook.
Pusher has the concept of channels that you subscribe to. Channels are a human readable string that provide a logical identifier to information (e.g. "some-channel-name") and therefore seems to naturally suggest that in a social application any updates on a user or topic should be sent on a channel specific to that item (e.g. "userX-status-updates" or "myBrand-status-updates").
However, this raises concerns about how efficient it is to subscribe to multiple channels if a user is following a high number of other users or topic.
Therefore, what are the appropriate strategies for structuring channels in an social status update style application that uses Pusher?
The first thing to clarify is that you need a mapping of who you are following so for the purposes of this answer I'm going to assume that it's stored in a DB on the server. It also assumed that status updates are triggered as follows:
Client (userX posts status update) -> Your Server (sanitize & validate)
Your Server -> Pusher
Pusher -> Clients (users interested in updates from UserX)
There are two possible solutions to the channel information architecture problem:
Channel Per User Status: A user subscribes to a userX-status-updates channel for all the users that they follow and users trigger update events on their own status update channel.
Users I'm Following Channel: When a user posts a status update you look up who is following that user and publish the update on a users-you-follow-updates channel.
Strategy 1. is the most optimal solution as it keeps interactions with your own infrastructure an Pusher to a minimum.
Here's the detail on these two strategies:
1. Channel Per User Status
The assumption here is that subscribing to channels is costly but that not entirely correct. Channels are simply a way of routing events. However, if you are using authenticated channels (private & presence) you need to authenticate the subscription via your own server. If you use the Pusher WebSocket libraries "out of the box" each subscription will result in a request to your server. So, a user is following 1,000 users that's 1,000 requests to your server.
But, for the pusher-js library there is a multi-auth plugin that can batch the authentication requests into a single call.
There is also a BatchAuthorizer for the Pusher WebSocket Java library, but it's only a sample solution to this scenario.
2. Users I'm Following Channel
Note: although this is an option it's probably only appropriate for smaller numbers of users
In this scenario a user sends their status update to the server, the server performs a lookup of which users are interested in the update and triggers and update even on a channel for each interested user.
For example, give users UserA, UserB and UserC each of those users will subscribe to their own update channel; UserA-followers-updates, UserB-followers-updates, and UserC-followers-updates respectively. If each of these users follows UserZ then when UserZ makes as status update that update is published on each of those channels.
This may also sound inefficient, however it is possible to trigger the same event on 10 channels at a time. So in the above example it would only require one call to the Pusher HTTP API to send the status update to all interested users. More information on multi-channel event publishing here.
First from this question :
Asmack/openfire How do I keep a user permanently in groupchat room
I read that I cannot use MUC to keep the user persistent in the group, they'll automatically leave the group and can rejoin after they come online again, that concept is like IRC like what've been asked in here -> http://community.igniterealtime.org/thread/48020.
Then from the stackoverflow question I read about using pubsub, then I've done some research about pubsub and what I've got is pubsub can persist the user to be in the group even the user is offline but the message flow is more like one directional from the publisher to the subscriber (read-only).
So if I want to create a group chat application can I use pubsub and set all the member to become both publisher and subscriber? or is there any alternative solution?or my understanding of the pubsub and MUC is incorrect?
my goal is to create some group chat like in the whatsapp or blackberry messenger group.
Thanks.
You can make users permanent in Group chat in MUC by changing the following code of openfire.
File : src/java/org/jivesoftware/openfire/muc/spi/LocalMUCUser.java
change line 547-550:
// TODO Consider that different nodes can be creating and processing this presence at the same time (when
remote node went down)
removeRole(group);
role.getChatRoom().leaveRoom(role);
TO:
// TODO Consider that different nodes can be creating and processing this presence at the same time (when
remote node went down)
// TODO Dont remove user from group when they go offline.
//removeRole(group);
//role.getChatRoom().leaveRoom(role);
Setup:
I have setup a pubsub service wherein the publishers publish geolocation data at regular intervals.
The subscribers receive the location data of the publishers.
The subscribers are not presence subscribed, in the sense, the subscribers are not in the publishers rosters.
Problem:
The subscribers need to know the presence status of publishers.
Is there a way for the subscribers to know the presence status of publishers?
No, since there is no direct relationship between subscribers and publishers, which is typical of any pubsub design. To accomplish this the subscribers would need to know who the publishers are, which is not a good generic pubsub design.
It sounds like what you actually want is PEP (Personal Eventing Protocol), which is a subset of pubsub. In this case, the subscribers are subscribing to nodes belonging to the actual user they are interested in. If they are subscribed to the users presence, they automatically have access to the users nodes.
NOTE: I have recently found out that the newer version of the spec does in fact support an attribute that identifies the publisher. Thus making it feasible to get their presence, but you would still have to subscribe or query for it.