Another use case if when you have a long-running meeting, and still need to share. I found I sometimes just do not sit and listen for those 1-2 hours meetings, but prefer to code.
And for those of us who just don't like audio, like myself. I have many students who I am willing to help, but I don't wanna get audio-involved. My voice chat is not a very parallelable resource.
What could be going on when you're not home?
If this is meant as a security tool, the fact you have to look at it is a non-starter.
If this is meant as anything else, why wouldn't you use VNC?
I've been wanting to create something WebRTC based, I'm not happy with either VNC or RDP.
On Linux, I've used both kinds of VNC server. One does start a new X instance, while the other one shares your main X instance. At the time I tried it, it was "TightVNCServer" to get a new X instance, and "X11vnc" to share the existing session.
Couple it with novnc if you want it in the web browser. Currently WebSockets but WebCodecs support looks to be around the corner[1].
> Terrible product design.
Which "product" are you even talking about here? VNC is a protocol with several different implementations.
On what, your primary desktop?
Maybe you are just a bit Windows-centric but I would guess many of us run virtual desktops and/or other means of remote access such as ssh.
For general monitoring, maybe have a look at state of the art solutions, like https://prometheus.io/
Doesn't this require leaving the computer unlocked?
> 1fps.video is perfect for introverts and remote workers who prefer sharing their screen without the pressure of audio or video calls. It's a versatile solution that works alongside any team chat application you're already using.
It seems closer to "text chat while sending screenshots" than "share screen in a voice call." I can see why some would prefer this.
It seems like it would be better to just send a screenshot and then discuss, so the other person doesn't have to watch you typing messages to them instead of looking at the actual thing you want to share.
> we use WebSocket-based cursor tracking, providing smooth, near 30 FPS pointer movement for precise demonstrations.
This part does not seem to support that use case, you don't need 30 FPS pointer tracking for text chat.. Moreover, it'd be actively bad, as the cursor is likely to be pointing to the text chat window.