GotoFinal: yeah, i did not understand that at all, with the limitations being present

Since the rate limit is per user, might need to explore a round robin option and have users complement each other since there is no limit on requesting serializations. I have a psuedocode and testing the idea of a "memory" cache that each user will have, and complete each other like a p2p network.

Balphagore: Ohhh, interesting.

Netcat~: Here's a simple example: https://github.com/vrchat-community/examples-image-loading

This one uses a 'slideshow' style to show one image at a time, so the request delay is not obvious to the user. You could do the same with manual control by loading the 'next' image when the user changes to the 'current' one, and swapping it out when they change.

We' reviewing all the feedback about images and string loading - we understand that creators always want more! Just wanted to illustrate that you _can_ implement this concept within the current limitations.

Momo the Monster: I think it's less about wanting more, and more about wanting the basic functionality that's already available in browsers and other software.

Can the VRC team give some examples of possible abuse that led to the 5 second limit, plus reasons why it can't be something closer to 50 requests per 10 seconds?

If this is a basic feature that will be expanded later simply due to a lack of dev time, then I understand. And I also understand the VRC team doesn't want to announce things that are too far ahead. But that sort of transparency would be appreciated, since right now it makes the decision seem strange and it artificially limits creators.

We appreciate the solutions, but these solutions only exist to get around a seemingly arbitrary limitation. It also creates extra engineering overhead for the creator not only within their world, but also limits their ability to use external APIs without having their own aggregation solutions that they would have to host themselves.

Some clarity on the decision would help us understand.

DarkSwordsman: The 5-second rate limit is part of an overall design to that makes it harder and slower to exfiltrate user data via GET requests to third-party servers.

Momo the Monster: But VRCUrls are already locked down, and the only way for custom inputs to be sent as GET requests is if the user inputs into a VRCUrlInputField.

Unless you are saying there is a known exploit that allows users to fake inputs to VRCUrlInputFields and send data every 5 seconds?

I also don't think the rate limit will change anything. Any data that can be stored in the URL can just be encoded in a higher bit depth. As far as I understand, this would be alphanumeric plus , so a maximum bit depth of 62 bits (lowercase, uppercase, number, special). The user can figure out an encoding and decoding scheme to maximize the amount of data that can be sent through query params.

DarkSwordsman: No, there's not a way to fake inputs into VRCUrlInputFields. I've tried to provide some clarity around the decision here, and I hope you understand that it's not a good idea for us to spell out how someone might try to exfiltrate user data. I'm sorry if you're not satisfied by the answers I can give - we're looking at ways to safely reduce these limitations, I hope that we can do that soon.

Momo the Monster: I appreciate your effort to provide clarity, and I understand the need to not mention any possible exploits. Though, I would much prefer to have the possible exploits mentioned, since it still feels like an arbitrary decision.

Security through obscurity isn't security. I would imagine that you'd want people to try to exploit your program so you can fix the possible exploits faster.

We're not going to get anywhere if we are going to try to anticipate things that may never happen or don't exist, which it feels like the VRC team does quite often. Many decisions being made at the fear of something possibly happening.

Momo the Monster: Data exfiltration will always happen in other ways, and even happens a lot right now. I understand the safety concern, but VRChat is not only a social platform, but a sandbox for creators to make amazing things and scripts for people to enjoy in a dynamic environment.

I've played other games that permitted API calls to help bring forth helpful utilities that either provided Discord integration, or an external database to load user's configured profiles they setup on a web panel.

Balphagore: Agreed. The solution here is less about possible abuse and more about accountability.

I think it would be useful if the user can see which domains/requests are being made in an instance. I.E: The world creator would have to create a manifest/a script can be run at build time to show which domains are listed. Even better if it can show the requests themselves to gather an idea of the data that is being sent. Especially better if the world creator has to write what data is being sent/receive on a domain.

This would allow the users to determine if a world is trustworthy and whitelist it, and VRC can implement their own checks for rate abuse or bad domains. A whitelist can also be stale if a world is updated.

There are smart tools and systems that VRC can make/use, which rely on the community to provide for reporting. Similar to the FOSS community, and they do already rely on user reports.

DarkSwordsman: Check out this post I made not long ago, it's not relevant to the current limit set but I pitched an idea to be more transparent about the requests going in/out, and leave it up to the user to allow or deny those requests(Only domain-level & sub-domain level). The remainder of the same URL is OK going forward.

I'd feel pleased as a player knowing that there are more potential for creativity, and that I will know if/when an untrusted URL is being requested. https://vrchat.canny.io/vrchat-udon-closed-alpha-feedback/p/allow-vrcurl-url-dynamic-urls-at-runtime-its-time-for-a-change

Momo the Monster: What about maybe, offering a hosting option directly from VRChat. So you won't have to stress about "exfiltrate user data". You could allow the URL from that specific domain from vrchat.com. allowing no rate limit under your own trustworthy URL. It will allow some world to save on data that absolutely doesn't need to be always loaded in the ram for everyone. For example Karaoke worlds when you search for a song, you won't need all the thumbnail from all the album from the map, it allow a way lower. It won't fix everything but it will allow more use from this function then : Slide show, calendar.

Reverse: Technically they could already do this with the whitelisted URLs, since there's no real way to write data to those hosting solutions. No need for them to do their own hosting solution.

Momo the Monster: Simply allowing the following small images to be loaded without limitations will make it easier to avoid the bug of images being inverted in Quest.

[Build: 1282] Image loader on quest loads images upside down

DarkSwordsman: You can use an editor script, or any other way, to generate urls in build time and access them later in run time