A place to return to
I built JanjaLive for friends who want to share a screen privately and return to the same group later. Rooms and membership persist; presence and streams do not.
That distinction shapes the experience: people can reopen an authorized room without treating every session as a completely new public broadcast.
Permissions before transmission
Discord provides sign-in. Room membership uses invitations or approval, and the product has no public directory of live streams.
The interface asks the user to select what to share. Screen capture, system audio and playback are different browser and platform capabilities, so the product does not promise universal support for all three.
Web and desktop, shared rules
The web and Windows clients use the same rooms and membership rules. WebRTC carries the media, while the backend handles identity, room permissions and the temporary signaling needed to connect participants.
The desktop adds its own source picker, room links and update flow. It remains subject to the same authorization boundaries rather than becoming an alternative route around them.
Designing for the real session
Resolution and frame rate are explicit choices. More than one member can transmit, and the viewer explicitly selects what to watch.
The work includes mobile player interactions and the browser-controlled capture flow. Those details affect whether people can use the product comfortably, not just whether a stream connects.
Web and Windows
I built web and Windows clients around the same room and membership rules. The current focus is Chromium on Windows, with source selection and sharing quality configured before each session.
