'Super admin' features via API? (List all users, bridge info, etc)

Hi,
I need to implement a way for a ‘super admin’ to search users (ALL users on a given Jitsi deployment) along with their bridge/conference IDs that they are participating in (if they are, otherwise, just the user)
I’m new to Jitsi, but after reading about all of their documentation (some topics missing? like on react features?), including external API, web SDK, etc - I could not find such functionalities.

Here are some ways I was thinking to implement that:

  1. Implement a ‘feature’ in jisti-meet. to make a call to jicofo (via prosody) to trigger a custom XMPP ‘get’ with that information.
  2. Implement a separate module/service that will query jocofo via prosody directly. (lambda->prosody) making that XMPP get call.
  3. Fork jicofo project and add the desired REST end points (jicofo has some REST end points already, but very basic…usually stats only). But in this case, we would need to maintain our own version of jicofo (good and bad). We would then use a service/client to call that REST end point for the desired info (or perhaps make that end point available via API gateway directly, provided it is safe to do so) ← AWS specific
  4. do the same as #3, but as a contributor to Jitsi …and create a PR for it…

OR, did I miss this functionality and it’s already build in??

Thanks in advance!!

Have you tried this: feat: Add a debug HTTP interface. by bgrozev · Pull Request #860 · jitsi/jicofo · GitHub
It is a new thing, you can use unstable packages to try it.

1 Like

Very interesting, thank you! That is very close to what I was looking for, and I will probably use it.

(Not a criticism, but some ideas for the future - Which I might implement?): “debug” is a good start, but that is more of a dump of values from different entities. It might be nice to have a more refined “admin” or “management” API in jicofo that allows for more specific data to be retrieved (In case I don’t need the full object(s) state, and additional features like sending a message to a user (without having to join the conference? Not sure that’s possible), ‘force’ add or move a user from a conference to another - Ok, those are features I need it at the moment lol. Anyways, I’m still very new to Jitsi, so let me get more familiar first before thinking anything ‘big’.
Thanks again for the (super) fast reply!

This is a debug interface. The feature you are looking for is a custom feature that doesn’t fit the current packages … that doesn’t work with a large-scale deployment with a dynamic number of shards, it just doesn’t scale.
For administrating participants you need info and custom modules in prosody.

The number of users, number of bridges, and all other analytics are already accessible through stats and can be pushed to any analytics platform …

1 Like

Yes, I realized it would not scale in the way I proposed. Better to aggregate the information and push to another centralized system for a holistic view, and then I can search, act on that data. Thank you for all the information and tips!

@damencho We are using the latest docker image of jicofo, and it has the debug API - It looks great, thank you for that suggestion!
One follow up clarification that you might know the answer to is this:
We join a meeting using the External API, passing userInfo (email, display name) when joining. The debug REST end point on jicofo does return the “participants”, however, I can’t seem to find a way to link the participant ID and the user… the participant id on jicofo is a hash… and the userInfo, well, it’s either email or a name. How can I correlate that data? Or is there a parameter I can pass when joining to force jicofo to take that ID as the user/participant identifier? Thank you in advance!!

Nope, that match you can do in prosody. In general, all participant-related logic should be in prosody.
You can take a look for example prosody-plugins/event_sync at main · jitsi-contrib/prosody-plugins · GitHub you can use that or extend it to include more stats to your backend.

The ids are based on the xmpp connection jids, which needs to be in the format you see it or some stuff in jvb will fail, as it depends on that format.

1 Like

Thank you for the reply, again :slight_smile:
It’s interesting to see the plugins in Prosody, and fairly easy to follow. The only issue I see (for my particular case) is that if I send the ‘events’ to an external API, yes, I can collect that data, but that is more of an event sourcing approach (on the external API/system part). That is good, until I miss events for whatever reason… then, if a muc-occupant-left/joined is missed, things get out of sync… I really wanted a way to be able to get a ‘snapshot’ of the current state (pretty much what I’m getting on Jicofo’s debug), only issue is that user mismatch thing. But this is good, it does give me some options. Again, thank you very much for your help and expertise!

The real state of participants is in prosody, jicofo is another client to the xmpp server, you can be getting snapshots from there. There are already many examples like this one jitsi-meet/mod_muc_census.lua at master · jitsi/jitsi-meet · GitHub
And here is extracting display name from an occupant: jitsi-meet/mod_speakerstats_component.lua at 9d829003b4337ce3ebdb2e584e6a2d212d119ec5 · jitsi/jitsi-meet · GitHub

2 Likes