Player rating

[jollaman]

At present, there is no way to keep a rating of each player you play with. Also, the only possible action to avoid people which misbehave is to mute them. It would be nice to have a personal scoring system to quickly distinguish those who behave (and play) correctly from those who don't.

The simplest approach could be a single 5 star rating system (stored on the client's filesystem), where each user could evaluate any other. For instance, I could give 5 stars to players A and B which I know behave and play very well, 3 stars to C which behaves nicely but just begun learning the instrument, and 1 stars to D which steals sessions, always plays at top volume etc. Of course, votes cast should be visible in the main connection form.

Other possible approaches:

• public rating system with cumulative points
• different ratings based on instruments and general behavior

[pljones]

Jamulus does not capture any identity information and never will.

[chrisrimple]

While it's true that Jamulus doesn't capture identity information, it does keep Mute and Volume settings per username in the INI, and it would be possible to keep a similar 1-5 rating in the same place. That solution would not accomplish the goal of (1) crowdsourced ratings or (2) ratings visible to others, but would at least provide ratings for individual use.

[pljones]

You could just as well write it on a post-it stuck to your PC. Any client can choose any name and instrument to connect to any server, so the use of name or name+instrument doesn't give any clear identity to a client. The current fader settings solution is thus a bit of a hack, in my view (but then, neither do I find it of any use, generally).

[jollaman]

Sure, you can also find musicians in real life and avoid playing online with Jamulus or any other software. What's the point? It's a feature request. Also, when we are playing we cannot just stop, take a sheet of paper and write stuff. Moreover, the same person could change nickname/instrument/country to come back and harass you again if that's their goal.

BTW: It's not personal information you are collecting, at minimum it's a personal rating/review stored on the client.

[pljones]

could change nickname/instrument/country to come back and harass you again if that's their goal.

Exactly. So tracking anything in the client won't help you there, either. They could enter your details and use them when being disruptive to you, or someone else's details, when being disruptive to them.

[mcfnord]

You can click and ctrl-click names on https://jamulus.live .

Click gives you a yellow highlight and ctrl-click gives a green one.

I use this to track people I'm drawn to, but I've heard of people also using it to track people they're done with.

This tracking is stored in the browser so I couldn't aggregate it at the server (at this time).

If someone changes their name, everything starts anew, because as you point out, we don't have a centralized account system.

[jollaman]

could change nickname/instrument/country to come back and harass you again if that's their goal.

Exactly. So tracking anything in the client won't help you there, either. They could enter your details and use them when being disruptive to you, or someone else's details, when being disruptive to them.

A unique ID for each client would serve the scope, at least to some extent, and is not personal information. Don't forget that the same rating might also be useful to quickly spot people you've already played with, for instance.

[jollaman]

You can click and ctrl-click names on https://jamulus.live .

Click gives you a yellow highlight and ctrl-click gives a green one.

I use this to track people I'm drawn to, but I've heard of people also using it to track people they're done with.

This tracking is stored in the browser so I couldn't aggregate it at the server (at this time).

If someone changes their name, everything starts anew, because as you point out, we don't have a centralized account system.

Nice! I didn't know there was a web app running, very interesting!

[mcfnord]

If you login, the people you've played with the most will get auto-highlighted. Hope this helps.

[jollaman]

If you login, the people you've played with the most will get auto-highlighted. Hope this helps.

Yes I had a quick reading, I'll try late evening as now I'm working. Thanks

[pljones]

A unique ID for each client would serve the scope, at least to some extent, and is not personal information

Each client is identical, however - there is no unique ID available. Each instance of Jamulus would need to be separately compiled to do this. As it's open source, anyone could pick any ID. So you'd still be able to have someone taking on the same ID as someone else.

[jollaman]

A unique ID for each client would serve the scope, at least to some extent, and is not personal information

Each client is identical, however - there is no unique ID available. Each instance of Jamulus would need to be separately compiled to do this. As it's open source, anyone could pick any ID. So you'd still be able to have someone taking on the same ID as someone else.

Well, yes thinking carefully I must say the ID solution is very limited. Even if the ID is a 256B randomly created hash or something similar, anybody could bruteforce all to impersonate whoever he wants. So no, a unique ID wouldn't serve the scope unless it's centralized somewhere, but that would require user registration.

[pljones]

require user registration

And that's something that Jamulus will not enforce.

[jollaman]

require user registration

And that's something that Jamulus will not enforce.

Even a nickname/password? That shouldn't require user info. Anyway the first solution - storing ratings on the client's FS - wouldn't require anything.

[pljones]

Storing anything means the server needs extra complexity (i.e. setting up some kind of data store, having some sort of password recovery system, etc - lots and lots of complexity, that's nothing to do with realtime jamming, and therefore not in line with the Jamulus approach) and it would block, completely, interaction between new clients and old servers. If you look on Jamulus Explorer, you'll see a lot of old servers. Do you want to be automatically excluded from them because they do not support a login scheme?

[mcfnord]

I store ratings in the client browser's FS, and have considered centralizing this data. It's a lot of infrastructure for a bit of convenience. I have 3 browsers on 3 devices showing https://jamulus.live, and I click favorite musicians on each of them. I could export-import across browsers, but instead I just habitually click impressive musicians. If they change their name, I'll click the new name, too.

Centralized identity management is the most common social network access control technique. One thing about musicians: our sound is our credentials. This makes us somewhat immune to most of the problems solved by centralized identity management.

Musicians are rather tribal. I do create a unique i.d. value for each connection. If you change your name, your i.d. changes, but you still follow the same patterns, and I bet I could non-definitively associate old and new names quickly. So the idea of stable identity isn't really off the table.

You aren't the first to see our lack of centralized identity as a deficiency. I've tried to emulate many of the features people expect from a social network, like following friends, feeling connected to a tribe, seeing history, and participating in a shared future. Ultimately we may pair with a centralized identity manager like Discord or Google for offline communication, but I think our unrestricted identity model gives us what we need from a social network. It's just less visible and less coercive, and nobody can forget their password.

[jollaman]

Yes I understand all the points above, thanks for the answer. Pairing with another ID manager as you mentioned could also be a solution, but in the end storing ratings etc. on a cookie/txt file would do the job exactly as you do with jamulus.live. Of course it's just a partial solution, but enough for many people I suppose. Or sort of just integrating Jamulus client with Jamulus.live.

[mcfnord]

I'd like to make the icon in the client's upper-left clickable to jamulus.live. Some people hate jamulus.live, and so we might need to let server operators choose where the client clicks through to. Which probably involves an untested approach called welcome message metadata. Maybe someday we'll get there!

[gilgongo]

Thanks @jollaman - I hope we've covered this even if we won't resolve it directly in Jamulus (for reasons explained).