Enable ad-hoc peer discovery for easier (and reverse) session initiation

[lostintangent]

Currently, in order to start a collaboration session, the "host" needs to share their project and then exchange a URI with each developer they'd like to work with. The benefit of this workflow is that it's extremely flexible, since it doesn't necessitate any specific network topology and/or communication tool in order to coordinate collaboration.

However, this URI exchange workflow may feel a little heavyweight over time, particularly for folks that are collaborating regularly, and may already be co-located (e.g. team room, hack-a-thon)
and/or on the same network/VPN. Since we want to enable lightweight/frequent collaboration, anything we can do to simplify the actual session initiation process, would likely go a long way to improving the overall experience.

We could explore allowing Live Share users to opt-in to some form of peer discovery model (this would not be on by default!), that is based on some kind of ad-hoc group, where anyone in the same group (e.g. the same subnet/VPN, using a shared group “moniker”) could see their presence, and automate the process of sharing/joining. Conceptually, this could be somewhat similar to Bounjour/AirDop/UPnP experiences for network-local collaboration, or Twitter hashtags for arbitrary co-ordination amongst interested parties across the Internet.

Additionally, this kind of proposal could allow "guests" to request that someone share with them (as opposed to being host-driven), which could potentially be compelling for classroom scenarios (e.g. a teacher wants to help out a specific student).

This proposal wouldn't remove the existing authentication requirement, and in fact, the need to sign-in would allow the peer discovery process to work based on known identities (e.g. "I can see that Sri is online"), as opposed to IP addresses/machine names. Under the covers, this experience could effectively just automate the share and join process, using the same URIs, but with a single-click, and without the need to switch contexts to and from a separate communication.

[miking-the-viking]

Philosophically, I believe the end goal of VS Code is to be the One Stop Shop IDE.

Likewise, I find the current setup of Live Share is very explicit, and easy to execute. For frequent collaboration it can be tedious though, especially in earlier states of the project as it's reliability is improving but necessitating many ended/restarted sessions and many shared links.

1. I converse with my colleague(s) either in-person, over the phone, or over another medium like Slack. A Live Share session is decided upon.

Simultaneous concurrent communication of collaborators via some medium(s) outside of VS Code seems to be an implicit necessity for a Live Share session. To be fair, that's what this plugin is trying to help facilitate.

2. A user initiates a share session, they now need to send the share link to their collaborators; ideally through a medium that is clickable or at least copy&pastable from the device that they're coding on and not transmitted orally.
   The may also start sharing their terminal and/or local ports for remote shared access.
3. The collaboratees now use the shared link to join the session.
4. If something goes wonky, the collaboratees may leave and rejoin with minimal fuss. But if the host has an issue the session is ended, and a new share session must be started, a new link must be generated and shared, and all collaboratees must receive and retrieve that link to resume.

In it's current implementation, VS Live Share is required to butt heads with the core VS Code ideology of being the One Stop Shop due to the requirements of external link sharing and collaborator communication. Session discovery would be a perfect means of embracing that ideology by allowing users to access/find/discover Live Share sessions all within VS Code. Either locally on the same network; or remotely via repository access, custom groups, etc.

There's some great implications for user management via the already implemented user authentication mechanisms required by Live Share (Microsoft or GitHub accounts, which could be expanded upon). It may need to be a bit more fleshed out with items like:

• user permissions, toggled at share session creation (?) repo-wide (?) user/group (?)
  • read-only guest access (?)
  • publically discoverable (?)
  • (custom) groups (?)
  • session-based permission (?) [at some point during session, admin promotes/demotes permission for a user/group]
  • more granular permissions for terminal/port access in larger share sessions (?)
• user management controls (?)
• send invitation to user x (?)
  • implies searching for users (?)
    • by their GitHub/Microsoft/... user name (?)
  • retrieve users online state through VS Code (?)
  • internal user-to-user invitation mechanism (?)

I'm curious what the discovery experience would look like. But all-in-all I think this idea would be a boon to VS Live Share.

[lostintangent]

Closing this due to low activity and lack of significant customer interest. We can re-open it if/when we begin to hear more feedback 👍