* 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.
* Fix a bug on iPads in landscape mode where the screen width is 1024px.
Previously, they would fall into a weird mode in between mobile and
desktop, where the chat panels are mobile-style (one panel instead of
three) but the navigation buttons normally shown on mobile were not
appearing, making the app impossible to navigate.
* Add a Working Out status option.
Make some improvements to the mobile web layout:
* The Who List button now will always be on the top right corner of conversation
threads, including when you are in a DM. This makes navigating easier as you
don't need to leave your DM and return to a public channel before being able
to access the Who List.
* In the top panel for DM threads, remove the Profile and Close buttons. Instead,
the Close button will be on the DM itself on the Channels list.
* When you are in a DM thread, and your chat partner is on camera, their camera
button will appear in the title bar for easy access and visibility.
* In a DM thread, clicking the username in the chat title bar will open their
profile card.
* Ignore HTML tags in the message so we don't sometimes false-positive
based on the base64-encoded image data shared in chat.
* Remove 'session' from the messenger list, it is a more obscure
messenger and source of too many false positives.
The Bug:
* The dark video detector on chat sometimes triggered false positives,
and it would read a solid black screenshot from the user's camera.
* My personal repro steps would be: if I plug my USB webcam in after
Firefox has already opened, the dark video detector would misfire and
get a black image every time. But if I restart Firefox after the
webcam is plugged in, it would work correctly and read screenshots off
the camera fine.
* A couple other users ran into the false positive too, where rebooting
their browser didn't work; it seemed either some webcam models or some
security setting on their device may have been related.
Through Some Experimenting:
* I found a demo page online which screenshots your camera into a Canvas
the exact same way I was doing, and it worked during the conditions
where BareRTC would have gotten a solid black screenshot.
* Previously, BareRTC was creating the Canvas dynamically by calling
document.createElement("canvas") and the Canvas wasn't added to the
web page DOM.
* So I added a <canvas id="darkVideoDetector"> to the DOM and used that
instead of creating a dynamic one.
* If the Canvas on the page were "visible" to the user, it would
successfully screenshot my webcam into it and read it back out. But if
the Canvas were "invisible", it would return a solid black image the
same as the dynamically created Canvas would.
* By "invisible" I mean: if the Canvas or its container had any CSS on
it such as display:none, visibility:hidden, opacity:0, or a
width/height of 0px, then the Canvas would not screenshot the webcam
and get a black image back.
* Note: even a low opacity setting like 0.1 would count the Canvas as
being "visible" and it would work correctly.
The Fix:
* A <canvas> tag is added to the page and is wrapped in a <div> which is
1x1 pixel in size and anchored to the bottom-right of the page,
thereby making the canvas "visible" and able to screenshot the webcam.
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.
Update the Ban button shown to admins in the Profile Modal:
* Now displays a modal for the admin to enter a reason and select the
duration (1-96 hours).
* Along with the ban, the reason is posted to your main website as an
admin report so you can log which chat admin banned which user and the
reason given.
* Set 640x480 as the ideal constraint for most users.
* But if their webcam physically can't output that resolution, allow
them to choose the nearest up to 1280x720.
