Add moderation rules:
* You can apply rules in the settings.toml to enforce moderator restrictions on
certain users, e.g. to force their camera to always be NSFW or bar them from
sharing their webcam at all anymore.
Chat UI improvements around users blocking admin accounts:
* When a main website block is in place, the DMs button in the Who List shows
as greyed out with a cross through, as if that user had closed their DMs.
* Admin users are always able to watch the camera of people who have blocked
them. The broadcaster is not notified about the watch.
New operator commands:
* /cut username: to tell a user to turn off their webcam.
* /unmute-all: to lift all mutes on your side, e.g. so your moderator chatbot
can still see public messages from users who have blocked it.
* /help-advanced: moved the more dangerous admin command documentation here.
Miscellaneous fixes:
* The admin commands now tolerate an @ prefix in front of usernames.
* The /nsfw command won't fire unless the user's camera is actually active and
not marked as explicit.
* Add profile modal popups and Webhook support to get more detailed user
info from your website.
* Add "unboot" command, available in the profile modal.
Changes to the chat server:
* Blocking will not apply to admin user accounts (operators)
* Users who block an admin will instead mute them, but the admin can
still DM them if required
* Messages to VIP channels are broadcast to admins even if they are not
VIPs, e.g. so moderator chatbots can see
* On the Who List: VIP-only cameras to highlight with the VIP background
color on those buttons
* Deadlock detection: the chatbot handlers will spin off a background goroutine
to ping DMs at itself and test for responsiveness. If the echoes don't return
for a minute, issue a /api/shutdown command to the HTTP server to force a
reboot.
* New admin API endpoint: /api/shutdown, equivalent to the operator '/shutdown'
command sent in chat. Requires your AdminAPIKey to call it. Used by the chatbot
as part of deadlock detection.
* Adjust some uses of mutexes to hopefully mitigate deadlocks a bit.
* Do Not Disturb: if users opt to "Ignore unsolicited DMs" they will set a DND
status on the server which will grey-out their DM icon for other chatters.
* Bring back an option for ChatServer to notify you when somebody begins watching
your camera (on by default).
* Automatically focus the message entry box when changing channels.
* Lower webcam resolution hints to 480p to test performance implications.
* Added support for Webhooks and you can configure a Report Message hook
to let users report messages on chat.
* Add /reconfigure command to dynamically reload the server
settings.toml
* TODO: documentation for the webhooks.
* 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.
* 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
* 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).
* 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.
Noah