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.
https://github.com/karhuton/bluescreen
Runs on Hetzner EU currently.
Maybe I should open source it.
While we're on the subject of WebRTC, if anyone would need MIDI over WebRTC, here is my take on 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.
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.
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.
It’s decentralized, serverless, anonymous, private, ephemeral, and open source.
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)
Similar to https://pin.gl/
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.
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.
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.
You state it uses PeerJS. And indeed, the code calls from PeerJS,
const peer = new Peer();
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;
… so it sure looks to me like it is using a TURN server…
> Application error: a client-side exception has occurred (see the browser console for more information).