Is it possible to set different UUID for each channel that you've joined?
e.g. The user simultaneously joined different channels.
pubnub.subscribe({
channel: [mainChannel, broadcastChannel, controllerChannel]
});
NOTE THAT I've assigned the UUID on PUBNUB.INIT()
The reason why I've wanted to do this is because:
On user login my app assigns a static UUID for the account. But different user account has different UUID (eg. user1-channel2, user2-channel2).
The app allows multiple users to use the same account. So basically all of them have the same UUID and this is okay for "mainChannel" & "broadcastChannel" but not for "controllerChannel" as they should have unique UUID for the channel so I can identify different users not different accounts.
Is this possible? If it is not, then is there an alternative solution for my problem?
Try using state! http://www.pubnub.com/docs/javascript/api/reference.html#state
State is still bound to a single uuid, but you can create an object that encapsulates arbitrary info around it. For example, in your case, you should create an object like:
{"mainChannel":"foo", "userChannel":"bar", "controlChannel":"baz"}
Shoot us an email at support#pubnub.com if this does not work for you, we can discuss alternatives still.
geremy
Related
I building chat application with pubnub,
I have setup everything both backend and frontend,
but in front-end, it requires another argument for UUID. Can anyone tell me where can i get the UUID? how to generate it with pubnub? Do i need to store the UUID in my datbase?
const pubnub = new PubNub({
publishKey: 'myPublishKey',
subscribeKey: 'mySubscribeKey',
uuid: 'myUniqueUUID'
});
Pubnub docs it seems worst, i have not found any information regarding generating UUID, Can anyone tell me how can i resolve it?
PubNub UUID Management Best Practices
The UUID should be something that, as the acronym implies, uniquely identifies the user (or device, server instance, etc.). The UUID can be whatever you see fit to accomplish this in your applications but there are some guidelines you should follow with respect to PubNub.
This is well-documented in the PubNub Platform Documentation, so I am not going to repeat all of that here. Please review Users & Devices: Identity Management docs, under the Connections section, for the full story.
TL;DR
Generate a UUID for the user when they register as a new user and store it in their user profile record in your system (or use PubNub Objects: UUIDMetadata).
Upon successful registration/login of a user, pass the following back to the user (the client PubNub application):
subscribe key
publish key (only need if client can send messages)
uuid (there are UUID generator APIs in PN SDKs - you can make your own but you should avoid using any PII as the UUID).
auth key (this has to do with PubNub Access Manager and not related to this post, but should be implemented for production applications)
use the above to init your PubNub object
each user/client/device should use the same UUID everytime the PubNub object is created
each server instance should have its own UUID. This can simply be a server instance name or identifier
Why are UUIDs Important in PubNub?
Again, it's all detailed in the same docs page under the UUID Impact section, but here's the highlights:
For billing purposes - it is used to calculate MAUs (Monthly Active Users)
For Presence service to work properly - uuid value is used to generate join event when a user subscribes to a channel and for all presence events and APIs.
For easy troubleshooting - if you ever have to contact PN Support, it makes it a lot easier to identify a user across multiple subscribes and other API calls if we can single out a UUID.
Have a Realtime Day!!! ;)
This is in ruby:
Pubnub::UUID.generate
I have a dialogflow bot that helps a user order an item from a menu. I would like to spawn multiple instances of the bot, because when two people talk to the bot they are talking to the same instance, and the bot takes both of their inputs into account. What is the correct way of making separate instances for each user?
You can use different session Ids for different users.
Detect Intent Request with the session Id
This is generally a coding problem on your side - usually meaning you're using global variables instead of storing information that needs to be maintained over the session in Context parameters.
I am currently developing a strategy for Dialogflow on https://passportjs.org.
From what I've learnt, Dialogflow doesn't authenticate users. So I'm thinking about making a strategy (for passportjs) that identify users from every plateform differently (analyse the originalRequest differently for each plateform).
For example, the Telegram originalRequest has this field:
originalRequest.data.message.from.id
The Telegram says this field is a:
"Unique identifier for this user or bot"
So I think it is safe to use it for authentication and identify every intent of my users fulfilled by my webhook.
I was wondering about the actions-on-google authentication and I found the field originalRequest.data.user.userId.
The documentation says:
"Users can reset this identifier, so don't store important user data keyed off this identifier, because once it's reset, that information is no longer accessible by the user."
So the only reason to not trust the userId is because it can be reset? At the end of the documentation it says:
User ID lifetime - User IDs are reset automatically after 30 days of inactivity or if users unlink their accounts on the device.
And:
"If a registered user's voice isn't recognized by the device or no registered voice exists, then a different ID is used that is unique for just that conversation."
How to differentiate users from one other? Can some IDs be recycled?
The best way to differentiate users from each other is to use the userId field, as you've determined. On the AoG platform, the userId is meant to be used somewhat like a web cookie can be used - if you see it again, you are assured that this is the same user that used it last time. But if you see a new one, you have to assume that you've never seen this user before, even if it means they deleted the cookie.
To be clear - most of the time, the UserId will remain the same and you can expect returning users to have the same ID. This won't be true in only three cases:
They have reset the ID for this Action. So they have deliberately chosen to start over.
They didn't use the Action for 30 days, in which case it makes sense to treat them as a brand new user anyway in most cases.
They were not recognized as a normal user of this device, so they are treated anonymously. (This is the equivalent of the clunky "Do not remember me on this machine" setting you see on websites, which forces a session cookie rather than a persistent cookie.)
The phrasing is poor in the documentation - I think it is meant to remind developers that the user is ultimately in charge of their privacy. And Google both forces you to do the same and adopt policies that do so.
IDs will not be recycled. In fact, they won't even be re-used between different Actions, even for the same Assistant account.
Summary: If you see the same UserId, you can trust it is the same user you saw before. If you see a new one, assume they are a new user.
If you want a more robust way to identify users, you might consider using Account Linking which puts you in control of the identifying token. But that has significant additional overhead.
Be careful when using other authentication methods - Google limits how you're allowed to use them as part of an Action, and expressly forbids them in some cases. See the General Policies for details.
I noticed that as part of the device discovery exchange, device-desc.xml file contains a UDN value.
Can I use this as a unique id for that chromecast device?
You should be able to use the UDN as a unique identifier for a particular Chromecast.
UDN typically means "unique device name" and the format looks like a UUID which was made so that you can uniquely identify things.
As for your other question about how to collect metrics, it depends on what you want to collect and why.
If, for example, you wanted to figure out what the social usage of your app was (assuming that you had some multi-participant logic) you could track usage by device and see if certain devices are hubs of social activity and see usage patterns. This might help you figure out what sorts of features you need and help you determine if you have repeat users or if you have repeat locations meaning that you may want to persist state in different places.
However, I would suppose that the most value can be gained by attaching behaviors to users. It may be better to track application sessions and attach data to a session which would indicate how users interacted with your app and with each other. You can define a "session" in multiple ways. It could be the duration of a user's "joining" of a receiver app or the life of the receiver app itself. Probably a bit of both would be best.
In my app which allows users to sync the core data content across their multiple devices, how unique should I make the NSPersistentStoreUbiquitousContentNameKey?
I.e. should it be unique in the sense of having the device ID? So if a user is running an app on their iPhone it has one NSPersistentStoreUbiquitousContentNameKey and if they're running it on their iPad is has another NSPersistentStoreUbiquitousContentNameKey?
Or does it have just be unique from app to app? I.e. if I have App A, it has one NSPersistentStoreUbiquitousContentNameKey and App B has another NSPersistentStoreUbiquitousContentNameKey?
It's purpose is to uniquely identify the persistent store within a users account. So if an app will only ever have a single persistent store (like a todo list might) then every installation of that app can share the same value for this key, but if you want to have multiple persistent stores then each one will need a unique key value here. Does this help?
From apple docs:
The content name is used to identify the store across different
devices so that transactions are synced consistently with the
potentially many instances of that persistent store file across all
the devices. For this reason, you must make sure you provide a unique
name for each store—for example, a UUID.
https://developer.apple.com/library/IOs/releasenotes/DataManagement/RN-iCloudCoreData/