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
2Doc
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.