* Add a feature where a webcam broadcaster may manually invite others on
chat to watch, even if normally the other person would not be allowed.
For example, it will bypass the mutual webcam requirement setting and
allow the invited user to watch even if their own camera is not on.
* The button appears in Profile Modals and in the overflow menu on the
MessageBox component.
To help alleviate rocky chat server reboots, WhoList messages will be
withheld in the first 15 seconds from server start.
When a lot of chatters were online during a reboot (e.g. 50 or more),
they would all try and reconnect after 5 seconds and each login was
broadcasting Who List updates to everybody else logged in. With the
surge of logins in a short time, these WhoList messages would fill up
the buffers of each recipient, kicking them offline for being too slow
to keep up with messages; only for that recipient to reconnect again.
The average user may have experienced 2 or 3 disconnects when the chat
server reboots.
To help alleviate the spam of messages being sent out:
* Presence messages are withheld for the first 30 seconds ("has joined
the room" notifications)
* Now, WhoList messages are withheld for the first 15 seconds.
After 16 seconds of uptime, the server will send a WhoList to everybody
currently online to catch them up.
To accommodate this, the front-end will show a spinner and say "Waiting
for Who List..." when the page is connected but no WhoList has been
received yet. Under normal operation, this spinner won't be visible
beyond a brief moment as a WhoList is normally sent upon joining the
chat.
Instead of the pure Go implementation of SQLite, swap in the cgo library
from mattn/go-sqlite3. On local testing this cuts the SQL query times in
half for the History modal (from 400ms per page to 150ms) and may
improve performance in production.
The ORDER BY timestamp on the DMs Username History endpoint was causing
SQLite to do a full table scan by timestamp instead of indexing on
channel ID. So, instead, we fetch the distinct channel IDs for the
current user and add them to an IN clause on the main query (instead of
a LIKE clause), which causes the index to use the channel_id instead of
timestamp. This may improve CPU performance and speed on this endpoint.
Add a feature where recent public channel messages can be echoed back to
newly joining users when they enter the chat room.
* Configure in settings.toml with EchoMessagesOnJoin. 0 = disable storage.
* Messages are stored in RAM and lost on a server reboot.
* A buffer of recent public messages per channel can be kept, e.g. for the
10 most recent messages.
* The settings can be reloaded with /reconfigure and the message buffers
will rebalance on the next message sent.
* When a new user logs in, a new "echo" message is sent that contains all
of the echoed messages on a "messages" list, in one WebSocket packet.
* Echoed messages are put above the ChatServer welcome messages.
* If a message is taken back, it's removed from the echo message buffer.
Other Changes
* Don't broadcast Presence messages within 30 seconds of the server boot, to
lessen a flood of messages when a lot of users were connected at reboot.
* Change the default "Join messages" setting on front-end to hide them in
public channels.
* For the admin buttons in ProfileModal, use the AlertModal instead of native
browser prompts.
* On the /nsfw command, BareRTC will issue an admin report to your main website
so you have visibility into when this command is used.
* On the server side, fix the "Open" command so it will prevent webcams from
connecting if the offerer had been Booted by the answerer, in addition to the
previous blocks about Mute and Block. Admin users can still connect always.
* Add a debug command `/watch username` to manually open somebody's camera on
chat. Note: the chat server enforces the permission to actually do so.
* Remove the /debug-dangerous-force-deadlock admin command.
* Add a History button under the DMs where an authenticated JWT user can page
through the usernames they have stored history with, to bring up those DMs
even if their chat partner is not currently online.
* Try some fixes to the dark video detector to see if it reduces false
positives: wait for the canplaythrough video event to fire before beginning
the dark detection. Also, increase the threshold so dark frames need to be
seen 5 times in a row instead of twice before cutting the camera.
Some users had reported the dark video detector errors out on their
camera, reading a solid black image and average color of 0 despite their
camera actually being bright and colorful.
This case seems rare, but the nodvd moderation rule can lift the feature
for specific affected users while keeping it in place for everyone else.
When the Safari browser puts a webcam video full-screen and then
returns, the z-index of the video was higher than the buttons and
controls normally overlaid on top of it.
Add a z-index:1 to the video controls to keep them on top after
returning from full screen. Similar: for popped-out draggable videos,
adding a z-index:1 allows the video to correctly sit on top of docked
videos without the docked video controls (zi:1) rendering above the
popped-out video when you overlap them.
Note: the z-index:1 is applied to popped-out and video controls, any
other combination (e.g. 1 for popped-out and 2 for controls) caused
controls of docked videos to render on top of popped-out ones when they
overlapped.
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 support for storing DM history between users in a SQLite3 database.
* Opt-in by editing your settings.toml to set DirectMessageHistory/Enabled=true
* Retention days (default 90) will flush old DMs on app startup.
* On the front-end, DM history is checked when a DM thread is opened.
* The /ban command doesn't require the target user to be online at the
time of the ban.
* Update the presence messages so they will generally only go to the
primary (first) public channel, and also to another public channel if
the user is currently looking at one of the others.
* Re-set user's status if they disconnect and reconnect
* Remove "(offline)" text next to ChatServer/ChatClient messages
* Make names and pictures in presence messages clickable to open profile
cards
* Add profile modal popups and Webhook support to get more detailed user
info from your website.
* Add "unboot" command, available in the profile modal.
* In place of the Help and Settings buttons, add a hamburger menu
dropdown and place the links under there.
* Also in the dropdown is Close All Cameras and Mute All Cameras (if you
have any cams open; the links are hidden if not)
* Also in the dropdown add a Logout button that just links to a new
/logout route in order to unload the page and align with some users'
expectations (not knowing closing out of the chat page was enough to
log out of the room before)
* Bring back "(offline)" indicators when a user is no longer in the
room.
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
This commit makes an initial port of the front-end over to a proper Vue
CLI application. It seems to work from surface level testing.
Changes made:
* Rename web/static to public/static to place it into the Vue build path
* Notes: web/static/js/BareRTC.js and web/templates/chat.html are now
deprecated
* Rename web/static/js/sounds.js into src/lib/sounds.js making it a
proper JavaScript module with exports.
* Fill out initial src/App.vue by copying and updating
web/templates/chat.html and web/static/js/BareRTC.js into this module.
* 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.
