About J8

Why J8 exists

J8 is a browser-based place for people to meet, talk, and share live conversations across distances. It brings video, audio, and text chat together in a straightforward interface for desktop and mobile devices.

The platform is designed around password-protected rooms, with a host managing who can speak while other participants watch and use text chat.

How to use J8

1. Create a room. Choose a room name and a password. Save the separate private host link securely.
2. Invite participants. Share the ordinary room link and its password. Do not share the private host link with viewers.
3. Join the conversation. Enter the room password and click Join. Viewers do not need to enable a camera or microphone.
4. Manage speakers. Enter through the private host link to assign speaker places. Assigned speakers choose when to start their camera and microphone.
5. Stay in control. Use the camera, microphone, sound, text-chat, and Leave controls. Headphones help prevent audio feedback.

Public accounts provide Login, Sign up, and My page. Account login does not replace a room password or grant host privileges.

Current conference settings

Rooms are configured for up to 24 participants, with at most eight assigned camera/microphone publishers. Other participants can watch, listen, and use text chat.

The video target is 240p at up to 15 frames per second. Adaptive subscriptions and lower-resolution video layers help reduce traffic when appropriate. Actual quality depends on each device, network conditions, and available server bandwidth.

J8 remains in beta. The configured limits are not a guarantee of full-room performance; larger conferences still require capacity testing.

Technologies behind J8

• HTML and CSS: page structure, dark styling, and responsive layouts.
• JavaScript and the LiveKit browser SDK: call controls, participant updates, media playback, and live text chat.
• Python and Django: accounts, room creation, password checks, host authorization, and server-issued conference permissions.
• PostgreSQL: persistent account, room, and authorization records.
• Redis: request-rate limiting and supporting application infrastructure.
• Self-hosted LiveKit: WebRTC audio/video distribution through a selective forwarding unit, or SFU.
• TURN: a relay fallback when a participant's network prevents direct connectivity to the media server.
• Nginx, Gunicorn, and systemd: HTTPS delivery, Django application serving, and background-service management.

The application uses Django-rendered pages and browser JavaScript. It does not require React, Vue, Angular, or a Node.js application backend.

How a call works

Django first checks room access and issues a room-specific LiveKit token. Participants initially receive viewer permissions. Host actions pass through Django, which checks authorization before asking LiveKit to change speaker permissions.

A speaker publishes audio and video to LiveKit. The SFU forwards subscribed media to other participants, so the speaker does not need a separate upload for every viewer. This is an SFU architecture, not peer-to-peer mesh.

HTTPS protects web requests, and WebRTC encrypts media in transit. This deployment should not be described as end-to-end encrypted between participants.

Room safety

Keep private host links secret: possession of a valid link grants host access. Administrators can replace host links and reset room passwords.

A background authorization guard periodically removes connections whose room grants have expired or changed. Removal is not instantaneous and depends on the guard and media services being available.

The current interface provides live text chat without a saved chat-history feature.