jamulussoftware
JSON-RPC: Send a broadcast chat to all connected channels
What is the current behaviour and why should it be changed?
Create the ability to send a broadcast chat message to all connected clients via the JSON-RPC api. This would be a general capability that would allow rpc users to automatically send messages to all connected clients for a variety of use-cases.
Describe possible approaches
Presently this is not possible because all methods on the server object that expose chat functionality are private. Moreover, each either requires a 'source' connection id or prepends the message with the a static literal (in the case of the welcome message).
I propose a rather simple change which would refactor CreateAndSendChatTextForAllConChannels (which would remain private) to split the formatting of the chat from the sending of the chat. The formatting (prepending the sender user name and time) would remain in this method, but the loop to send to all connected clients would be moved to a new public method potentially called CreateAndBroadcastChat().
Note: the refactoring is simply to avoid duplication of the same code in multiple methods. This is optional and the same functionality could be achieved by leaving the existing method "as-is" and creating a new method which contains a duplication of the send loop.
serverrpc would be extended to include a new method "jamulusserver/broadcastChat" (or similar), accepting a chat string as a parameter. This rpc method would then access to the new CreateAndBroadcastChat method on pServer.
Has this feature been discussed and generally agreed?
No
Without having looked at the actual approach, I just want to point out that @dtinth seems to have something like this here: https://github.com/dtinth/jamulus/commit/f37450b0ef86482cbc35f9bb06bff848a3c885ee
You are correct. Server-level chat (both send and broadcast-received) was in an early version of @dtinth code but it didn't make it into the merge as far as I can see. I suspect it had to do with trying not to impact server.cpp with the initial RPC introduction. What do you think is the best approach for trying to reintroduce some of these? One by one as I'm doing here, or with a more broad feature request that can be built upon by others?
I suspect it had to do with trying not to impact server.cpp with the initial RPC introduction.
Yes, that is one of the reasons that it is not included.
Another reason being, some objection has been raised about having such powerful feature in the main Jamulus source code. Allowing JSON-RPC clients to interact with the system would make it easy for server operators to eavesdrop messages and impersonate users in the chat. It would violate the Privacy Statement:
Text Chat
When you type a message in the Chat Window, other connected players can see that, but chats are not stored by the server and neither the server operator nor any third parties have access to them.
My main use case for this is to allow jammers to control the recording system right from the chat room:
What do you think is the best approach for trying to reintroduce some of these?
This is my personal opinion:
-
Remove or alter the Privacy Statement as it is essentially unenforceable. Chat messages are not encrypted (so theoretically ISPs can read them), and a server operator may alter the Jamulus server’s source code in a way that doesn’t uphold the privacy statement (there are practical, non-malicious use cases for that, as per above). They may also run
tcpdumpto log chat messages. By relaxing the privacy statement, it will allow the chat feature to be implemented. -
Implement the
jamulusserver/broadcastChatas proposed on this issue. I’m on the “platform thinking” side — give server operators building blocks where they can build things upon their own way, rather than provide limited functionalities that address specific use cases.
I agree with @dtinth as we have very similar use-cases. Further, the privacy statement reads as if Jamulus is a service and makes claims that cannot be enforced. Frankly, I would be more inclined to have Jamulus, as an open-source application, distance itself as far away from any statements of application-use privacy as possible since it cannot make any representation about how an operator would/could use the software. Perhaps something that embodies:
"Jamulus is a software application, not a service. With respect to information provided in the Jamulus settings and configuration, as well as information transmitted to and from Jamulus servers and directory servers, there should be no expectation of privacy whatsoever. All connections are unencrypted and server operators may alter their environments and this software to suit the needs of their user communities. Privacy policies are the responsibility of the server operator, not the Jamulus software itself. Questions and concerns over privacy related matters should be directed to the operator of any Jamulus server you plan to connect to."
This isn't new... It has always been this way.
Jamulus is a software application, not a service.
Please open a discussion on this topic. I think the exact wording needs to be discussed somewhere (what about privacy on the public directory servers,...)
Updated commit link on top of r3_8_2nightly1: https://github.com/dtinth/jamulus/commit/d8469480b0f9408b5b46ad3f668ae1b95fc73955