* New API endpoint: /api/blocklist where your site can pre-deliver muted
username lists for users before they enter the chat.
* Image sharing in DMs is allowed if either party is an operator.
* Add a scrollback buffer option to the chat Settings to trim room history
so your browser can manage its memory usage
* Update the wording that ChatServer sends to users when the /nsfw command
has been used on them
* Fix the ordering of active DMs for Chromium browsers so the most recently
updated DM thread moves to the top of the list
* Show an indicator on videos whether the person you watch also watches
you back
* Fix the "X" button on the photo modal not functioning correctly
* When JWT tokens are used to join the chat and the username conflicts:
instead of renaming the new user to add a "2" it will disconnect the
original login (sending a message that they have signed in somewhere
else and are logged out now)
* When disconnected the text entry box will be greyed out.
* Improvements for the mobile user experience: if you're viewing the
chat history panel and have unread messages or DMs, a number indicator
appears on the channels button. It is grey for public channel messages
or red if any of them are DMs
* Fix the emoji picker drop-down on the first messages of a DM thread
* Consolidate all the Video flags (active, nsfw, mutual, mutualOpen)
into a bitmask flag (single integer)
* New video flag for when the source has muted their video, to show a
crossed out grey mic on their camera for other chatters
* Bugfixes around syncing the mute state for self and other videos when
videos are opened, closed and opened again
* Profile pictures on the DMs list
* Add a distinctly colored title and background for DM threads apart
from the public channels
* On the Who List, the profile picture is clickable to open profile
links
* Fix auto-scrolling issues: it won't autoscroll if the new message was
in a different channel, and when toggling between channels always
scroll back to the bottom of that channel
* The who list now sorts alphabetically instead of random
* New user controls when they share video:
* Require users to also be sharing before they open ours
* We auto-open a viewer's video when they open ours
* 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.
