Permissions API: Non-player support?

[lokka30]

Should the Permissions API have support for non-player accounts?

• The specific term Non-Player does not need to be used: this discussion purely discusses whether (and how) to provide support for non-players.
• @MrIvanPlays discussed below that it is likely necessary to implement this as it is used by Groups. Jikoo noted that somehow distinguishing players from groups makes it possible to not implement non-players, so this poll has remained open. Regardless of the poll, the discussion goes on in terms of implementation and what-not.

Discussion derived from this thread.

[MrIvanPlays]

Yes it should because a node holder can be a group too. But the problem is naming because we dont know what else can be a node holder, not just player and group. The non player name is not suitable.

[Jikoo]

Yeah. agreed. Technically anything that can run a command or perform an action is a holder of nodes in a similar vein to a player, but a command block is not a group. Perhaps a specific way to get groups then? Unsure.

[lokka30]

Adventure uses the term Audience, though to avoid matching it, we would need to use a different name with the same effect. That is unless we decide to switch Treasury to depend upon Adventure (which is probably not a wise idea).

[MrIvanPlays]

adventure's audience has nothing to do with node holders. audience in adventure's context is either a command sender (the console) or the player, which audience may have information that is retrieved by pointers.

[lokka30]

interface NodeHolder, interface PlayerNodeHolder extends NodeHolder, interface GroupNodeHolder extends NodeHolder?

[Jikoo]

I do think that the permissions API should be capable of supporting non-players with permissions. There are niche cases where you may want to deny the console access to certain commands, set permissions specific to certain command blocks, etc. depending on details on both user and implementer ends. I think the current draft API does a good job of offering that.

As far as terminology goes, I think that NodeHolder is a good name as it stands for an object that can have nodes assigned to it, and it's relatively unique to Treasury in the Minecraft space.

I've been having some more thoughts that are more appropriate for the main API discussion while typing this up, so I'm going to go vomit my train of thought over there.

[Jikoo]

The counterpoint to this anecdote is that the console is always available on the server, its permissions should always be present and set using platform-supported methods. One assumes that the permissions implementation will bundle its own permission manipulation commands, so Treasury doesn't necessarily need full read/write access methods for every single individual. Is Treasury also seeking to serve as a full replacement for inbuilt platform permissions APIs?

[MrIvanPlays]

Is Treasury also seeking to serve as a full replacement for inbuilt platform permissions APIs?

not really. treasury permissions api is aiming to be a permissions api that sets the bare minimum standard of what a permission plugin's nodes shall consist of - in the current draft api we have that is context, weight, key and value (data). with platform permission apis you are unable to retrieve, for example, the permission context and weight, whilst with treasury - you can. another usecase i can think of is you're writing a plugin to which you want as less platform code as possible, but you need permissions - not to worry - treasury's permissions api is by your side.

[Jikoo]

another usecase i can think of is you're writing a plugin to which you want as less platform code as possible, but you need permissions - not to worry - treasury's permissions api is by your side

In that case yes, we are trying to provide some kind of equivalent/replacement of the platform's API, so we definitely need non-player representation.

[lokka30]

Thanks for your thoughts. I'm somewhat uncomfortable managing the permissions of console - firstly, it doesn't seem to be intentional by Bukkit's design, and there's no guarantee other platforms share this behavior.

---

Perhaps some servers want to allocate permissions to NPCs, that in itself would necessitate some form of non-player node holder.

[Jikoo]

Re: other platforms:
Sponge's equivalent of a Permissible is a Subject. Subclasses include the SystemSubject (console/generic server operations), ServerPlayer, and CommandBlock among other things. Unlike Bukkit, not every single entity is permissible, but there are a lot of non-player permissible things.
Minestom's PermissionHandler is basically the same as Bukkit. Any entity, console, command blocks, players, etc.