Send arbitrary data for each participant

Good morning Community.

Which would be a recommended/suggested way to:

  1. Send extra data for each participant. I know that we can set some predefined data (displayName, avatarUrl, email, etc) by hash/url/jwt parameter. We would like to send extra arbitrary data (some info that only makes sense for our system which is intended to be used for some menu/options validations, or displaying some labels in the thumbnails like “company’s role”). This should be shared through prosody in order to know about the properties of the other participants. I don’t know if we can put extra information in JWT that is not defined in the docs.

  2. Send extra data for conference. We actually can set “conferenceSubject” and a “conferenceId” parameters, but we want to attach extra information like “conferenceDurationLimit”, or “participantsLimit”. This information also should be stored in prosody’s memory.

For both mechanisms, I know that we should modify web, desktop, android & ios frontend code in jitsi-meet repository. Probably lib-jitsi-meet should be modified and I don’t know If an extra module for prosody must also be written (I know that we can send extra participant info in the entity).

I would appreciate any hints about this. Thanks.

You can add as many data as you want into JWT but you need to write some codes to process these values.

Check this post

1 Like

Thank you @emrah, this extra information will be only available for local participant right? If we would like to share this information with other participants, I guess we should send this info in the “presence entity” to the MUC in prosody.

Regards

It’s available for the user web session and for prosody.

1 Like

@alan_tulais Another option for the participant-specific data is by using JitsiParticipant.setProperty and JitsiParticipant.getProperty methods in lib-jitsi-meet. If you are interested on being notified when a property changes, you can listen to JitsiConferenceEvents.PARTICIPANT_PROPERTY_CHANGED events.

Regarding data at a conference level that is persisted, so far the only place I found for that is by setting / subscribing to conferenceSubject. What I did is to JSON.stringify an object with the data I need, storing it in the conference subject (with this then you cannot show directly the conference subject as in jitsi-meet). I would really like to have other places to store/retrieve data in the same way, without having to use only the conference subject.

There is the JitsiConference.sendCommand method that adds information to the presence, and you can do JitsiConference.addCommandListener to listen to changes. But I have had issues with this approach because older commands are still received later and that produces order of operations problems, having to deal with old updates that need to be discarded.

1 Like

There is send command once method.

1 Like

@damencho That is a good one. However the challenge I found with sendCommandOnce is that the data is received once for the existing participants, and participants that join after cannot read that information. That is why I ended up using conferenceSubject as a persistent placeholder for custom conference data.

Thank you very much for your time.

So let me see if I understand:

  • We can put all extra information in the JWT payload as we wish

  • We can retrieve all information contained in that payload from React. For this I have two questions:

    1. We can access decoded payload directly from React? Or it is received/decoded from prosody after validation
    2. Which is the recommended way to send JWT to React frontend? I’ve tried to send it as a query parameter (https://mydomain.com/myConference?jwt=xxxxx) but if the user reloads the page it is lost.
  • We have to use “sendCommand” method in order to send extra information about the participant in the muc presence entity.

  • The remote participant should be able to retrieve that information by using the “getProperty” method on a participant instance.

  • There’s no available method to send extra information about the conference itself. sendCommandOnce will only work to send information to currently active participants. A workaround is to use an encoded ConferenceSubject.

    1. If we would like to use another property, I guest we have to write or modify existing lua modules and patch lib-jitsi-meet. In addition of that, we have to develop the mechanisc to pass those values in every client (android, ios, electron, web) to Reac/React Native. Is that correct?

Thank you very much for your attention.

Regards.

You’re welcome. You have very good questions. Here are the answers as far as I know (I am not a Jitsi developer so I might be wrong).

  1. Yes, I understand you can expand the JSON object with the information you need.

  2. (1) I guess you are looking into this https://github.com/jitsi/jitsi-meet/blob/master/react/features/base/jwt/middleware.js#L131 where the token is decoded. I use lib-jitsi-meet and not the full jitsi-meet so I am not completely sure for your case. I would use jwt-decode library (https://github.com/auth0/jwt-decode#readme) in my custom app like in that code reference, calling jwt_decode method if you install version 3. Regarding (2) I think you could add custom code to store the jwt in local storage and then retrieve it when the page is reloaded. Another option is to retrieve the token from an issuer application you maintain, by doing an API request. Specially if you have an authentication mechanism in a separate application.

  3. I understand that sendCommand allows not only that but also to send data at a conference level. But yes it is also used to send information about a specific participant (I just realized that by looking into JitsiConference.setLocalParticipantProperty code).

  4. If you call setLocalParticipantProperty in the JitsiConference instance in Participant A, then in Participant B you can call getProperty on participant A’s object in order to get that information (I just tested that and it worked for me).

  5. That’s how I understand it. Only that adding another persistent property is beyond my expertise, so I am not sure which would be the steps needed.

1 Like

Thank you very much for your response again, @johnny256!
I appreciate your time to reply.

We were expecting to send extra participant’s data in this method:

But after seeing your reply, we have to send participant with its basic information and then we will update it by calling _overwriteLocalParticipant method in the JWT middleware that you exposed. I truly believe that storing meeting params sent by query r hash params should be stored in localStorage for future usage (when reloading page for example) so we will be working on that.

About conference-specific attributes, we are going to evaluate the cost of allowing new custom attributes. As far as I know it is not going to be very easy because we have to follow rules XEP-0045 rules:

So for this behavior we can use the conferenceSubject encoding method you suggested. We will use this mechanism in order to set a custom participant limit for each conference, so prosody must be aware.

Thank you very much again!
Regards.

1 Like