Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permission system #35

Open
Snowiiii opened this issue Aug 19, 2024 · 12 comments
Open

Permission system #35

Snowiiii opened this issue Aug 19, 2024 · 12 comments
Labels
enhancement New feature or request

Comments

@Snowiiii
Copy link
Collaborator

We want to have an good Permission system using SQL Databases

@Snowiiii Snowiiii added this to Pumpkin Aug 9, 2024
@Snowiiii Snowiiii converted this from a draft issue Aug 19, 2024
@Snowiiii Snowiiii added the enhancement New feature or request label Aug 19, 2024
@zp3x
Copy link
Contributor

zp3x commented Aug 19, 2024

I can do that.

@Snowiiii
Copy link
Collaborator Author

I can do that.

great, go ahead

@Erb3
Copy link
Contributor

Erb3 commented Aug 20, 2024

I think it makes sense to use SQLite, or a similar file-based database.

@Snowiiii
Copy link
Collaborator Author

I think it makes sense to use SQLite, or a similar file-based database.

Yep, I already had that in mind

@Bryntet
Copy link
Contributor

Bryntet commented Sep 6, 2024

Why would we want a database for permissions, and not just store it on the player? Or are we thinking its stored on both? Like its loaded from a db when player joins?

@Wundero
Copy link

Wundero commented Oct 16, 2024

Why would we want a database for permissions, and not just store it on the player? Or are we thinking its stored on both? Like its loaded from a db when player joins?

Storing permissions in a database allows the server to have a lower memory overhead, especially for servers which have large numbers of permissions / online players. Database performance is quite fast and highly optimized for memory and cpu usage, and queries against permissions are relatively simple to index, so for most practical purposes, running something like SQLite in the background will be better for performance and maintainability than storing a bunch of strings on the player's struct in memory. No sense reinventing the wheel here IMO.

I think it makes sense to use SQLite, or a similar file-based database.

I think it would be nice to be able to plug+play the database in the long run, so users who want databases running on separate servers can provide a connection URL and swap from SQLite to MySQL, PostgreSQL, or some other implementation or machine, but this would be a lower priority than just implementing it to begin with on SQLite.

@lokka30
Copy link
Contributor

lokka30 commented Oct 26, 2024

It would be very interesting if somehow LuckPerms can be ported to work far down the line. Potentially that plugin would be a great reference on what features would be useful here - particularly, design choices made in its API might be notable to consider designing Pumpkin's.

@zp3x
Copy link
Contributor

zp3x commented Nov 16, 2024

I will try to implement sources like LuckPerms as well.

@vyPal
Copy link
Contributor

vyPal commented Feb 7, 2025

(Copied from discord)
ok so I did a little bit of digging and apparently bukkit's plugin system only temporarily stores which permissions exist and which player has which permissions. It also allows plugins to query the permissions of a player, modify the permissions, etc. It is the job of a plugin like luckperms to store the permissions somewhere (like a db) and tell bukkit who has which permissions. Now the question is if we want to take a similar approach.

@BigPebble123
Copy link

Wouldn't a permission system as a plugin (just like LuckPerms) be better to keep core as close to vanilla as possible?

@vyPal
Copy link
Contributor

vyPal commented Feb 8, 2025

Wouldn't a permission system as a plugin (just like LuckPerms) be better

Well that's kinda the problem, luckperms is not a permission system. It is only responsible for storing which player has which permissions (and of course it has some other features, but those aren't a requirement). The server itself (Bukkit, spigot, etc.) contains the logic for validating permissions, and the APIs to let plugins set and query permissions.

to keep core as close to vanilla as possible?

I also see vanilla parity as an important thing for this project, however we are already quite far off vanilla parity just by having a plugin system. Now in vanilla there is essentially just the op "permission" which can have different levels to allow different actions to be performed by server operators. If we introduced a node-based permissions system (pumpkin.command.setblock for example) into the core of Pumpkin, it wouldn't change anything for users who don't use any plugins. This is because in Bukkit's node based system, there is the option to set a "default" parameter, this determines which players receive the given role unless a permission management plugin (like luckperms) says otherwise.

So in short, a node-based permission system (inspired by Bukkit or spigot) would appear to work the same as vanilla for anyone not using plugins, but for servers using plugins, it would allow them to coordinate permissions between each other without having to all depend on an extra plugin

@Q2297045667
Copy link

Wouldn't a permission system as a plugin (just like LuckPerms) be better to keep core as close to vanilla as possible?

I think with the current capabilities of the Minecraft community,it’s unlikely that anyone would develop a plugin like LuckPerms,or we could just build in a simple permission system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

9 participants