Ban user

[marceldehaan80]

It would be great to have a option to ban users that don't behave.

[mcfnord]

If you run the server, you can determine the IP address of the user, and block it.

[ann0see]

Related: https://github.com/orgs/jamulussoftware/discussions/1057

[iknowkungfutoo]

It's been requested many times, but the dev team are reluctant to add it. It isn't a difficult task to accomplish; just a few lines of code to change for simple user management. Perhaps there is some political reason they do not wish to do it. Without this and with an increasing number of problematic users disrupting sessions for everyone, Jamulus will ultimately die and be replaced with another application with better "legitimate use of identifiable data" for server and user management.

[ann0see]

It's not that easy unfortunately - also technical limitations such as the fact that there are no accounts (and we don't really think that they should be added). So IP blocking would be the way. We'd need to find a way which works for everyone (remaining open by default) - and that's hard.

[iknowkungfutoo]

I have done it with IP blocking, a simple change of code to log user name and IP address to the log or separate file. A password-protected PHP script to list the last 1,000 users with a tick box and a "ban button". The script updates the iptables automatically when the ban button is pressed.

[mcfnord]

I hadn't heard before that there are "an increasing number of problematic users disrupting sessions for everyone." Would you say more about what you're seeing?

[dcorson-ticino-com]

I can only remember once being disturbed by someone.
After they didn't leave when we asked them we, the members of the group playing, simply soloed each other so we didn't hear anyone else.
That worked just fine and the disturber then left pretty quickly.
As I said, only once in about 4.5 years of weekly use.

[AndyMcProducer]

I have done it with IP blocking, a simple change of code to log user name and IP address to the log or separate file. A password-protected PHP script to list the last 1,000 users with a tick box and a "ban button". The script updates the iptables automatically when the ban button is pressed.

Pointless, as many isp's now use cgnat and shared ip's. So banning an IP could ban a large part of that ISP.
Plus getting around ip bans isn't hard but creating a user system based on ip etc can help, but still a waste of time and can
be circumvented.

It's a lot of work for little return. Who's to say who shoudl be banned, some admins will be the issue and on a power trip.
Lot of the problem comes when you get small groups and they all start feeling more important than they are.
I'm not tryign to gas light, it's just the attitudes sometimes is like you've entered an hostile enviorment.
My thought on this is if you only want soem peopel in, make a private server. But I think some groups think a server is a venue.
So if you go in and ruin their public gig ya focked so they shoudl be private but they want them public for the audience.
So this is why some built in streaming options would be handy, give it to them on a plate so they can achieve what they want.
If they own the server then they can have optiosn to mute out others they don't want in their stream wihtout muting them in the server, not all will be happy still but its a best situation out of a bad one for all. But mute and mute chat is fair play, blocking though should be a last extreme measure liek mentioned.

[JacquesFreud]

I don't know if there is indeed 'an increasing number of problematic users disrupting sessions for everyone'. Sometimes you only need one problematic user to spoil the party for a lot of other players.

In the Western European servers there is a bass player who claims he should be allowed to play in any session he feels like. Even if there is a relatively fixed group of players who maybe befriended each other in the past years and who are perfectly happy to play their favourite tunes together, he thinks he can join in and demand his place. If the bass player of the group does not voluntarily give up his place, he TAKES it and plays OVER it. His argument: your server is a public place and there are no privileges. When the other members complain, he starts firing off huge stories in the chat with muddled talk of fallacies. He never uses a microphone, so normal conversation with him is never possible. When he feels driven into the well, he comes up with tales of hatred and fascism and only a clerical group of ‘haters’ would take it out on him. However, if you inquire around you about this figure's reputation, you hear the same complaints everywhere.

So, while there is no increasing number of disruptive users, there is almost constant disruption by this one figure.
I know the answer would be to put your group all on solo or to mute the annoying intruder, but groups can maybe want to stay open to new ideas from unexpected (and nice) players. (Also, using the solo button can easily lead to unexpected mistakes. When a 'solo'd' player leaves early and comes back in your session the next day, you may hear only him, because to you he is still on solo.)

One would wish there'd be a solution to ban a spoilsport like this. Maybe not for ever, but say for a month. If he promises to behave let him in again and if not, give him two months.

[iknowkungfutoo]

It's up to the server administrator to ultimately decide.

Why don't I commit my code? Because of the massive reluctance to agree on a solution, here and in previous threads on the subject. I'd happily do so otherwise. How about we start working towards a solution rather than looking for ways not to do it? Also, my solution is tailored for Linux systems. If you want the full automatic iptables updating solution, it wouldn't be suited for MAC or PC based servers. Someone else would need to write that. But if people are willing to agree to logging the IP address alongside the username... that should work on any platform and at the very least, gives server admins the ability to easily search the log for subject in question.

[mcfnord]

Debates like these can be frustrating, because there are many strong, differing views on these topics. I've been studying how we might prevent programmatic attacks by bad actors, which I think represent an existential threat to our community. I've concluded that our defense relies on the ability to block entire IP subnet lists by ARN across all servers in an automated way. You're describing a sub-problem that I call the "anti-social drunk" problem.

Our community relies on hundreds of servers, including many that receive little or no operator attention. That's why I tend to favor solutions that "just work" without involving operators to perform additional manual steps.

I think of muting a connection as a core skill all users need to develop. That makes this person's behavior a user training exercise. I think this tends to work out OK, and it's a skill that makes our userbase pretty resilient. You are correct that a bad actor could just change their name. That makes SOLO competency another core skill, and a tricky one, with gotchas including what you've described.

I do wonder if there's a sensible solution to your observation that SOLO persists across sessions. Maybe SOLO could be forgotten after a session ends. When I use SOLO one day, I almost never want it to return another day and mute everyone else until I figure out what has gone wrong. I've wondered if we should have a global "Clear All SOLOs" button, or if this could happen automatically when some milestone is reached.

To prevent flooding the chat, I imagine an invisible feature where a connection that everyone has muted also goes unseen in the chat. Perhaps this is undetectable to the ranting party.

Sometimes a solution to a bad actor problem seems sub-optimal. ("This is why we can't have nice things.") Even a SOLO feature with more training wheels seems sub-optimal, because a good actor who wanders in won't be heard at first. But placing new steps on the server operator seems like a big ask. I favor ideas that "just work" without operator attention, because our deployed servers largely operate without operator attention.

[chrisrimple]

@mcfnord Great thoughts. I believe that the existing feature Edit > Clear All Stored Solo & Mute Settings solves for the Solo persistence issue you raise (I think it may require a Jamulus restart), although I could see an option to Clear All Solos On Exit being made available as well.

[ann0see]

To prevent flooding the chat, I imagine an invisible feature where a connection that everyone has muted also goes unseen in the chat.

This is actually a very good starting point of finding a solution to chat spamming.

I think this can be implemented (but will depend on the server side).
The question is if we want that muting channel = muting chat. I don't think that this works as there are valid reasons to mute some channel but allowing chat messages to come through (making ones mix simpler but still being able to interact with the person, helping inexperienced users who muted a conductor by accident)

[mcfnord]

If I try chatting, and 70%+ of the room has muted me... then mute my chat for those who have muted me.

[marceldehaan80]

Would be nice if there was an option to vote for a ban. So only when everybody on the server agrees. Not everybody is a server owner and it's nice to play with and meet new people on public servers. I now you can solo, but this person we are talking about doesn't leave and write the rest of the evening negative things in the chat. It's frustrating when you have a nice jam other people are leaving because of this person. Op za 26 apr 2025, 20:57 schreef Chris Rimple ***@***.***>:

…

I understand the concern, but if you're not the server owner, why do you feel that you (or anyone who is not the owner) should have "banning" rights? The server owner has opted to leave it public for a reason - those who want private servers set up their own. As has been pointed out, there are solutions in place (Mute, Solo). Adding a "ban" option that is not controlled by the server owner is very risky - the problem bass player could ban every other bass player as they arrive, and the other musicians would not be aware that those other players have been banned, etc. So banning power needs to be limited to an "approved" person(s), probably only the server owner. And what happens when the problem bassist arrives, but the server owner is not present to ban them? All that said, if some form of banning/blocking were to be implemented, I think it should only be available to the server owner (or perhaps a list of users they specify). Then, as the person paying for the server (public or not), they can decide who they want to allow to use it. — Reply to this email directly, view it on GitHub <#3485 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BPXRLKIVQOI67SYTYM7RELD23PJI7AVCNFSM6AAAAAB2ECYVS2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEOJVGY3DGNI> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[chrisrimple]

Building a system to vote for a ban, and a system to ban a user, all sounds like a lot of effort to solve a problem of one bad user.

But you raise an interesting point, that a Muted user (or one that is not Soloed) can still write in the Chat, and those posts are visible to all. Perhaps only posts by Unmuted or Soloed users should be shown. Doesn't help for the user that has just joined the server, but they also don't see any chat history, and there's an opportunity to tell them to Mute the offending user.

[iknowkungfutoo]

There's nothing to stop the bad actor from coming back with a different username. Using mute just doesn't cut it.

[dcorson-ticino-com]

There's nothing to stop the bad actor from coming back with a different username. Using mute just doesn't cut it.

As this appears to be very important for you I would suggest that you submit code that will work for all the user base of Jamulus so that the powers at be can make a decision. This is open source free software that advances only when people see a problem and solve it themselves. You can not expect people who do not see the problem as very important to spend their time to solve it.

I can imagine that a solution that would make banning users by the server owner simpler could be regarded with favor if it would work for all the user base/operating systems supported by Jamulus. And that even if the powers at be do not see the necessity of finding a solution themselves.

[iknowkungfutoo]

I said that I would be willing to share the simplest solution of logging IP address and username to a log file, which is cross-platform compatible, should a consensus be agreed for that to be the way forward.

The rest of my solution is not part of the Jamulus code base. It's a PHP script that reads the log file and presents the data to the server administrator via a password-protected webpage and as such, is beyond the scope of the Jamulus code/repository. It would be for individuals to write their own automatic solution, be it on MAC, PC or Linux. They would at least be able to browse the log file, search by username, copy the IP address and update their firewall, iptables, or whatever it is on a MAC system manually.

If people want it, say so and I will push my changes to the repo.

[rdica]

As this appears to be very important for you I would suggest that you submit code that will work for all the user base of Jamulus so that the powers at be can make a decision. This is open source free software that advances only when people see a problem and solve it themselves. You can not expect people who do not see the problem as very important to spend their time to solve it.

I can imagine that a solution that would make banning users by the server owner simpler could be regarded with favor if it would work for all the user base/operating systems supported by Jamulus. And that even if the powers at be do not see the necessity of finding a solution themselves.

@Rob-NY has already submitted code to manage a firewall via RPC-JSON interface. It's OS-agnostic. Since that's not been merged or otherwise even further considered, individual server admins are left to themselves to implement blocking.
I even advocated the inclusion of that RPC firewall code in the Jamulus 4.0 Roadmap discussion. If anything came out of that discussion regarding it's inclusion, it wasn't communicated to that thread.

Continually asking for code submissions for this functionality doesn't mean any such submission will be accepted.
There appears to be a consensus in the core dev group that this functionality will not be added, else it would have already been implemented.

@iknowkungfutoo I'd be interested in reviewing your logging solution.

[freenopen]

It would be great to have a option to ban users that don't behave.

Would be a desaster imo.

User abuse by admins

It would lead to extensive abuse and in the long run to a socially fascistoid structured community.

It would open the 'final' door for diffamation, slander and bully campaigns which you can already observe today.
(And where you even can read an example of in the posts above by user Jaques, which is built from lies and slander to create a false bad narrative (i can give a lot of evidence for that, but its not the topic/place here and slanderers and bully campaigners like that person are not worth it anyway. I'm only reffering to that as an example.)
It's one of the little dirty taboos of the Jamulus community that there are some people who use all possible means to either gain social rank and control in a group or to get rid of e.g. a 'competitor' of their instrument. Unfortunately some (or many?) on Jamulus view playing an instrument as some sort of sports competition and so play 'against' others of their instrument group. Combined with a certain personality structure this can lead to disgusting effects, also in group dynamics (to describe it 'neutral').

Cover abuse

Covering abuse is abuse aswell, e.g. cover bully campaigns.
With a permanent ban a victim wouldn't even have any opportunity anymore to defend or to clarify things or reveal lies and slander.
While slander campaigns anyway aim at the complete social exlusion of the victim (which is social murder, thats why slander/diffamation is a criminal offense), a ban is the mean to cover the abuse by victim blaming. (As it already happens in the community. Probably in all communities were it lacks open and democratic concioussness, respectively where means for such abuses are given).

Impossibility by principle of a fair decision

But the issue starts already at this points:

1. Define "don't behave"
2. Define "chat spam"

While the 2nd can be defined relatively easy - spam is:

• (commercial) advertisement,
• row repetitive posts, e.g. endless posting of random chars or nonsense, that includes also 'spamming' others comments 'away'.),
• calls for violance.

Though that can make real troubles in decisions, e.g. expression of opinion is no spam, neither is giving points in a debate.
E.g. the majority or majority-opinion, as somone supposed, in no way can be a criteria when its e.g. about someone expressing an opinion. That would indeed be fascist style - democracy and an open society is not just the rule of the majority, it is the protection of minorities and different opinions.

The definition of 1st is
a) impossible
b) would be bend for sure by some admins to serve own purposes.
By experience, also as a long time moderator of several internet forums, i can claim that there exist almost zero persons, if not 0, who are wise enough and personally stable enough with sufficient integrity to keep objectivity when its issues about themselves or their favourite persons, indepedant wether intentionally or not.

Nick Impersonation - abuse by erratic ban

As already seen many times, people use the nicknames of other users. For several reasons. One of is diffamation of the 'copied person'. E.g. joining a server and behaving 'bad' (calling people names, creating loud feedback loops, making the chat unusable by spamming random chars nonstop etc.). No theoretic case, i've seen that many times.
Later the admin bans the real person by its IP for reasons the faked person created earlier.

Abuse by 'Ban on Call'

An admin A bans person B by call of person C who claims person A would show bad behaviour, A believes C because they are friends or because it fits into his own confirmation bias or 'competition needs' or just because being not very bright.

Patronizing other players = double abuse

This point corresponds with the thread about user IP-collecting and -spreading.

As already shown existing abuse some admins applied IP-bans to users on public servers for no reasons (means discrimination by personal taste, e.g. wrong opinion, wrong skin color, personal instrument 'competitor', call/request by 3rd person etc.).
This is not only an abuse to the blocked person, it is also an abuse to the other players - in several aspects:

• The other players - nor on the specific server nor elsewhere - have any notification and no clue if and who is banned and on what server/s. It is hidden, Only the abused one and the admin know it.
  (Once someone asked me if he has done something bad to me or why i wouldn't play with him anymore, he had seen me on other servers but not joining the server he was on to play with him as we used to. It turned out he was on a server where my IP was blocked. He didn't know and thought i was angry at him.)
• The admin that way not only decides about the abused user who the one is allowed to play with or not - that admin also decides for all others who they are allowed to play with or not. With not even giving them notice. (That counts the same for a chat mute by admin.)
• 24 h ban for a 2 h need?
  An IP-blocked person is banned from a public server 24/7. Even when the blocking admin or its mates use that server only 2 h a day or week it prevents the blockled user aswell as all other players from playing with the blocked user all the remaining time on that public server. And see above: the other players not even knowing that. Can also result in this: A player sees his mates or others playing on a server, they used to play together many times with no issues. But the player cannot join the server because he is blocked. The abusive admin so prevented x players to play together. If many players are concentrated on such a server, the blocked one is totally excluded playing atall and from the community.

All means needed already exist in Jamulus

1. if you don't like a person or it's play: use the mute button.
2. if you don't like a statement of a person or a debate in chat: Either ignore it - nobody is forced to talk or write. Or join the debate and give reasoning or points. But don' try to surpress opinions by ad hominem/personal attacks or diffamation when you are out of reasoning.
3. As its even written in the Jamulus documentary: a public/registered server listed in the public server list means that everybody can join and play. If you want to control who is joining your server: host your server in private mode/unregistered.

Fazit

All in all what is listed is or leads to the absolute opposite of an open community.
And 'open' has a double meaning here: an open community using an open software. Open and free software imo stands not for 'just doesn't cost euros' - it stands for a certain, also an open spirit and a general view on society and social complexity and against the control of a few over all others and their opportunities to develop.
All attempts here to give hardcoded tools for IP blocking in the end and in abstracttion only serve that sort of people who are stuck in authoritarian mind structures and who aim for controlling others. Without even a need to - and with the common shit results that you can already see today forced by such people in the jamulus community.
The abusive use of IP-bans not only has a temporal impact - it also prevents people from their musical development, which can be a profound intervention in personal development and personal rights.

As you already could read, some even want to command others what topic to talk about in the Jamulus chat or not, or what channel someone has to use to talk (mic or written word). I even faced that some wanted to forbid me to use certain words in the chat. And i dont mean 'dirty' words or something, just normal words like 'evidence' or 'narrative'. Censorship by bad education? ;-) :D.
And such would only be the beginning.

I'm really glad and that's another of the reasons i like Jamulus so much - It's (yet) in the spirit of 'open' in all meanings and the devs immediately recognized the danger of implementing user control features like a ban feature and instantly reffered to the already given features for personal user comfort - the mute button and the server private mode.
Thx to the devs! :-)

A thematic bridge to the issue of IP-collecting: dynamic IP and static IP
_No clue how to solve/fix that issue concerning IP-blocking. Some people got dynamic IPs others a static IP. This opens another issue with IP-blocking.

1. People cannot join a public server because they got a dynamic IP that is blocked earlier used by someone else. (This can include a range of x-hundredthousands of IPs)
2. An admin becomes aware that a blocked person got dynamic IPs and so starts blocking whole IP-ranges/subnets to be sure to 'catch' the right one. Which excludes x users from the server. (I figured out that one Jamulus admin of a public server blocked more than round 400.000 IPs to match one user.)
   How does that comply with the (european) state laws for public spaces that forbid discrimination/privilegues when already banning one person for no resaons, respectively personal reasons, offends the prohibition of discrimination?_

[iknowkungfutoo]

You do not have to provide a reason to the user for blocking or banning them under the GDPR when the decision is human-moderated.

Because Jamulus is open-source and relies on individuals hosting their own private servers or connecting to public directories, the act of a server administrator banning someone is a human moderation choice. The GDPR handles data protection; it does not dictate the rules of who you allow into your virtual jamming space.

To enforce a ban on Jamulus, a server admin needs to retain specific identifying data, such as the user's IP address or banned nickname, to prevent them from simply reconnecting. It is allowed to keep this data on a ban list or "suppression list". The legal basis under the GDPR for keeping this data without their consent is Legitimate Interest (protecting your server from disruption, harassment, or spam).

A server admin must provide a user with the personal data that is stored (e.g., their IP address, profile name, and logs of their connections) only if they submit a Subject Access Request. To do so, they would need to prove to the server admin that they are said user beyond a shadow of a doubt. Should the server admin doubt this and suspect someone is attempting to obtain the details of someone else, they can legitimately refuse to provide any data that they have legitimately stored about the user.

None of this is the responsibility of the Jamulus developers, other than to inform operators of the servers what information that the Jamulus server code logs. Thus, I believe that discussion of the GDPR here is off-topic, but I wanted to correct your assertions in the context of human-moderated bans.

[pljones]

The problem with enabling a server admin to collect personally identifiable data is you then make all server admins liable for reporting compliance with relevant data protection legislation.

That's one reason I'm strongly against any changes to Jamulus that would constitute recording information that could be used to identify an individual.

As a user, you have a clock on the wall and you have the IP address and port number of the server you were connected to. Those three items are all the data anyone currently knows about anyone else on Jamulus.

If a server admin wanted to, Jamulus already supports logging of new connections and disconnections (it does not store this internally, only emits it if requested). I'd have to check exactly what's available but it's no more than time, IP and port of the client. The server admin can offer to investigate reports of problems on their server(s) already.

If you read the welcome message of a server when connecting, you'll see that several already do this.

What Jamulus doesn't do is record chat. However, a "fake client" could be logged in to listen to chat and log it -- again, this would be down to whoever wanted to log that data. The content of such a log would, of course, have no legal validity as it would not have any proof of authenticity. A server admin would be under no duress to take any notice of someone presenting a log and claiming they'd been caused offence.

You can read what we've currently got written as the official privacy statement here - I'm probably doing a bad job of repeating it:
https://jamulus.io/wiki/Privacy-Statement

[iknowkungfutoo]

Although it could be provided and disabled by default. Enabling it is then a conscious effort of the server admin. At the least, adding the Jamulus channel number would really help and still doesn't identify a user from stored logs alone.

[pljones]

There's a very simple rule: if it doesn't make the Jamulus software better, you can't have it. What you're asking for isn't to make the Jamulus software better.

Client Channel Number on different Client instances isn't necessarily the same (it varies with version) and it isn't necessarily the same as the Server. The only useful information the Server needs to identify a Client is IP/port so it can communicate packets.

[freenopen]

@iknowkungfutoo
Its not the question who hosts the service or what kind of software or license it is or who the admin is or how it is 'moderated'. The relevant point is if the service is a public service. A public jamulus server is a public service. and the GDPR talks about the provider and its representatives.
Latestly since 2022 there is no distinction anymore if the provider is a person or a company. (btw. a person is as well a private provider like a company is, a copmpany counts to the private sector.) The distinction is only in the charges in cases of offenses. While a big company might be charbed with lets say 50.000 € for an offense, a single person might be charged with 2000 €;

The core of the GDPR is not data protection - it is user abuse protection. By data protection. The GDPR does not only speak about stored data - the right a user has to get information about him from a service provider includes all information the provider holds.
And the person is already identified by its IP at a certain time, thats independant of his nick.

It is also not the question if an admin is allowed to ban or not. An admin is allowed to ban - but not arbitrarily. A ban must comply to the laws, in this case for public spaces/places, means the priorized state laws. (E.g. a ban because of the eye or skin color of a person or because of a different opinion and similar is prohibited, because of discrimination laws and right of free speech). Don't forget: it's a public server.
And a ban needs to store several information about the case.
In combination that results in the obligation to give the banned one info about the ban, the duration, the reason and the prove.

It's simple: No sentence/punishment/ban without reason and prove. Thats the principle of all EU states juristic system.

[mcfnord]

The GDPR governs personal data, not who you may ban. Its stated subject matter (Art. 1) is "the protection of natural persons with regard to the processing of personal data." It does not regulate a server operator's decision about who may connect. So the claim that a ban must come with a "block note, duration, reason, and proof" is not a GDPR obligation. That "no punishment without reason and proof" principle is criminal/administrative due process — it constrains the state administering justice, not a hobbyist running an audio server. Declining to let someone connect isn't a legal "sentence."

• The only EU regime that requires a statement of reasons for moderation is the Digital Services Act (Art. 17), not the GDPR — and it applies to in-scope online platforms, with exemptions for small/micro operators. A private Jamulus server is almost certainly out of scope, and even the DSA never requires "proof."
• A human-moderated ban also falls outside GDPR Art. 22, which only covers solely automated decisions. So there's no automated-decision obligation here either.

"The core of the GDPR is user-abuse protection, not data protection" — that's not correct. It is a data-protection regulation by definition. Art. 1 and Recital 1 are explicit.

The right of access (Art. 15) is real but bounded. It covers personal data concerning the requester that a controller processes — not "all information the provider holds." It's also subject to identity verification (Art. 12(6)) and to not adversely affecting others' rights (Art. 15(4)). If a server logs nothing, there is nothing to disclose.

"Public server" ≠ "public service." In Jamulus, "public" means publicly listed and joinable. It does not make the operator a legal public-sector body, and it does not import a duty to admit everyone. Anti-discrimination law is a separate regime from the GDPR: a race-based exclusion could engage directives like 2000/43/EC, but "opinion," "instrument competitor," or "different taste" are not protected characteristics under EU anti-discrimination law, and free-speech guarantees bind the state, not a private host. None of this is GDPR.

[freenopen]

Like already written above:

In combination [GDPR + other laws/state laws] that results in the obligation to give the banned one info about the ban, the duration, the reason and the prove.

By GDPR any 'special' treatment of a user has to be documented and transparent (2 of the GDPR base principles).
Also repeated: An arbitrary ban is forbidden by priorized laws that protect people in public spaces/areas (no discrimination, free speech, no administrative abuse)

"Public server" ≠ "public service." In Jamulus, "public" means publicly listed and joinable.

That is the definition of "public", and because a server which provides the service of making music together/routing the streams for that issue, it is a service. A simple syllogism.
=> public jamulus server = public (online) service

And yes, that founds the "duty to admit everyone" to the server. Thats btw THE intention and purpose of a public Jamulus server and the software as stated by the developers too. And thats why the server mode "private/unregistered" exists - there you can apply face control like in your private rooms.

And your last sentence does not make any sense or is a strawman - nobody claimed that the terms "instrument competitior" and the other ones you listed where terms of/in the GDPR.

(strawman fallacy: https://en.wikipedia.org/wiki/Straw_man
or also Red Herring (class of fallacies of relevance): https://en.wikipedia.org/wiki/Red_herring)

[AndyMcProducer]

Mute User would be useful, for Chat and Audio. Bans, blocks and so on just invite trolling and sometimes peeps are being reactive to some of the rude people around.
So try deal with those people without the rudeness and contempt as not everyone is cut from the same clothe and judging is a form of hate.
Live and let Live.

[iknowkungfutoo]

Bans are a last resort and used only when diplomacy has failed through a number of attempts.

[freenopen]

Bans are a last resort and used only when diplomacy has failed through a number of attempts.

I can assure you that's a wrong wrong assumption. Empirically. Both parts of that claim, in particular the second part.
That's only the wish of correctness and fairness that we all share. But reality showed different.
I can tell that by experience also from other webplaces and where i was in admin teams.

[iknowkungfutoo]

I’m speaking from my personal experience as a server admin.

[freenopen]

Concluding from oneself to others is a fallacy in principle. And your general statement is one of that kind that is disproven by opposite experience and empirism, also on Jamulus already.

[mcfnord]

Some people ain't no good.

[iknowkungfutoo]

I don’t think a report option will work without knowing the admin details. Admins are not going to be monitoring logs for a report notice. Admins that require such reporting can leave their contact details in the server welcome message.

Time, name etc that’s available in the client window and provided during a report still doesn’t allow an admin looking through the logs to determine which user is which. The username still needs to be logged in the server log file. This could be off by default and turned on by the admin through a command line switch. Thus this doesn’t force every server owner to adhere to GDPR by default.

Whilst this doesn’t improve Jamulus software directly it will improve the experience for all and that of the server owner should it become necessary to ban someone.

No one wants to ban users of Jamulus. We all want everyone to take part for the benefit of all. However. there are always people who are set on spoiling it for others. We’ve all experienced such people in every thing we do not just Jamulus. So please put this change in so these trolls can be excluded for the benefit of those that are using Jamulus in the spirit it was intended.

[freenopen]

No one wants to ban users of Jamulus.

You are wrong there again and also again empirically. A wish is not the same like truth.
And no, "we" do not all have experienced such people. In the many years since Corona when i started using Jamulus i did not meet on any person on Jamulus that i would have infinitely banned because of chat or music issues.
You claim a lot from nowhere and as "we" tbh.

Still there was not one attempt by anyone yet to define "bad behaviour" or a rule set to justify a ban. Why?

I am anyway wonderin why some try to even refuse giving reasoning or prove for a ban.
Isn't that totally natural, doesn't it go without saying? Isnt't it what we learn from childhood, the fundament of justice?
Even if it would not be obligatrory by laws i would give that to the banned user and even to the other users.
I wouldn't want having a server with the reputation "it's the server were people dissapear" like in a southamerican dictatorship e.g. like under Pinochet.

I can see only two causes why one refuses to give reason and prove with a ban (if you have another one let us know):

1. lazyness/work.
   Imo thats not a valid reason taking into account the impact on and importance of user rights and justice ethics.
2. one wants to ban for personal reasons or advantage and knows exactly it's not ok.
   That would mean the person is an abusive personality or/and has a fascistoid mindset.

[iknowkungfutoo]

This is completely off topic now. This thread is about adding features to help server admins. Discussion of whether or not, why, etc is not pertinent.

[freenopen]

If this is offtopic then it was you going offtopic, i only replied.
And no, you seem to confuse this thread with the new version feature thread. This here has the title "Ban user".

[ann0see]

Anything actionable which we could put into a defined spec and open an issue?

probably a mute chat feature?

[ann0see]

I mean if it mutes the chat, shouldn't it be in the chat window?

[ann0see]

Add username to new connection log entry that is disabled by default and enabled by command line switch

JSON-RPC can do this already now I think.

[iknowkungfutoo]

Add username to new connection log entry that is disabled by default and enabled by command line switch

JSON-RPC can do this already now I think.

I am not familiar with JSON-RPC, but I will be if necessary. If what you say is indeed true, is the username and IP address returned over an IP link back to the issuer of the command or is that information stored locally on the server? I ask for security purposes because if it is returned back to the issuer over ethernet, isn't that a breach of GDPR, at the very least, as the connection is not secure?

[ann0see]

JSON RPC is designed to be localhost only. Check the docs/ folder for what is possible with it.

[iknowkungfutoo]

JSON RPC is designed to be localhost only. Check the docs/ folder for what is possible with it.

Ok. I have had a look at this and yes, it does appear to do what we need. Server admins should be able to knock up a python script to poll the connected client at a regular interval. Easy to do with ChatGPT or some other AI assistant if the server admin lacks the necessary coding skills.

[AndyMcProducer]

Just rememebr and keep in mind that anything done to someone can feel like an attack and with groups of people it tends to be follow the leader.
So if that leader is a bad actor in diguise then they can litrually bully a user and name and shame someone out of existence.
And that person/s could be totally oblivious to what has happened. I say this seeing it happenign so much in the past on ninjam.
All I did for years was helper new peopel get on and the amount of haters who would n00b bash, and some of them n00bs they bashed
went on to become the better players and jammers. Ya can't judge a book by it's cover and some peopel do n00b nash whcih doesn't help
build a community. You need people to be a community, not a few small gangs of people.

But I do agree liek timeout's are much better than other methods but, if people want such systems then you coudl argue that they must
save say an encryted chat log when the ban is asked for. Else you will get some dictate who and who can not play on Jamulus.
And that is what you don't want for a community.

It all comes out eventually and people tend to see the truth eventually but not before so much damage can be done.
So if I'm in a server and someone is trolling, first thing I do is speak to them and ask what happened to findout why they're trolling
and normally it's somoene's been rude or over stepped the mark and are party to blame.

So if ya get someoen trollign jsut ask them what's up, what's happened., they might be abusive at first but we all grown ups.
Diplomacy like someone said above sorts most issues not wars.

Happy Friday!! Don't forget JamulusPlus is their if ya wanna rip anythign from it. xx

[AndyMcProducer]

Also can Cloudflare not be a much better way to ban people if it was needed and protect servers from being direct on the net?
The free tier can do that.