GET /v1/presence should return userData
We started using the userData property, but it's not returning on the presence request. Is this a feature request or a bug report?
Comments
-
To clarify: The daily-js lib no longer allows us to set the userId, we have to use userData now. We want to get the user ID in the presence object, but the newer API does not let us do that.
0 -
Thanks for the additional clarification 😃
I’ve shared this issue with the Daily Engineering team and they are looking into it.
We’ll send you an update on this before EOD tomorrow.
1 -
@ricardopieper we're still discussing this 🧙♂️
You'll get a follow-up answer shortly. Thanks for your patience! 🙏
0 -
Hi @ricardopieper !
The Daily API has only supported setting the
user_id
by passing in a properly signed meeting token at join time, generated using the REST API or by self-signing.If you were seeing different behavior, we can take a look. Can you share more information on how you've been setting the
user_id
field for participants? Can you also share the daily-js library version in use?1 -
@daily_joey We just use a raw HTTP POST /meeting-tokens to create the token, and we pass the user_id property. With the daily-js library (0.35.1), we just do this:
call .preAuth({ token, url: roomUrl, userName: user.firstName, userData: { id: user.id, name: user.firstName }, })
And when we request /v1/presence, the user IDs are not there.
0 -
To add to the previous comment, we are using the knock feature (enable_knocking: true on POST /rooms), therefore actually we only call the .preAuth method like this, without passing a token:
call .preAuth({ url: roomUrl, userName: user.firstName, userData: { id: user.id, name: user.firstName }, })
In this situation the user is kept in a waiting room for the call owner to approve their participation. So actually we don't use the /meeting-tokens most of the time, only if this user connects again (and is already pre-approved).
In this daily-js call, we cannot set the user id. My colleague who worked on this tells that, in previous versions, the library would actually let you set the user id, but not anymore. Why that's the case we don't know, but we expected the userData to appear in the /v1/presence call, and the fact it doesn't makes me wonder what is this useful for.
0 -
To clarify even more, we really really need to see the user ID in the presence API, to know who is online in the call in realtime. Doesn't matter if the user connected once or twice. We run some things in the backend that need to link back to the user ID in the call. We need this due to the dynamics of the call, i.e. there are actions we take when someone disconnects at specific points in time in the call. Nowadays we are doing something ugly, where the frontend updates the backend whenever necessary, but this dependency has caused us trouble.
Maybe there is another API call that I would have to do to get this information? Like, from the presence API result, can I somehow get the data I need?
0 -
Hi @ricardopieper , thank you for all of the clarification!
What
userData
was designed forThe
userData
field is currently only meant for use within a single session. At the moment the data is not stored to Daily's backend and does not persist across sessions. It is only accessible as part of theparticipants()
method, which makes it useful for sharing state information between users within a call, but less so for identifying a user from the REST API.Additionally, the 4K size limit of the
userData
field makes it less suitable for storage in our database or exposure via the REST API. It's possible this may change in the future, but it's unlikely the/presence
API will expose theuserData
field (see below). For persisting data across sessions, you'll likely want to include a separate, purpose-built database solution.Using the
/presence
APIThe
/presence
API is designed to be a lightweight endpoint to allow for monitoring all sessions across a domain via polling. For some users of Daily, this can be tens of users per session across thousands of concurrent sessions. As such, the data that is returned is limited to basic information like meeting and participant session IDs on purpose.That being said, I'll check with the team on whether the
user_id
field can be exposed when querying the/presence
endpoint. Based on its usage and functionality, I think it's reasonable for the API to be updated to return theuser_id
field, so I'll submit this as a feature request.In the meantime, you should still be able to use the
/presence
API to track when a user is in a room or not.Each user is assigned a unique
session_id
upon joining, which is returned for the local participant in the joined-meeting event or fetched manually using the participants() method. By sending this unique ID back to your own database, you can map the records returned by the/presence
API to the correct user records. If a user rejoins a session, a newsession_id
should be sent to update the ID in your database.1 -
Hi Joey,
This part I didn't really understand: "That being said, I'll check with the team on whether the
user_id
field can be exposed when querying the/presence
endpoint."This is *already* exposed. In fact, for the room owner, due to the way we use the API, we can see their user_id field in the /presence endpoint, it's filled and it's correct. However, for all other users who entered the call using the knock API, it's null. In theory, if the user disconnects and connect again, we could see their user id as well (also due to the way we use the API, because we generate the token on a reconnect).
I think you guys already thought of my exact use case, I don't think I'm talking about anything you guys haven't thought already. This is supported by the fact that this field is already exposed, there's a way to set it, just not during knocking. If there was a way to set the user ID of the user during knocking, like this:
call .preAuth({ url: roomUrl, userName: user.firstName, userId: user.id, userData: { id: user.id, name: user.firstName }, })
Then it would be perfect.
And yes, I understand that the presence API is for a single session, not across sessions.
0 -
Hi Ricardo,
Apologies for the error in my previous message! An engineer confirmed that the
user_id
field does get returned by the/presence
endpoint when it is available for a given user.You are correct that when a user attempts to join via knocking, because they don't have a token, there is no way to pass in a
user_id
since a meeting token is currently the only supported method. We'll need to discuss internally ways to resolve this.1