tl;dr: Are alts surely punished?

I set

punishAlts: true
denyAlts: true

in my config and did a clean restart, just to be sure.

Then I searched for a user with a known alt and used bminfo to verify that BM knows about.
After banning one of these alts I checked with bminfo again if the ban was successful.
Currently banned for test by Console at 15-03-2016 09:33:26 which expires in 23 hours

Then I checked the alt with bminfo as well, but it seems that this account has not been banned too.
Maybe this information is missing at the bminfo of alts?

Unfortunately I could not test this by logging in with their accounts to verify who was really banned. I just checked with bminfo.

BM5.9.0

I should clarify the explanation in the config a little more. punishAlts applies on join, rather than commands.

Hm no, I think it is okey as it is for now.
I think you mean an enhancement for the ban command for example like ban -alts Stupidplayer being stupid to ban any known alts as well. But not sure how this could be handled if the alts were not known at the time when the ban happened....

Anyway. As enhancement there could be kind a whitelist for alts. As you described at the config this can affect brothers and sisters.
The main reason for the punishAlts and denyAlts is to prevent rule breakers to bypass a ban or mute. Often seen by joining new players moments after another player has been banned.
But if I enable this feature in production environment and a well known long time user with a brother gets a tempban or whatever, he will be punished as well, but we know in fact that this is another individual and no "multiacc" to bypass a sanction.
So I would like to see if an exception can be added for known/trusted alts. This could be permission-based as well but I would like to allow rank lower team mates that do not have access to set permissions to whitelist players as well. A command-based solution with database store would be more comfortable. Like trustalt <playername> (and untrustalt <playername> to reverse) for example.

So if there were three players, let's call 'em X, Y and Z using the same IP.
X gets a trusted alt. Y and Z are not, because we do know trust them or don't know if these are individuals.

• If X gets banned, Y and Z will not be punished.
• If Z gets banned, Y gets punished as well, X not.

Maybe not the best example, because when I would know about two brothers which are individuals I would trustalt both of them of course.

Having a static list of "trusted" players doesn't give you much useful information unless notes are attached as well.

What about a bi-directional relationship between players instead?

addalt <playerX> <playerY> <reason> addalt playerX playerY Siblings

This could then be used for features like duplicateIpCheck warnings on join. The message can simply not appear, or state X is not an alt of banned player Y instead. I am sure there would be far more uses than just this one example.

Ah okey. Did not know that.
So basically player X gets banned for one day. Then player Y with the same IP address joins two hours later and gets the same one day ban applied.

Correct.

I do recall a feature request a very long time ago asking for a flag of some sorts for player commands to affect alts (players with the same ip address). Perhaps something like that would suffice instead?

Yes, you are right. Does not make much sense if no one knows the relationship between various trusts.

How would you handle the situation if a 3rd sibling should be added to the group?

Good question. Initial thoughts, similar to a member/group relationship:

trusted_alts table

alt_id, created, reason

trusted_player_alts table

id, alt_id, player_id

This would allow for limitless alt relationships, and be multidirectional; i.e. player A can be a trusted alt of player B. Separately, it caters for when player B can also be a trusted alt of player C, but not A (E.g. A and B are the same person with multiple accounts, where as C is a sibling, therefore the relationship needs a different definition).

However, this will create some difficulty with regards to how commands would work.

Quite complex solution for a (in theory) simple problem ^^

Indeed, however I'd prefer to do it correct the first time and cater for as many scenarios as possible.

My main concern is with commands. I suppose if <reason> is optional if one of the listed players is already part of a trusted alt 'group', it would make it easier to handle adding additional alts

Agreed. Also it is a Ban_Management_, therefor it is kind a justified 😁

If you have an existing pair of accounts with reason already provided...well either the reason provided with the command to add a 3rd account is ignored or overwrites the existing reason or adds the new reason to an array of reasons. None of those is the best solution in my eyes, but I also have no idea how to solve this (yet).