Does this mean I don't need plugins to set permissions now? Bukkit just provides the concept of permissions, you'll still need to get a plugin to tell bukkit which players should get which permissions when. Don't worry, SpaceManiac made a simple plugin that I'm recommending to use! http://forums.bukkit.org/threads/ad...-0-official-default-groups-plugin-1000.26785/ If you're a small server or group of people, you don't technically need a plugin for permissions. As long as the plugins you're using had set defaults then simply giving someone op should give them the permissions they'll need for op-related tasks. How easy will it be to convert from (some old permission plugin) to Bukkits? It would depend on the old permission system, but I am quite sure that people will make tools to help convert you over. If the developers of that plugin wish, they could even make the old api compatible with the new one to make the transition seamless. Why is there a permissions.yml? I thought bukkit didn't save permissions? Server owners can create their own permissions here which we believe will help make your lives easier with other plugins. The possibilities of the usefulness of this is quite extensive, but the most popular case would be that you can create a permission that contains other permissions that you assign people often, and then you only need to assign people this new permission. What does the Bukkit permission API consist of? The API we are providing is just an API and minimal implementation. There is no groups system or ways to store permissions for players. We provide the concept of permissions and plugins will be required to still tell bukkit which permissions to give to who, and when. Do I have to register my permissions in plugin.yml? No. It's entirely optional to register permissions at all. However, I recommend that you do so that you may provide a description of each permissions and set a default. Also, you can set "shortcut" permissions in plugin.yml to let people easily pick groups of similar permissions using a single node. Can I register permissions outside of plugin.yml? Certainly! It's a simple getPluginManager().addPermission(new Permission(.....)). Note that this will throw an exception if there's already a permission registered with the given name. How do I test if someone has a permission? Easy! player.hasPermission("my.plugins.permission"). If they don't have it, this'll default to whatever the default value of the permission was (if it isn't registered, it'll default to false). What defaults can be set? You have the following 4 options: true, false, op, not op. The "op" default will be true if the player is op, and the opposite for "not op". Bukkit has no group system, but I need to know what group they're in! In almost every case that plugins need to know the group of a player, they're actually trying to figure out if they have permission to do something. In this case, please just use a permission and see if they have that! In the other cases, which I can only think of being for display purposes (like a chat prefix) you will have to reference a plugin directly as normal. But I would still advise another approach to this, such as using permissions as normal. For example, if you're trying to figure out which group should have which chat prefix, have a config file listing permission nodes -> prefixes. The server owner sets which node you should set on, and if someone has this node give them that prefix. What are "child permissions" and "parent permissions"? Permissions may contain other permissions; we call these "parent" and "children". If you give someone a parent, they automatically have the children set as per the parents requests. What happens if I give someone a parent permission, and set it to false? It will invert the children. If a child was normally set to true inside the parent, then it will now be set to false (and vice-versa). Why aren't there * permissions in this system? Because we solved the issue that * was trying to work around. Now you can set entire groups at a time with parent/child permissions, and also permissions can default to op/notop. We advise plugin developers to create a * permission as a parent to assist users.