OSC Developers - How to avoid abuse?

Hey OSC developers, I’ve got a question for you.

Many recent discussions have occurred regarding excessively large or persistent chatboxes. Things that advertise currently playing song names, current time, and other information are being used by some people, and some others don’t like it.

One problem that’s on us to solve is to implement a chatbox mute button, which would separate the chatbox mute away from voice. This is something we want to do, it’s just a matter of time.

I’ve had a few thoughts about finding ways to discourage the use of the chatbox for these types of things, since, in my mind, the chatbox is a communication and accessibility tool. However, the use cases that people are using these statuses for are, admittedly, kinda cool. The problem is that it’s just all up in your face, and as of right now, not hidable unless you want to mute someone. (again, we’ll get to it :sweat_smile: )

I’m interested in discussing ideas, pitches, or other features that might help here!

A few rules to the discussion:

  • All ideas are OK to pitch, even if you think have obvious flaws.
  • All feedback should be constructive. If your post just says “this idea is bad”, reconsider posting.
  • Not all ideas need feedback. Just get it out of your head. We’re not voting for favorites here, I’m farming ideas. Cultivate!
  • Don’t place blame. The use case exists, but the “pressure” it is putting on the chatbox is because there’s nowhere else for the flow to go. Let’s find a solution that makes people happy.

I’ll start!

Require Messages to have X difference

There’s this metric called the Levenshtein distance that tells you how different two strings are from each other. We could require that repeated messages have some minimum Levenshtein distance in order for them to refresh the Chatbox’s duration.

Improve the User Status field

We already have a user status – what if we made it better and faster-reacting? Would people use that instead for showing off what songs they’re playing?

Provide an avatar component

What if we made an avatar component that you could send text to? A little digital watch that I could push a button on to pop up a holo-display of my current song would be cool and unobtrusive.

1 Like

Interesting. I’m not an OSC developer but I just read these docs OSC Overview.

My first question is this really a problem? I’ve not seen this but let’s say they display the name of a song in a Chatbox. Is that more or less annoying that jumping on another player or shouting something rude every few minutes? Doesn’t one typically just block rudeness (for whatever reason)?

If 15 people in the world think seeing the song name is great and one person doesn’t like it why does the 1 person “win” by virtue of some preventative measure?

If it this “X difference” test doesn’t one just rotate between two messages? The song title and the performer for instance? Zero match on consecutive messages.

I tend to doubt anyone who thinks the Chatbox should be used for displaying song titles would opt to use the status instead. Some might, some won’t.

And I obviously know nothing about OSC so… must the messages be affixed to an avatar? It would seem to me (again with no real-world experience using OSC) that having it display on an in-world object would be 100 times nicer.

Besides Damerau-Levenshtein, Jaro-Winkler are probably also worth consideration, to account for character transpositions etc.

Random half-cocked spitballing: implement some form of Discord Rich Presence and make it a VRC+ feature :slight_smile:

This feels like a backdoor webview reintroduction in sheep’s clothing because the complexity is unbounded if you don’t accept essentially the same restrictions as you have on the chat boxes normally. IIRC TMP text shaping happens on the main thread. A lot of the aesthetic appeal or ability to tune style or insert rich content may be undercut by safety concerns.

Crazy ideas that piggy back off of that, though: throw Avatar Udon onto the pile, allow for private unsynced OSC parameters, and do some kind of cursed base64 image output OSC handling. Optimize image decoding by enforcing a maximum dimensions limit, and require high trust level or avatar-showing to see it at all.

Chatbox mute will be powerful just because of social pressure. If folks using large OSC chatboxes find that most users immediately mute them, I imagine they’ll slowly fade out.

An avatar component would be phenomenal! A bit back using OSC, FrostierFridge created an unobtrusive implementation for showing off what song they’re listening to on Spotify.

Edit* Ouch, that embeded video got its bitrate butchered.

Right now translating text onto an avatar via an OSC data source is not feasible for the masses.

The invisible and sometimes surprising pitfall of this sort of thing is that shader or animator based techniques to turn OSC into ASCII are disinclusive non-solutions to users whose primary language is not based on the roman alphabet - or require the animator to become outrageously large.

Fair! Another possible implementation could be a variation of Contact component. When touched by another user, it could spawn a chatbox just for them, near the contact with whatever text it received last. Basically. an “on request” chatbox that the local user can feed updated information and others can “opt-in” to seeing by interacting.

Its size limit should probably be much smaller than a standard contact and there are things to worry about like the size of the chatbox. How long should it be displayed? Should it update the text if it’s currently visible? etc.

An added benefit of being a variation of contact means it could fall right under Avatar Interaction permissions, meaning you could make it friends only or disable self interact.

I think the option to just mute chatboxes will already be enough to combat the issue.

But one other thing that jumps out at me is some sort of option to filter between chatboxes that are being used for accessibility purposes (ill refer to this as text use), and chatboxes that are being used for cosmetic purposes (ill refer to this as data use).

If, when sending chatbox messages via OSC, it could be indicated that the message is data, not text, and other users had the option to disable seeing data chatboxes. Then that would be a easy way to clean up the chatbox landscape for people who don’t care what spotify song you are listening too, or how hot your GPU is running.

Obviously, this would require support from the devs that make the most common OSC chatbox programs. The whole system falls apart if a program creator intentionally decides to send data via the text endpoint. But this might be combatted by making the text endpoint have stricter restrictions (such as Levenshtein (or another algorithm) Distance, no special characters, etc).

I think there is a lot of “cool” value in letting people send whatever they want to the chatbox in certain situations. The person who set up their chatbox to be a live game of Tetris is a good example. But I also think that accessibility, conversation and not polluting genuine interaction with useless information is equally(read more) as important.

(ps, if we got a flexible way to receive and display text using an avatar component like you mentioned, that would be absolutely insanely really cool too. Like heartrate monitor and watch prefabs have been an animator nightmare because there are just really limited ways to do it. A armband that displays spotify song is a lot cooler and less intrusive than a chatbox.)

1 Like

I personally really like this idea. This bundled with chatbox muting could be a really powerful combination to filter out the majority of this sort of traffic. If someone sends the wrong kinds of data you could easily filter them out while (hopefully) the majority of tool creators would properly adapt this featureset.

3 Likes

I think there could be a couple of useful things to learn from protocols such as MQTT and IRC:
First, from MQTT, having QoS flags like:

  • At most once (QoS 0)
  • At least once (QoS 1)
  • Exactly once (QoS 2)

Spammy updates could have QoS 0, and be dropped altogether if the update rate is too fast. Typed text updates could be QoS 2, and 1 could be left relatively unused, or perhaps reserved internally to distinguish between in-client typed messages vs osc-derived messages (this is a distinction without a difference for now).

Secondly, borrowing the tagged messages spec from IRCv3 could be a way to supply useful per-message metadata - essentially, a small key-value dictionary. Eventually, this might prove useful should there be Udon integration with OSC at some future point.

Using OSC’s type tags to piggyback the data in a backwards-compatible way so as to not break old and/or simple OSC programs that don’t opt for the additional complexity should be possible.

3 Likes

I also like the idea of an avatar component. It would allow an alternate and far more creative way to do these sorts of things. The addition of a local only for remote clients contact receiver would also be nice for being able to interact with this sort of thing (and plenty of other things that could be somewhat obnoxious if it happened for more than just the user that interacted with it). It shouldn’t be too hard to repurpose the existing Allow Self code to allow that.

Although it would have to have a somewhat wide adaption for people who use public avatars to switch from chat boxes to using on avatar text. If the avatar component had some nicer features in terms of stylization that the chat box can not do, it might catch on some more. Some sort of markup language like text mesh pro has would add value to an avatar alternative that can’t be had with a normal chat box.

Note: These suggestions assert the chatbox is for communication only. A “data chatbox” should follow different rules.

1. The chatbox should be displayed locally, similarly to join/leave notifications.

At the moment, when a user sends a message with the chatbox, it is very difficult for them to see what they’ve just sent, as the local position of the chatbox for the local player is the same as it would be for a remote player. This means that, for example, your chatbox will be displayed far above your head, or stuck partially inside you. In either case, it is nearly impossible to read it.

If the chatbox were displayed on the user’s screen, with a similar appearance to notifications, it would improve usability of the chatbox, while also disincentivizing the use of the chatbox as a dumping ground for random status messages the sender can’t see. If your screen is blotted out by the status message you’re sending other people, maybe you’ll think twice about sending it.

On the flipside, sometimes people make mistakes in their messages. Also common is that people will type a message, but won’t know when the message has timed out and become invisible, leading to awkward silences where someone has to go “uh… could you repeat that? I don’t think XX read it”. Making the local display more prominent would help that case as well.

I think implementing useful features like this is a good way for making the chatbox system more useful as a means of communication, and more irritating if the sender is abusing it.

2. The chatbox should have a “rolling update” option built in.

I think support for receiving and displaying a gradually updating text buffer should be provided as a first class feature, both through the VRC user interface, and through OSC interfaces like OSCQuery.

I’ve used an OSC-based text system for a few years, and I’ve found that communication is much easier if people see what you’re typing as you type it. When having a conversation through voice, it is not necessarily to wait for a person to finish a sentence before hearing the message.

Updating on a word-by-word or character-by-character basis makes conversation flow naturally, as the other person is not stuck staring at a “…” above your head while you try to find the right words for a sentence. The immediacy also allows for quick corrections and adjustments as you talk.

However, the VRC chatbox actively disincentivizes this with an update limit. In my opinion, “require Messages to have X difference” is a spiky bandaid that would make the chatbox even worse for communicating. It would prevent this kind of gradual update from being provided by an external client.

It is far easier for people to reformat their spam every time they send it than for someone to rewrite what they’re saying mid sentence because they tripped some arbitrary sameness threshold.

3. The chatbox should have a slight Z-offset or other change to render in front of avatars.

When the chatbox is set to waist height, it can often be rendered inside an avatar, which… makes it unreadable.
This isn’t strictly related to the topic of abuse, but it does factor into how people decide to use the chatbox on a large scale, so I think it’s important to consider.

Etc

I think these features are important for getting people to comfortably use the chatbox as a communications tool. The current chatbox feels like it’s much more suited to a “status display box” than a means of communication, so it is really any surprise we’re seeing people use it this way?
I think it’s worth reconsidering the stuff I pointed out when the chatbox was first introduced on Canny; regarding accessibility, and regarding persistence.

7 Likes

If the song id chatboxes were like smaller such that I had to walk up to a person to read their song I wouldn’t mind it as much.

Aren’t chatboxes still disabled by default for everyone except friends? It seems to me like they’re already not treated like a communication method, since voice isn’t disabled by default, despite it being abused far more.

1 Like

Giving people the ability to push the live data updates directly to the display name status box seems logical if “uncluttering” the space is the intention.

Although I would expect query rate to become an issue.

Uncouple the status update rate from the client/web and allow OSC data attached to the status to have a higher update rate?

I’m just spit-balling on limited knowledge about OSC, Hope a clean solution is found!

I think it’d be good to pair the ability to mute chatbox with them being on by default.

1 Like

I agree and I’m not sure why this wasn’t done from the very start.

They aren’t on for everyone by default because there were (and still are) moderation concerns. Keeping them friends only is annoying and dissuades a lot of legit use cases, but also cuts out a huge amount of attack surface.

There’s been some discussion about changing that, but that’s not what we’re talking about here. :smiley:

My idea

let me recap this topic in one sentence. Some people overusing there chatbox with text like others there voice channel with music. The best solution is what i would like to get is 2 individual buttons for chatbox/voice mute per user.
I like Zekks “mute button for chatbox data” idea as something optional we could get on top.

Provide an avatar component

This is opening many questions to me. What’s the difference to chatbox in updaterate, text length and style? How would press a button work when i’m in a menu? Would the text placed infront? Or where the Chatbox normaly would be? If it’s “on my Avatar” how would that work with imposters, Fallbacks, Cross Avatars? if i have to press it on somebodies avatar, how can i perma show it for somebody? Avatars again, how would that work with imposters, Fallbacks, Cross Avatars?

Chatbox distance effects

I would like to have chatboxes getting smaller and/or more transparent by distance. same distance as my hearing. This should be a user choice off/transparent/distance/both. according to the selection “Outside transparency/size” like we already have “Outside Volume” for Earmufffs. This would be an voice over distance representation.

Status/API

Our status ingame can be updated over http api but is not effective while we are ingame. Allowing us to update our status, profile picture and more over http api calls while in an instance would be needed. Pushing this idea would be my biggest interest. As far as i can see this would be the first function (a user could controll) to push a command/message into the client. Which would open up a lot more possabilities. Avatar switch on the website could work without instance rejoining. we could join instances with a click on the website instead of sending us self invites, accepting friend requests on website could show up in game imidiatly, Changing groups we representing, … and much more. This could help users at some point to design there own shortcuts or even menues (let me dream for 2 seconds, …) think about possabilaties and autosation worldhopping to get in a random new world with your friends you were never in every 5 minutes (thanks)