I am developing an ios app like Tinder. Users can chat only in private 1:1.
Should I have to open one channel for every single "match"? Is this the correct design pattern for this case study? What about performance if i have one channel per "match".
*Match" is when a user matches to another and can start a private chat.
If one person can have multiple matches, you can ask PubNub client to open separate channel for each nothing person. So, when you have two matching persons, you take some unique identifiers from both of them and using known algorithm create unique name of the channel for which both clients will subscribe to communicate.
One channel for whole application - really bad idea, because of possible massive flow of data, which for most of subscribers will be useless, because consumer is one of other subscribers.
Yes, the best approach is that every "match" should have it's own channel on which both participants publish/subscribe to communicate. PubNub has no limit on channels (nor does it charge based on channels), so this shouldn't create a performance or cost issue.
To add access control to the "match" channel (if you want to ensure no one else can access that channel), use PubNub Access Manager, documented here: http://www.pubnub.com/docs/javascript/tutorial/access-manager.html (use dropdown to change programming language)
If you want to provide chat history, so that the two participants can see messages from previous chat sessions, enable PubNub Storage & Playback, and use the PubNub.History() API, documented here: http://www.pubnub.com/docs/javascript/overview/storage-playback.html
If you want to see when those two participants are connected to the Match channel, use PubNub Presence, documented in the same place.
Related
I work in a large enterprise where multiple teams are developing Lex bots (on separate accounts). Each bot supports a different domain or application,. In some cases, it would be nice for a single user interface to ask a question without needing to know which bot to ask. Is there a way to federate bots, or to forward un-recognized intentions to 'backup' bots?
I feel like what I really want to do is treat each bot as a skill is treated in Alexa, except I'm in the position (through entitlements) to know which 'skills' would be appropriate for a given user.
The answer here is that you would need to develop a custom application that delivers a user's input to each of your company's array of bots.
You'd need to look at the NLU Confidence score from each Bot's response to decide which response is the most accurate to return to the user. Would also be worthwhile keeping some state in your app to remember which Bot the user is currently interacting with and defaulting to that Bot for successive user inputs. Should you reach a point where the confidence score is low, it might present a signal to you to test the user's input across the other Bots.
What you'll need to be aware of here is that your costs will increase with each additional Bot that you add. So, assuming you have 5 area-specific Bots, one inbound message from your user could result in 5 Lex calls. As you start moving into significant volumes of interactions, this could start proving to be an obstacle.
An alternative would be to use a custom fallback intent to invoke a Lambda function that calls your Bot orchestration function. Assuming that you're able to find the correct Bot to handle the user's query, you'd need to remember that so succesive messages now get routed to that Bot.
On a ride booking app, it is required communication between driver and user.
Now the case, if user A contacts the driver via website or app, call or sms can be achieved via Twilio, we don't want to expose their contact numbers to each other.
If three users A, B and C contacts the driver and driver has no app installed, in fact the driver wants call back and sms reply. How the driver can reach users on Caller ID.
There could be large number of users and we can't buy separate twilio number for each user.
Please advise the solution.
How many users are likely to need to contact each individual driver at any one time? Not many I wouldn't think.
Buy 10 Twilio numbers, assign them incrementally as users call/SMS their driver and save the assignment for user/driver numbers in your database.
If the driver calls/SMS a number in response query the database and route the call/SMS to the user it was assigned to when they called the driver.
Recycle the 1st assignment once the 11th user calls/SMS the driver, rinse and repeat.
Twilio developer evangelist here.
In order to maintain anonymous communications in this way you need as many numbers as the maximum number of relationships one person in your system has. The best explanation of this is in this article on masked text messaging with Twilio (though it applies to calls too).
Your comment on miknik's answer suggests you want to keep these relationships alive forever. This is not the way that most services build out this feature. They normally give a particular length to the relationship, Uber for example will recycle the phone number a number of minutes after a ride ends.
If you are looking for an easier way to manage this kind of number pooling and masking, check out Twilio Proxy, it handles a lot of the logic for you. It is still in developer preview right now, but you can apply for early access.
I am currently using Rails to prepare backed for reacting and react-native applications. The token is used for authentication.
I've got two features in my application, which require WebSockets:
Chat system(one chat open at a time)
Notification system
I see two ways to implement WebSockets:
Two separate channels
First channel: NotificationChannel to which I subscribe when client opens application and then I broadcast sth if it is required
Second channel: ChatChannel to which I subscribe when I open a chat, the code would look as follows:
class ChatChannel < ApplicationCable::Channel
def subscribed
authorize_chat_room_id(params[:chat_room_id]) #
stream_from "chat_channel_#{params[:chat_room_id]}"
end
# here methods for receiving data from client
# maybe some other methods for tracking if sb is typing and so on
# private authorize_chat_room_id method
end
In this scenario user is subscribed maximally to 2 channels and authorization is performed only once when subscribing to chat.
In this approach, I authorize only once the user, when he subscribes to channel, however, I don't know how having 2 channels opened instead of 1, affects performance on the server.
One channel
The single channel would be called: PersonalChannel, and would take care of all information flow, the code would look sth like this:
def subscribed
stream_from "personal_channel_#{current_user.id}"
end
def send_message(data)
if authorize_chat_room_id(data['chat_room_id'])
#create message
end
end
def start_typing(data)
if authorize_chat_room_id(data['chat_room_id'])
# some broadcast
end
end
And when I would broadcast, then I would send in the payload for example type(ex. 'MESSAGE_SEND'), and based on that, react client would print the message if chat would be open.
The advantage of this approach is that when sending the message I can broadcast only to one user and I won't get back message from the channel. But in this case, I have to authorize each time performed an action.
My question is which solution would be better in case of performance and what is generally accepted approach(to make Channels very general or to make each Channel take care of single task)?
On this issue, I would suggest that you consider prioritizing code maintenance concerns over performance.
The concept of channels allows us to decouple publishers from consumers. This simplifies a lot of code and helps with separation of concerns.
For example, a user posting in a chat room wouldn't need to know (nor manage) how many people are subscribed to that chat room, nor who they might be. These concerns are now handled by the pub/sub system rather than the user.
This separation of concerns makes adding or removing chat members much easier (you don't need to updated every user, you only need to update the pub/sub system).
This separation also prevents multiple copies of the data from being stored (the pub/sub system holds the only valid copy).
In the long run, by consolidating all the data into a single PersonalChannel, you'll be reintroducing the coupling between publishers and consumers - this will increase complexity and make maintenance mode difficult over time.
In the chatroom example, each user will need to grab a copy of all the room's members and send each message to all users. This increases the number of copies (of the member's list) as well as introduces synchronization concerns.
The advantage of this approach is that when sending the message I can broadcast only to one user and I won't get back message from the channel. But in this case, I have to authorize each time performed an action.
This advantage is actually something you can easily achieve using the first approach by subscribing each user to a personal channel as well as the other channels, subscribing to three channels instead of two.
I can create a muc room. But if i gave the room name as existing one in the database, the server rejects it.So is it possible to create two rooms with same name in ejabberd server(MYSQl backend)?
If possible, then what are the consequences? For example, i created two rooms with unique name say "newGroupChat" and same user list(user1, user2). How can ejabberd identifies it? If i send messages in "newGroupChat", does those messages appear in one room or both of the rooms.
Its hard to specifically no what you are trying to achieve, but I came across this in another XMPP server setup( Its pretty much generic with few config differences on different servers), and the idea I got is like this:
If you use different systems( different IP) it is possible to have the same room across multiple domains, hence you can mirror the rooms but the room name has to be the same thing, for example "newGroupChat#conference.serverIP1" , and one the second system "newGroupChat#conference.serverIP2", and when you send messages on System 1, system 2 users can also see the same messages if they are online and logged into the room.
If it's the same system I don't know how you intend to set a boundary on it, there are two ways to do this I figured out, using different OS(maybe bridged networking) and also separating databases. If you use an embedded database there is no way you can re-create the same room, you might try adding extensions to the name to see if it would work as such : "newGroupChat#conference.serverIP1/ID1" and "newGroupChat#conference.serverIP1/ID2", the above also applies to an external database such as SQL. These are a few suggestions and muc setup might have slight config setup in contrast to the examples I gave, but that's a general idea, if you have better explanations you can also share with me, as I am looking into LAN chatting on different systems with the same muc room.
In Xmpp world, room#service is used as an identifier for a room, so here the room is unique. That's why use failed to create when using a existing name.
I think you can try use subject configure for this purpose.
Xmpp MUC Xep-0045
Room, A virtual space that users figuratively enter in order to participate in real-time, text-based conferencing with other users.
Room ID, The localpart of a Room JID, which might be opaque and thus lack meaning for human users (see under Business Rules for syntax); contrast with Room Name.
Room JID, The address of a room.
Room Name, A user-friendly, natural-language name for a room, configured by the room owner and presented in Service Discovery queries; contrast with Room ID.
I can create a muc room. But if i gave the room name as existing one
in the database, the server rejects it.So is it possible to create two
rooms with same name in ejabberd server(MYSQl backend)?
No.It is not possible to create two room with same name in a host in ejabberd(as per XEP-45,too).
So I got a task to prepare a simple analysis on how useful, from sociometrical point of view, are Slack API methods (https://api.slack.com/methods).
Yesterday I didn't even know that such thing as sociometry exists, and i still dont know how to evaluate any API using its methodology. Does anyone here ever got a similar task, or have any idea how to approach such analysis? What literature will be useful? I don't mean this analysis to be particularly long, but as for now I don't even know where to start.
Frankly, I am not an expert on sociometry , but here is how I would approach it:
I would assume the goal is to create a sociogramm depicting the relationships between all users on a Slack team using the API methods. So the question is how useful the API methods are to achieve that goal.
Slack does not have a "friends list", like Facebook, so you have to come up with your own approach on how to identify relationships on Slack. Slack is a messaging system, so it makes sense to define it based on who is communicating with whom.
Lets define users to have a relationships if they are
direct messaging each other (including groups)
talking to each other in a channel (using the #user
mention)
or just being part of the same channel and talking in the channel
Now to assess the effectiveness of the API methods. The basic approach would be to retrieve the messages of a public channel with channels.history (or im.history for direct messages, groups.history for for private channel and mpim.history for direct messaging channels with multiple participants) for a given time period. In addition you can retrieve the members of a channel with channels.info (or their pendants for the other channel types). Then you would parse all retrieved messages and the member list of a channel to identify the relationship and calculate the sociagram.
However, Slack will only allow users to access channels, that they are members of. That includes access through the API and that includes users with the role admin and owner.
So its not possible to see all direct messages, groups chats and private channel of a Slack team through the API and we would therefore need to limit the approach to public channels and some private channel. Depending on where most of the conversation is happening on a specific Slack team and which private channels our slack user is a member of this could significantly limit the ability to calculate a complete sociogram.
In summary you can use the API methods to calculate a sociogram for your Slack team based on which users users are communicating with each other. But that analysis will not be 100% complete, since its not possible to access all private communication on a Slack team though the API. The calculated sociogram might still be useful though, if the Slack user doing the calculation has access to all relevant private channels.