Did a quick test on Demo site. It works like a charm.
One issue: when I stopped sharing, my audience (my another computer) can still see my shared screen (I assume the last frame), what I think it shouldn't. And there is no indication or whatsoever that I have stopped sharing.
The afore mentioned webapp is based on WebRTC so, not totally unrelated.
I have nothing to advertise as I have nothing to gain from this. I just wanted to offer additional solution for people that might find it useful.
Also, judging by the other comments, it seems that someone did find it useful.
Furthermore, reading through other comments on this thread, there are a lot of other WebRTC projects mentions anyway, and many of them have nothing to do with screen sharing.
Slightly off-topic, but I’ve been searching for a long time for something like this, but for text chat: go to a website; create a room; share a code/link with others; people join and chat; then at some point in the future the room simply disappears (you can save a log if you want). Ideally anonymous with the best possible cryptographic implementation.
Has anyone stumbled upon something similar? I hate having to register and login to every chat platform, especially bloated ones like Discord and Slack. The closest one to what I want is gitter but it requires a GitHub signin.
I think https://call.element.io/ works like that. Calls are encrypted and the client includes screen sharing and all the standard video conferencing features.
Jitsi Meet is also a classic example of this, though these days it requires at least one logged-in "moderator" user to work.
click create space -> choose proceed as anonymous -> In your space, use chat or other apps.
It's end to end encrypted (using the hash-frag in url as key, AES-128 bit GCM)
The reason why this doesn't usually exist is because anonymous text sharing is almost immediately taken over by people using it to do crimes. So be aware of that.
Just deployed a new feature, audio can also be shared now! But it's only supported in Chrome and Edge, and users must select the option to share a tab. It won't work for sharing a window or whole screen.
I'm not sure, but is it possible to make it work on Android? I've tried on my pixel 7a, it gave me the code, I pasted it in another device in Safari, but it was only Loading... on the button.
Gave it a quick run! Works great. The notification to share your screen goes away quickly. Is there any way to get back to it? I generated a new code to fire the notification again.
If you can get remote control to work that would be amazing. I assume that's impossible with current browser APIs though. A real pain point of Google Meet.
I too yearn for the day where my parents webbrowser can run Win+R and delete their System32 directory after they clicked "Ok" on a prompt whose message they wouldn't be able to tell me if I paid them a billion Euros for it.
The problem with doing it via downloads or plugins is that it's OS and maybe browser specific (have fun making your plugin for Firefox on Windows, Chrome on Mac, etc.), and also it's extra friction.
The reason I want to remote control someone's computer is because talking them through the actions is too tedious. The last thing I want to do is talk them through downloading and installing some browser plugin first.
Security & scamming is obviously a concern but let's not pretend it is impossible to solve. People thought the full screen API shouldn't be done because of security concerns, but that's laughable now.
As an initial step they could at least support showing a "laser pointer" on other people's screens so you can say "click here" instead of "up a bit, no... go back.. no third from the bottom, yeah that one". That has zero security implications.
My 'dumb reductionist take' is me trying to tease out (with a little bit of humor) how you imagine this absolute security nightmare to be implemented in a way that wouldn't result in abuse of apocalyptic proportions. I mean maybe you had something ingenious in mind here, but then I'd like to hear it in detail instead of handweaving and arguing "there are other bad things so let's make it worse by 10 magnitudes".
So now without the humor: How would you design the system to prevent abuse, remote code execution and such? Because if that part isn't clear that idea should probably be shelved.
I would probably do it the same way any other dangerous operations are protected: make people type confirmation in (e.g. how you delete repos on GitHub), require you to manually add websites to a whitelist (e.g. how screen sharing for apps already works on Mac, or how some permissions work on Android). You can use heuristics to provide a more onerous confirmation for suspicious sites, exactly how running executables works on Windows.
Other security measures you could do:
1. Throttle events to the speed that a human could do them, so you can't instantly open a terminal and paste code in.
2. Require additional confirmation to sent events to specific applications, like the terminal, or explorer or whatever.
3. Only allow control of apps that are already open. That would be better than nothing.
There are probably other things I haven't thought of.
Anyway the point is the danger is only two clicks away already. This isn't a risk that isn't already there, it just makes the tech less annoying.
Are you talking about in components/ui? If so that's ShadCN and it works by fetching components and copy/pasting them into your project rather than trying to continue to keep the components up to date.
I.e., it constructs a PeerJS Peer without manually specifying PeerOptions. That class, in turn, states,
/**
* Configuration hash passed to RTCPeerConnection.
* This hash contains any custom ICE/TURN server configuration.
*
* Defaults to {@apilink util.defaultConfig}
*/
config?: any;
Sorry for the misleading wording, I was trying to say that I'm not paying for any TURN servers. You are totally right, PeerJS is still using TURN server under the hood. Thanks for pointing that out!
I guess you visited the page right after a new deployment. This happens sometimes due to a version mismatch in Next.js after deployment. Refreshing the page should fix it!
Did a quick test on Demo site. It works like a charm.
One issue: when I stopped sharing, my audience (my another computer) can still see my shared screen (I assume the last frame), what I think it shouldn't. And there is no indication or whatsoever that I have stopped sharing.
Thanks for the feedback! I’ll check out the issue. It still has a lot to improve!
Great! Thanks.
While we're on the subject of WebRTC, if anyone would need MIDI over WebRTC, here is my take on it:
https://github.com/AtmanActive/webmidi-rtc-transport
Perfect timing! Seems to suit (some of) my needs, thanks. And +1 for mentioning sonobus - that's a lot of fun, too.
Browser-based screen sharing is the subject. Is it normal to advertise unrelated projects in HN comments?
I don't know. Is it?
The afore mentioned webapp is based on WebRTC so, not totally unrelated.
I have nothing to advertise as I have nothing to gain from this. I just wanted to offer additional solution for people that might find it useful.
Also, judging by the other comments, it seems that someone did find it useful.
Furthermore, reading through other comments on this thread, there are a lot of other WebRTC projects mentions anyway, and many of them have nothing to do with screen sharing.
Similar tool I like and used to self-host for personal use: https://screego.net/#/
What I love about developing with cursor et al is it forces devs to keep the app simple.
No custom UI bloat when shadcn will do; no feature creep when the outline is fulfilled.
Simple apps < 30,000 LOC means cursor can keep the code base in the context window, so its generations stay high quality.
[dead]
Slightly off-topic, but I’ve been searching for a long time for something like this, but for text chat: go to a website; create a room; share a code/link with others; people join and chat; then at some point in the future the room simply disappears (you can save a log if you want). Ideally anonymous with the best possible cryptographic implementation.
Has anyone stumbled upon something similar? I hate having to register and login to every chat platform, especially bloated ones like Discord and Slack. The closest one to what I want is gitter but it requires a GitHub signin.
I built exactly what you’re describing: https://chitchatter.im/
It’s decentralized, serverless, anonymous, private, ephemeral, and open source.
Looks great, will try!
Awesome, thanks for checking it out! Let me know what you think. :)
I think https://call.element.io/ works like that. Calls are encrypted and the client includes screen sharing and all the standard video conferencing features.
Jitsi Meet is also a classic example of this, though these days it requires at least one logged-in "moderator" user to work.
Something like this? https://offrecord.ca/#lobby
Mine is a work in progress, but chat should work just fine. Let me know if you have any questions/concerns.
https://oorja.io/
click create space -> choose proceed as anonymous -> In your space, use chat or other apps. It's end to end encrypted (using the hash-frag in url as key, AES-128 bit GCM)
You could easily build one using Yjs [1]. I'm using it for my work together website [2] (it has a chat).
[1] https://github.com/yjs/yjs
[2] https://juntos.pages.dev/
The reason why this doesn't usually exist is because anonymous text sharing is almost immediately taken over by people using it to do crimes. So be aware of that.
Jitsi Meet?
Do some Phoenix tutorials and you have your own.
This is quite similar to https://screensharing.net. Works like magic. Thanks for sharing!
Nice work.
Similar to https://pin.gl/
Just deployed a new feature, audio can also be shared now! But it's only supported in Chrome and Edge, and users must select the option to share a tab. It won't work for sharing a window or whole screen.
I'm not sure, but is it possible to make it work on Android? I've tried on my pixel 7a, it gave me the code, I pasted it in another device in Safari, but it was only Loading... on the button.
Yeah, it's not working that well on phones right now, working on it...
Gave it a quick run! Works great. The notification to share your screen goes away quickly. Is there any way to get back to it? I generated a new code to fire the notification again.
I just fixed that, the share button should stay forever now until you click it.
If you can get remote control to work that would be amazing. I assume that's impossible with current browser APIs though. A real pain point of Google Meet.
I too yearn for the day where my parents webbrowser can run Win+R and delete their System32 directory after they clicked "Ok" on a prompt whose message they wouldn't be able to tell me if I paid them a billion Euros for it.
It can already do that. The prompt just says "Click here to download".
So you say we need a easily accessible RCE-API to make this even simpler?
I will ignore your dumb reductionist take...
The problem with doing it via downloads or plugins is that it's OS and maybe browser specific (have fun making your plugin for Firefox on Windows, Chrome on Mac, etc.), and also it's extra friction.
The reason I want to remote control someone's computer is because talking them through the actions is too tedious. The last thing I want to do is talk them through downloading and installing some browser plugin first.
Security & scamming is obviously a concern but let's not pretend it is impossible to solve. People thought the full screen API shouldn't be done because of security concerns, but that's laughable now.
As an initial step they could at least support showing a "laser pointer" on other people's screens so you can say "click here" instead of "up a bit, no... go back.. no third from the bottom, yeah that one". That has zero security implications.
My 'dumb reductionist take' is me trying to tease out (with a little bit of humor) how you imagine this absolute security nightmare to be implemented in a way that wouldn't result in abuse of apocalyptic proportions. I mean maybe you had something ingenious in mind here, but then I'd like to hear it in detail instead of handweaving and arguing "there are other bad things so let's make it worse by 10 magnitudes".
So now without the humor: How would you design the system to prevent abuse, remote code execution and such? Because if that part isn't clear that idea should probably be shelved.
I would probably do it the same way any other dangerous operations are protected: make people type confirmation in (e.g. how you delete repos on GitHub), require you to manually add websites to a whitelist (e.g. how screen sharing for apps already works on Mac, or how some permissions work on Android). You can use heuristics to provide a more onerous confirmation for suspicious sites, exactly how running executables works on Windows.
Other security measures you could do:
1. Throttle events to the speed that a human could do them, so you can't instantly open a terminal and paste code in.
2. Require additional confirmation to sent events to specific applications, like the terminal, or explorer or whatever.
3. Only allow control of apps that are already open. That would be better than nothing.
There are probably other things I haven't thought of.
Anyway the point is the danger is only two clicks away already. This isn't a risk that isn't already there, it just makes the tech less annoying.
Thank you, that sounds somewhat reasonable, but I am still not entirely convinced that the added attack surface is really worth it..
why the source have an accordion and carousel component? :)
Are you talking about in components/ui? If so that's ShadCN and it works by fetching components and copy/pasting them into your project rather than trying to continue to keep the components up to date.
don't know why Bolt.new downloaded all the shadcn components for me lol
Does this share your screen across domains? If so, how?
No, it doesn't share across domains.
Would be great if I could share a URL to the room, instead of a room code.
Thanks for the idea! I just made that feature!
Doesn't work on Linux?
It should work, is it not working for you?
Awesome demo! Are you paying for the TURN server?
No, it's not using TURN server now.
> No, it's not using TURN server now.
You state it uses PeerJS. And indeed, the code calls from PeerJS,
(https://github.com/tonghohin/screen-sharing/blob/18f6ab93716...)I.e., it constructs a PeerJS Peer without manually specifying PeerOptions. That class, in turn, states,
Since we're not overriding it, we take the default. And `defaultConfig` leads us to: https://github.com/peers/peerjs/blob/c073252f879b57757f8a82d... which lists STUN & TURN servers.… so it sure looks to me like it is using a TURN server…
Sorry for the misleading wording, I was trying to say that I'm not paying for any TURN servers. You are totally right, PeerJS is still using TURN server under the hood. Thanks for pointing that out!
Immediately upon loading the homepage:
> Application error: a client-side exception has occurred (see the browser console for more information).
I guess you visited the page right after a new deployment. This happens sometimes due to a version mismatch in Next.js after deployment. Refreshing the page should fix it!
It works great!! I Like it!
-
For mobile I find google meet the best, I think even Whatsapp is now allowing to screen share.
wow, I didn't know this was possible
[dead]
[dead]