Pretty much anyone who has ever worked remotely knows it - today’s remote collaboration solutions provide much better screensharing quality and reliability (thanks, Zoom) compared to a few years ago. But it takes the same frustrating steps to connect and to pick windows again and again, only one user can share screens and remote control at a time, users have to ask for permissions to interact, etc.
By turning your secondary display into your team desktop, CoScreen enables you to share your windows with your peers in a single, natural interaction step by drag & drop. Any windows you drag to your extended screen are shared with your peers. They can share their windows in the same way, on the same desktop, side-by-side, at the same time. Each team member has an own mouse pointer and can interact with all windows without having to request controls. It also works great if you only have one screen and you can also chat with each other via audio.
CoScreen launched on Product Upcoming with a private beta a few months ago with over 300 sign-ups and early testers from small startups to large tech companies. Since today it is in public beta and you can use it for free by going to coscreen.co.
We can’t wait to hear what you think as it’s still an early beta version and while it’s still rough around the edges.
Till & the CoScreen team
Where as pretty much all Windows users in game dev seem to have 2 or more monitors.
Are you expecting lots of mac users to buy a second monitor or use an iPad for this second monitor or is my experience just atypical and lots of mac users have 2 monitors?
Over the last decade, I’ve worked in shops supporting Macs (as well as other OSes) along with other Mac-using developers and designers.
All my Mac-using colleagues have dual-or-higher monitor setups.
In any case, CoScreen also works great with just one screen and you can share/unshare with a single tap of a button.
I’m curious how you handle different monitor resolutions?
My team is split between people with 4k or even 5k screens and wide-angle screens with lower pixel densities, so this would be an issue. Not sure how common that is, though.
Here's a quick form for the many folks interested in Windows & Linux support, please help us prioritize:
UPDATE 2: As mentioned further below, we're also on Product Hunt today - check it out (and let's beat the boring marketing apps):
I used to have a big screen tv and 2 keyboards and wireless mice at a coffee table in my office for just this problem, and a crazy (for normal humans) hdmi splitting setup that allowed for a byod of sorts.
Also, I'd assume you use video compression; keep in mind that encrypted video still reveals some information through sizes, especially if you have some idea of the kinds of applications users typically use.
one way to do that would be the ability to minimize shared windows.
the teacher (or anyone with moderator privileges) would be allowed to minimize windows, but also have a way to look at windows while minimized (as a teacher i want to see what everyone is doing on their own windows, while at the same time get the students to focus on a particular window.)
Really? A Wordpress "Linkbuildr" that automates spamming emails when you write posts? And nothing but praise in the comments? PH has become a joke and we definitely need some ethical competition in the product discovery space.
But as a CTO, I would be concerned about the security implications.
It makes sense to route traffic via a central server because P2P does not scale to large numbers of participants (which is why things like the Jitsi Videobridge exist despite WebRTC P2P being a thing), but it means your customers have to trust you not to get hacked, be compelled to, or otherwise misplace/record sessions.
Since peers can interact with the remote windows, this is basically a remote control tool, and getting hacked also means being able to inject keystrokes or otherwise compromise clients (as recently demonstrated by TeamViewer). For security-critical things like SRE work this is a particularly big concern.
Adding end-to-end encryption would alleviate some of these concerns and reduce the attack surface to implementation mistakes or compromised software updates, which is far easier to reason about.
Perhaps it's not a concern for a small startup, but it's definitely something larger companies worry about.
Please add support for other platforms and add end-to-end encryption, because I really want to use this!
As suggested by someone else, we would definitely pre-order licenses for Linux and Windows.
Is there some path I didn't know about?
If I drag an app that has an integrated terminal (e.g., VS Code), could one of my teammates start rooting around in my filesystem?
It wouldn't be too hard to use Slack status to determine a time to do this when the other people sharing are not online/not watching.
I'm curious about this statement. Intuitively it seems there is already an algorithm to near-optimally distribute updates to a sparsely connected mesh network. You'd want two or three connections from each peer to another, not N:N. Optimal is not necessary as long as you have at-least-once semantics on message delivery; a node can just ignore messages it's seen already, as long as it's not too often. Is there a name for this existing algorithm?
On top of that you could overlay a symmetric session key and you'd have full E2E. Then central server would be session initiation only--which could still do authn/z to hand out session keys--and billing/metrics.
And I wouldn't pay too much attention to the Windows/Linux users in the very early days if it's too much of a development burden. There are tons of tech forward companies that are mac-only that are a large enough market to build momentum.
If the windows/linux people want it make them put their money where their mouth is and charge them in some way. It costs nothing for them to say "Build this for me!" but they already have enough info from the demos and mac app to make a purchasing decision. So if they're serious get some money from them. If you do a pre-order and say "if it's not released in 3 months you get your money back" that should be enough signal to know if they really want it or not.
Congrats! Not many people make something this good. Now don't screw it up :)
And if you're not part of YC already you should do a late application for the W20 batch.
on my computer i select the windows i want to share. each of those windows could be sent in a separate stream to the remote machines. and likewise my computer could receive independent streams of multiple windows. this way i could arrange all windows as i see fit.
the alternative is that the app takes over a full screen and the shared windows are rendered within it. then the app is responsible for window placement and can implement its own way to arrange windows as it sees fit, and share that location with its peers. a window manager within a window manager, of sorts. something that many windows applications like photoshop already do. linux/unix could do that with Xnest already more than 30 years ago. nowadays there is also xpra, which can mirror windows across multiple screens. i don't know about wayland, but i believe it should be possible there too.
But I've been thinking about it for the last five minutes and I cannot figure out how you guys actually managed to implement this. What sorcery is at the root of this? How do you composite windows from two different machines into a single desktop on macOS?
How does it work with selecting text and copy-pasting? In the Sublime Text example, can Bob overwrite Alice's clipboard.
Also: this would be a major feature request from me. The ability for me to paste code into someone's else text editor (or copy out an error message) when I'm helping them would be a major productivity boost.
A similar but much more low-key solution that I love using is tmate. Tmate is a tmux session that can be shared over SSH. It's super easy to install and anyone who has a SSH client can join in two seconds. It's great for pairing sessions if both developers are into vim or emacs editors. Or just to show a quick thing.
Our security concept was recently approved after an extensive vendor risk assessment by a large global enterprise. This is a positive indication but obviously don't hesitate to drop us a mail if you want to discuss specific requirements!
This is mostly harmless in my solo environment, although one does have to be careful about things like .bash_history and websites that might actually be listening for keystrokes and sending them upstream. Having a team window seems like it would make this a greater risk.
On a different topic, I'm one of those people that can't stand pair programming and related--it destroys my ability to concentrate deeply on the problem in front of me.
The best video you can show for this is your JIRA board where everyone can update it in realtime in a team meeting with remote teams.
Don't bother with the animations, they make your product look not real! Very impressive.
A lot of browsers disable audio on auto play videos. The fact that the controls are also hidden and the background color being the same as the website, it just looks like an animation, not a video. So some icons move but the meat of the video doesn’t start until after people will have disengaged.
But we're on windows.
Get that pre-order form online already! ;)
It leaves me with very little confidence that the Zoom client for Windows doesn't have some gaping undiscovered vulnerability in it.
Dropping Zoom based on their security mistake would make sense if one of two things was true:
1. The vulnerability was introduced intentionally
2. The vulnerability was introduced due to a persistent culture of negligence
I have seen no evidence that either of those are the case. Someone at Zoom made a mistake. Granted, it was a big mistake. I've made a few of those in my career too.
(It's actually meant to help us prioritize, thanks in advance for your feedback!)
(Incidentally the issue hopefully only affects Mac/Safari users while the survey is focused on non-Mac users anyway)
Please fill it out and you'll hear from us!
also no hint the company is even interested in windows...?
UPDATE: yes, in their https://www.coscreen.co/feedback they ask about windows support...
For the next update please explain things before hand in your page!
Fwiw, doing a 3D "desktop" on linux a year ago, I was pleasantly surprised by electron's desktopCapturer for visuals. But multi-source input... X was ok-ish, Wayland not.
Also thanks for the hint, we'll use it as a starting point for Linux
I want to be able to open up my IDE, go full screen with it, and have zero overlays visible.
The only tool I've been able to find that lets me do this is Tuple (tuple.app), which is the closest thing I've found to Screenhero (which was my favorite screen sharing and pair programming app back in the day).
If I could make a tiny suggestion: Why not hide the coscreen functionality under a little system tray icon with a pop-out menu? That way, it's invisible, but still easy to get to.
A bit of feedback on your website: the yellow you've chosen is nearly impossible to read on my monitor, especially with the thin font used in "Sign up".
95% isn't 100%. A mere assemblage of tools isn't a finished, polished, well-designed, reliable product.
Obviously we'd love this to be as legendary in 12 years from now ;)
My impression is that the product hasn’t been built yet or is even ready for beta. Is this another one of those ‘MVP’ landing pages that fools the consumer into believing there is a product to gather reception?
=> Gets you to the download page, download the DMG, launch the app, collaborate...
I've got plenty of stuff I'd be happy to share with other people to let them look, but I don't want them messing things up.
I'd be fine allowing them write access on a per-user/per-window basis, but I'd like to default to read-only.
Still definitely useful! Just trying to learn the limitations.
This is awesome by the way, I'll definitely be checking it out!
What makes it different from (or better than) free versions of Zoom or Webex Teams?
On security, when you say encrypted in realtime, does this mean client-side encryption? Is the server trusted?
But here's the part of the video that shows the app (note: Linux & Windows isn't released yet, but you can see exactly how it works for an individual user)
Is it because:
1) Authors don't know the demographics?
2) They think that Windows users wouldn't pay? (Not true I think)
or some other reason?
The reasons where:
1. Our personal devices were Macs at the time we started.
2. We felt that the first use case for CoScreen would be agile developers who collaborate with UX designers. The latter seemed to mainly use Macs (https://austinknight.com/writing/designers-prefer-macs) while the former are mixed e.g. also depending on the region. In the SF Bay Area Macs quite popular among developers so we ran with it.
In any case, we hope to be able to support all 3 OSes soon. For that reason CoScreen was built 95% in a platform-agnostic way (nwjs) so we're optimistic.
I would’ve thought that’s too much for typical (laptop) cpus but have to admit I never tried this
The way I understand you, coscreen captures each window shown individually.
Doesn’t that also mean that overlapping windows are captured in full? I can’t try it out atm so perhaps if you could leave a comment on cpu usage for encoding as well as bandwidth (upload) compared to a typical Screen Sharing solution with a single screen that would be great.
I’ve been toying with the idea of getting a MacBook with cores > 4 for precisely that idea: capturing every single window, streaming them out to a separate machine for analysis of what’s happening in them and possibly making them accessible for collaboration as well, all without losing too much performance
I believe somewhere in this area is a lot of productivity waiting to be unlocked with better tools, not just for typical remote use cases but for any kind of office work
"Windows is used way more than [Macintosh] on developer machines."
- Citation needed. Macs are extremely popular among web developers, and are required for iOS developers, both pretty major categories of "developer".
Edit: + Stats from the Stack Overflow Developer Survey