2026 bump

This is still one of the biggest gaps in Udon. Persistence helped with save data, but it can’t be set up before a player visits, players can wipe it, and it doesn’t carry across a creator’s worlds. Display names remain the only way to recognize someone, and they change constantly.

What user IDs would enable

Event and staff whitelists: DJs, dancers, performers, and staff are whitelisted for stages and controls, and many change names often. IDs never break on a rename, can’t be faked by copying a name, and are easier to add, since you can just copy the ID from someone’s profile.

Player-specific redeem codes and rewards that can’t be shared or reused by someone else.

Creator Economy perks that line up with records kept outside VRChat, like Patreon tiers or event tickets.

Save data that works like other games: Steam exposes SteamIDs and Roblox exposes UserIds. Persistence already ties data to the account internally, so we’re only asking for access to that identity.

Repeatable gimmicks, like a love tester that gives the same result for the same two people, even after a name change.

Addressing abuse concerns

The main worry is shared ban lists. Those are already against the rules, and anyone can compile a list of display names today. Withholding IDs doesn’t stop that. It only makes legitimate tools break.

User IDs are also already public in every VRChat.com profile URL. VRChat already shares VRC+ status and Creator Economy owner names with Udon, so this follows the same pattern.

Proposal

Expose raw user IDs to Udon. This is the simplest and most useful option.

If more protection is needed, use a per-world ID: hash(userId + worldId). It stays consistent within a world but can’t be matched across worlds.

Either way, let creators link their own worlds so the same player is recognized across a creator’s hub, event, and game worlds.

Optionally limit access to verified creators, such as Creator Economy participants.

World creators are already responsible for what we upload and the rules we follow. User IDs would let us run safer events, offer unique redeems and perks, and keep whitelists tied to the person instead of a name that can change at any time.

This would be nice for whitelisting, because as far as I know, the only way that is exposed to Udon for identifying players is the display name, but if the player changed their display name, that won't work for them anymore until the whitelist is updated. Unless you use some kind of Persistance to fix this issue, there is no other workaround with that. Though this could be a problem for Blacklisting as someone else also pointed out, this could be a definitive way to ensure a player doesn't lose access to areas, like from supporting a creators patreon to access special areas, or whitelisted features like a infinite ammo in weapons in game worlds.

Why is this not implemented still?

We can already create filter lists for admin panels, vips, etc.. so this is not the concern.

We NEED this implemented so cheaters wont get access to admin panels or vip features by spoofing display name.

I don't agree with this. This is a slippery slope

While the beneficial side is allowing an online white listed area ..

It can also be abused for malicious intent

VrChat ToS says that creating a white list area is okay but maintaining a blacklist, especially when it prevents the user from enjoying the world that is publicly released can be done.

Imagine that you're friends with a VrChat game world creator. You guys had a stupid falling out that had nothing to do with the game

Some of your friends asked to join you to your former friends game world to have fun

You accept and enter the world. Udon reads your username and insta teleports you to a blocked area

While this may not prevent them from entering the world, this essentially creates a blacklist and punishment that a world creator that made a public world, can whimsically decide who can and can enter their public world

It's a slippery slope

Bump, pushing for this for a more accurate way to tell which player is who and to avoid the common issue with special character names breaking playerlisting.

the problem is that same client users can spoof the displayname and this is not funny for an admin pannel script

In the meantime, I've found that anytime you want to compare displayName strings, it's sometimes safer and avoids issues if you convert the strings to be compared to hash codes using string.GetHashCode()