This message was deleted.

are you talking about a sdk internal reconnect (RoomEvent.Reconnecting) or are you closing the connection and re-connecting yourself with the original token?

I take the token that sdk generated for me and insert it in this example https://example.livekit.io/ , then I change the rights with sdk, they change, I check them with the ListParticipants method. After that I close the tab in the browser, and I try to reconnect with the token that I generated at the beginning, in the new tab, and I still have the rights as they were before they were updated.

@wooden-park-67608, I don't think the LiveKit server is keeping persistent states between manual connections for participants. If a participant leaves, then his state is not kept in any database in a chance of reconnecting, etc. With this said, pretty sure the state is kept if this reconnecting is happening from internal. But someone could confirm this from the LK team. My Take on this, is you might be looking for a custom implementation of a state manager.

@brief-refrigerator-69901 is right. as soon as you close the tab, the participant disconnects from the server and the server “forgets” about this participant. when you connect again with the same token, the server only interprets the permissions that are encoded in that token. one way to solve this in your app could be to have users request a token with the desired permissions before they connect.

@polite-kilobyte-67570 I thought about it, but I noticed that the SetValidFor method doesn’t work quite as I expected. For example, I set the lifetime of the token to SetValidFor(30 * time.Second), but the token still lived for one minute. But if I logged into that token during that minute, the token was given a lifetime longer than that minute. My main problem is that a user can log in and immediately leave the room and another person will take his place, and if that user uses his old token again, there will be one more person in the room who will be streaming. Restriction on the number of people in the room, I can not put, because there are spectators. Because of this, the only solution I came up with is to give permission after the connection, and before that to give rights only to view.

Although, only 1 person can be joining a room with the same identity, so if this 2nd person is already logged, then he will be replaced with the latest participant joining with that token identity.

@brief-refrigerator-69901 If you make them one identity, the old person can still enter the room using the old token, and kick the person who is there correctly out of the room.

That is correct, although why would 2 people be sharing the same token?

I thought you suggested using different tokens, but instead of a name, specify in identity the place of the streamer.

Sorry for the confusion, I think we misunderstood ourselves. Every users should have its own token. I feel like I might be missing a bit more context on your application, but wouldn't you be able to generate tokens for streamers and a different token for spectators?

Yes, that’s right, everyone’s token is different, and everyone’s personality is different. Otherwise they would just be kicking each other around in circles. The idea is for the streamers to switch, first one would sit down and tell stories, and then when one leaves, another would sit in his place. If I give the streaming rights right away in the token, then I will not be able to update the user’s token, and he can use it after someone has sat in his place, and it turns out that there are two people sitting in the same place.

Okay, I understand what you are saying. In this case, to come back to your original question, as @polite-kilobyte-67570 confirmed LiveKit does not keep persistent state of participant if they leave a room. My suggestions would probably be one of these 3 options: 1- Create custom tokens for streamers 2- Keep a room state of your participants based on identity outside of LK, handled through server SDK 3- Probably not the best but, if a streamer disconnects, assign the streamer permissions to any spectator until another streamer joins a room and that spectator could reassign permissions to the new streamer. (This is somewhat how zoom works if the host leaves the room) Those are my thoughts @wooden-park-67608.

The idea is for the streamers to switch, first one would sit down and tell stories, and then when one leaves, another would sit in his place.

I’m not sure I follow. This sounds like the fact that a streamer leaving and having permissions reset to viewer-only is actually a good thing for your use case? 1. Alice joins with subscribe only permissions 2. App grants alice publish permissions when it’s her streaming slot is available 3. Alice disconnects, App grants publish permissions to someone else 4. Alice connects again and has to wait again until publishing rights are granted in order to stream

Yes, it is. I would like a user who stopped being a streamer, and his place was taken could not come back to be a streamer, until his place is free. Otherwise it may be when 2 people will stream at the same time. Initially, I wanted to give them a token with permission of streaming, and take it away remotely. But now I realized that the option to give them viewing permission, and then give them streaming permission looks easier to implement.

I know there's an option on the LiveKit Server level around automatically create rooms if they don't exists.

Thanks for the help.