Expose a stable connection ID across motd, handshake, login and join events

Is your feature request related to a problem?

Yes.

Plugins may need to associate information collected during the handshake phase with the player that later reaches AsyncPlayerPreLoginEvent, PlayerLoginEvent, or PlayerJoinEvent.

Currently, the only common identifier available in the early stages of the connection process is the remote IP address. However, IP addresses are not a reliable way to correlate a specific connection, as multiple connections can originate from the same address.

As a result, it is difficult for plugins to reliably determine which handshake belongs to which login attempt.

Describe the solution you'd like.

Expose a stable connection identifier (for example, getConnectionId()) that is available throughout the entire connection lifecycle.

The identifier should remain the same from the initial handshake until the connection is either closed or the player fully joins the server.

Ideally, it would be accessible from events such as:

• ServerListPingEvent
• PlayerHandshakeEvent
• AsyncPlayerPreLoginEvent
• PlayerLoginEvent
• PlayerJoinEvent

This would allow plugins to reliably associate data collected during earlier connection stages with the player that eventually logs in, without relying on IP addresses.

Describe alternatives you've considered.

The main alternative is using the remote IP address to correlate events. However, this is not reliable because multiple connections may share the same address.

Another option is maintaining custom tracking logic inside plugins, but there is currently no stable connection-specific identifier exposed by the API that can be used across all stages of the connection process.

A built-in connection ID would provide a much cleaner and more reliable solution.

Other

Example use case:

A plugin collects data during the handshake phase and needs to access that data later in AsyncPlayerPreLoginEvent. With a stable connection ID, the plugin could safely map the handshake information to the correct login attempt without relying on IP-based matching.

Start by tracing the connection lifecycle across ServerListPingEvent, PlayerHandshakeEvent, AsyncPlayerPreLoginEvent, PlayerLoginEvent, and PlayerJoinEvent. Determine where a shared connection identifier can be exposed and verify that it remains stable from handshake through join or closure, with API coverage for each listed event.