Jamulus
Replies: 3 comments 10 replies
-
|
We have JSON-RPC API, why add parsing for welcome message metadata. Expanding its functionality makes more sense from a client and server perspective than parsing some metadata in a welcome message. I disagree with forcing client behaviour change. Looking for a solution to a nonexistent problem? |
Beta Was this translation helpful? Give feedback.
-
|
New ideas can solve problems we don't know we have! I think we could eventually ship with a default welcome file that includes default metadata. I'm thinking about rolling out a Google Space for every server, and can imagine metadata in the welcome message specifying preferences. Integrate with in-app chat via JSON-RPC? Announce groups? Real time rule-based push notifications over Google's network would probably help some jams grow, and might operate best at the server level. Some do this via Discord today. Why not do this worldwide tomorrow? I'd feel better if the default server welcome message instructed the client to some safe-by-default configuration first. So I'm fishing for the most obviously powerful feature as a starting point. If there is no obviously powerful feature in this architecture, then maybe it's a dud. We just took a KB page live that gives some crummy examples of what metadata could be hidden in a welcome message. But there must be some brilliant use case. Maybe a few. |
Beta Was this translation helpful? Give feedback.
-
|
This was my original response. I saved it in case I chose to post it dependent on your above response, I have included comments for the response above as well.
Yes, I remember this discussion. It was also suggested as a mechanism to block your bots. The mention of a default welcome message I'm sure can be a means for you to force an opt-out instead of an opt-in strategy for your bots access if the devs approved of such a thing, and if you could be trusted to honour it. I recognized it as such when it was first suggested, and you've confirmed it now. Anything to not block your bots by default.
This is an edge case. Jamulus documentation is quite clear about needs for low latency. Satellite is not low latency. Forcing a client to change its audio quality does not a user experience make, especially when the server operator is offering a substandard connection to begin with. The user experience of connecting to a high latency server and attempting to play is just horrendous. You know this already.
How would the server know if a signal is stereo, dual channel mono, or channels hard panned?
Forced client change does not a user experience make. The only thing interesting is that you'd even think about it. What was that expression you used in a prior post that contradicts what you're expressing here, about "being wedded to dark vision of operator power".
If you're recording on a public server, you're aware and prepared to accept people are going to come and go while recording. Forced muting provides zero benefit to a recording session. The wav files are still created. Track management would still be a function in the daw software the recording project was imported into. That you think forced muting would be a benefit to recording a session demonstrates a lack of knowledge on how Jamulus records audio, how to manage your own Jamulus client, how to participate in a recording, and how to use daw software.
Wedded to dark vision of operator power? If you're going to permanently mute someone, each individual user can make that choice and do so in their client. This is not the function of the server operator. For the server operator its simply better to block that user from joining, thus providing an open slot for another participant. Conserves resources the server operator pays for, amongst other benefits to the users already connected. Blocking the client from joining, and opening a potential slot for another player is a worthwhile endeavour, and can be made possible using the JSON-RPC API. This API can have its current feature set expanded to provide ACL control of the server without disrupting running sessions. It could also be used to block your bots, with no need to trust you to honour welcome message metadata. But that's a separate discussion.
As a server operator, the only thing that can be asked of a client without depriving the user of their autonomy over the function of their own client, is to respect the others connected, and behave in a civil manner. Any forced change in a client not made by the users themselves poses more risk of degraded user experience than any possible benefit.
Why can't the server operators/communities decide for themselves if they want that? Ostensibly you could offer your services to provide such a thing for them, and it wouldn't be forced on those that don't want it.
Just. Wow. How is the current default configuration of a newly installed client unsafe? It's curious that when server operators implement controls over their servers, you call us haters, anti-social, UNSTABLE, but when it's something you want that will help with features for your product, its fine. You have ideas, thats fine. Don't try to force implementing them on others without their knowledge or consent, thats where you err. Here's some food for thought in general: They don't force their comms and/or bots on others outside their servers. Build your own community. Create your technology. Run it for your community. Offer it to the world. This is what softins and dtinth have done with their solutions. If anyone wants to use it, they can. Everybody wins! You had a good idea with the single pane view of everyone playing on a public server. You erred with the bots rollouts, as you've admitted. You could still salvage your reputation and the bots access if you decide to consult with server operators for permission first to place your bots on them. This would show respect for operators and the resources they pay for, and demonstrate a willingness to work with us and not treat us and our resources as commodities to be exploited. |
Beta Was this translation helpful? Give feedback.
-
|
I think your hostility overwhelms your ability to think straight or communicate in a thoughtful manner. Your understanding of some factual matters is also mistaken, which has led you to false conclusions. |
Beta Was this translation helpful? Give feedback.
-
|
I think you'd need to justify where the idea of "hostility" arises or else risk having this discussion locked. |
Beta Was this translation helpful? Give feedback.
-
|
I find that the degree of hostility overwhelms anything I might add. When you read the message, do you see much beyond hostility? I believe the hostility derives from fundamental differences between worldviews. I've invited @rdica to speak with me personally in a bid to improve relations, but he declined. I suggest to you that it's fair to summarize a virulently hostile rant by saying I see a pattern of hostility, without a deep dive into where it's from. But that's secondary to my hope for this discussion. If you feel there's no merit to my original inquiries, then lock this discussion up! I like this idea of metadata generally, and did specify examples for your consideration. If that doesn't bring you to respond, I doubt anyone else's opinion matters, in this instance. Perhaps the matter can rest with @rdica's engineering review (he found no merit to the idea). |
Beta Was this translation helpful? Give feedback.
-
|
Let's start from the premise that you feel threatened. OK, there's no problem with that - only you can determine and choose to say how you feel about your circumstances. However, that you feel a particular way in response to circumstances doesn't mean those circumstances are being imposed upon you by some intelligent outside force over which you have no control. Indeed, to judge the cause, you need to understand why you feel the way you do, to start with. You've not said why. |
Beta Was this translation helpful? Give feedback.
-
|
@rdica @mcfnord let's treat this whole thing as a problem without getting personal. I suggest the following:
The goal is to find peace in this part of the community. |
Beta Was this translation helpful? Give feedback.
-
|
I am experienced being the target of hostility and even smears, and have been front-page news in scandals against powerful, treacherous people. I don't feel threatened here. I did invite Rick to speak with me directly to clarify a few things, and that invitation remains open. There are two antagonistic impulses of man interacting in the United States Jamulus community, which have fused to two antagonistic visions of software. It has stirred up remarkable passions and caused real pain, which I don't like a bit. But I think it might be necessary to just watch things play out. This discussion about clients acting on welcome file metadata was triggered by this page: https://jamulus.io/kb/2023/07/30/Server-Metadata.html This page misleads people on two features:
About embedding contact information, instead I hope to see guidance recommending inclusion of overtly visible contact information. I've concluded that individual granularity for bots is the only real solution. So I set up a system that does this, where I can give a user a "halo" that prevents bots from joining them. Results with beta testers have been pretty successful, but manual management is not ideal. You might see a halo after entering localStorage.setItem("show-halos", 1); in the browser console. I began studying two musicians who hate bots. With halos, bots don't approach them. Before this, both regularly left the server when a bot arrived. So my long-term plan is to detect accounts that leave when bots arrive, and automatically give those accounts halo protection. While the resulting protection might be probabilistic rather than absolute, this automated, self-serve management of individual bot policies seems like the best primary control, along with my manual controls in place now. Ideally, I'd like to imagine a truly killer usage of server welcome message metadata. So I asked the group for ways a server could shape clients that connect there, but nobody thought of anything. Maybe, even by design, the discussion shifted to conflict management that I sadly suspect is naive. Have you noticed how a disruptive crew doesn't show up to video chat about concerns, but does show up with haunting speculations and innuendo? Concepts like DARVO explain a lot more to me than quaint conflict resolution tactics. My plan is that every individual has snippeting, streaming, and eventually recording preferences using a self-serve, tag-based, user-granular metadata model. This and firewalls make server-level bot policy unneeded. I feel too lazy to start a PR but I'd like to remove those 2 misleading details eventually. |
Beta Was this translation helpful? Give feedback.
-
|
So actually the client and server should send policies which bots parse? Would that be an easier solution then your probabilistic approach? |
Beta Was this translation helpful? Give feedback.
-
|
If each client could indicate a policy based on user input, that'd be kind of amazing, but I'm not sure how it would work. Perhaps a server could collect data from client connections and provide this data in a public summary. Perhaps right alongside instrument and skill level, a client might set snippeting, streaming, and recording policy. So clean and easy! |
Beta Was this translation helpful? Give feedback.
-
|
Sure, as long as client default is disabled. And there's a server option, again off by default, to collect that information. Other than providing specific functionality for your product, how would users and server operators otherwise benefit from these features? |
Beta Was this translation helpful? Give feedback.
-
|
I'd just send a clear text field for metadata to allow arbitrary metadata. Like we do it e.g for the city How bots handle it would be up to the bot provider. |
Beta Was this translation helpful? Give feedback.
-
I was thinking about the metadata-via-welcome discussion. Maybe it can specify preferences for clients expressed by server operators.
I thought of some good scenarios:
I knew a guy who ran a server on his Starlink connection. He probably should just get a cloud instance, but he wanted to record. Anyway, it's fair to say he'll get maximum performance if his clients set on a lowest-throughput setup, such as Low quality audio. If a client connects to his server at another setting, a UI could invite them to change the setting.
If a server operator wanted to assure connections use stereo, server metadata could invite each connection to switch to that mode.
I think there are serious concerns around this line of thinking. Changing someone's settings might cause them to lose performance or functionality in the client, as with hardware ill-configured for stereo. But it's an interesting line of thinking.
For example, metadata could insist that people join with themselves muted. I bet anyone who is recording would prefer that.
Perhaps metadata could even mandate the joiner is muted, permanently, for the connection's lifetime. If the operator can update the welcome message, that changes the state of new clients. Interesting? Dunno.
I'm creating this discussion because I don't quite know what feature would make the infrastructure worthwhile.
What could a server operator ask or require of a client, why might they want to, and what risks does that pose to the stability of the client for that user?
Beta Was this translation helpful? Give feedback.
All reactions