Live Share Guest Limit Ignored

[shanrauf]

Describe what happened: In Live Share's settings, there is an option to increase the guest limit from 5 to 30. With this option unchecked, I tested this limit by connecting to my own Live Share session on the same computer using 10 or so incognito Chrome tabs. Even though there should be a limit of 5 guests, it seems like an unlimited # of guests could join the session. It is possible that I am running into this issue because the extension knows that every incognito tab is not really a different connection since its from the same computer, but I'm not sure.

I actually don't want to limit my guest count to 5 or 30. Ideally, I would like an unlimited # of guests to be able to connect to my Live Share session. Is that possible (disregarding my network capabilities)? Or is there a limit imposed by the extension? Is that limit manually configurable?

What was your system configuration? Product and Version [VS/VSCode]: VSCode

OS Version[macOS/Windows]: Windows 10

Live Share Extension Version: 1.0.2106

Target Platform or Language [e.g. Node.js]: Node.js

Steps to Reproduce / Scenario:

1. Start a Live Share session (I am personally starting a read-only session because I want many guests to view my code in realtime but without edit, terminal, chat, etc privileges)
2. Select the Live Share tab, and then under the Help tab, select Configure Settings.
3. Ensure "Increased Guest Limit" is unchecked
4. Attempt to have more than 5 people join the session.

Please attach logs to this issue: 20200510_053834_15890891140080_VSCode.log

[nandiniYeltiwar]

@shanrauf thanks for reaching out to us. I am trying to repro the scenario as you suggested but I do receive an error when i try to join as the 6th guests. I would need more info to narrow down the issue. Did you join the session from browser for all the guests? Were all guests anonymous? @fubaduba we have a request for unlimited guest support in session.

[shanrauf]

@nandiniYeltiwar, I tried reproducing my error and couldn't. I ended up getting the max participants prompt after 5 participants. It is possible that I thought I was running into an issue because I started a collaboration session with the guest limit at 30, and then unchecked the option to test the limit of 5 guests without closing the session and creating a new one for the settings to take effect, but I'm not sure if that is what happened. In any case, my apologies.

For more context on the feature request, the main problem I am trying to solve is livestreaming software engineering. Since livestreams get more than 30 viewers, a guest limit of 30 wouldn't be sufficient.

Explaining why I want to use Live Share for this: By giving viewers realtime read access to the source code, I figured I could solve some major issues I see when people livestream code:

• Making the livestream comprehensible to someone jumping in midway. If someone turns on the stream and sees me editting a random file, they have no context. One way to help give context is to give viewers realtime read access to the source code and allow them to explore the file I'm editting and the file's dependencies.

• Allowing copy/paste of the source code

• Allowing viewers to learn/comprehend at their own pace. In livestreams, It is impractical, if not impossible, for viewers to pause the stream to look at my code. If I implement a function, someone may want to ponder over it, but instead, I may switch to another file in the stream to make a different change, preventing the viewer from reading over the function. Realtime access to the code allows a viewer to remain on a file and look over the code before moving on.

Live Share doesn't solve all issues with livestreaming code (i.e code can still be incomprehensible even with access to source code, etc etc), but it's a part of the puzzle that I would like to test (but I cannot test it with a guest limit of 30).

Github is the next best alternative for people to interact with my code. The only problems are that viewers wouldn't get VS Code features (e.x terminal, file explorer, personal extensions, indication of which file I am currently editting with Live Share, etc), and also I would need to commit really frequently for people to see my realtime changes reflected on Github; this is not necessarily an issue since I can squash those intermediate commits into a single commit, but it's not ideal, and neither is Github's UI for viewing code (although VS Codespaces might fix that, I'm not sure. It's possible that the best solution here is to encourage people to use Codespaces and then I use Gitdoc to auto-commit, but Codespaces is not public yet so I can't test that)

[shanrauf]

@nandiniYeltiwar What's your opinion on the use case I outlined above?

[nandiniYeltiwar]

Hey @shanrauf thanks for describing your use case, it helps us understand the impact of the feature request to increasing guest limit. We have this feature planned in our roadmap and we are working towards it.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically in 2 days.

[fubaduba]

@shanrauf we appreciate understanding your use case of streaming and sharing your code with a >30 audience. For Live Share, our main value comes from having the rich co-editing experience where all the editor functionality is remoted to the guest. This becomes harder to achieve at the scale of streaming without compromising on the performance of our service. For streaming to work well with Live Share, we would need a more dedicated stripped down version of Live Share that also takes into account uses like you mentioned. We understand this may be disappointing; we've all been there, whether in this project or others we've contributed to. However, rest assured that we love your input. If you feel it deserves to stay open, then clarify your use case and contact us to let us know how severe it’s for you.