Μerlin I mean, yeah. Given that you were seemingly the only one with the knowledge to pursue Udon 2, I don't imagine VRChat will ever actually finish it, but I'm making this in the hopes that they'll try.

It's extremely obvious the community doesn't want Soba, this canny is only 20 upvotes away from being on-par with the Soba (formally Udon 2) canny and that's with a 232 day difference on the two. If 119 community members are coming out and effectively saying "Give us back Udon 2", I would hope they'll get the damn hint.

Μerlin What about udonsharp 1.2+? Can we expect you to keep delivering on the udonsharp compiler? though.. Are you still allowed to work on it? idk how VRC sees Udonsharp nowadays anyway.

At the end of day, the Udonsharp compiler was amazing from the start, I don't think the community can thank you enough for it lol

ThisMight I will try to get 1.2 to a decently stable place. I probably won't be doing a ton with U# past 1.2's features since Soba having the VM to work with allow it to be objectively be better at some point than what U# can provide. U# is MIT so it's fine.

Balphagore Please don't ever try to do sandboxing, it's not that simple...

So many ways for people to try abuse stuff, reflections, unsafe, badly implemented existing libraries, and the more you block the more limited the language becomes until you end up with something that can only run very basic c# code.

And even then you are still not anywhere close to good enough, as unity code must run on the main thread, so anyone can stall this main thread forever with no way for you to stop it without crashing whole unity.

Then you also have the fact that its not just c# you are trying to secure, but also access to some of the unity - like VrChat does not allow you to touch players directly in any way, and many other internal parts of the scene.

Thats why the idea here is to use WASM with c# support, as you get the whole runtime environment of wasm with full c# support but in a much safer way, as that environment just does not see the actual user system and cannot affect the rest of the game - expect for the provided methods ofc. While the provided methods can also ensure they are only exposing whats needed.

GotoFinal Sidenote, for an example of a game that uses C# sandboxing to support arbitrary client code being delivered over the air: Space Station 14!

It can be done but it's a PITA.

FairlySadPanda Where tho? I'm not familiar with the game, but I can't find anything in repo or documentation/wiki about any code being transferred between clients. It has modding support for sure, but thats very different and just not secure like most modding solutions. Hopefully it does not automatically downloads mods from the servers... but otherwise not related unless I'm missing something

GotoFinal Check out how Empyrion Galactic Survival exposed their modding interface and we modders have the freedom to mod the game with c#. It also runs on the Unity Game engine. The code is executed client side.

Balphagore Eh, but we are not talking about modding, this is VERY different. It's kinda scary people don't understand it.

Some games have safe modding, when they have some own scripting language to control or something made for that purpose like lua, but I don't think I've ever seen c# used in safe way - other than solutions like U#.

If you mod a game you are putting yourself at risk - usually just trusting the modpack creators and your friends.

But in game like vrchat, with content created by other users that is downloaded automatically to your PC when you join world... I don't want to enter wrong portal by accident and get my C drive wiped.

Many mods in popular games have FULL access to your pc, they can do whatever they want, like client side Minecraft mods - and Empyrion seems to be no different here as far as I see.

GotoFinal Actually, without WASM system interface, WASM can't access some of the dangerous stuff, such as the file system

RingLo_零落 Yes, I know, thats the point, but Balphagore was suggesting just loading c# code directly and trying to sandbox it manually without WASM. And thats just not safe.

ni1chigo2115 They can precompile wasm binaries for iOS with extremely little, to no performance loss.

FairlySadPanda The origin of those rules on iOS is that interpreted languages of any sort used to be banned, so at Facebook we made extensive use of JavaScriptCore embedded in iOS to manage dynamic behaviors that were downloaded out-of-band to the client.

Even this, at first, was met with harsh resistance at Apple, as it meant that previously-reviewed functionality could become something entirely different (point a). A bigger concern was that the leverage of Facebook was such that it could create an app market based on that technology, as in the distant past (early 2010's) Facebook had hosted a hosted app platform embedded within the site (point b).

Also, someone on my team, a former jailbreaker, was very adept at obfuscating Objective-C selectors (method names) in such a way that they could call internal SDK functions in a way that was undetectable except through live analysis of the execution of the app, hence point c.

So that covers the policies that allowed for sanctioned code downloading with JavaScriptCore. The general ideas being, in plainer language, 1. don't make an entirely different app, 2. don't make an app store within an app store, and 3. don't try and hack the system.

The next problem that we faced after JSC was deeply integrated into the system was that the volume of and the deep integration with Javascript meant that the app startup was delayed by the translation and code generation (aka parsing and compiling to bytecode) steps more so than execution. To address this, we created our own Javascript VM called Hermes, such that we could skip several steps to load and execute the bytecode. Since this was an interpreted VM, and not a JITted VM, it was clear, but on a bit of shaky ground until Apple's reviewers got used to it, because they can be capricious and trigger-happy until the policies are clear.

It should be worth noting that wasm is not inherently JITted. Common implementations of wasm do JIT, but wasm interpreting is an option, and that is the approach that VRChat certainly took with Udon 2 as well as Soba. And JIT is less of a policy limitation than a technical limitation imposed by Apple: executable memory is read-only, and read-write memory is disallowed execution at a very low level. It is not _possible_ to write dynamically compiled bytecode at runtime then execute it, as JIT does.

AOT compiled wasm would also not fall afoul of the policy, as it would essentially be subject to the restrictions from the first rule you posted.

For what it's worth, Hermes also supports asm.js, another target for native code that, rather than specifying another bytecode, instead opts for a restricted low-level subset of JS. As Hermes (internally) predated WebAssembly, and was interpreted anyways, it was easier to support compliant JavaScript rather than add support for a different bytecode altogether, and performance is relatively competitive for non-JITted execution.

> This is a complicated topic so if anyone can point me towards an approved application on iOS that downloads pre-compiled wasm off the internet and executes it, I'd like to know so I don't spread misinformation when this gets brought up in my dev circles.

Facebook. Facebook downloads pre-compiled bytecode (though Hermes bytecode, not wasm bytecode) off the internet and executes it, and has for most of the decade.

FWIW although I operated at arms' length to several of the teams involved, you probably won't find anyone outside of the people who worked on the actual teams with a clearer understanding of the above history and how the technical underpinnings fit into the broader context of iOS App Store approval process. I was, uh, rather curious and nosy about it, and the team I was under worked on the core client infrastructure for all of Facebook's iOS (and later, Android) apps.

(Fionna knows the one person who would know better, as he was the director of that department)

Ultimately, the approach of Soba and Udon 2 using their own bytecodes are functionally identical from the policy point of view. The problem is that Soba will be far more expensive to develop, and slower to respond to the evolving ecosystem of .NET and Unity.

Udon 2 entailed integrating an open-source wasm interpreter and embedding the .NET runtime compiled to target wasm, creating C# bindings to be executed within this context, and then executing wasm with integration between the Unity host. This offers several advantages such as strong sandboxing, as well as better chance for tooling integration. It may be necessary to work cross-functionally with teams outside the company to achieve the necessary deliverables.

Soba is a bespoke VM. It's not a per se, in terms of technical choices absent any product, corporate, or financial contexts, but if a team of several engineers with a cumulative salary of several millions of dollars has spent the better part of the decade to achieve rough parity with wasm...I hate to say it so bluntly, but one engineer cannot possibly compete with that.

I have no doubt that it takes an immense amount of talent to achieve an end-to-end working result, but I am concerned that the bus factor of the project means that the ability to execute on Soba at all is heavily reliant on the continued employment of a single person, and has less than zero external hire-ability, in contrast to technologies that are a lot more friendly to corporate nerdsniping such as WebAssembly. Although Udon 2 had a bus factor of 1 as well, the surface area of that was significantly, smaller.

On a technical level, it is not difficult to craft a rationale to stick with Soba, and as someone whose multi-year project was cancelled in the recent past it hurts me to admit that there are valid reasons to walk away from excellent technical work for reasons that have absolutely nothing to do with technical merit. But on a project level, I have deep reservations that Soba is a sustainable technology for VRChat to deploy, and I have many fewer reservations for the WASM approach.

(Apologies for the four comments, I'm hitting character limits)

Lastly, I would also like to point out that although people are the most valuable resource a company has, at this point the overriding question should be about "how do we retain, engage, and excite the people in the community creating content" over "how do we retain the work on Soba". At this point the choice is between wasting the work on Soba or wasting the work on Udon, PLUS revisiting the long-term impact of deploying either of them to the community as well as VRChat's own ability to meet future expectations of continued execution on clearly understood goals.

To that end, whatever approach best accommodates:

Is the one that I think will be successful.

WASM has precompiled Modules that work on IOS and are used by other applications, the IOS concern is only if apple decides to enforce its vague policy against VRC/Roblox/Ect which is a possibility. I would argue even Soba would qualify

GlitchyDev Precompiled modules that produce dylibs should be kosher if the dylibs are themselves properly signed, and I believe that is a more recent amendment to their approval practices, but doesn't really change anything.

pema99 I'll likely reword it soon. Also, I stated that it won't have generics _at launch_

pema99 Emotionally charged language hurting a case only makes sense in a lobotomized and sanitized corporate environment where the higher-ups want obedient little piggies to shut the fuck up and do their work.

This is a social platform, and us as advanced creators - getting constantly shafted and strung along with a carrot on a string for years that turns out to be nothing - DESERVE to be able to freely and fully communicate how pissed we are at how dogshit communication and decisions have been from this pathetic company. It's part of the argument.

But ultimately it doesn't matter. VRChat does not, and has never, cared about its creators or their insights. We have no power. Not even their own staff members have the power to speak their mind against the true key holders. Thank fuck you don't get banned on the canny for speaking your mind or being "too combative", lmao.

2Doc Yup. VRChat is a public company, the shareholders want money, they couldn't give a flying fuck about the creators. They never have. That's why they've gotten away with waving their dicks about for so long.

The only time the shareholders would "care" is if they're losing money, which would only happen if VRChat had a massive scale exodus to other platforms were to occur, which is unlikely to happen nor succeed, as it didn't with EAC.

Not__Shadow I do not disagree with the notion that vrc needs to be better, however you're wrong that they're a public company. Public implies that they have shares publicly available on the stock market. From what I can gather they are still private. What you are implying is that they have investors, which private firms can still receive.

StackOverflow Yep. Especially when it's so CPU constrained right now, WebAssembly would improve frametimes across the board and make VRChat run much better.