* Users can now boot viewers off their camera. From the viewer's POV the
booter has just turned off their camera and it will remain "off" for
the remainder of the booter's session.
* Users can now mute one another: if you mute a user, you will no longer
see that user's messages or DMs; and the muted user will never see
your video as being active (like a boot but revokable if you unmute
later).
* 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