Use the Slack Calls API for #co-working-room

[ebanner]

Slack has a pretty banger Calls API which we could use to 1) make the #co-working-room app alerts look visually nicer and 2) would allow us to offload some of the logic from the #co-working-room app (I'm actually not as clear as to the impact here)

[ebanner]

cc @danieltott did you know about this?

[ebanner]

Did some work on this - I made a prototype:

Desktop

Mobile

[ebanner]

cc @meg-gutshall @JoeKarow

[ebanner]

One nice technical feature of this implementation is that it's stateless, so we could get rid of Airtable.

@danieltott is there a reason we're tracking room instances in Airtable? I can't see why - the co-working-room zoom meeting ID is always the same, so even if multiple meetings send events to the service, we can just check the meeting ID and disregard events not from the co-working-room meeting room. Plus there's only ever one active co-working-room session at a time.

[ebanner]

Summary of proposed enhancements:

• We get a nicer looking widget clearly showing who is in the room at any given time, and also everyone who joined (when the call ends)
• We eliminate the dependence on Airtable
• We delete code (e.g. the Airtable race condition retry logic and the UI code to join a co-working-room session and list participants)

One thing I'm not sure is how we should go about letting users create a a new co-working-room session - we could have a slash command (e.g. /start-co-working-room-session) or we could keep the Start a New Session! button that's currently there.

[ebanner]

FYI @JoeKarow from my experiments, it doesn't look like Zoom provides consistent user_ids (for mapping to slack IDs) - the user_id is only consistent if you have the zoom app installed (the zoom dev app which represents this application).

[JoeKarow]

When I was looking at doing something like this a couple years ago, I noticed that the user identification that the zoom webhook was valid for the current session only. I was going to use some type of simple KV store (probably could use Cloudflare's Workers KV) to store a mapping between the Slack user ID to that zoom session user ID to track the participants.

[danieltott]

@ebanner I think this is pretty dope! The reason we needed to track instances is that since we were just making a thread, we needed a way to track the active room instance to the thread that we had posted. Looks like we don't need this anymore, but that's why we were doing it.

What does the Zoom side of this look like? Just using the webhook?

[ebanner]

Yup, just sending participant join and leave events from the zoom side via a webhook 👍

[ebanner]

@danieltott anything preventing us from switching over to this? The main thing we would need to do is update the notification endpoint URL on the zoom app side to point to the lambda (this is running on my AWS account) so that it can start receiving participant.joined and participant.left events.

We would also need to add a slash command /co-working-room to be able to create a new co-working room instance.

[meg-gutshall]

All of them for right now. 1 and 2 due to the ability for users to change their Zoom name. 3 due to the ability for users to change their Zoom name plus duplicate Slack accounts.

If a user entered the Zoom meeting as "Tony," changed their name while in the meeting, and left the Zoom meeting as "Lord Anthony of the Seven Suns," how would Slack know who left that meeting and how to reflect it in the Calls API?

Please understand – I'm not saying your ideas are bad. They simply won't work for this particular use case.

No, just that I'm rooting for you guys to come up with a solution here 🙂

I do see myself "passing the torch/baton" to you guys for this leg of the project for you to lead. I will share ideas if I think of any and would be down if you guys want feedback or to brainstorm!

Can you poke any holes in that Co-working-room Bot Ideation document I posted in this thread yesterday? Joe and I created it right after Pack Hunt. We think we covered everything, but I'd appreciate another perspective on how this process could break. Thanks, Eddie!

[ebanner]

Oh, I didn't realize you wanted feedback on that! Here it is:

Overall, I don't understand the value of tracking the zoom_meeting_id and slack_call_id. What value do they provide?

And when you say:

Call Slack API (calls.participants.add) to add the user to the widget

and

Add the slack_id to a field in Zoom's Add a meeting registrant API

the fundamental issue is that Slack doesn't fire an event when the Join button on the Calls widget gets clicked (as mentioned in this comment). So you don't know who to add/remove from the Slack call (or how to get the Slack ID into a zoom registrant). You're only dealing with Zoom events.

[ebanner]

@meg-gutshall @danieltott how about this: what if we use NO custom photos (just use zoom usernames) for the initial launch? That way Joe and Meg can independently work on the matching part and it doesn't block the rollout of this feature.

[danieltott]

That sounds like it'd be a good solution 👍🏼

[ebanner]

OK @danieltott I went ahead and made that change.

PR is ready for review!

Virtual-Coffee/webhooks#27