Nothing changed about how the community is. The consensus across the community has been to do shady things like this (e.g. using weird paid Lua obfuscation services originating from the Roblox community that lead to a lot of behavioral issues and more), and this being done out-of-band off the forums by nearly everyone led to issues with us being unable to actually fix bugs at all as e.g. people were dismissing requests for a repro like such:
This so-called ‘nat215 framework’ was being sold out-of-band, likely with a lot of ‘IP locking’ etc., and the user was refusing to provide any such asset to replicate their issue: now, with an official solution for resource sellers to be able to do ‘locking’ of whatever sorts while keeping the original resource on our backend services so we can actually reproduce this kind of issue, even if the resource author is not explicitly playing along.
The ‘asset escrow’ system was meant to be initially ‘done’ before we’d allow paid releases on the forum at all, but this took a lot more time than expected, mainly as we had to find a new set of developers skilled in working on web/backend services for this: none of the core game folks are working on this whatsoever, e.g. I’m explicitly keeping my hands off of this mess.
As to the core ‘root of trust’ for the access control here: the basis is that these wrapped assets are not able to be loaded by simply unwrapping (e.g. server-signed Lua bytecode, similar to MTASA: without actually decompiling fully and cleanly which currently no Lua decompiler can) and since a server owner usually won’t be able to get all people playing on their server to run a custom game version, any ‘stolen’ assets are unusable to them on normal builds of FiveM.
Other things done by this ‘under-the-table’ off-site selling of assets being normalized has been stuff like backdoors in re-re-re-sold resources being remarkably common, without us being able to revoke, check or otherwise deal with these resources. This is also why ‘obfuscated code’ from random weird ‘Lua obfuscation services’ is generally prevented from loading by the actual client/server patch sets: it’s just too risky to keep like that.
Finally, the assumptions made in the last four paragraphs in your message are again entirely irrelevant since the point here is that clients are generally trusted in their form of being a ‘consensus’, and the threat actor is a potential malicious server owner or their supply chain. While a single client may definitely be able to load an unauthorized copy of a resource, all of them being able to do so is highly unlikely.
Summarizing: I’m personally also very much against what’s going on here and the general tendency to see FiveM as a ‘get rich quick scheme’ for everyone involved, this however is needed to allow the community to do what they already have been doing since the project has existed but without it being something we can’t monitor, influence or even be aware of at all other than trying to ‘fight it’, which is a fight one certainly will lose.
