First of: Protection is *not* an expression of not trusting players. Protection can be helpful even to players who have no griefing at all in mind and just place a torch or dig something in order to get told who build that nice structure on that area they're currently exploring. And it does save time as the building will be safe from unwanted modifications. Nobody has to constantly check for griefing. buildings are save, admins can concentrate on other tasks.

Some of the concepts discussed here are far too complex for everyday use. Most of the time, some simple checks are more than sufficient to filter out those who have no real idea what the game is about. And even the most elaborate check will not be safe enough to filter out people who will eventually grief. Even requiring the players to build something nice before beeing allowed access to more advanced areas is no guarantee for anything.

Attemts to self-govern or to trust overly in automation are usually the first systems that are bound to fail. Griefers love voting systems! They'll be the ones sitting there and kicking your builders out - not vice versa. Just have a couple of trusted (i.e. known) moderators who can act when needed. Human intelligence is far more suitable for this task than any automatization.

I've thought about diffrent areas for new and for more experienced players recently. Just having a place - maybe the only area the new player can build - and grant rights for the players to truely interact with the rest of the world after they've proven that they can handle it. But in the end it may not gain much.

If you want to help young kids, a skyblock server might be best. It hands out easy-to-follow goals to new players and offers progress by seeing how the own island expands.

So I'm aware I am necroposting the thread, but I thought it best to keep this stuff together...

Prologue

I wondered if over the last two years anybody came up with further ideas? In an ironic flash of laziness and by necessity due to mobs' behaviours, I put something in place that covers some of the concerns we discussed way back when.

Some time ago, I created a mod called "rspawn" which simply caused the player to spawn somewhere random on the map. Originally, I had intended it to allow singleplayer to get new spawn places in a map, rather than create a new world everytime they got bored of their central spawn.

When applied to a server though, this means that the chance of two players ever sharing the same space is reduced drastically. When I decided to open "Not So Simple Server (Mk IV)" I had one main preoccupation: minimal administration activities. I did not want to build a spawn hut because 1) I am a rubbish builder, and 2) also to not have to deal with griefed spawn areas, and 3) NSSM mobs swarm central spawn points. Adding "rspawn" to deal with these base considerations was my first motivation.

Over the last month, some players suggested enhancements to the random spawning to allow players to play together once more. We ended up with the combined concepts of "guests" and "towns", where players could invite eachother to their spawns as explicit guests, or even open up their spawn to the wider player base as a "town" to visit, whilst spawn owners and their explicit guests were able to ban other players from their spawn-town. If a town-banned player approaches a spawn they are banned from, they get sent back to their own spawn. A buffer zone, in which they receive a warning first, prevents this from being too much of a surprise.

Having the "town" system also allows the creation of a central hub building - so whilst there is no "spawn building", you can still have a social centre open to all as an option - several, even.

I also added SmallJoker's "channels" mod, and augmented it with the ability to invite other players, as well as providing admins and moderators (who have "basic_privs" and/or "server" privs) to send a chat message to all.

The Delegated Subspaces Approach

This effectively created the following situation:

* the environment is hostile, and death on the road is a likely possibility. * players seeking to deliberately destroy builds need to go out of their way to find someone's build* groups of players have the ability to congregate in a single space at-will, and have control of that space; unless they open the town, it's only really shared amongst trusted peers. * players can forcibly evict others from their space, or allow their allies to do so (their own team of moderators, essentially!)* players can retreat to a safe chat space at will (via `channels`), to avoid chat spammers.* protectors still provide the final line of defense against greifers who get into a town before they are town-banned

Put another way: Players are each given their own sub-spaces to self-govern, with grief management and expulsion delegated to the players themselves.

We mentioned ways of trying to give players ban-ability based on trust points or merit etc - this implementation effectively gives them a full-on, arbitrary eviction ability on their personal space.

Referring back to CuriousNoob's UNIX agalogies, we essentially created a sort of "reverse container": whereas in operating systems you "mistrust-by-default" and add containerize potentially untrusted process and memeory sapces, the game uses a "trust-by-default" model out of the necessity of allowing exploration, but permits fencing out individual untrusted entities. The guest and town banning mechanism effectively extends this idea.

Of course, my current implementation is rudimentary - there are probably plenty loopholes in it at the moment, but I thought it would be interesting to share this approach I pretty much stumbled on by accident, namely the idea of owning space around a single point and being able to delegate "eviction" to owner and friends.

Corollary

The main combination I think that provides it in this implementation is:

* a hostile environment -- mobs and survival type servers probably provide this, raises the barrier to reaching another player's location uninvited, and the cost of doing so high

* players owning a distinct single space they can ban from -- random spawning does it for me, but any way to give players their own land can work - Skyblocks' procedural spawn generation works too, even if it's predictable in layout.

Allowing players to self-define their personal central point works too, if you can ensure they are likely to be sufficiently spaced out...

* ability to evict players, and keep them focibly evicted -- the defined single, fixed territory per player helps both as defining the area to protect, as well as giving a place to send infringers to. I built it into the spawn commands, but perhaps it can be isolated out?

Comments, extensions and further corollaries on the back of a postcard welcome!

Please consider trying, or at least checking out, mt2fa as an alternative method to build a more mature playerbase. mt2fa can be configured by the server operator to require an email confirmation on signup or even every login.

Mostly I'm applying @taikedz method of player screening. My server is small and unpopular that makes everything easier to manage. Players usually stays less than 5 minutes, but I dont know why some stays for weeks or months. They are good players, nice to each others and generous. The biggest threat may be my own curiousity that a single keystroke can send the server to be inoperable. And some keypoints to make administration easier while still give players some degree of freedom are:

I have few players but I can say them hardened players. Creative yet combative that I dont want to mess with them. Players will leave eventually and let them have good time during that time in our server.

Only my way of saying 2 areas per account but they may have alts and make more area protection. Asking permission from admin to make protection is inconvenient. Using protection nodes litter landscape. And unlimited protection sounds greedy. I dont know how to say properly may be.

I get the idea. I agree, that protection nodes looks horrible. Areas often become dormant though, creating protected ghost towns. Perhaps if the owner doesn't visit the owned areas within a certain time frame the protection should be lifted.

That sounds more practical than lifting protection nodes one by one. But at the moment i'll leave buildings by players as it is. It's kinda interesting to find one of them since we dont have idea where other players live.

I'm not sure I like the solution however, as there are some concerns...

First off, the purpose of 2FA tends to be to allow users to ensure their account is not taken over by a different user ; the topic here is more geared towards ensuring bad players, even under their own name, don't get to the griefing point. Having a player use an email address mitigates this a little, but addresses are cheap commodity...

Secondly, a Minetest server is not like a company with a legal entity, that may be audited and held to account. Creating an environment in which it is felt natural that any server can ask for your email address is, in my opinion, more likely to do harm than good. Rogue server creators can easily use this to steal access to players' email accounts and identities (password re-use as you probably know is woefully common).

Finally, as a server operator, I would not want to handle players' real life information through a Minetest server, especially given the number of youngsters play on these servers. Requiring email would deter some, but I cannot guarantee that a few younger players won't just bilndly enter their details out of ingrained habit.

I also saw in the documentation that you run the server component to facilitate email transfers (is that correct?) From a data safety and GDPR point of view, this is not workable. Handing over players' data to a third party requires a server operator to trust the services they are sending the data to; comments on legal entities and auditability apply here again.

I would be concerned that more conscientious players (the ones we in fact want!) would be deterred, the naive players would become easy prey to unscrupulous server operators, and troublesomely bad actors would be relatively unaffected.

To be fair, I *have* been thinking of a 2FA system in which the 2FA server would be the sole entity handling players' real data, allowing any other server to use playernames + tokens and callbacks to validate users, allowing the 2FA server to be the sole entity that needs auditing. It could also serve as a social hub for bragging, so the cost of having bans on an account becomes higher. Thoughts on napkins for now, not gotten round to implementing it yet; I'd be interested to know if someone has done something like this already...

taikedz wrote:First off, the purpose of 2FA tends to be to allow users to ensure their account is not taken over by a different user ; the topic here is more geared towards ensuring bad players, even under their own name, don't get to the griefing point. Having a player use an email address mitigates this a little, but addresses are cheap commodity...

yes and no. bad actors will circumvent any measure. However, most players are not bad actors from the start, and will build up a sizable amount of logins and time on servers. Having the potential of losing access to many servers because of a bad act is a good deterrence for those players, and we want to work on making better players, and reward them. The focus isn't to correct players who are always bad, you can't anyway.

taikedz wrote:Secondly, a Minetest server is not like a company with a legal entity, that may be audited and held to account. Creating an environment in which it is felt natural that any server can ask for your email address is, in my opinion, more likely to do harm than good. Rogue server creators can easily use this to steal access to players' email accounts and identities (password re-use as you probably know is woefully common).

Finally, as a server operator, I would not want to handle players' real life information through a Minetest server, especially given the number of youngsters play on these servers. Requiring email would deter some, but I cannot guarantee that a few younger players won't just bilndly enter their details out of ingrained habit.

I also saw in the documentation that you run the server component to facilitate email transfers (is that correct?) From a data safety and GDPR point of view, this is not workable. Handing over players' data to a third party requires a server operator to trust the services they are sending the data to; comments on legal entities and auditability apply here again.

mt2fa's server (that I operate) has a privacy policy that I believe to be in compliance with the GDPR. Server operators do not retain the email address, it is only once relayed directly through. I see your concerns, but in the larger scheme of things, and with the privacy policy in place, I feel this is a minor concern.

taikedz wrote:I would be concerned that more conscientious players (the ones we in fact want!) would be deterred, the naive players would become easy prey to unscrupulous server operators, and troublesomely bad actors would be relatively unaffected.

it depends. If good servers for conscientious players are successfull, it works the other way around. The only way to get an idea if this works for (some) players is to try it, and mt2fa is the first implementation I made for this sort of system-of-trust. Other systems-of-trust may also be created and work better, or, maybe better for (some) other players.

Now that there is one such system, it may be easier to create others, and I believe this is in the best interest of users and server admins alike.

taikedz wrote:To be fair, I *have* been thinking of a 2FA system in which the 2FA server would be the sole entity handling players' real data, allowing any other server to use playernames + tokens and callbacks to validate users, allowing the 2FA server to be the sole entity that needs auditing. It could also serve as a social hub for bragging, so the cost of having bans on an account becomes higher. Thoughts on napkins for now, not gotten round to implementing it yet; I'd be interested to know if someone has done something like this already...

mt2fa contains backend code to relay ban information, I just need to add more hooks and implement it. I'm also interested to allow TOTP type 2fa work in mt2fa. If you can, check out the server side code as well.

I still feel my "secondly" point still stands - I don't think it's the game server that should ask for the email address, but the 2FA service itself. This would also allow any game server to attach to any 2FA server it decides to trust, whilst allowing the player to only have to trust a single party...

Re the client side code and server side code - hadn't seen that the server component was published, thanks, will indeed take a look. Indeed I may try to implement something in turn as I've been meaning to for a while, and being able to study your approach will be a great help, so very much, thanks!

taikedz wrote:Handing over players' data to a third party requires a server operator to trust the services they are sending the data to;

Nope, trust is not part of the GDPR. The minimum here is that the server owner gets consent from the players before sending the mail address to the 3rd party and has to inform the player who the 3rd party is and how to contact them and what data is transferred and for what purpose.

taikedz wrote:Handing over players' data to a third party requires a server operator to trust the services they are sending the data to;

Nope, trust is not part of the GDPR.

Indeed, sorry I should have changed paragraphs or something.

I meant that as a server operator, I want to know that third party servers to which I send my users' data have been audited - basically, "what it says on the tin."

I don't want to get into what sofar is or is not able to provide as service or credentials (honestly, I'd trust anything offered by the core devs in preference to something hosted by anyone else; even if I came up with something under my own model, I'd rather push for it to be hosted in fine by the core team - not by taikedz-random-user). The point is, I feel the model needs further refinement. Game servers should not know users' IRL info beyond their connecting address.

This was a design choice, and it could be changed. The main reason that the email prompt currently is on the server as you login because it makes things a lot simpler for the player.

The alternative is that the player gets a link, or token, and then has to manually type this token into a webpage. Because minetest doesn't handle links, and because copy+paste doesn't work from minetest in many cases, this is unworkable and therefore a non-acceptable solution.