* Track the window focus/blur events. Leaving the tab while in a channel
now means you may still hear sound effects in that channel.
* Add a CORS JSON API /v1/statistics to get details from the server
about who is online. The CORSHosts whitelist in the settings.toml
limits domain access to the endpoint.
* Added a top panel to put your video controls in.
* Broadcaster can mute or unmute their own audio input.
* When viewing others' cams, buttons appear to control their video:
* Their username is displayed in the corner.
* Mute/unmute button to silence their audio.
* "X" button to close their camera.
* Button to show what viewers are currently watching your camera.
* Add an "About" page and config for app branding.
* Add dark theme CSS for prefers-dark browsers.
* Add support for JWT tokens to authenticate users from your external app.
* JWT backed users can have profile pictures, profile URLs, and operator
status (admin). Note that no operator features exist yet.
* Add WelcomeMessages to settings.toml for default ChatServer messages to
write to each public channel directed at a new user logging in.
* Markdown support for chat messages!
* Add configuration system and default public channels support
* Add support for multiple channels and DM threads with users,
with unread badge indicators. DMs rearrange themselves by
most recently updated on top.
* Responsive CSS to work well on mobile devices.
* Two users can activate their cameras locally and then connect them together
with WebRTC with video and audio support working!
* Limitation: users need to be broadcasting video themselves before they can
connect to someone's camera. If the offerer doesn't add tracks of their own,
the SDP offer doesn't request video channels; so even though the answerer
adds their tracks to the connection, they aren't used by the offerer.
* As currently implemented, the offerer's camera feed will also appear on
screen for the answerer - every video connection opens the feed both ways.
Compared to the previous commit (where clients shared SDP messages but not
ICE candidates or anything further) the fixes and learnings were:
* The back-end was trying to relay candidate messages, but there was a JSON
marshalling error (json object casted into a string) - changed the Message
type to map[string]interface{} and both sides could exchange ICE candidates.
* Both sides needed to add their video tracks to the connection so that there
was anything of value to be sent over the WebRTC channel.
Other changes:
* Server will send a ping message every minute to connected WebSockets.
* WebRTC pees exchange local/remote descriptions ("offer" and "answer")
* They don't seem to exchange ICE candidates yet
* Some back and forth happens but the final WebRTC stream connection
isn't established yet.
* Reworked full screen CSS layout for the chat.html, still using Bulma
components with some custom CSS Grid.
* Duplicate username handling: server can push a new username to change
the client's selection.
* Who List sync between clients.
* Local video casting works so far - plays back your camera in the local
feed. Your video broadcasting boolean is synced to backend, which
lights up the video button in the Who List.
Noah