User:OrangeStar/world-domination-plans

This is a list of (probably bad) ideas I've had. They're not on Tech:Projects since I've never really discussed these with anyone else, so it's not like these are going to be implemented on Miraheze. They're published here since someone may find it interesting anyway.

True SSO with OAuth + WSOAuth
This is the CentralAuth killer.

This idea involves building a new loginwiki running OAuth, and having the rest of the wikis run WSOAuth + PluggableAuth. Loginwiki would now serve as the GlobalUserPage wiki and also host the OAuth consumers for these wikis.

Users logging in to any Miraheze wiki would be redirected to loginwiki first, where they can authenticate via password and whatever they're running as second factor, then click authorize in a form similar to the one that appears when logging in to Phabricator.

Better support for WebAuthn
While WebAuthn is running on Miraheze (T10700), it doesn't really support CentralAuth setups. This is because of one of the properties of WebAuthn, anti phishing.

The authenticator only works on the domain where it was registered. If you register it at Meta, you'll have to go to Meta everytime you want to log-in to Miraheze, you can't go to AVID's Special:UserLogin and login, it won't work. This problem is also faced by Wikimedia: T248339. The current situation isn't great in terms of user interface.

This new setup would fix this because all login attempts would redirect you to loginwiki, fixing the issue completely.

Remove known CentralAuth issues in Miraheze
CentralAuth doesn't like it when you have many local accounts. Notably, one user reported this on Discord.

Their global account was attached to more than 3000 wikis, which CentralAuth couldn't handle. Another user, CosmicAlpha, also reported CentralAuth failing on them. Similar issues are faced by the Stewards when renaming accounts, which led to the creation of global renamers.

This is a problem that's only going to get worse as time goes on. As users navigate all the various wikis and attach their global account to an ever-growing number of local accounts, these issues will just get more common.

These issues would be fixed in a setup like this.

Why it will never happen
And now, back in reality:

Wiki creations
This setup would kill CreateWiki because wiki creations would require SRE intervention to perform the OAuth registration for the new wiki. This would take a lot of collateral with it, like Wiki creators (unless they want to join SRE, that is) and ManageWiki due to it depending on CreateWiki being installed currently.

In my opinion, the ability for wiki creations to be performed on wiki is what led Miraheze to grow like it has. Changing radically our way to request and create wikis to a potentially less-user-friendly way is not good.

Renames
Hopefully you'll never need that your account be renamed! As global renames are implemented in CentralAuth, they would now become impossible to perform.

This can maybe be worked around via a running foreachwikiindblist and reassigning edits to the new account, then disabling the now abandoned account. Talking about disabling:

Locking accounts
Account locking (preventing an account from being logged into) is also a CentralAuth thing. This can maybe be worked around via a new extension that just re-implements CentralAuth's locking feature, and installing that extension on the new loginwiki.

Global groups
Global groups/userrights is also a CentralAuth thing. We would likely need a new extension that implements global groups without requiring CentralAuth. How do you do that, is left as an exercise for the reader.

What do we do with our current accounts?
We would need everyone to re-register on the new loginwiki, since their previous accounts would be unusable. This is likely to cause a mess of unimaginable proportions.

Conclusion
This is likely to never happen because of all the issues mentioned above. If someone has a time machine though, you could go back in time and prevent Miraheze from going the CentralAuth route, as these issues only apply because of needing to move our current setup to this one.