User-private persistence
TapGhoul
I would love a way to store persistent data that doesn't get replicated. This likely wouldn't make as much sense on PlayerObjects, but it would be great to have either a flag or a section in PlayerData that's scoped only to the local user, for storing more private data.
This would be great for things like a "last entered code" for admin panels, for example, where it improves UX but you wouldn't want it replicated out to all clients in an instance.
I can forsee one potential issue with this however, users storing potentially sensitive information in these keys (such as passwords) so this would likely need to come with some kind of disclaimer.
Log In
Reimajo
Apart from privacy, the current persistence is also completely unusable because it floods the network with data that shouldn't be networked. We can't afford that, because the network data limits are already too strict.
I can't think of a single use case where I want the persistent data to be synced to everyone. That's a massive overhead in practically any real use case right now that nobody needs. Most people just want to sync local stuff like the menu settings! Why was anything else the focus of this implementation? And if anyone builds a complex game world, they have their own system in place that controls what should be synced.
As usual, once persistence left the public beta, VRChat has not implemented private persistence or added any other new features to it. It has been released and not touched again since. We are once again left with a half-baked system that is unusable unless you work around all those obvious issues.
I am extremely frustrated about this because I made the original persistence Canny, was happy that it was being worked on, but what we got is the opposite of what we wanted because VRChat made up this whole networking thing that nobody asked for, and prioritized it for no reason.
I couldn't implement persistence anywhere so far. Occasionally, I try to implement it, and it just leaves me speechless at how unusable it is or how much bloat it would add.
A local key-value store, like browser cookies, is all we wanted. And yes, I also want to store data that should not fall into the hands of client users. There is no reason to have another feature that they can have access to and exploit.
Kaj II
So is the "less than a tenth of a floppy disk" persistence storage space per-user per-world the result of server bandwidth costs OR the result of persistent data being inexplicably inherently udon synced (when it doesn't need to be?) lmao
DrBlackRat
This was also something I requested during the closed beta, sadly it didn’t make it in before the open beta.
My current setup is quite cursed, as I essentially create local only persistence by just not doing anything if you aren’t the local owner of a player object. I do this as I already had networking setup for the system I’m using this for, so it being networked is more of an inconvenience to me than actual helpful.
Genesis
It's crazy that per-user data is not private by default, this seems more like an oversight in the design that should be corrected before being released.
Μerlin
This should be the default behavior for persistent data IMO, security by default. Very surprising it's not like this already considering how much VRC says it cares about security. If they change the default this is something that needs to happen
now
and cannot be put off without a giant breaking change.TapGhoul
Μerlin I don't feel like persistence should be seen as a security feature - if it were "secure" in that way you wouldn't want it leaving your machine, or at least have some guarantee that it's encrypted/protected server-side.
I do feel that persistence should not be required to be coupled to sync here, at least on the player key/value side (maybe objects too? I dunno here) - but I say this from a devex/design perspective, not a security one. Privacy, perhaps, but not security.
That being said, having VRCObjectSync already persist (at the time of writing) is pretty damn nice from a world creator perspective, given doing so is opt-in via the enable persistence component.
Μerlin
TapGhoul It's a security point on users potentially saving data in the world they expect to be private. It's not a security feature itself, it needs to be thought of how users will use it though and how to guard against exploits. For example, network events are callable by default on any UdonBehaviour, this has historically been a big issue because people could just call any event even if they were intended to be local by the world creator. You have some button in your world that teleports you to a location? People could just make everyone in the lobby spam that button. The obvious solution here is to just make people opt into specific events being networkable. But VRC didn't do that now so it's a big potential breaking change that they don't want to address.
I wish persistence wasn't tied to sync, that's been one of the major feedback items on it forever and it would have almost certainly taken much less time for VRC to implement if they didn't tie it to sync. But that's a whole other can of worms that should probably be its own canny for VRC to ignore.