Relevance of a user system in music apps

[Arlodotexe]

Background

There are many models in the Strix SDK. Albums, Artists, Tracks, Playlists, Search, Library, the list goes on. The models in the Strix SDK have spent the last 2 years going through rigorous evaluation and re-evaluation, making sure they're exactly what we need.

However, there's one exception to this: the models pertaining to Users. This includes ICoreUser, ICoreUserProfile, IUserProfileBase, IUser, IUserProfile, etc.

When we first added these, the intention was to provide cores with a way to relay information about the logged in user.

The issue

We could have used this in OneDrive, but it went largely ignored. Since we were easily able to communicate who was logged into the core instance using the InstanceDescriptor, we just didn't need it.

A User profile contains information not found in other parts of the app, like

• Profile images
• Region
• Display name
• Full name
• Email.

When brought into the context of a music app, especially one that can identify logins without them, these things just aren't very useful.
That begs the question:

Do we really need this?

If not, we'll remove it to make maintenance easier.
If so, we need to clearly define the intended use cases and improve it to fully support them.

Add to this discussion with examples of how you would or wouldn't need a user system in your Cores.

[Arlodotexe]

Additional note - IUserProfile is used (but not required) on Playlists, to identify the creator of the playlist.
If this is the only use case, it could be replaced by something much simpler.

[Arlodotexe]

Still looking for feedback on the community for this! If we don't hear anything, we'll take the best action based on our best judgement.

[yoshiask]

How would integration with services like LastFM (which list active/recent listeners for a given media) without this?

[Arlodotexe]

How would integration with LastFM work with this?

If you're adding a LastFM plugin, then you're probably not injecting new data, you're likely just observing playback devices. Anything else can be exposed on the plugin class and consumed by the app which added the plugin.

There are even ways to add entirely new properties/methods/events to the SDK models via plugins, though we haven't tried this yet. You can create an extension method that crawls into a model's plugins via IDelegatable<T>.Inner and checks each one for an interface. When you find it, you can use it. LastFM models go on that interface.