JSON-RPC roadmap/feature requests for servers

[rdica]

JSON-RPC Interface - Server Feature Requests

Current functionality in the RPC interface doesn't yet offer much towards actual server management.
I don't know if there's a roadmap defining future functionality so in light of this I'm going to
propose a list of feature requests to be added.

1. Max number of clients changed w/o restart.
2. Aforementioned whitelist the above won't affect.
3. A means to disconnect/block clients based on username and/or IP.
4. Dynamic registration to directory servers.

It's understood that some of these feature requests are either not desired, nor easily implemented
without some major rewrite/refactor, but at the least we can open a discussion on the roadmap
for JSON-RPC.

Thanks

[pljones]

I'd suggest splitting functionality that exists today but is not available through JSONRPC from that which does not yet exist.

This is because the approach taken to such requests will differ significantly and the discussions around them will be similarly different.

Hence on the list above, the last entry is one that already exists in the graphical interface and, as such, is supported by the Jamulus server software already.

[ann0see]

A means to disconnect/block clients based on username and/or IP.

Probably the most controversial one. Disconnection is possible, blocking not. I think we could set the isIdentified variable.

[mcfnord]

I know a guy who blocks IPs on their Jamulus server at the network level. The same person has added names to Jamulus logs so they can then block IPs used by those names. Blocking is a dark art because malevolence is persistent, but disconnection of a channel one time seems like it covers much more. I've seen many scenarios where one channel is just a mess and a zombie, so I wanna just disconnect it so that party can regroup as we return to normalcy. Would help an operator protect newbies who have low mute-solo skills.

[ann0see]

I don't know if there's a roadmap defining future functionality so in light of this I'm going to
propose a list of feature requests to be added.

No. But there are some open issues concerning JSON-RPC

[iamthechrisb]

Hi all, Jamulus team, as always -- huge thanks to you! What an amazing gift you have given to so many.

At this point, I'm kind of mixed on the firewall / whitelist thing. I think this can be done by other means and perhaps should stay that way. I think if any related feature that would be nice - is a server api call that can stop a client's send and/or receive audio channels -- otherwise time/resources could be used for other api enhancements.

I can think of some that may be... pretty straightforward:

1. have the server api return some of the extra attributes on connected clients that are now only available in the client api -- insturment name is the one that first comes to mind. I would suggest leaving the current jamulusserver/getClients intact and make a jamulus server command that is equivalent to jamulusclient/getChannelInfo.
2. allow server api to change max clients
3. allow client api to opt in/out of notifications
4. enable server API to send/receive chat message (maybe not so straightforward)
5. more a question -- is there any metric we can get back from server api to derive connected clients approximate overall delay? that would be super.

Thank you!

[pljones]

enable server API to send/receive chat message (maybe not so straightforward)

Do-able: the server sends all chat messages now.

[pljones]

server api to derive connected clients approximate overall delay

The server only knows its own jitter buffer sizes for each client, not the pings.

[pljones]

allow server api to change max clients

It might be possible to allow the slot count to be lowered. But it would need a restart to raise it above the --channels value (i.e. specify a new --channels value). Raising it back up to that initial value might be possible.

[iamthechrisb]

thank you @pljones . Really glad to hear this all.

• Did not realize that on /getClients -- would be nice to get jamulus name + instrument in one call, for all channels.. I'll look at this further
  -with --channels, even with the potential restart, what you describe sounds fine.

[iamthechrisb]

I would suggest leaving the current jamulusserver/getClients intact and make a jamulus server command that is equivalent to jamulusclient/getChannelInfo.

Use jamulusserver/getClients with a filter for the channel you want.

@pljones -- is this supposed to work now for instrument information?

[mcfnord]

silence detection is a feature that I'd monitor on all active servers, although if each configuration must allowlist me, I'm afraid that's much less valuable.

[Rob-NY]

I’m willing to take on some of these suggestions as well as others that I have. I’ve been away for a while, but getting back into this. I’m currently considering the following (which has some cross-over with the above):

• Server initiated chats. This would support those operators who need to send automated messages to connected clients concerning system status, etc.
• Define Bind Address. I know many folks were adamant about restricting this to the loopback interface, but for operators that have multiple servers in a single VPC there should be a way to allow them to communicate without having to tunnel or jump through other hoops. Would still default to loopback.
• Extending the connected client result set to include the parameters @iamthechrisb mentioned. Not sure yet whether to do this as part of the existing message or not. I had an old patch that extended this message so I might go that direction as it is also backward compatible if I recall.
• Client Connect Push - instead of having to poll RPC for connected clients, a message would push when a new client connects. This was originally not included to limit the file scope of RPC.
• Server Monitored Chat - while I know there were privacy concerns about this, being able to offer users some limited control of the servers through chat-based interactions (like a bot) is an interesting idea. (IE: $recording start, etc..)

Other items to be evaluated:

1. Dynamic directory registration of headless server #2888 (and I think @rdica ‘s 4th item above) - Changing directory registration status
2. Options for selected bad-actor blocking capability within the server
3. Dynamically changing max clients - although I think the concept might be better thought of as max clients is the utmost max, and we introduce a new value to throttle the number of connections up to the max; which would let us go either way up or down to that max — although I think there are still issues with the connection data structure that will make this exercise challenging.

[hoffie]

I'd certainly welcome further work on the RPC features!

To go ahead, it would certainly be useful to have most of those as individual PRs to help with reviewing and shorten any upcoming discussions.
Some items might be controversial as a topic, due to the specific implementations or both (bad actor blocking, chat integration). For those, it might make sense to open (or continue the existing) individual issues which lay out the specific plan.

[Rob-NY]

@hoffie - the challenge with the a-la-carte approach is that there is quite a bit of crossover when it comes to these features. I've been working on a few of the items from the "existing" list (a few were mine anyway), and those in this thread above. I have the following working in my sand box and will put a demo out there in the coming days. There are more than a few operators I work with who are looking for flavors of these capabilities -- whether they ultimately get pulled into the releases or not. Personally, I would much prefer that they be evaluated and peer-reviewed here, so hopefully everyone gives them fair consideration and keeps an open mind.

1. Server chats - the ability to send a chat to all users via RPC as "from server"
2. Chat Notification - RPC notifications generated when any chat (except server chats) are sent (@dtinth had a good use-case for this)
3. New Client Connect - a jamulusserver/ notification when a new client connects.
4. Client Info Changed - a jamulusserver/ notification when Name, country, city, instrument or skill level are changed by a client.
5. Expanded jamulusserver/getClients to include a count of connections, and the expansion of the clients "array" to include instrument code, instrument name, city, country code, country name, skill level code, skill level name. Should be backward compatible with the current version as I didn't touch the existing response names, only added to them.
6. Ability to specify a bind address for the RPC server - continues to default to the loopback.

There was also an earlier thread (#2511) that should be revisited in conjunction with these expanded efforts. Clearly @dtinth's work on pushing the initial release of RPC has spawned significant interest in taking Jamulus into new places. Fair consideration should be given to recognizing these opportunities and either supporting these ideas or recommending alternatives to them.

Thanks for considering these -- and if there are any particularly thorny items, I think we should spin them into individual new threads so that we can try and reach decisions on each.

(Sorry @rdica - none of your original list is here, but I'm still looking at them. )

[rdica]

No worries, gotta start somewhere, I'm pleased that things can move forward with JSON-RPC, and my most favorite feature request would be the ability to dynamically set public/private status of server without restarts :)

[Rob-NY]

I'm preparing a PR that contains the following -- but I want to outline it here first with some rationale. Also, there is a crude demo of what is possible with these added capabilities running on server: jamulus-1.servers.vjammers.net (or as Experimental/VULTR NJ on Any Genre 2).

New RPC methods:

• jamulusserver/clientConnect - a push notification on new client connect containing all info ("all info" is name, ip, instrument code, instrument name, skill code, skill name, country code, country name, city)
• jamulusserver/clientDisconnect - a push notification on client disconnect containing channel, name, ip.
• jamulusserver/clientInfoChanged - a push notification when a client changes any of their profile information.
• jamulusserver/chatReceived - a push notification when a chat is received by the server including channel, name, ip, timestamp, and message.
• jamulusserver/sendBroadcastChat - method to broadcast a server-level message to all connected clients.
• jamulusserver/sendChat - method to send a chat to any individual connected channel based upon IP address.

Modified RPC methods:

• jamulusserver/getClients - modified (without impacting backward compatibility) to add the number of connections as well as the balance of "all info" for all connected clients.

Command Line

• Introduced --jsonrpcbind to override the default bind address of the loopback (127.0.01). The current logic that RPC is enabled only when a PORT is specified has not been changed and the RPC code defaults to the loopback address just as it does today.

Misc.
A utility function to centralize converting skill number to skill literal.

As a forward-thinking idea, I also included appending "_rpc" to the server-reported "version number" in both connected and connection-less states. I believe this will help in the privacy discussion. By keeping monitoring/logging/etc enabling functionality within the RPC modules, and then alerting when RPC is enabled for a server, the client dialog can be modified to contain a notice to this effect. Obviously not perfect, but it does insulate Jamulus (the software project) from any data-use issues resulting from the use of RPC by the server operator. (My thought was this allows servers to notify clients of RPC usage without messing with the core protocol.)

(This potential PR will address #2495 and #2488, will cancel #2487, and partially touches on #2468)