Collaboration (multi user) support #33
Comments
|
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. |
|
Currently, we do not support multiple users collaboratively editing on the same 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). |
|
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. |
|
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. |
|
@kylecarbs does vscode live share work? |
|
I believe it would if the extension was open-sourced. Unfortunately, we can't provide support for it. |
|
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. |
|
Maybe also with an interactive button in the status bar showing connected user and options to manage permissions. |
|
I'd have a look at how MS Word Online handles it: I like the idea of having a different cursor for every person actively editing, Also, when providing a login functionality, there should be a modern backend for this, not just local users. As I mentioned in #85, you could use Keycloak (which can handle both SAML and OpenID) as an IdP: |
|
How have they implemented it? Optimally it wouldn’t allow for full-access
(to prevent malicious activity).
…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:
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. |
|
@kylecarbs - sorry I accidentally commented and then deleted it haha. See my new comment.
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! :) |
|
I think project selection should be done after login via a seperate page, locking each vs code session to one project to work on at a time. |
|
@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). |
|
My concern is not one of trust, it's one of software security. For an optimal experience, i'd really like to see each terminal in it's own docker container, where you can select any docker image before running it. That would solve both security and the build/dev environment, and also is able to scale properly. |
nhooyr
added
enhancement
|
See how the jupyter team solved this: https://jupyter.org/hub |
|
I believe codesandbox io has this feature as well and it is open source. |
|
Be reminded we can try VS Live Share, which is available in the official extensions gallery, I think we can pull from there and support that atm |
|
I don't think it'll be "officially" supported because I don't believe there's a official way to obtain it. (But I do think it's a very good solution if you can get the .VSIX.) |
|
@sr229 - have you tried it? does it actually work? |
|
@PassTheMayo Great! haha. Thanks for letting me know that it doesn't work ;) |
|
@toddewilliams I don't want to derail the subject of this issue, but it's not clear to me from what you shared, that its not legal - it does states that "You may install and use any number of copies of the software to use solely with Microsoft Visual Studio family of products." |
Short answer: No, as it's not a product from Microsoft. Longer answer: Microsofts lists those products in their Terms of Use for their website, which I referenced in my prior link. And they also have this handy page for documentation for the "Microsoft Visual Studio Product Family". You can see the members of the product family are both well-known and quite precisely restricted to Microsoft products. |
|
It's pretty clear for me what the Visual Studio product family is, its just a little fuzzy for me when a product stops being Visual Studio Code (in this case, running in the browser), and starts being a "new" product that is no longer Visual Studio Code. |
|
Further explanation can be found on the Code-Server FAQ: And the link to codium includes more info:
|
|
Anyway, I tried it and it doesn't work, so we can forget it. Still looking forward to |
I'm in the exact same spot. Would really really like to see multi user support. Cloud9 is kinda dead, maybe, somewhat - underdeveloped and badly maintained under Amazon rule. |
|
This feature seemed to be getting a lot of traction and was really close to being solved by @rdbeach back in 2020:
My question is, is there any fundamental opposition from @toddewilliams or anyone else, or is it just a case of bad luck that this issue has been stalling for exactly 4 years? Yet @nhooyr seemed to show some interest at one point, if I followed correctly. |
|
@matbgn I'm responding since I was specifically mentioned.
Not only don't I have any opposition to this, I'm not even in a position to have any opposition. I don't contribute to code-server and am not an employee of Coder. I think all approaches to this issue are great! We (CodeTogether) developed our technology to enable cross-IDE collaboration between all the IDE's developers use (that are built on VS Code, Eclipse, or IntelliJ). As a result, it happens to work for code-server so I contributed to the documentation to make everyone aware that it was one solution to this issue. My other posts simply point out that since code-server is not a Microsoft product, that it is prohibited from using Microsoft's Live Share as a solution due the the license under which Live Share is published. So while I haven't looked at your project, I certainly applaud that you're trying to solve this issue as well and wish you nothing but success with it. |
|
On the Coder end our scope has shrunk to maintaining what is already there and keeping Code up to date so adding collaboration is likely not something we would drive at the moment. That said, as far as I know there is no fundamental opposition to collaboration. I do have some opposition to adding it directly to code-server though (rather than as an open-source extension, possibly extending the API if necessary) unless there is a compelling use-case that cannot be supported by extensions. |
|
How could the authentication system be enhanced from an extension ? |
|
I am not too familiar with VS Live Share but we could do authentication the same way they do, which I think is based on sending a link with a token in it. What sort of enhancements are you thinking about? |
Would that allow using VCS, plugins, etc. ?
Well, as the title says : multi user. |
I think Multiuser is a separate goal from collaboration. Maybe we can clarify what is requested.. Various collaborative editors - including VSCode live share - still have each user running their own local editor. They are simply connected together with one-off tokens and I imagine that could be achievable via plugin here too. Every user would be expected to have an editor (Code-Server instance) already. Meanwhile, multiuser I understand to be actually multi-tenant where one server would run multiple user's editors at the same time. If I understand that correctly then it's a more foundational task? But if you don't care about live collaboration, you could just run Code-Server multiple times and give each user their own instance. And then this hypothetical plugin could still be added to collaborate, once it exists |
|
Actually, I meant both : live collaboration using multiple users, which would be like Google Workspace but for code instead of office documents. Users have access to the same UI on which they log in and open files. What's so great about code-server is that everything happens server-side, opening this possibility. |
|
Good example of what people expect, I think, is like AWS Cloud9. We use it. It's like Google Docs but for code. Filesystem is shared between all users and I can see other colored cursors in my code while I edit. Even terminals are shared. Cloud9 base is opensource, or was, until AWS came ... they should be still available on Github. Why I'm looking at code-server and comment on this issue is that we'd like to break free from AWS :). They aren't that great company, but Cloud9 is still, the only software that does the thing that we all love in our company (true live single file collabration). |
|
Ahhhhhhhhhhh right I was too focused on the collaboration part and forgot about the single instance part. Yeah some patching directly to code-server would be necessary. 😞 I agree that multi-tenant can be considered separately from collaboration. Perhaps multi-tenant can be patched directly into code-server (possibly with some new API for plugins to manage authentication) then the collaboration part could be implemented in a plugin. |
|
Then what would happen when multiple users would open the same file simultaneously without using the plugin ? |
|
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. |
|
What guest instances ? |
|
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. |
|
@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. |
|
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. |
|
JupyterLab has real time collaboration using y.js, it would be nice if code server supported something similar. |
|
@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 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... |
|
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 |
|
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? |
and others
It's not documented whether multiple users can use one self hosted installation at once or not. Is this a supported use case?
The text was updated successfully, but these errors were encountered: