Backend Servers Rearchitecture

Right now there's a very strict way of viewing servers as only a "registered server" which is tied to the server map (which is already a broken contract).

This server only contains a server-info with the IP, port, and information regarding the server itself, while the registered server contains things like players, and the ability to ping the remote.

This is an issue since there's a lot of things which go on in a server which there's either no control over or it's statically defined which takes away from the idea of a "server", such as forwarding method, forwarding secrets, etc... which all go along with the server's handshake.

The goal is to properly restructure servers to reflect that some servers won't be registered, along with allowing servers to maintain their own configuration while using the main velocity configuration as a basic default.

The goal:

server (as an audience) => {
    remote info,
    handshake data? => {
        forwarding method
        forwarding secret?
    }
    name
}

This server type should be able to provide the basic defaults of what a server actually is. The registration adds a layer on it, but it should not actually be required as something for a velocity player to connect to.

Players should also be able to connect to the raw server rather than simply a "VelocityRegisteredServer" which it's locked into by virtue of how it's written. This can be avoided by allowing this interface to be accepted by the player as a valid connection point. If a user decides to misconfigure or send a player an improperly made server it should be on them to understand the use case outside of the immediate API (creating their own implementation of a "server").

Velocity Registered Server => {
  <connected players>
  <server instance>
  <server interface>
}

Registered servers should comprise solely of registered servers, and the sub-server implementation which those players are connected to.

The server map should work as a default but should not be heavily enforced into the idea of what a server is. There are plenty of use-cases for a system where server registration is a secondary use-case to a preferred stateless setup. Although this idea was implemented earlier it still does not fit well with what it is actually doing as in bad naming and improper handling of how the server is actually dealt with.

With this new setup servers can have memoized configurations with customized forwarding secrets and forwarding modes. This specific use-case looks at a server where it needs:

server a = 1.12.2 forge
server b = 1.17.1 fabric

This setup is impossible with the current velocity layout but becomes possible when player info forwarding is dynamic.

Another use-case for this kind of structure is such:

server a owned by person a = modern
server b owned by person b = modern

server a should not be accessible via person b

This creates an issue since the forwarding secret is a shared value which means that their access on server b gives them the secret to impersonate anyone on server a which causes a security issue. While this is probably a pretty rare use case, it allows for more dynamic setups where shared ownership under a main host is not an issue, along with sectioning off responsibilities and access for users such as staff, community managers, etc...

This reconfiguration could go into the server info but a restructuring of how the "connections" consume new servers is a pretty necessary step for moving forward with this change, along with looking at how the "player forwarding" is effected outside of the proxy -> server handshake.

Looking for any feedback/ideas which may make this server re-architecture work better / provide a more robust API.

Start by mapping the current server, registered-server, server-map, connection, and player-forwarding abstractions described in the issue, including how the proxy-to-server handshake consumes them. Define the API boundaries for raw and registered servers, per-server forwarding configuration, and player connections before implementing anything. Done means unregistered servers can be connection targets and registered servers remain a separate layer with dynamic forwarding settings.