* Explicit button: outline it in blue to reflect that your camera is
currently blue. Solid red continues to mean your camera is red.
* Tweak the QR code opacity to be less obtrusive.
* Add a NoWatermark video flag so users can opt-out of the QR code being
shown over their webcam when others watch their video.
* The setting can be found in the Chat Settings 'Camera' tab, and must be
opted in (default is to protect cameras with watermarks).
* Update the About page and QR code info modal with instructions.
A user reported that they hear the 'Unwatch' sound effect play more
often than they should, including when his camera isn't even active.
Only the BareRTC unwatch command makes the page play that sound effect,
so some debug messages will post in the Debug Log channel to check if I
hear the sound effect.
* Adjust the animation settings on QR code videos, to be more translucent
most of the time but occasionally flash white and strong
* Alert Modal: Allow some alerts to be dismissed by clicking on the
background curtain, e.g. for the QR code explanation or the Close DMs
explanation.
* Add an admin /api/amend-jwt endpoint that allows your main website to post
an updated JWT token for a user who may already be logged into chat.
* It allows for updating a logged-in user's nickname, profile picture URL,
username, chat moderation rules, etc. without them needing to exit and
rejoin the chat room.
Add spam detection in case a user copy/pastes a hyperlink to everybody
on chat via their DMs:
* If the same link is copied to many different people within a time
window, the user can be kicked from the chat room with a warning.
* The server remembers rate limits by username, so if they log back in
and continue to spam the same links, they instead receive a temporary
chat ban.
* The spam threshold, time window and ban hours are configurable in the
BareRTC settings.toml.
Other fixes:
* The front-end will send a "me" update with its current status and
video setting in the 'onLoggedIn' handler. This should help alleviate
rough server reboots when a ton of idle users are online, so they
don't spam "me" updates to correct their status once the WhoLists
begin to roll in.
* 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.
* Move all WebRTC and webcam-related functionality from App.vue into an
external Vue mixin.
* Centralize the stand-alone functions videoIconClass and
videoButtonClass into the new WebRTC mixin, which is called by
WhoListRow and MessageBox.
MessageBox Improvements (Card Style):
* Rearrange the buttons by the username (Send DM, Mute, Takeback) by putting the
lesser used options into a drop-down overflow menu to make room for adding a
Video button, to easily see someone's webcam when they are broadcasting or to
see if you are already watching it.
* The visible buttons now are: Send DMs, Open Video, and Overflow.
* The Overflow menu contains: Mute, Takeback, Hide Message
* If the user is not on video, only DMs and Overflow buttons are shown.
* Spell out the word "Translate" on the Google Translate button, as a lot of
users were not aware of what that button did.
MessageBox Improvements (Compact style):
* The Video button is added in between the current Overflow Menu and Emojis
Other Improvements:
* On the MessageBox, when a user is offline, their display name will be crossed
out and their avatar image is turned to grayscale.
* On your DMs List: offline users will also have grayscale avatars.
On Chromium, if the DOM is updated during a dragenter event (e.g. to
display the drop zone div), the browser will immediately fire dragleave
as well which leads to a rapid flickering effect.
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.
In profile cards, show a prompt to regular users to remind a user to
mark their camera as Explicit, when the camera is blue and is currently
being watched by the current user.
Under the hood, this sends a 'react' message with a msgID of -451 and
the target's username as the react message. Updated chat pages will look
for this reaction and show a nice reminder in chat, if the user's camera
is blue and they have at least 2 watchers. Old page versions at
deployment time will simply ignore these react messages.
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.
For the broadcaster:
* Turning on the NonExplicit option will be mutually exclusive to the
Explicit option: the Explicit option is unset and the checkbox
disabled, and the Explicit button will not be usable while the
NonExplicit setting is active.
For watchers:
* Respect the NonExplicit setting of other cams you have open while your
own camera is marked as Explicit.
* The NonExplicit video button is \ out on the Who List and will present
an error message that they don't want your cam to be red when watching
theirs.
* When your cam toggles to become Explicit, close any videos you have
open with NonExplicit broadcasters.
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.
