Feature: Allow configuring API URLs

[evan-goode]

I would like to configure the API_BASE_URL to point to a different server than api.geysermc.org. Perhaps config options like api.base-url and api.websocket-url. Happy to prepare a PR if one would be welcome!

[SleepyPopp]

Feel free to open a new pull request. We welcome any contributions.

[SleepyPopp]

Please note we have an AI policy: https://github.com/GeyserMC/.github/blob/master/AI_POLICY.md

[Tim203]

Something like that would defeat the purpose of the global api, which is why I personally would be hesitant to accept something like that (especially as config option.) When the global api becomes a local api then you could've just used local linking. There are also sites using the global api to get skin information about players (e.g. to show an avatar on their website), which would also stop working if it becomes a local api.
I could maybe see something in an environment variable, but due to reasons like the ones mentioned above I also wouldn't be a big fan about that.

[Tim203]

I'm more open to a local linking type that calls an URL to look if the player is linked (instead of looking at a database like the current local linking database types.) Would that also fit your use case?

[tnqzh123]

I'm more open to a local linking type that calls an URL to look if the player is linked (instead of looking at a database like the current local linking database types.) Would that also fit your use case?

One use case of custom Global API is using Geyser & Floodgate with a custom Yggdrasil authentication server (e.g. public services like LittleSkin / Ely.by or self-hosted Blessing Skin / Drasl instance). You may refer to authlib-injector for more information.

In this circumstance, "global" is the custom Yggdrasil authentication server but not Mojang. As players may have a different UUID with their Mojang account in those auth servers, the official Geyser Global API is not usable. HTTP interface for Local Linking can absolutely "work" since Global Linking and Local Linking are basically doing the same thing but in different scopes, but it's still Local Linking, 1) if a player is not linked in local then Floodgate may fallback to global (Mojang), resulting a totally wrong profile, 2) game server owners may want to build their own Local Linking while not breaking the Global Linking of public custom Yggdrasil auth servers.

[tnqzh123]

One use case of custom Global API is using Geyser & Floodgate with a custom Yggdrasil authentication server (e.g. public services like LittleSkin / Ely.by or self-hosted Blessing Skin / Drasl instance). You may refer to authlib-injector for more information.

A bunch of servers are already doing this. Before the sunset of traditional username & password login API, it's okay since players could just enter their credentials in those custom Yggdrasil auth server and authlib-injector will handle these calls of the login API to the custom Yggdrasil auth server, but for now Global Linking / Local Linking is the only way to do this. You may refer to yushijinhun/authlib-injector#230 and yushijinhun/authlib-injector#295 for more information.

[Tim203]

if a player is not linked in local then Floodgate may fallback to global (Mojang), resulting a totally wrong profile

This is only true if you've enabled global linking, which is something you should disable if you want to use your own auth server.
If the player isn't linked locally and global linking is disabled, Floodgate will use the Bedrock's XUID as UUID.

game server owners may want to build their own Local Linking while not breaking the Global Linking of public custom Yggdrasil auth servers.

I don't think that this something that should be in scope of Floodgate. Using a custom authentication server is already unsupported territory and having to consider this use case too would be pushing it. And if we were to add a http local linking type, there's nothing stopping you from implementing such a fallback system yourself. Your local linking http server could call auth server's global linking endpoint and return it, Floodgate would blindly accept what is returned from that endpoint.

By using your own http local linking you'd gain the functionality you want to see, without the downsides that using a different global api would bring to the wider Minecraft community.

[tnqzh123]

And if we were to add a http local linking type, there's nothing stopping you from implementing such a fallback system yourself. Your local linking http server could call auth server's global linking endpoint and return it, Floodgate would blindly accept what is returned from that endpoint.

Then for /linkaccount and /unlinkaccount, how to distingush whether the HTTP Local Linking interface is a real Local Linking or a "Global Linking"? Some public custom auth servers may only allow account linking / unlinking on web, and bad designs in game may lead to confusion. Or will you just recommend turn it off in this circumstance?

By using your own http local linking you'd gain the functionality you want to see, without the downsides that using a different global api would bring to the wider Minecraft community.

Just curious: wdym "downsides that using a different global api would bring to the wider Minecraft community"? IMO others don't use custom Global API / custom auth server won't be affected at all. I'm not familar with Geyser ecosystem, a more clear explanation would help me to evaluate the feature we're talking here better.

Thanks for your patience, hope these questions won't be too pushy!

[evan-goode]

Yes, I'm also thinking of the custom authentication server use case. I absolutely understand why a single global API is preferable for linking Microsoft BE and Microsoft JE accounts (ideally, Mojang would offer this API themselves, right?). But Floodgate could also be useful for linking Microsoft BE accounts and JE accounts on some other authentication server. @tnqzh123 and I are imagining a design where the JE authentication server also implements the Floodgate linking API. In that situation, the linking API server is still "global" in the sense that there is a single linking server for the authentication server, and all MC servers using that authentication server should also be configured to use that linking server.

HTTP local linking sounds promising too.