[API Request] Client data storage

[intergrav]

Type of change

API extension

Proposal description

I think that we should provide a simple way for clients to store a small amount of data on the server (per authenticated user). Could probably be a set of JSON data associated with the client app identified by the c API parameter. This could be used for, say, sharing settings across different devices that are running the same client.

I was thinking about this because one of the usecases of my client (tinysub) is that it can be run pretty much anywhere - and I use it on a couple different devices per day (the chromebooks at my school, my phone, my PC, VR headset, etc). However, every time I log in I have to reconfigure the client to my liking as there are quite a lot of settings. Being able to store the settings on the server would be super handy in this case.

In the client itself, if the server supports the extension, I could probably show a "sync settings to and from server" toggle of some sort.

Backward compatibility impact

No response

Backward compatibility

• No backward compatibility impact.

API details

getClientData

Returns the JSON-encoded data stored on the server for the authenticated user and current client application (associated by c param which already identifies the client application)

Returns: data - JSON data stored on server

setClientData

Stores, replaces or clears the JSON data stored on the server for the authenticated user and current client application (associated by c param)

Parameters: data - JSON data to store on server (optional! if data param is omitted, clear the data on the server)

Returns: empty subsonic-response on success

Security impacts

Data is associated with the user and client, so servers should only allow users to access and modify their own data.

This feature should be intended for non-sensitive, client-specific settings/state, clients should not use it to store sensitive information like credentials.

Servers should also enforce a small maximum size (maybe around 32-64kb or something?) to prevent misuse.

Potential issues

Unless I missed something, c is not defined as having to remain static across client version changes. Therefore, this extension should recommend that client developers keep their c identifier consistent across versions so that stored client data remains accessible.

One other issue that may be present is that, in the rare case that a client has the same c identifier as another, the data could collide... so developers should therefore ensure that their c identifier is unique to their client.

Alternative solutions

Of course, I could also just provide a way for the user to manually import a JSON file or something but I find that much less intuitive.

[lachlan-00]

Interesting idea!

Ampache uses preferences https://ampache.org/api/api-json-methods#preference_create but they require admin access and they're per item but i would absolutely add something like this as well to both api's

I would skip c and use a named parameter for it so then the client doesn't matter. But there should absolutely be a prefix of some kind on the input names.

Then people could pull tinysub_config for their user id and be on their way.