Add ability to check for existence of a user


There are a couple of additional API methods I could use in the Identity Service:

  1. identityService.exists(username)
  2. A way to subscribe for a user who may not yet exist but will receive an event when created


In regards to #1, I think this is a good feature request. We will add it to our next release. For now it seems like:

const exists = (identityService.user(username) !== undefined)

Would be a good workaround, although there is currently a bug we are working on where getting a non-existent user causes an exception.

Can you expand a little more on the use case for #2? The identity service doesn’t currently have any subscription mechanism now.


Per #1, sounds good, thanks.

Per #2, we are building in-app screen-sharing. There is a screen where a presenter waits for potential presentees to connect, and uses the presenceService.subscribe(username) method. In some cases, though, the user corresponding to username may exist in the app but not yet in Convergence. So when the user eventually gets created (via a JWT) the presenter has to refresh the page to be notified of the presentee’s presence.


To me this sounds like a use case for an Activity, not the Presence subsystem. If you used an activity, you would be notified when the user joins the activity. The added benefit, is you don’t care if the user exists in convergence or not when you set up the activity, you are just looking for session_joined events and can look for a session joining for the user you care about.


Interesting. I can see that working. Currently, when the presenter starts a screenshare session we create a new Activity with a random GUID as its ID, which represents the collaborative session ID. This ID is then attached to the presenter’s presence state which the presentee can access when joining the session. So we are currently only using Activities to represent an active collaboration session.

Semantically, it makes sense to use Presence in the original use case. Basically, the presenter knows about a few users with whom she might like to start a collaboration session, and waits for their presence in Convergence. Simply connecting to the same domain as a presentee would indicate their availability for collaboration, which seems like what Presence was defined for. The alternative (as you suggested) would be to define some sort of generic activity id="screen-sharing" or something, which everybody would immediately join to after connecting to a domain. This action would represent the “I’m ready to be presented to” state. I think that would work also, and perhaps even allow for additional later collaborative use cases.


This is an interesting use case. Another few thoughts / questions here.

First when a presentee logs in, how do they know they are invited to a session. Simply placing the random GUID in the presenters Presence state does not seem sufficient. How would the presentee know that there is a presenter out there who has invited them to a collaboration session. Do they need to loop over all users in the system? I assume not. I assume there is some other mechanism for inviting? If so, could you not simply include the activity id in that mechanism? This would be opposed to having a global “screen-sharing” activity.

Are we most concerned with the list of users who exist in the system that could be invited to a collaboration regardless of if they are online or not? If so, does the rest of the system have a user store that you could use? Alternatively, cloud you simply create a user in convergence whenever a user is created in the system of record?

Does the presenter actually care if the user is “Online” or not? If I understand the use case, the presenter creates a screen share and invites use A, B and C. Those users may or may not be online at this point. If user C connects to the domain, but does not actually join the screen share, is this knowledge actually useful to the presenter? I assume what the presenter is waiting for is for the user to actually join the screen share activity so that they know that the user is online AND actually in the screen share.

Last point, the Presence state is global in the system for the user. Thus, if the same user logged in to two different web browsers (different tabs, different machines, etc.) and started a screen share on each session, it seems like the special attribute in the Presence system indicating an activity id would conflict.


Yes, good questions. I actually changed the session discovery aspect to leverage an Activity rather than Presence, as you suggested. At this point this is all working, but could potentially be improved:

Some clarifications for the app:

  • Screenshare sessions are 1:1 only.
  • Presenters have a list of presentees they are interested in, and vice versa. This comes from the system of record.
  • A presenter and presentee will be on a phone call for the entire setup + screenshare process.
  • Does the presenter actually care if the user is “Online” or not? Probably not, in fact it might be preferable to be able to start a new session even if the presentee is not logged in to the app at all. Most meeting apps work this way. The below workflow would need to be tweaked slightly to accommodate this.

Here is the workflow:

  • When a presenter or presentee navigate to the share-screen-setup page, they join the “screen-sharing” activity.
  • For a presenter on this page, we set up a subscription to listen for JOIN and LEFT events. This is used to populate an onlineParticipants list that is a subset of the backend-provided potentialParticipants list.
  • When a presenter clicks the “Start screenshare” button next to an onlineParticipant, we set to attributes in the presenter’s presence state: DESIRED_PRESENTEE (a username) and SESSION_ID (a guid). We also create a new activity with id = SESSION_ID which represents the actual 1:1 screensharing session, and listen for JOIN events. If someone joins, we remove the two presence state values for the presenter.
  • For a presentee on this page, we iterate through the system-provided list of potentialPresenters and listen for presence state changes for each potentialPresenter. If we find a presenter with DESIRED_PRESENTEE set to the presentee, we show a “do you want to join this session with {{ presenter }}?” question, with “yes” and “no” buttons. If “yes” is clicked, we join the activity with SESSION_ID pulled from the presenter’s state.

When designing this, some sort of generic messaging framework seems like it would be more ergonomic. So, for instance, the presenter could just send a direct message to the presentee asking her if she would like to join a new screenshare session.