OSC Developers - How to avoid abuse?

Creator Hub Tool Creators
1

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
2

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)?

3

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.

4

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.

5

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.

6

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.

7

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.

8

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.

9

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
10

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
11

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
12

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.

13

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
14

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.

16

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!

17

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

1 Like
19

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:

20

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)

1 Like
21

Interesting, but I think this will be avoidable by using unicode hijinks; there are a lot of characters that look similar, but aren’t, as well as various ways to encode the same glyphs. It also discourages correcting typos, and short form responses.

As someone who doesn’t hang out with the kind of folks who abuse chatboxes, it’s hard to tell if this would be adopted. Do those folks tend to upload their own avatars? Would we expect public avatars to start having general-purpose text displays attached to them?

If VRChat implements a prop or accessory system, then this could be effective, but if it requires an avatar upload, it might not divert as much of this abuse as you intend.

This also feels like a lot more effort to implement properly than a player or instance/group-moderator chatbox mute option; a new avatar component is a long-lived API that people will want a lot of customization and control over, and if it’s not done right you’ll be left with an albatross of an API hanging off the Avatar SDK that you can’t get rid of due to the small handful of people actually using it…

This also feels like it might be effective - just make very large chat displays annoying for the person using them. Maybe even make the chat display become bigger for a short time every time it’s updated over OSC. This does require a bit of balancing to avoid being too annoying for legitimate use cases, of course, but a big part of these sorts of problems is it’s too easy to be oblivious to how it impacts others…

22

Hello! I just found this thread and thought I’d add my 2 cents as someone who uses the chatbox for its intended purpose.

I’m often on the VRC canny reporting and pitching ways to make the system less frustrating for myself and hopefully everyone else with my shared experience, so I’d like to provide some perspective as someone on the receiving-end of the status clutter.

Speaking from my own experience, I strongly believe that allowing users to use the chatbox for statuses in any regard is super damaging to the chatbox’s function as an accessibility tool.
Currently, if someone finds the constant status messages annoying, they just disable chatboxes entirely and move on.
(Ignoring the “Friends only by default” stuff,) This prevents me from being able to communicate with a very large number of people. I have a very hard time participating in conversations with new people because I often have to ask friends nearby to tell them to enable my chatbox, or use pens to communicate, which isn’t always an option.

Now, taking into account the possibility of an individual-user chatbox mute option, this might seem like a solved problem.

I still don’t think this is the case.

Allowing passive, optional information to occupy the same space as high-priority, active social communication is still a problem because people’s brains get trained to just stop looking at the high-priority stuff when there are so many passive statuses you have to turn off.
This is already a huge part of the problem I’ve noticed after hours of examining and evaluating ways people interact with me as a chatbox user. People will straight up ignore what I’m saying even if they do have chatboxes enabled, because they think I have a spotify status on my head.

This is something I’m super passionate about and could talk about for way longer, but I’ll stay relatively on-topic and touch on the proposed solutions to solve this.

I’m not a huge fan of this idea because I’m just imagining all the scenarios where I’d just be trying to say “yes” and “yes!!” right after eachother and not being able to. This would become a huge problem for people who actually use the chatbox for…chatting.

This is what I want the most. I would love if there were a system similar to Discord’s rich presence that let you put statuses on your profile/nameplate rather than trying to “make the chatbox work” for statuses, based on the reasons I mentioned earlier.
The idea to let avatars take advantage of these statuses would also be super cool!

I had originally thought this would be the best solution, and I was initially very supportive of a canny post pitching a similar concept, but I just feel like if you’re going to allow OSC developers to split statuses off into their own “data-but-not-actually-a-message”-type input, why not just send it to a dedicated status system in the first place?
Having “data” chatbox messages would honestly just incentivize people to use the chatbox for statuses even more because they’d now have a relatively valid excuse to do so.

So while this is a great idea at its core, I’d much rather if it were spun into the “Improve the User Status field” idea as a separate OSC function rather than a branch of chatbox input.

I don’t want people to get used to the chatbox being a status tool that happens to secondarily serve as a communication tool. I really want to be able to express myself and know that people will likely be able to acknowledge my attempts to participate in conversation.

Anyway, please feel free to reply, ask questions, or reach out to me directly for anything regarding this sort of stuff, I’m extremely passionate about accessibility in VRChat.

I wrote all this on a whim and I’m not used to writing forum posts haha, so I really hope this can serve as valuable feedback.

3 Likes