feather-rs / feather

A Minecraft server implementation in Rust
Apache License 2.0
2.58k stars 143 forks source link

Permissions Registry & Support for Vanilla's OP System #484

Open ambeeeeee opened 2 years ago

ambeeeeee commented 2 years ago

Through discussion in previous months on the discord, I think(?) the idea of supporting Bukkit-style permissions natively. We must, of course, additionally support the Vanilla-style OP system since it is actually weirdly a part of the protocol. This issue outlines our steps forward in implementing this feature, considerations, and future steps to complete it.

Now

Our priority is to get something we can build on later, and this suits that need pretty well. The process of updating it shouldn't change much in existing usage of the permissions registry, which is a good sign that this path forward is the one to take.

The permissions system will involve two main parts:

Additionally, something similar to these types will be used to store permissions:

pub struct VanillaPermissions {
    /// The OP level
    level: u8,
    /// Whether the player bypasses player count limits
    bypasses_player_limit: bool
}

Haven't figured out how to name this struct though

pub struct FooPermissions {
    /// A map of permission keys to values
    permissions: HashMap<String, String>
}

This is the struct that will be used as a component.

pub struct PlayerPermissions {
    vanilla_permissions: VanillaPermissions,
    foo_permissions: FooPermissions
}

There needs to be chaperone types to serde the permissions, but that's straightforward.

The registry type can be whatever works, probably something like a HashMap<Uuid, CombinedPermissionsStorage>.

It's important to maintain compat, so OP level should be saved to the ops.json file.

The op level should have a magic key minecraft.opLevel or similar that causes it to be written into the vanilla permissions instead of the bukkit-style system.

For now, permissions should be able to be queried, added, loaded on server load, saved on player leave (at a minimum)

Soon

The things described in this part of the issue are things we need to do soon, but aren't requirements (nor should they be added) for the first implementation of the system.

Higher priority:

Lower priority:

ambeeeeee commented 2 years ago

Should be noted that @UltraWelfare is working on the initial implementation, this is all open to discussion and will be kept up to date.