VRChat Udon Web API
complete
Kaj
Add a UnityWebRequest (HTTP GET) equivalent function set
tl;dr: Persistence and web connectivity IS going to happen whether these Udon functions are added or not, but it would be better to have a controlled, standardized, and built-in solution than the SDK2 style hacks that creators will standardize themselves.
For a long time world creators have done without web panels and have had to use VRC_Panoramas and shaders to squeeze out the smallest possible web functionality available (see Maki's clock prefab) in VRChat worlds. With Udon's full programming power, world creators are finally able to make web based features for worlds - the main one being persistent values/settings across the whole platform. Web connections can currently (almost) be done with SDK2-style workarounds instead of built-in Udon HTTP functions - which by all means SHOULD exist. Creators have already altered the VRC_Panorama server system to return data directly through images, which can then be processed through Texture2D functions in Udon. Creators have even set up video player based streaming servers that return similar data, in case a VRC_Panorama equivalent never resurfaces. I've even personally planned for an external program that reads the game's output log, makes web requests through signals in the log, and returns data through OSC to make Udon web connectivity possible (though this is a sketchy and insecure solution, it would work better than other methods).
The point here is that web connectivity IS going to happen whether these Udon functions are added or not, but it would be better to have a standardized built-in solution than the SDK2 style hacks that creators will standardize themselves.
There are 3 main arguments I've heard from VRChat staff against web functionality in Udon: sandbox security, user identity/IP protection, and the desire for an in-house persistence solution without the need for web connectivity.
The security of the Udon sandbox is not something that should keep this functionality from existing. Simple HTTP requests do not allow for XSS style attacks, and there's no way simple data from an external server could harm the Udon VM, if the VM itself is secure. Even if there were vulnerabilities in the Udon VM, they would be attack vectors that that don't even require web connectivity. Plus, its already been established that people are going to make their own web request solutions. If anything it would be LESS secure to not make HTTP requests available through Udon so security flaws could be easily patched in the future without breaking content.
Player IP protection is something that cannot be done. As Tupper has mentioned in a previous canny post, "IPs are not expected to be private information. ... If you want to keep your IP truly safe, we encourage the use of a VPN." (https://vrchat.canny.io/bug-reports/p/eu-gdpr-compliant-serious-post-ip-grabbing) Completely protecting players' IP addresses would mean completely locking the game out from the outside world and removing features like video players and VRC_Panorama entirely. Even now, you can go into a public world with a video player, drop in a link to your web server, and get the IP address of all users in the room. Unless web based media is completely removed from the game, IP addresses are not going to be protected.
An in-house data storage/persistence solution for VRChat worlds is no real argument for limiting web connectivity at all. Not everything people want to do with HTTP requests involves world persistence. One use case might involve streaming in realtime data from a website to visualize in a VRChat world - something that's already done with VRC_Panorama except in image form. A simplified persistence service provided VRChat could exist in the future for less technically inclined world creators, but it is by no means equivalent to full web connectivity.
Again, web requests are going to happen whether the VRChat team approves of its methods or not. With the fine-grained level of control Udon provides, web requests will happen through inane workarounds that then go on to become established standards. Please take control of this situation while you can and add an Udon Web API.
Log In
Fax
complete
We just released a new version of our Worlds SDK, version 3.1.11.
String Loading is now available!
Thank you for suggesting this feature. We're looking forward to what you'll create with it!
SplitScream
Fax: there seems to be an issue, the monkey paw curled, and the URLs are locked down and static
Kaj
lol
Momo the Monster
Merged in a post:
Make loading text files possible from URL link.
MrDummy_NL
You have many security reasons do not use HTML website loading inside VRChat, due possible strange sites. It was removed long time ago.
But how about read URL links as only text / string? This makes chances to load different texts or even game data possible. Because it reads as text, you can parse it by yourself and use it in the world.
If you load in as uuencode format (its still text file) you can even load different images or some data for game save.
If it has some <HTML> or [B] code, with own Udon parsing script, we can make bulletin boards with some text formatting!
So if everything goes well, we have 3 ways to load data in:
- with video URL (already done)
- with VRC_Panorama function (still waiting, SDK2 has it for pictures loading)
- with text file URL (safe way to read data, no direct HTML need, mean no ingame HTML browser needed, own parsing possible to bring it to information boards, it's much smaller and less heavy than VRC_Panorama.)
These 3 things will make worlds much interesting and useful. We can do many things with it.
We understand there are security reasons, but you cannot keep avoiding things and many people are waiting for it. Because if you want 100% security and nothing must read, then remove video player function, because it loads anyway external.
But that will kill more VRChat fun and you're forced to use SDK2, makes SDK3 even more laughable idea due ridiculous fear to reading data. If you want make SDK3 / Udon great, then do it, and do it with safe many as possible. You just cannot prevent everything at all. We are waiting for it for long time!
Thank you.
Momo the Monster
in progress
We have added Remote String Loading to the upcoming Worlds SDK 3.1.11!
Rainwolf plush
Momo the Monster: is that going to be like the next update that comes out
DarkSwordsman
Momo the Monster: Thank you! Looking forward to using it!
Momo the Monster
Rainwolf plush: Yep! It's 95% ready, we'll have more info about it in the Dev Update tomorrow.
miner28_3
Momo the Monster: Are Dynamic Images going to be included too ? And JSON handling support ?
miner28_3
Also could *.githubusercontent.com be added to StringUrl List ? allows use of raw.githubusercontent.com for using github repo as storage.
Kelar
This would allow a lot of additional world richness which I think would offset the overall security risks. Almost every single device we have today spys on us, and consumers are generally OK with that. Heck lots of VRChat users already use the Quest 2, which is owned by a company whose whole business is based upon invading user privacy.
I can tell you some of the really rich stuff I want to do with VRChat worlds involves accessing large data stores elsewhere. But even simple stuff like shared sculpting worlds are really hamstrung by the lack of network accessibility - how do you export your artwork?
A more restricted start would be allowing http connections to localhost, but that will ultimately result in someone simply building a proxy.
My preference is that this work like permissions in android, the world creator needs to explicitly tick a box that says they wish to use networking, and then when a user views the world or enters the world the user is warned that this world accesses the network. I suspect this also will result in needing a more optimized UDON, or some simple restful helper functions.
I am seriously considering creating worlds in other platforms if they let me have unrestricted HTTP access, I want to visualize a complex 3d data set which is petabytes in size and have the awesome features of VRChat.
dmx512
please also add websockets.
WolfGang
I think the key problem with this is that VRChat content would break if the server not hosted by vrchat went away.
Yes web requests add allot of possible functionality, but you would inevitably end up with hundreds of Worlds that are broken and don't work.
This would be solveable with some sort of system where users clients report to vrchat when requests fail, and worlds get flagged as "Broken" but this would be overly exploitable. As for instance you could ddos a small server, or just block it on a couple machines and send hundreds of fake "webserver down" results to vrchat.
The argument about web players is flawed, because the easy fix for that, would be to whitelist domains that web players can access if they wanted to limit their security implications.
And the last bit about the fact that they will happen wether the vrchat team wants them or not, is wrong. They can be stopped if vrchat wants them to be, short of forcing all your players to use a modified client, you cannot gurantee a method of getting a webrequest out, as I mentioned above, vrchat can close the routes currently available, with fairly simple domain whitelisting.
Personally I would be all for web requests, I am msotly a web dev myself, and can think of many ways to use them, but they don't really outweigh the problems from vrchats perspective, if other forms of persistance / between world comunication were possible.
Also web requests will just lead to an awful lot of anti-user behaviour, we will get worlds that subscribe to shared "blacklists" to block people they don't like, tracking were users go, worlds that include some thrird party library to go some cool cars but include a backdoor to let the creator mess with any instance of your world tahts running.
I can't really see a good argument for web requests, so long as vrchat itself provides a decent persistence model, and some between instance comunication. Preferably persistence would have per user, per world, per group levels, but that's more something for a different issue.
Maybe outside api's could be made available on a case by case basis.
pichuchen
WolfGang: I think the 3rd-party server will discontinue to maintain or break is a problem, but won’t be critical problem. because author of world should maintain their world regularly, or they might can't support some user (eg. PC-only world, which quest user can't get in).
I think the discontinue or out-of-maintain will be very usually, because most of world author is volunteer, so may be disappear for one month with no expected just because busy on school or work, so a work around is telling authors, that author should make a mock image or content for if the server is going down, and avoid breaking the user experience.
DarkSwordsman
> Yes web requests add allot of possible functionality, but you would inevitably end up with hundreds of Worlds that are broken and don't work.
This is a non issue. I.E: It is not a reason for the functionality to NOT exist.
indominablerexx
The real question here is how to do it safely. Allowing anyone to access just any URL is quite big inherent security risk. How would you propose that be mitigated in a safe way? Because of this, I am 85% sure this will never become a reality, even though it would be quite nice.
GotoFinal
indominablerexx: in same way it was proposed long time ago by tupper, just display information on world and confirmation on first enter that given world is using some 3rd party services.
Additional security could be made by resolving url by vrchat hosted DNS + disallow any local ips to prevent people from trying to access anything locally.
Reimajo
It's funny how we are using GET-requests with video players today to send all kind of data to a webserver, which processes it, turns it into a POST-request and also load data from the server back into another video player. Full web connectivity but an awful lot of overhead / performance.
elyx0
Reimajo: What if we allowed blockchain reads
Load More
→