Migrate to fabric-permission-api-v1

[ThatCuteOne]

The Problem

Fabric is moving towards fabric-permission-api-v1 (included in the normal fabric api ) i feel like for compatibility reasons this should be implemented

A Solution

Migrate to fabric-permission-api-v1

Alternatives

Add support for fabric-permission-api-v1 but also still support fabric-permission-api-v0 from lucko. This would be more maintain cost though since you are supporting 2 apis

Anything Else?

not sure if i should have put this as a bug report or feat

[me4502]

Thanks for making this issue! I'd been a little OOTL on Fabric permissions developments so was not aware this change had occurred.

Add support for fabric-permission-api-v1 but also still support fabric-permission-api-v0 from lucko. This would be more maintain cost though since you are supporting 2 apis

Just in terms of this one, are you aware of the status of the various permissions mods, and how they've adopted -v1? If they're still fairly split, it might be that we need to keep -v0 around for a little while either way

[me4502]

So from having a quick look over the new Fabric permissions API, it honestly seems it has a few odd design decisions that will limit things a bit. Firstly it partially inherits some of the design oddities of NeoForge's permissions system, but thankfully not in a limited way that prevents a mod like WorldEdit from interfacing with the system.

The main two oddities I see (both workable realistically) are:

• Need to create an instance of Identifier per permissions check. This is fairly wasteful/churny when it comes to memory usage. These could theoretically be cached, but that is more a band-aid solution that doesn't scale well when dynamic permission nodes are at play.
• The usage of an identifier means it requires a different permission node format to the rest of the MC ecosystem. Theoretically we can adapt to this as all of our permission nodes begin with worldedit., eg worldedit.whatever.whatever; so we can use worldedit:whatever.whatever fairly easily from a technical standpoint (although again, adds a layer of computation waste). The larger concern is from a user experience / documentation perspective. I guess that side will depend on how permission mods actually decide to show that to users.

[me4502]

I've written and tested a proof of concept implementation of this, and discovered another (potentially larger) issue. As the API uses Identifier, it inherits a very strict set of allowed characters in the permission node. We have a fair few dynamic permission nodes that are based on various things such as file names, player names, etc. It's very possible and even likely to have a file name which doesn't match the allowed character list for an Identifier. There's not really a clean way around this without introducing weird points of confusion/security holes/etc.

[ThatCuteOne]

I dont know that much about permissions and on how they work but maybe it could be benfical to see how luckperms implemented it
https://github.com/LuckPerms/LuckPerms/blob/master/fabric/src/main/java/me/lucko/luckperms/fabric/listeners/FabricPermissionsApiV1Listener.java

[me4502]

Thanks, this is more about limitations in the API itself, rather than questions around implementing it.

This issue has been closed by 8cc045f, with a follow-up PR on our docs to document the limitations imposed by this API which affect the end-user: EngineHub/WorldEditDocs#79