Tamed pets and skin heads break after /premium on Velocity with offline UUID compatibility

[strobil]

What behaviour is observed?

After enabling premium mode for my account with /premium and reconnecting, the login itself works correctly: I can join without entering my AuthMe password and the backend still sees my old offline UUID.

However, while premium mode is enabled:

• My existing tamed wolves, cats and parrots no longer recognize me as their owner. They are shown as unowned on the minimap and I cannot interact with them using right click.
• My skin is shown correctly on the player model, but Chat Heads shows the default head for me.
• Simple Voice Chat also shows a default skin for me in voice groups.

I checked the player and entity data on the backend. My player entity uses the old offline UUID, and the Owner field of the loaded tamed animals contains the same offline UUID. The animals have not lost their owner in the world data.

If I run /freemium, reconnect and restart the client, pet ownership and the affected skin heads work normally again.

The actual proxy is Velocity. I selected BungeeCord below only because the issue form does not provide a Velocity option.

Expected behaviour

With premium.keepOfflineUuidCompatibility: true, premium login should preserve the old offline UUID without breaking client-side identity handling.

Existing tamed animals should continue to recognize the player as their owner, and mods that obtain the skin from the connected player profile should continue to show the correct skin.

To Reproduce

1. Use an offline-mode Velocity proxy with modern forwarding.
2. Install AuthMe Velocity on the proxy and AuthMe Paper on the authentication backend.
3. Enable premium login and set premium.keepOfflineUuidCompatibility: true on the proxy.
4. Join as an existing offline-mode player who already owns tamed animals.
5. Log in with the AuthMe password and run /premium.
6. Reconnect with the licensed Minecraft account.
7. Confirm that password bypass works and the backend still reports the previous offline UUID.
8. Try to interact with an existing tamed wolf, cat or parrot.
9. Check the same player in Chat Heads or a Simple Voice Chat group.
10. Run /freemium, reconnect and restart the client. The problems disappear.

Plugin list

Proxy:

• Velocity 4.0.0 (build 6)
• AuthMe Velocity 6.0.1-SNAPSHOT-b2767
• SkinsRestorer 15.12.5

Authentication backend:

• Paper
• AuthMe Paper 6.0.1-SNAPSHOT-b2767

Gameplay backend and client components used to observe the problem:

• Paper
• Simple Voice Chat 2.6.21
• SkinsRestorer 15.12.5
• Chat Heads (client mod)

Server Implementation

BungeeCord

Database Implementation

MySQL

AuthMe Version

AuthMe 6.0.1-SNAPSHOT-b2767 (CodeMC build 2767)

Error log (if applicable)

No response

Configuration

Sanitized relevant settings: velocity.toml online-mode=false and player-info-forwarding-mode=modern; AuthMe Velocity premium.keepOfflineUuidCompatibility=true; backend AuthMe settings.enablePremium=true and Hooks.bungeecord=true. The shared secret is configured and has been redacted.

[strobil]

Dug into this from the code side. The UUID chain itself is fine: with keepOfflineUuidCompatibility: true the offline UUID reaches both the backend and the client — which matches the consistent server-side data you observed.

What breaks is that the client still treats the connection as online-mode. Our Velocity premium path goes through forceOnlineMode(), so the login is encrypted and Mojang-authenticated, and the client then resolves "me" through its Mojang session (profile key pair, tab heads, social lookups, mods reading the online-mode state) — a premium UUID that matches nothing in a world keyed on the offline v3 one. Hence Chat Heads / SVC / pet ownership all breaking while server data is intact, and /freemium working because that login is genuinely offline. Before 26.2 the client derived this from Connection#isEncrypted; since 26.2 it's an onlineMode flag in the join packet, which Velocity fills with player.isOnlineMode() (PaperMC/Velocity@d7ad0522). The option is only a few months old, so it probably just never met a modded client before.

That 26.2 change is also what makes it fixable from the proxy: the client now trusts the server-sent flag. Proposed fix is to make the Velocity path do what the Bungee one already does when the option is enabled — skip forceOnlineMode(), verify premium in the login phase via PacketEvents (reusing ProxyPremiumLoginVerifier and the AES codecs from authme-bungee), drop the GameProfileRequestEvent rewrite, fail closed to password auth without PacketEvents. The connection then stays offline-mode for Velocity and the flag reaches 26.2+ clients as false. Older clients can't be helped from the proxy side either way, since for them encryption itself is the signal.

I've also opened PaperMC/Velocity#1875 asking for an API to set that flag directly, which would make the PacketEvents flow unnecessary. Workaround meanwhile: keepOfflineUuidCompatibility: false.

Happy to put together a PR if maintainers agree with the approach.