Sorry, ignore me…
Weird - I post a totally incorrect question in error in a topic I don’t understand, wipe the text out, and now it is a new thread? 
I am trying to unsubscribe from all this Listenbrainz stuff and somehow have now ended up with the exact opposite… LOL
/unsubscribed
“Edit” seems to be a poor choice of word?? Anyway, your comment did make me realise I was sending the component name/version as a user agent but it’s pointless because it’s completely ignored the other end. I guess this is a hangover from me maintaining foo_musicbrainz where a user agent is absolutely required!
I suppose adding the component name to additonal_info is a possibility but I’d much rather see something standardised first before I go making things up.
For the Rhythmbox plugin I added sending a “source” field in the additional data. But this is a bit different. Since Rhythmbox allows not only playback of local files but also from external services like e.g. lastfm or jamendo, the source gets set to this service. I personally find this more interesting then the playback software being used, but of course this also could be sent. I very much would like to see some standardization here an LB making use of this information.
I’ve actually been thinking about this for my Kodi addon too. It would be great if we could come up with some kind of uniform tag or some such to identify clients and client versions.
A user_agent key (with a “client/version” and/or “client/version supporting_library/version …” value) to mirror HTTP requests? Or something more fancy?
I’m fully on board, although with other motivations. It would be awesome for ListenBrainz.org to publish basic metrics about popular clients based on what current users are submitting listens with. It could potentially enable a self-discovery mechanism for developers creating third-party software around the ListenBrainz site (or simply, “if you make cool things for LB, we will help you get your cool things out to the world”). 
To enable the self-discovery mechanism described above, including some metadata about the client is useful (along with any API compatibility metadata):
This gives a LB server more detailed information about clients used by downstream users. It allows a LB server to showcase its most popular clients used to submit to that server. It also could give some insight about who our downstream developers or organizations are.
I opened a ticket suggesting this a while back - https://tickets.metabrainz.org/projects/LB/issues/LB-321
I agree that it’d be a good idea. I like @Freso’s suggestion of user_agent. Keep in mind that a large amount of data (client name, homepage, developers name, etc, etc) would be added to every listen, and so has the potential to increase the payload size.
I think it’d be good to also always require a human-readable value that could be shown directly on the LB website, instead of a hard-to-parse browser user-agent style string
Does that mean you think user_agent itself should be directly human readable? Or that clients should submit two values, user_agent for machine readability and… listenbrainz_client(?) for UI display/human readability?
Here is the ticket I added for the source idea:
Good question, I didn’t get that far. Perhaps we could brainstorm a few user-agent strings to see what comes out. Perhaps both can be included in the same value as sort of a “start basic, add more data if you have it”
Just my thoughts…
If the payload size increase is not a problem I would suggest the following data:
Client name "user_agent"
Client home page (i.e. URL) "user_agent_home_url"
Developer name(s) / organization "user_agent_developer"
Source "listening_from"
Player name/package name "player_name"
I think that player name would be a useful addition as to populate the database with known combinations of usable clients for specific players, which could be presented on the site https://listenbrainz.org with links to the developers site.
In addition there will be no need to update the thread of known apps List of native ListenBrainz API apps
For example Simple Scobbler for Android can be used with multiple players.
foo_listenbrainz2 or @marc2k3 listenbrainz script is only for foobar2000.
As for Source “listening_from” I have the same interest as @outsidecontext of where my listens are from.
soo, I wanted to bring this feature up to the PanoScrobbler devs, but I found there’s no documentation for these identifiers… or at least, I couldn’t find any…
Client identifiers are documented in JSON Documentation — ListenBrainz 0.1.0 documentation
See also the relevant discussion at Updates to recommended listen data fields to report clients and track sources
ah, I see it now~ I blame my late night brain, lol
…and that’s the tread I was looking for too, lol