Add presence detection using the firebase realtime database websocket #507
Conversation
…allow importing firebase-functions-test
|
FYI, I have tested this on the emulator, where it works well and is quite fast. However, if we find in production that it's too slow to respond when someone connects, we should be able to add an endpoint so the client can update the status proactively, rather than waiting for the trigger to fire. |
| "$experimentId": { | ||
| "$publicId": { | ||
| ".read": "true", | ||
| ".write": "true" |
There was a problem hiding this comment.
Does this make the db open to the public?
There was a problem hiding this comment.
It makes this key open to the public, but you can only access records for known IDs. Since research participants are anonymous (from an auth perspective) there is no other way.
However, I notice that I misnamed that ID. So lemme go fix that...
…nstitute/deliberate-lab-clean into raindrift/presence-detection
utils/src/participant.ts
Outdated
| @@ -36,6 +36,7 @@ export interface ParticipantProfile extends ParticipantProfileBase { | |||
| currentStatus: ParticipantStatus; | |||
| timestamps: ProgressTimestamps; | |||
| anonymousProfiles: Record<string, AnonymousProfileMetadata>; | |||
| connected: boolean; | |||
There was a problem hiding this comment.
Since this field is added, can we make the ParticipantProfile backwards compatible on the frontend (i.e., if reading in previously stored experiments) by adjusting the snapshot listeners in ParticipantService, ExperimentManager, and CohortService (if field is meant to be included in ParticipantProfile, not just ParticipantProfileExtended - see other comment)? You'll notice we did this already with agentConfig field.
There was a problem hiding this comment.
Oh good point! I wasn't considering backward compatibility at all.
utils/src/participant.ts
Outdated
| @@ -36,6 +36,7 @@ export interface ParticipantProfile extends ParticipantProfileBase { | |||
| currentStatus: ParticipantStatus; | |||
| timestamps: ProgressTimestamps; | |||
| anonymousProfiles: Record<string, AnonymousProfileMetadata>; | |||
| connected: boolean; | |||
There was a problem hiding this comment.
Is this new field intentionally under ParticipantProfile (all participants have access to other participants' connected status), or should it be under ParticipantProfileExtended (only experimenters or the current participant has access to the participant's status)? My understanding is that it might be more appropriate under the latter?
There was a problem hiding this comment.
It wasn't intentionally there, but I think it needs to be there. With this change, isActiveParticipant depends on the connected property, and it's used in a bunch of the participant views.
…rticipants are now always online
|
Ok, updated to make the connected property optional. Also now makes sense for agent participants. Previously it would show them as always offline. I guess this is technically true in a way, but not useful. Now it will show them as always online instead. |
Fixes #506
With this PR, whether a user has their browser window open and connected is reflected in the UI, and the
connectedproperty on their participant record. It allows the experimenter to know if the participant is still present, which is important for experiments that involve participants interacting with one another.This works by using the firebase rtdb's existing presence functionality, and a cloud function that mirrors the user's state into firestore.