Docs for the Sponge permission system


I’m currently working on a plugin and I want to create a permission system based on the sponge api’s permission system (creating/managing groups, contexts, etc) but the sponge docs only got me so far. I don’t know if I’m just missing the obvious, but the explanation seems to be missing some implementation details. For example how to create a group and assign a player to it (and I don’t fell like going through source code at the moment).
Before I’m going to go through other peoples code I wanted to ask if anyone has a good documentation, explanation, resource, etc on the sponge permission system (even a well commented plugin would be helpful, but I’d prefer actual text first).

Thanks in advance!

The reason why permission groups are not in the doc (probably … I didnt write it) is because the Sponge API has nothing to do with permission groups.

As you know you can apply permissions to a single player. That bit is explained in the docs.

How permission groups work is its essentially a single object that holds the UUID (or some other way to identify a player) and the permissions that the group should have. When the player joins the server, your plugin gets the group the player is in and then applies the permissions set inside the group to the player.

Thats the very basic idea of permission groups, simple classes. You can then add more advanced stuff like inheritance and stuff, but the only Sponge API that permission groups use is the applying of permissions to a single player, the on connection of a player event and the launch plugin event.

I’m going to take this at face value and presume that by creating a permission system you mean that you’re trying to implement the PermissionService. The PermissionService is not an easy service to implement, and I’m interested in knowing what would motivate you to try to rebuild it yourself rather than using an existing implementation such as LuckPerms.

The docs are not designed to guide people through creating a service - if you’re trying to implement one of the major Sponge services, it is presumed that you have an understanding of how the system functions and know exactly what you’re getting yourself into. Based on your post it seems like you’re still new with Sponge, and I would not recommend trying to start by implementing the most important and complex aspect of Sponge outside of the project itself. If for some reason you feel the need to do so, then you should know exactly what you’re getting yourself into.

Now, in the case that you’re just creating a plugin that would use permissions, then you’re looking in the wrong direction. As a developer, you should only be concerned with what permissions a subject has, not where those permissions came from - that’s left up to the implementation. Any changes to permissions or groups I feel are best left to the server owners to do through their permissions plugin on their own; it should not be something that you are changing yourself.


Ah I see, I didn’t know that I had to implement the entire service, but that makes sense now that I think about it. The only reason I want to implement it myself is, to get to know the Sponge API better. I do not plan on realising the plugin in any way, so I’m just messing with my own server as a little side project.

Thanks for the quick reply.

1 Like

This is entirely untrue. Sponge’s permissions API exposes group data in the same way it exposes user data – if service is a PermissionService, a group’s permissions could be accessed by doing service.getGroupSubjects().get("group name").getPermissions(context), and a user can have the group added or removed as necessary. Sponge’s permissions API does not specify how the data must be stored – it contains only interfaces, not any concrete classes.

As stated by Simon, the permissions api is complicated and I haven’t seen any good reasons to start a new plugin rather than contributing to or forking an existing one.

1 Like

I found that out by now, but I’m still going to do it myself. For example I want to customise the way the permissions are stored and it’s also a nice way to learn how it actually works. Since I won’t release the plugin, there is no harm in doing so, I’m just curious.
But thanks anyway!