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?

1
1 votes

Active · Last Updated

«1

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.

  • Tasha
    Tasha Community Manager, Dailynista admin

    Hi @ricardopieper

    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.

  • Tasha
    Tasha Community Manager, Dailynista admin

    @ricardopieper we're still discussing this 🧙‍♂️

    You'll get a follow-up answer shortly. Thanks for your patience! 🙏

  • daily_joey
    daily_joey Dailynista

    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?

  • @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.

  • ricardopieper
    ricardopieper Member
    edited January 23

    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.

  • ricardopieper
    ricardopieper Member
    edited January 23

    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?

  • daily_joey
    daily_joey Dailynista

    Hi @ricardopieper , thank you for all of the clarification!

    What userData was designed for

    The 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 the participants() 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 the userData field (see below). For persisting data across sessions, you'll likely want to include a separate, purpose-built database solution.

    Using the /presence API

    The /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 the user_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 new session_id should be sent to update the ID in your database.

  • ricardopieper
    ricardopieper Member
    edited January 23

    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.

  • daily_joey
    daily_joey Dailynista

    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.