Permissions

Permissions decide what a user can do once they're in a call or chat: speak, show video, only watch, moderate, and so on. Your backend sets them when it makes a token. They are signed into the token, so the app can't add more.

Where this fits: your backend makes tokens → permissions say what each token allows → Livqeno enforces them on every action.

Why it matters: in a webinar, you want the audience to watch but not take over the stage. In a class, students may speak but only the teacher moderates chat. Permissions are how you say that, and because the server checks them, a user can't get around them by editing your app.

RTC permissions

These control what a user can do in a call. To publish means to send your own media (camera, mic, screen) to the room; to subscribe means to receive other people's.

Anything you don't set is denied. There is no "allow by default".

Two rules to remember:

• publish: true alone (no publishAudio or publishVideo) means both mic and camera are allowed. Use the sub-flags only to narrow it.
• A sub-flag without publish allows nothing.

Common setups

Pick the line that matches each kind of user in your app, and use it in your backend's livqeno.tokens.create() call:

// A participant in a call
{ join: true, subscribe: true, publish: true }
 
// Audio-only participant
{ join: true, subscribe: true, publish: true, publishAudio: true }
 
// A viewer — cannot publish, by construction
{ join: true, subscribe: true }
 
// A bot that only sends data
{ join: true, publishData: true }

When they are checked

The server checks them every time someone joins and every time they publish. Not just once. If a token without publish tries to turn on the camera, the server refuses it and the room fires an error event.

Chat scopes

These control what a user can do in chat. A scope is one named permission on a chat token.

Chat checks two things, and both must allow the action:

1. The token's scopes.
2. The user's role in the conversation: MEMBER, MODERATOR, or ADMIN.

Scopes can only narrow the role. If you ask for chat:moderate for a plain member, the token is still made, but without that scope. So a stolen token is never stronger than its user.

When would you narrow? Say Alice is an ADMIN, but this token is for a read-only "transcript" view of the conversation. Give that token only chat:read, so even if it leaks, nobody can post as Alice:

await livqeno.chat.createToken({
  userId: 'alice',
  scopes: ['chat:read', 'chat:send'],   // narrower than her ADMIN role
});

Live-stream roles

A live stream sets permissions for you. Each role is a ready-made set:

The role depends only on which endpoint your backend called.

Related

• Access tokens: where these are set.
• Security: every credential and its risks.
• Roles & permissions: your team's roles in a project. That's a different thing.