Fediverse Integration: login with [email protected] and federate with other authentication servers.

[oneechanhax]

It would be awesome to have servers work like the Mastedon product, or other Fediverse products like Peertube. Your login would be similar to email usage, as "[email protected]".
https://fediverse.party/

XMPP already uses this and it works by verifying the SSL of the domain name, doing client-to-server connections, and more importantly the server-to-server connections to pass around messages between users and between group chats at domains.
https://en.wikipedia.org/wiki/JID_(Jabber)
https://xmpp.org/extensions/xep-0029.html

The "Mojang Namespace" seems like a related feature already,

-Dauthlibinjector.mojangNamespace={default|enabled|disabled} 

already having users named as username@mojang is cool, it provides an idea of how to do it already.
under federation naming, the username formats would be "[email protected]" or "[email protected]"

To perform this though, we also need a way to allow-list and deny-list specific domains since people can abuse the existence of federation. This isn't a downside or a bug, its a feature!

Building a web of trusted authentication servers is a big task to ask of a community, but it can make this authlib-injector last a very long time in our hearts.
I'm interested in hearing what other people think of this. Thank you for hearing me out with this proposal ❤️

[Maybe we can implement plugins to make specific domains read-only to worlds and the like, to prevent griefing. Would make it easy to add players to your world, but would also need more heavy modifications than just authentication edits.]

[lamadaemon]

How are you going to manage player profiles (name, uuid, and skins) and authentication process when joining a server?

Those servers will need a support for Yggdrasil Protocol. I think the best way is to modify Mastedon server for supporting Yggdrasil Protocols instead of changing in authlib-injector.

[oneechanhax]

The reply thing is a little weird,
I written this in response.
#253 (comment)

[oneechanhax]

In response to: #253 (comment)
Probably wont be able to drop-in replacement the mastedon stuff.

If we do it like XMPP, you need 2(1) servers and a client.
First a user needs to tell the auth domain that it wishes to identify with, lets say gamersnexus.com, the username will be ricky(@gamersnexus.com) to login as.
It needs to authenticate with the gamersnexus.com server first and it will receive its full username ([email protected]).

Second, they want to connect to your minecraft server spelunkingminers.net, the server will then present the authentication servers that It is using, but in this case they use a separate server to do authentication "linustechtips.com",
in order to connect [email protected] to spelunkingminers.net (using linustechtips.com to auth), the authentication servers themselves have to verify the SSL is correct (important as this proves identity and ownership)
gamersnexus.com and linustechtips.com then do a little dance to be like, "yes this is the user in question" "hmm yes, allow them i shall"

linustechtips.com will tell the minecraft server that the user wishes to authenticate and has correctly identified themself,
gamersnexus.com will then reply with the response it had received to the client and the client will proceed to enter,
Now

[email protected] has joined the spelunkingminers.net

is in chat :)

For user management and storage, I believe you can use random UIDs or using partially of the less significant bits (im unsure which those are) but there may be challenges at scale.
This certainly creates a large exponential issue since it goes from 1 server managing its own auth to managing everything possible. Random UID per authentication may be the best we have until a better method comes around.
Each server creating the UIDs as the successful authentications arrive, and only after a successful authentication.
( we should have a hard limit per domain for user creating authentications to prevent abuse, rate limiting is a must)

So in the case above after they have successfully authenticated server-server, linustechtips.com would have to create the definitive UID since it is authenticating the server being reached, and it would need to forward that information to both the server and the client.

[lamadaemon]

That's a good idea, but still not really necessary to modify authlib-injector. All you need to do is implementing a linking server for Mastedon. Players will use <name>@mastedon.example.com as their username to login, and the linking server will manage their profile (name, uuid, and skins).

However there is currently no way to solve two players logged with different services that have the same name. This issue is somehow related to project like MultiLogin or MultiYggdrasil.

[lamadaemon]

What authlib-injector really need is like what you said, the namespaces. Not just Mojang namespaces but across servers. However this will require authlib-injector to support multiple Yggdrasil services at once which is hard to implement. Maybe you can open an issue on requesting a better namespace system.

[oneechanhax]

Not sure I want to use mastedon as a requirement to do this sort of domain namespacing. Seems quite, heavy. it may do the authentication using the ActivityPub protocol which we could build on top of. could maybe be used as a secondary o-auth login or something like that.
https://en.wikipedia.org/wiki/ActivityPub

I can code in golang pretty well so far as a beginner in go, (as far as singlefile projects go)
managing state, especially fedi-authentication state, by hand, seems like a difficult challenge and nightmare.

May be a good idea to fork one of the golang auth servers and can try patching it together in a branch somehow,
I cant promise anything, but I'll think about this since its something I really want to see. Idk much about the protocols but only one way to find out what goes wrong is to trial and error and document it.

I would want to bring it up with them first to see what they think first and see if they can do it for me hehe.

[oneechanhax]

From first glance,
The MultiLogin/MultiYggdrasil is pretty neat, the MultiLogin looks like its trying to do what I am trying to achieve but are limited somewhere in how the yggdrasil protocal works.

I think instead of doing it minecraft server sided with multilogin or via the multiyggdrasil auth-injector fork, the authentication servers themselves need to do communication between themselves more.

Auth server fork to handle this auth server-to-server communication may be a todo.