Virtual situation rooms are a quick way to build a command and control structure, and since they are virtual, they do not require physical space and can be created in large numbers to give teams room to collaborate.
Welcome to a series of posts
I will guide you through creating a virtual situation room in this series. It will have the following episodes.
- Creating a virtual situation room
Creating rooms, different kinds of users - Connecting the virtual situation room
Inviting participants, adding sources - Optimize the layout
Custom Layout - Permalink rooms
Different usage, standard ops only?
If you have specific questions, let me know. Also, note that I might switch use cases to give you a blend of pieces showing what you must do or how to solve certain requirements.
Part 1: Creating a virtual situation room
To create a virtual situation room using the Eyeson API, you need to start an Eyeson room, which is the simplest solution for this scenario.
Here's a brief overview of what you need to do:
If you haven't already, obtain an API key from Eyeson. Go to the Developer Portal, sign up, create a project, and get your API key now. It is free for developers (no credit card, no spam).
To create an Eyeson room, make a single POST request to the Eyeson API. This request will provide a link to a reference web UI that can be used immediately.
Basic curl script to create a roomcurl -X POST \
-H "Authorization: YOUR_API_KEY" \
-d "id=VSR" \
-d "user[name]=Host" \
"https://api.eyeson.team/rooms"You'll receive a guest token and a direct URL to the Eyeson GUI in the API response. This URL can be used without any further API communication, allowing your users to join the virtual situation room directly.
Example response from API{
"access_key": "ACCESS_KEY",
"ready": false,
"locked": false,
"room": {
"id": "tryout",
"name": "VSR",
"ready": false,
"started_at": "2024-10-04T11:18:43.568Z",
"shutdown": false,
"guest_token": "e0dkCcDalWsQwxWT3Ena020b"
},
"team": {
"name": "VSR"
},
"user": {
"id": "66ffcf13fae130863805c90b",
"room_id": "tryout",
"name": "Host",
"avatar": null,
"guest": false,
"blocked": false,
"ready": false
},
"links": {
"self": "https://api.eyeson.team/rooms/4r3lJExyaa4RWXKEt948Az5e",
"gui": "https://app.eyeson.team/?4r3lJExyaa4RWXKEt948Az5e",
"guest_join": "https://app.eyeson.team/?guest=e0dkCcDalWsQwxWT3Ena020b",
"websocket": "https://api.eyeson.team/rt?access_key=4r3lJExyaa4RWXKEt948Az5e"
},
…
}You need to join that meeting room asap. The meeting will be spun down and cease to exist if you do not enter the meeting room.
Let's break down the methods for authenticating even further:
- API Key: This is the most powerful authentication method for server-side operations. It's obtained from the Eyeson Developer dashboard and allows full access to the API. It should never be exposed in client-side code.
- Access Key: This is used for client-side authentication, typically when a registered user joins a meeting. It's generated via the API and scoped to a specific user's permissions. It's used in the front end with the Eyeson iframe API.
- Guest Token: This temporary, single-use token allows guests to join meetings without full user registration. It's typically generated when starting a meeting and provides limited, often read-only access to meeting features.
The choice between these methods depends on your use case. For backend operations and management, you'll use the API Key. For registered users joining meetings, you'll use Access Keys. And for quick, temporary access for guests, you'll use Guest Tokens. Each method balances security, convenience, and feature access differently.