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.
Related
So, i'm relatively new to Vue, and I'm currently using it to build a small app that displays order data from Square's API.
I'm currently working on a stack that uses rails to make api calls using the square.rb gem. The frontend is entirely Vue which uses Pinia as a store, and there isnt going to be any kind of database behind this because reasons.
All data is provided directly via Square's API. I am currently polling to update order info, but my client wants to make this app truly real time, as it deals with food deliveries through ride-share companies and the purpose of this app is to show in real time statuses of orders for an in house screen at the restaurant.
Now Square has a webhook subscription service, and based on my reading it sounds like I can consume these to update my app, but there are a few logical leaps that I havent been able to make yet with how to get that data to the frontend of my app.
My questions are the following, with the intent being to connect the dots between the different technologies I might need to employ here to make this work. Kinda get a sense of what i'd need and where to link it up.
Can I use vue to consume webhook payloads directly and update through reactivity? That would be ideal, but I have found no docs yet that give me a good idea of whether thats possible.
If that is not possible, do I need to use some sort of socket connection (socket.io) to listen for these webhook updates?
If the current setup or proposed setup in the questions above is not feasible, what is a better solution for handling this while still using Vue?
I am using Twilio for the first time. It is implemented already, but I am trying to solidify the system.
My question is pretty simple. I would like to know if Twilio has integrated protections against trolls entering numbers such as 911-123-4567. I wouldn't want the company to get into troubles because someone decided to have the system make emergency calls on our name.
Otherwise, I could make an array of public numbers, for which, if the number given starts by said numbers, I throw an error.
Which one would be the best practice?
Thanks in advance!
Twilio doesn't have any automated blocks on dialling numbers. You might not want to call emergency numbers, for example, but some applications do.
You could certainly build your own blocklist for numbers you don't want your application to be able to call. Or for more security, your own allowlist.
One other option is verifying that the user owns the phone number that they are submitting, so that you know it is theirs. You could do this by implementing SMS or voice verification calls using the Twilio Verify API. It depends on your use case which of these three methods work with your use-case.
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'm using Firebase in my iOS app but I want to ensure a value is never sent from the server to the client.
Users in the app are shown to each other based on a score they have. So a user with a score of 5 will see other users who have a score of 5. I don't want to include this value in the request/response to Firebase.
Where I can manage the server I can have server side logic handle this by looking up the user on the server then calling a function that determines who has the same score and returning the relevant users without the client ever receiving the user score.
With Firebase my understanding is I'd have to send the value to Firebase in a query i.e. get all users with this user's score.
How can I do this without exposing the user's score? I want something along the lines of a node user_scores where I can query the current users score and then using this query another node users to return me the relevant users without having to nest the query on the client and thus expose the score in the request/response?
Many thanks!
Your understanding is pretty much on point, there is no way to make a "dynamic" query like this without actually exposing the varying parameter to the client.
Here are two ideas you could try to use as a workaround:
A variation of "security by obscurity": instead of exposing a single number, obfuscate that value in a way that makes guessing its purpose and other values an unpleasant experience; and share that with the client.
If you keep your users grouped by this key, not just as a flat list where this is a child node, you can use security rules to enforce that the user cannot read any other group than theirs.
(Note that this is also true for numerical values. Security rules are not filters.)
In a much more involved strategy, you could make the query static. Store and maintain a list of matching users per user, so the clients can load their own personal list without any varying parameters sans the UID.
(This is probably not really feasible if there is a lot of movement involved. But it might work in some edge cases.)
I have a ruby on rails app which essentially runs on a bunch of AJAX calls and a tonne of jquery/javascript. A particular action accepts an id(integer and serially ordered) and returns some value. The nature of the application is such that I want to allow the function to be called only when called from the browser or how a regular user would interact with the app. However, a malicious user can probably set up a bot to call the function with the id to get the return value. Is there a way to stop this?
You will not be able to differentiate between bots and real users 100% of the time. Whatever counter-measure you put in, a bot would be able to bypass if the bot creator cares enough. You need to ask yourself how important it is to you to stop bots and weigh it against the time you will take to implement and maintain your counter-measures and how much you'll be hassling your real users. Some possibilities:
Captcha - will stop most bots and irritate real users
Anti-bot question ("what's 4 plus five?") - will stop most bots and slightly irritate real users
Rails's CSRF protections - will stop some bots and not affect real users
Require users to be logged in/verified by e-mail - will stop most bots and highly irritate real users if they don't already have to have accounts