Important question: if I have configured my editor with the one true way (VIM), and the remote has some dumb evil way setup (not VIM), are we able to be separately good and evil?

Absolutely! Live Share allows developers to quickly/easily collaborate with each other, while continuing to use their pre-configured editor, which includes themes, key maps, extensions, etc. This way, everyone can feel completely at home while working together.

Does this require full internet access or can this work peer-to-peer for developers working behind the firewall.

Full internet access required. From this comment: https://news.ycombinator.com/item?id=15705063

Authentication and authorization is managed by a cloud service

Wondering what will be the final pricing of this feature? It looks too good to be available for free for any VS/VSCode user.

Surely they're not incurring much costs with this feature if they're just using Microsoft servers for the initial WebRTC handshake? That's what Atom's recently announced Teletype feature does at least: https://blog.atom.io/2017/11/15/code-together-in-real-time-w...

This is incredibly not promising (in regards to pricing): https://twitter.com/VisualStudio/status/930885113159802886

This looks pretty amazing. Question: if two people are sharing code and one of them hits "Build", whose machine builds the project?

Great question! The project would be built on the machine of the developer who initiated the Live Share session. That developer is effectively the "owner" of the session, and all developers who join the session are connecting their editor/IDE to theirs, and remoting certain editing/building/debugging operations. This allows the participants to fully collaborate, investigate/explore the project independently, but without incurring additional environment/setup requirements simply to get started.

We want the act of providing feedback/advice/etc. to each other to be as lightweight/frictionless as possible. Ideally, it would be so easy to collaborate, that it becomes harder for teams _not_ to do it :)

Wow, this is awesome. While the use case outlined here is great I could probably use this as a remote editor. That is, I can have my dev environment running in the 'cloud' and still expect responsiveness from my editor!

Remote development is definitely an adjacent use case that we believe could be really compelling. Thanks so much for providing the +1 on the scenario, and stay tuned (i.e. sign up :)) for future updates!

Cool, I signed up for updates and left my use case in the comments.

edit: grammar

Yes, I really want this too.

All the existing ways I know to do this (shared filesystem NFS/smb/sshfuse, or shared screen PCoIP/VNC/RDP, or remote file editors like BBEdit, TextMate+rmate, etc) are all terrible to use in practice.

My primary use case would also be as a remote editor.

How open is this going to be? Will it be based on a protocol implementable by other editors, akin to the Language Server Protocol (https://github.com/Microsoft/language-server-protocol) ?

Question: What data will be sent to the Microsoft servers? Lots of companies have very strict policies, most of them dont want their source code in any way at third parties.

I read a comment by another PM on Reddit who said that everything is fully encrypted, but is sent to a remote server to negotiate the connection with the other user. They also said that they don't collect any private information/code.

Are you gonna have any sort of extensibility apis. Would love to build something like coderpad, which saves/plays history of edits.

I hope this is just a another open source vscode plugin so other developers can contribute. I don’t trust Microsoft enough to build a closed collaboration system. We all know how abusive they were with good ol’ MSN messenger.

It would have been even better to include at least some idea of the expected release time or availability of the preview. It's hard to believe there is so much detail on the feature set, a big website to promote this and nobody at Microsoft has any certainty when this might be out.

We will be releasing a private preview of the feature early in 2018.

You can sign up for it here: http://landinghub.visualstudio.com/vsliveshare

Yes, I saw that but -

It doesn't mention a date.

It only says 'may'.

It asks for an email "For a Microsoft enabled work or school, personal Microsoft, or GitHub account", which is not particularly clear.

The form and data goes to some 'hubspot.com', rather than to Microsoft. It is default-blocked by ghostery as a tracker.

The feature looks really interesting, the promo site and the experience of using it is, to use the technical term, poopy.

This seems super helpful when swarming compared to squeezing everyone on the team into one office. Will collaborators all be required to be running admin level accounts? That might be a problem in shops (mine!) where admin access is rarely granted to devs.

Awesome! Thanks for this feedback. Swarming is definitely a scenario we'd love to see Live Share help improve. And no, collaborators wouldn't need to be running admin level in order to participate in a sharing session. We want to make sure collaboration is as accessible/frictionless as possible for everyone :)

Does it use any external services to perform the sharing ? Can I run it on a vpn? What port does it use ?

Is it relaying the data over Microsoft (or Azure/Skype/etc) server? Or is it a point-to-point / peer-to-peer connection?

And if it relays the shared data over Microsoft server, what data beside currently opened source code files and keyboard + mouse inputs is transfered? Will it also transfer more source code files (e.g. whole VS project)?

I have to say this feature reminds me of the hollywood movie "Startup" (2001): http://www.imdb.com/title/tt0218817/

Yes, the data goes over an Azure relay, but we are investigating using a peer-to-peer communication for sharing as well.

We don't transfer all keyboard and mouse inputs. Instead, we communicate the data behind each collaboration activity (e.g. opening and editing source files, initiating debug sessions, stepping through code, etc.). We only transfer what is needed during the collaboration session.