You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we do not support multiple users collaboratively editing on the same code-server instance. We've thought of this and would love to hear what your thoughts are.
In our world, it'd be great to provide collaborative access, but never allow the collaborator to have control over the host machine in any way (for security reasons).
Reacted by Carl J. Mosca, Damodharan J, Kesus Kim, Eugen Soloviov, GeorgeDuM, Benjamin Lukas Kollmer, Konstantin Kondr, Joe Taber, James Pham, Aleksa Savić and 53 more
I currently use https://github.com/c9/core for collaboration, where multiple users can log into the same server and work together.
code-server interests me as it uses VS Code so it heavily supported, unlike Cloud9. For my use case, permissions aren't really a problem.
Reacted by Chris Cullin, AndreasGassmann, h1nk, Mackaber (Miguel Bravo), Sandro, Dom H, Leo Gallucci, Liv Dywan, N. Milton Vega, vincent1890 and 5 more
This is a must for a cloud ide, Without this feature I don't even see an advantage of using a cloud editor as there are few ways to share the workspace through the client: and in plus require less resources than the browser.
So definitely +1
On Thu, Mar 7, 2019 at 9:52 PM Adrian Barylski ***@***.***> wrote:
This feature is a must for us. My suggestions based on Cloud9 experience:
- Allow for a shared terminal
The way Cloud9 tackled this is great and it is something I'd personally
love to see implemented in code-server.
The collaboration feature is super important for us. We use Cloud9 as our
go-to IDE but after Amazon's take over, we're looking for alternatives.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#33 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGysxLSMbqLxhV0ardGWbNZPQbEdFiYEks5vUfqDgaJpZM4bgsjG>
.
This feature is a must for us. In terms of access, I would say that allowing the use of a terminal and editing any file/folder etc. would be enough.
My suggestions based on Cloud9 experience:
Allow for a shared terminal
See exactly where others are on a file (cursor, line highlight)
A way to see how many people are currently viewing the project
A way to see a person's active file (we usually talk about a particular file that may be nested in 10 folders)
The way Cloud9 tackled this is great and it is something I'd personally love to see implemented in code-server. We use it as our go-to IDE but after Amazon's take over, we're looking for alternatives and Coder/code-server would be it if it had collaboration/live share.
Reacted by Giulio Zanchetta, Egoscio, Ahmed Mohamedeen, Lionel Vladimir Bino, Abubaker Bilal, chobiz13, Sandro, Florian Bopp, Dom H, Leo Gallucci and 6 more
@kylecarbs - sorry I accidentally commented and then deleted it haha. See my new comment.
Regarding how Cloud9 implemented this - I'm not sure about the self-hosted version as I haven't used it however, the way we use cloud one is this:
We create a remote SSH workspace from our master account per project
From the master account, we invite all devs to have access to the workspace (files/folders + terminal)
Then you switch to your personal account and use the workspace shared by the master account.
I'm trying to think what malicious activity there could be if this is self-hosted? Surely if you have a secure server and you trust your devs, there is nothing to worry about? In our case, we only have 3 full-time devs so I guess the only time where there could be a concern for this is if we get a freelancer or something.
If you could share some of your concerns about this, I'd love to hear them! :)
Reacted by Giulio Zanchetta, vincent1890, 关关来了 and laurentvergnaud
@PhilsLab - 100% agreed about the project selection. When it comes to accidentally killing the server - I guess there could be times when this happens but I don't think this is a massive concern. Well, it would be if you worked directly from a live server. Ideally you should only be working on a dev or staging server and then only push your code live so it's not a big deal (IMO).
We could just do nothing and let it work the same as if there were two separate code-server instances running. So whoever saved last would have the latest.
We could also make it so guest instances have no file access, then they have to use the plugin to edit forcing them to use it in collaboration mode.
The way I imagine the plugin working is you would create a token to give to people (through the API we would add) and those would be "guest" instances.
Or maybe the plugin would let you create users/logins and those would be guest instances or perhaps you would be able to specify whether they are guests just for collaboration or also have file access.
Basically what @rdbeach already did, just split up to minimize the patching. The more patching we have the more difficult it is to keep code-server up to date with upstream.
Is there really no solution that doesn't rely on either Live Share, Duckly, or CodeTogether?
This feature as well as remaining FOSS and not tied to a paid service are both mission critical for me.
Would it be at all feasible to patch in something like Etherpad, even if it isn't fully featured, just for syncing the state of the text buffer across open file(s)? Just... something? Anything?
I realize the security implications there but I'm just spitballing in the hopes that a band-aid solution might be somewhat attainable even if a native feature is realistically many months or years down the line.
OSS and free are two different concerns. CodeTogether is not OSS, because we made a large investment in both terms of technology innovation, engineering, and server time and want to be able to pay our developers and cover our worldwide hosting costs. We do this by offering a very low-priced "freemium" solution. Our free version includes unlimited 1-hour sessions with up to 3 people. Most of our users find that the free version completely meets their needs. But if it doesn't, you can remove those limits completely for a few dollars per month.
So free is already available, but not as OSS because we have expenses to pay. And even if CodeTogether was OSS, someone would still have to provide a worldwide server network to run it at scale, so the expenses would remain.
Can you help me understand why OSS in this particular area (which you'll be using only to develop a solution, not deliver as part of a solution) is so "mission critical" for you? I really am simply trying to understand as you're not the only one who has this belief.
Reacted by Morgan Wable, Brian Fernandes and Laury Bueno
In all honesty, it's largely because I'm broke. But there are a host of reasons. Pun intended.
The OSS aspect of things is less important - although I'll get to that later - but... the fact of the matter is that you are not in fact offering a free solution. And that's not your fault.
Imposing a limitation 3 collaborators for one hour at a time is reasonable for the service you're providing, being that you're offering them in such a way that they incur expenses that must be recovered and turn a profit in order to self-sustain.
Unfortunately, those limitations simply do not meet my needs.
Most of the time, I'll only be working with one other person at a time. But it isn't uncommon for me to need to open up a document with 5 or more people simultaneously. That capacity is non-negotiable.
And, in either case, I rarely do so for only one hour at a time. Even if the sessions are unlimited, having to exit and restart them at an hourly interval represents an absolutely intolerable interruption to my workflow - maybe I'm just overly sensitive to that because of ADHD, but as I'll say several times throughout, it's the principle of the matter.
That brings me to the money side of things.
I'm trying to cut down on subscription-based products and services. The harsh reality is that in a world that's being absolutely ravaged by price gouging and inflation, $5.25 billed monthly may sound inconsequential, but it adds up VERY quickly when combined with every other "reasonably priced"* piecemeal solution we've all steadily come to expect and rely upon.
*reasonably priced is in scare quotes here specifically because the price only becomes unreasonable when combined with many other subscriptions, even though it's far more than reasonable in isolation
Of course, given your particular offerings and infrastructure, not only is this a reasonable price, in isolation, but I would be highly unreasonable to expect you to provide the same services for completely free because you'd be operating at a loss. What I'm looking for - even if it isn't quite as feature complete or well-integrated, is a local solution that doesn't rely on someone else's servers.
The OSS nature of such a solution is mostly in relation to it not being something that exists for profit - because even the absolute cream of the crop of free closed-source software is subject to ruination at a moment's notice as a direct result of the whims of capital.
There's no guarantee that CodeTogether will exist forever. If anything, there's a guarantee that it won't simply because of the linear nature of time and the life cycle of private entities existing within the structure of capitalism - they either get bought up, get too big to fail (all things being relative), or they fail.
There also the exists the issue of OSS and extensibility - aside from the fact that you may change how your service works at any given moment without notice (assuming your TOS allows for that), there's also no guarantee I won't eventually face a situation where I need a functionality that is an uncommon use case and thus won't be considered for development, and I'll have no choice but to migrate.
That is highly unlikely, and it looks like your services are robust especially for the low price point, but it's the principle of the matter.
All that being said, if this truly doesn't currently exist in any form - which I find hard to believe, I feel like I simply must not have found it yet? - then... I sadly don't have the resources necessary to incentivize or kickstart its development. I can't expect anybody to do that for me, because I'd be expecting them to do it for free.
I'm just thinking out loud, here... what about something like y.js? true P2P collaboration - even with advanced functionality - without an intermediary server is clearly an extant possibility. What I want to know is why has nobody seemingly implemented such a solution within a text editor or IDE yet?
Obviously there must be a good answer to that question, but I can't think of one other than that it's simply not seen as a priority... which I find confusing but understandable - given that collaborative code is relatively new, I can understand why people haven't begun to see it as essential enough to develop a decentralized solution for... even though that disappoints me greatly. I'm just not sure where to go from that point, I suppose.
So.
Philosophizing aside, TL;DR: I desire a FOSS solution largely to save money; so that I can know it will actually be available to me in perpetuity, on premises, not at somebody else's expense; and so that can at least theoretically be adapted to my unusually picky needs and preferences if I were to either somehow learn how to do so myself or eventually afford the services of a developer. But of course if that truly, somehow, doesn't already exist... then it's not something I can reasonably ask of somebody to create.
I'd be highly disappointed and somewhat surprised if this kind of implementation doesn't already exist somewhere in some form, but if it doesn't... I guess I understand? Even though I don't quite get why I'd (in that case) be in the minority in placing it high in my list of priorities for a text editor.
Reacted by Guil. Sperb Machado, Todd Williams, Brian Fernandes, Stratos Gerakakis, Kasper J. Seweryn, Octo, NickAc, MP3Martin, Xie Zejian and huhu
@morganwk Thank you very much! That was an expansive reply that really does show how conflicting some of these decisions and desires can be.
I've always wondered what the principle concerns are for people that hold the apparently conflicting opinions of "I want all the software I use to be FOSS" and "I'm a software developer and want to be paid for the software I write."
I'm at the phase of my software career where I have to make payroll for talented developers that remind me of my former self. So to pay them, and cover our other operating costs, we charge for some of our products. We believe it's an honest and direct financial model.
As to why there are no general OSS solutions: I'll postulate that it's because robust remote editing with multiple participants is extremely difficult to do in a correct and instantaneous manner. For a introduction of what's involved, this paper on Differential Synchronization is a great primer on the topic. Then you have to build on this to do any number of participants, from any distance, with edit transmit times will vary wildly from edit to edit, who use different IDEs or browsers, etc.
But again, I really do appreciate you thinking through this so completely. I found your written internal dialog quite fascinating as it's from a completely different perspective than my own.
I wish you the best in finding (or building) what you're looking for.
Apologies if I am oversimplifying things, but why would it be difficult to implement concurrent editing of a simple text document (or two, five, or twenty)? Google Docs is doing it. Sharelatex (now Overleaf) is doing it. In the case of source code editing, it might even be more simplified since no document formatting is required (no headings, no images, no tables, no wysiwyg elements). Actually the y.js library mentioned above seems to be solving all this (I was not aware of it, until 5 mins ago)
If the concurrent editing results in an invalid source file, let the compiler complain. All the remaining infrastructure work that has already been implemented (spinning servers up, having access to terminals, compiling, port forwards, fully onlne editors, etc) can remain the same. I mean, the majority of, what I would consider the actually hard work, are already implemented and they do not have to support multiuser access. Is it the simple editing of some text files that is really the roadblock here...? (Note, I already apologized for potentially oversimplifying things :) )
Basically, I am also thinking out loudly about a similar internal lack of understanding of something like @morganwk explained above...
Reacted by Atif Ali, Octo and João Filipe Silva de Almeida
Hi, I would like to be able to create two accounts one for my daughter and one for me. Would it be possible so we could work/learn on our own projects with proper isolation?
Activity
sr229 commentedon Mar 6, 2019
If I remember, this is a planned feature. But if this was a 1:1 code-oss port. VS Live Share could work on this.
kylecarbs commentedon Mar 6, 2019
Currently, we do not support multiple users collaboratively editing on the same
code-serverinstance. We've thought of this and would love to hear what your thoughts are.In our world, it'd be great to provide collaborative access, but never allow the collaborator to have control over the host machine in any way (for security reasons).
sr229 commentedon Mar 6, 2019
I think we should do this the way how VS Live share does it - RBAC by limiting views to read-only and restricting terminal access.
xPaw commentedon Mar 6, 2019
I currently use https://github.com/c9/core for collaboration, where multiple users can log into the same server and work together.
code-server interests me as it uses VS Code so it heavily supported, unlike Cloud9. For my use case, permissions aren't really a problem.
nhooyr commentedon Mar 6, 2019
@kylecarbs does vscode live share work?
kylecarbs commentedon Mar 6, 2019
I believe it would if the extension was open-sourced. Unfortunately, we can't provide support for it.
See: microsoft/vscode#38733 (comment)
zanhk commentedon Mar 7, 2019
This is a must for a cloud ide, Without this feature I don't even see an advantage of using a cloud editor as there are few ways to share the workspace through the client: and in plus require less resources than the browser.
So definitely +1
zanhk commentedon Mar 7, 2019
Maybe also with an interactive button in the status bar showing connected user and options to manage permissions.
This could be a really game changer
kylecarbs commentedon Mar 8, 2019
baryla commentedon Mar 8, 2019
This feature is a must for us. In terms of access, I would say that allowing the use of a terminal and editing any file/folder etc. would be enough.
My suggestions based on Cloud9 experience:
The way Cloud9 tackled this is great and it is something I'd personally love to see implemented in code-server. We use it as our go-to IDE but after Amazon's take over, we're looking for alternatives and Coder/code-server would be it if it had collaboration/live share.
baryla commentedon Mar 8, 2019
@kylecarbs - sorry I accidentally commented and then deleted it haha. See my new comment.
Regarding how Cloud9 implemented this - I'm not sure about the self-hosted version as I haven't used it however, the way we use cloud one is this:
I'm trying to think what malicious activity there could be if this is self-hosted? Surely if you have a secure server and you trust your devs, there is nothing to worry about? In our case, we only have 3 full-time devs so I guess the only time where there could be a concern for this is if we get a freelancer or something.
If you could share some of your concerns about this, I'd love to hear them! :)
baryla commentedon Mar 8, 2019
@PhilsLab - 100% agreed about the project selection. When it comes to accidentally killing the server - I guess there could be times when this happens but I don't think this is a massive concern. Well, it would be if you worked directly from a live server. Ideally you should only be working on a dev or staging server and then only push your code live so it's not a big deal (IMO).
111 remaining items
code-asher commentedon Mar 20, 2023
We could just do nothing and let it work the same as if there were two separate code-server instances running. So whoever saved last would have the latest.
We could also make it so guest instances have no file access, then they have to use the plugin to edit forcing them to use it in collaboration mode.
KaKi87 commentedon Mar 20, 2023
What guest instances ?
code-asher commentedon Mar 21, 2023
The way I imagine the plugin working is you would create a token to give to people (through the API we would add) and those would be "guest" instances.
code-asher commentedon Mar 21, 2023
Or maybe the plugin would let you create users/logins and those would be guest instances or perhaps you would be able to specify whether they are guests just for collaboration or also have file access.
Basically what @rdbeach already did, just split up to minimize the patching. The more patching we have the more difficult it is to keep code-server up to date with upstream.
morganwk commentedon Mar 27, 2023
Is there really no solution that doesn't rely on either Live Share, Duckly, or CodeTogether?
This feature as well as remaining FOSS and not tied to a paid service are both mission critical for me.
Would it be at all feasible to patch in something like Etherpad, even if it isn't fully featured, just for syncing the state of the text buffer across open file(s)? Just... something? Anything?
I realize the security implications there but I'm just spitballing in the hopes that a band-aid solution might be somewhat attainable even if a native feature is realistically many months or years down the line.
toddewilliams commentedon Mar 27, 2023
@morganwk Your comment makes me curious.
OSS and free are two different concerns. CodeTogether is not OSS, because we made a large investment in both terms of technology innovation, engineering, and server time and want to be able to pay our developers and cover our worldwide hosting costs. We do this by offering a very low-priced "freemium" solution. Our free version includes unlimited 1-hour sessions with up to 3 people. Most of our users find that the free version completely meets their needs. But if it doesn't, you can remove those limits completely for a few dollars per month.
So free is already available, but not as OSS because we have expenses to pay. And even if CodeTogether was OSS, someone would still have to provide a worldwide server network to run it at scale, so the expenses would remain.
Can you help me understand why OSS in this particular area (which you'll be using only to develop a solution, not deliver as part of a solution) is so "mission critical" for you? I really am simply trying to understand as you're not the only one who has this belief.
morganwk commentedon Mar 27, 2023
In all honesty, it's largely because I'm broke. But there are a host of reasons. Pun intended.
The OSS aspect of things is less important - although I'll get to that later - but... the fact of the matter is that you are not in fact offering a free solution. And that's not your fault.
Imposing a limitation 3 collaborators for one hour at a time is reasonable for the service you're providing, being that you're offering them in such a way that they incur expenses that must be recovered and turn a profit in order to self-sustain.
Unfortunately, those limitations simply do not meet my needs.
Most of the time, I'll only be working with one other person at a time. But it isn't uncommon for me to need to open up a document with 5 or more people simultaneously. That capacity is non-negotiable.
And, in either case, I rarely do so for only one hour at a time. Even if the sessions are unlimited, having to exit and restart them at an hourly interval represents an absolutely intolerable interruption to my workflow - maybe I'm just overly sensitive to that because of ADHD, but as I'll say several times throughout, it's the principle of the matter.
That brings me to the money side of things.
I'm trying to cut down on subscription-based products and services. The harsh reality is that in a world that's being absolutely ravaged by price gouging and inflation, $5.25 billed monthly may sound inconsequential, but it adds up VERY quickly when combined with every other "reasonably priced"* piecemeal solution we've all steadily come to expect and rely upon.
*reasonably priced is in scare quotes here specifically because the price only becomes unreasonable when combined with many other subscriptions, even though it's far more than reasonable in isolation
Of course, given your particular offerings and infrastructure, not only is this a reasonable price, in isolation, but I would be highly unreasonable to expect you to provide the same services for completely free because you'd be operating at a loss. What I'm looking for - even if it isn't quite as feature complete or well-integrated, is a local solution that doesn't rely on someone else's servers.
The OSS nature of such a solution is mostly in relation to it not being something that exists for profit - because even the absolute cream of the crop of free closed-source software is subject to ruination at a moment's notice as a direct result of the whims of capital.
There's no guarantee that CodeTogether will exist forever. If anything, there's a guarantee that it won't simply because of the linear nature of time and the life cycle of private entities existing within the structure of capitalism - they either get bought up, get too big to fail (all things being relative), or they fail.
There also the exists the issue of OSS and extensibility - aside from the fact that you may change how your service works at any given moment without notice (assuming your TOS allows for that), there's also no guarantee I won't eventually face a situation where I need a functionality that is an uncommon use case and thus won't be considered for development, and I'll have no choice but to migrate.
That is highly unlikely, and it looks like your services are robust especially for the low price point, but it's the principle of the matter.
All that being said, if this truly doesn't currently exist in any form - which I find hard to believe, I feel like I simply must not have found it yet? - then... I sadly don't have the resources necessary to incentivize or kickstart its development. I can't expect anybody to do that for me, because I'd be expecting them to do it for free.
I'm just thinking out loud, here... what about something like y.js? true P2P collaboration - even with advanced functionality - without an intermediary server is clearly an extant possibility. What I want to know is why has nobody seemingly implemented such a solution within a text editor or IDE yet?
Obviously there must be a good answer to that question, but I can't think of one other than that it's simply not seen as a priority... which I find confusing but understandable - given that collaborative code is relatively new, I can understand why people haven't begun to see it as essential enough to develop a decentralized solution for... even though that disappoints me greatly. I'm just not sure where to go from that point, I suppose.
So.
Philosophizing aside, TL;DR: I desire a FOSS solution largely to save money; so that I can know it will actually be available to me in perpetuity, on premises, not at somebody else's expense; and so that can at least theoretically be adapted to my unusually picky needs and preferences if I were to either somehow learn how to do so myself or eventually afford the services of a developer. But of course if that truly, somehow, doesn't already exist... then it's not something I can reasonably ask of somebody to create.
I'd be highly disappointed and somewhat surprised if this kind of implementation doesn't already exist somewhere in some form, but if it doesn't... I guess I understand? Even though I don't quite get why I'd (in that case) be in the minority in placing it high in my list of priorities for a text editor.
andrewsali commentedon Mar 27, 2023
JupyterLab has real time collaboration using y.js, it would be nice if code server supported something similar.
toddewilliams commentedon Mar 27, 2023
@morganwk Thank you very much! That was an expansive reply that really does show how conflicting some of these decisions and desires can be.
I've always wondered what the principle concerns are for people that hold the apparently conflicting opinions of "I want all the software I use to be FOSS" and "I'm a software developer and want to be paid for the software I write."
I'm at the phase of my software career where I have to make payroll for talented developers that remind me of my former self. So to pay them, and cover our other operating costs, we charge for some of our products. We believe it's an honest and direct financial model.
As to why there are no general OSS solutions: I'll postulate that it's because robust remote editing with multiple participants is extremely difficult to do in a correct and instantaneous manner. For a introduction of what's involved, this paper on Differential Synchronization is a great primer on the topic. Then you have to build on this to do any number of participants, from any distance, with edit transmit times will vary wildly from edit to edit, who use different IDEs or browsers, etc.
But again, I really do appreciate you thinking through this so completely. I found your written internal dialog quite fascinating as it's from a completely different perspective than my own.
I wish you the best in finding (or building) what you're looking for.
stratosgear commentedon Mar 28, 2023
Apologies if I am oversimplifying things, but why would it be difficult to implement concurrent editing of a simple text document (or two, five, or twenty)? Google Docs is doing it. Sharelatex (now Overleaf) is doing it. In the case of source code editing, it might even be more simplified since no document formatting is required (no headings, no images, no tables, no wysiwyg elements). Actually the
y.jslibrary mentioned above seems to be solving all this (I was not aware of it, until 5 mins ago)If the concurrent editing results in an invalid source file, let the compiler complain. All the remaining infrastructure work that has already been implemented (spinning servers up, having access to terminals, compiling, port forwards, fully onlne editors, etc) can remain the same. I mean, the majority of, what I would consider the actually hard work, are already implemented and they do not have to support multiuser access. Is it the simple editing of some text files that is really the roadblock here...? (Note, I already apologized for potentially oversimplifying things :) )
Basically, I am also thinking out loudly about a similar internal lack of understanding of something like @morganwk explained above...
SichangHe commentedon Aug 11, 2024
This would be nice to be built into code-server itself, without the need for a separate hosting service.
Reference: https://github.com/coderpair/vscode-live
mictadlo commentedon Aug 15, 2024
Hi, I would like to be able to create two accounts one for my daughter and one for me. Would it be possible so we could work/learn on our own projects with proper isolation?
laurybueno commentedon Jan 22, 2025
For anyone still looking for this, Open Collaboration Tools and its IDE extension might be a way forward.
Edit: fixed link (thanks, @KaKi87)
KaKi87 commentedon Jan 22, 2025
You posted the same link twice 😅
toddewilliams commentedon Jan 22, 2025
It's been awhile since I've tested it, but CodeTogether Cloud works in VSCode and most derivatives.
And it's free and works across different IDEs and even with a browser client.