* When an admin has marked your camera 'red' for you, the Explicit button at the
top of the page now will require *two* clicks if the user wants to set their
camera back to blue:
On first click, they will get a red ChatClient message explaining that their
cam was most-recently marked red due to a server action (such as a moderator
flagging their cam for them). If they really mean to mark their camera blue,
they are instructed to click it a second time to confirm.
* This behavior only occurs when the most recent NSFW setting was dictated by
the server (e.g. a 'me' event disagreed with the page's local NSFW setting).
The flag is cleared any time the user themself toggles the flag, or when the
first ChatClient warning after a server event is shown.
* The explicit camera settings in the broadcast modal have been rearranged and
reworded.
* Add an 'advanced' webcam feature to automatically broadcast in the future on
page load. The option is only available in the Chat Settings 'Camera' tab
after you are already broadcasting (or rather: when a list of video devices
have become available to the page, indicating the user has possibly granted
permission already).
Apparently some iPad browsers were having their local webcam freeze
after a window.confirm prompt was shown. This replaces all uses of
window.confirm/window.alert with an in-app modal.
* Add local detection for users who are broadcasting dark (e.g. mostly
or completely black) video feeds from their local device.
* Every 5 seconds while the webcam is active, the average RGB color is
sampled. If the average color value remains below 60 (out of 255) for
two consecutive samples, the camera is stopped automatically.
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.
* WebRTC functionality is now 100% working as intended for Safari and
iPad browsers!
* The legacy WebRTC API had properties like offerToReceiveVideo
available on createOffer(), to set up a receive-only channel, but the
modern WebRTC API had removed these and Safari only supports the
modern API.
* The modern solution for the same feature is to add a recvonly
transceiver to the connection in place of offering a local video/audio
stream to share.
* 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.
* Try a new strategy to get Apple (iPad/iPhone) webcams to connect.
* "Apple compatibility mode" setting: on by default if iPad/iPhone is
detected or can be opted into in the chat settings Misc tab.
* In Apple compat mode: when you open someone else's webcam, you always
attach your local video on the WebRTC offer. This would normally make
your video auto-open on the remote side, but the previous commit
updates the chat page to ignore offered video if you did not opt-in to
auto-open your viewer's camera.
* This should satisfy the two-way video call limitation in Safari: the
iPad always shares its video and gets video from the person they are
watching.
* If the person they are watching did not auto-open your video: they
ignore the attached video on your offer and don't display it.
* 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.
