[Feature Request] Allow servers to declare permissions (e.g. which features comply with their rules)

[QarthO]

To follow Modrinth guidelines, you've had to made some adjustments to the features in order to upload to the site. I'm requesting in addition to requiring the user to be operator, or creative mode on a server, you also include a permission node. That way for servers who are okay with players in survival mode to use the full feature, they can still use the Modrinth version. This should also follow the guideline, as the server is providing the opt-in/opt-out permission node.

[MattSturgeon]

Upon initial investigation, there appears to be multiple implementations targeted at different server platforms (Bukkit, Spigot, Fabric).

Do these permission systems report to the client what permissions are available? If so, how and how consistently with each other?

[QarthO]

For Bukkit-based servers (spigot and paper will follow the same bukkit implementation) there will need to be a bukkit plugin made that will be the be the messenger to the client. It will supply the bukkit-permissions to the server, and when a player has the permission, the plugin will then tell the client.

For fabric, you would need to have the mod installed on the server doing the same thing.

https://luckperms.net/ This is the permissions plugin that basically every server uses, (bukkit/fabric/forge)

I've only worked on bukkit implementation, so not too sure how it would work on fabric, but can look at the implementations that other mods on bukkit servers send messages to the client such as.. https://modrinth.com/plugin/simple-voice-chat https://modrinth.com/plugin/ping-wheel-plugin

So basically when the player joins, if they have permission to ghost thru blocks (which would be handled by the server's freecam plugin/mod), you'd send a message to the client saying it is allowed. If the server either doesn't send a message, or the message says you cant, then you'd do nothing (the current implementation)

Hopefully this makes sense

[MattSturgeon]

If bukkit/spigot servers always sent a permissions packet automatically when joining a world it'd be a pretty simple feature. But needing to write & maintain an additional server-side mod/plugin makes this a little more effort.

Not sure @hashalite will be interested in doing that.

TBH if were writing server code, it begs the question why don't we just grant the player Spectator mode perms?

[QarthO]

I think all that needs to be done on Freecam's side is accept the capability to recieve a message from the server. And let the community or other developers maintain a server "addon" that will communicate such.

I would be happy to develop and maintain the bukkit side of the server plugin.

And spectator mode and modrinth freecam are two completely different things. There's a reason the mod exists even when all servers and singleplayer worlds have spectator natively.

[Lord-Memester]

Slightly different request: given that modrinth required some changes to the mod, could there be a curseforge version that would be exempt from this?

[MattSturgeon]

given that modrinth required some changes to the mod, could there be a curseforge version that would be exempt from this?

Not sure what you're requesting, because the Curseforge/GitHub release doesn't include any of the Modrinth changes.

I guess you mean this feature specifically should only affect Modrinth? I agree. On the normal build it either wouldn't exist or would be an opt-in feature.

[MattSturgeon]

On the normal build it either wouldn't exist or would be an opt-in feature.

On reflection I'm going to take s subtly different stance. My understanding is @hashalite agrees with me on this:

If we added a way for servers to tell us how our features fit with their rules, we shouldn't just ignore server rules on any of our builds. IMO this would give off the impression that we endorse cheating.

Instead, I think we should have a system where modrinth builds have certain features disabled by default (like they already are), and other builds have them allowed by default. Server perms/config could then explicitly mark features they care about as either "allowed" or "blocked" and we could respect that on both builds.

For modrinth builds, that'd mean servers could enable features we otherwise have to block.\ For other builds that'd mean we'd respect servers who care enough about their rules to add an integration with us.

I hope that summary isn't too confusing.

[QarthO]

I believe I'm following what you're saying and I really like this approach.

My guess is this would require the server to have Freecam installed in order to have the features be enabled, (ie. If a client joins and doesn't receive any freecam message from the server it assumes all the configurable features are disabled). Correct me if I'm misunderstanding.

So this approach would mean a server implementation would need to be developed to support a config, which both forge and fabric easily support being in the same jar.

Technically can be done as well for a bukkit plugin but IMO makes more sense to have it separate. I'd still be happy to make and maintain an external 3rd party bukkit version that'll just send the same data to the client and mirror the config

[MattSturgeon]

If a client joins it assumes all the configurable features are disabled [by default]. Correct me if I'm misunderstanding.

For Modrinth Edition, yes, servers could enable features we normally block.\ For normal builds it'd be the opposite; features would be enabled by default, but a server could choose to block specific features.

My guess is this would require the server to have Freecam installed in order to have the features be enabled [...] So this approach would mean a server implementation would need to be developed to support a config, which both forge and fabric easily support being in the same jar.

My comment was a high level overview of the approach we'd take. It doesn't consider any of the implementation details. That said I can't imagine a way we could do anything without either a server-side mod or a server-side plugin. Either way, that'd be optional.

Technically can be done as well for a bukkit plugin but IMO makes more sense to have it separate. I'd still be happy to make and maintain an external 3rd party bukkit version that'll just send the same data to the client and mirror the config

I think we'd be happy to have a server mod and/or plugin as separate repos on the @MinecraftFreecam org, though it could start life as a 3rd-party project too. Do you have a particular design in mind?

Ideally it'd be based on an existing server permissions system, better yet if our client-side code can be implementations agnostic. Some servers will prefer a mod while others would prefer a plugin.