@rossbates two things I'm thinking for the kind 2002 event that would potentially make it more interoperable / usable.

1) The "i" tag can just be any general information about how to find the song. The MBID schema is great if a user has it, but I don't think it needs to be limited to that. Having `spotify:track:{spotifyId}` or `tidal:track:{tidalId}` would allow clients to more easily link to a spot where the song can be played. 

2) I think adding a `source` would be fun, then a client like scrobble.nostr-music.cc can show which player the the scrobble event came from. Cmus, spotify, last.fm, etc...

This would also tie in nicely to building out a more structure graph of how to find music on the web. Something can ingest this data piece together the spotify link, tidal link, mbid link, etc... and turn that into a Song event.

I almost have a little app done that will handle publishing these events directly from your spotify plays, rather than having to go through last.fm, and I think that will open up this event kind to many more users. 

 I'm also trying to figure out the best way to link to bandcamp from the scrobble site. That's going to be next on my list once I get better integration with spotify. 

 You mean append a bandcamp link for songs that are available there regardless of the source in the event(s)? 

 Yeah, basically I just need to find a way to query for a bandcamp link by artist name, a quick look doesn't look like they really have a concept of IDs (at least not exposed in an easy way)

But I want my scrobbler app to have a link to checkout the song on bandcamp, so that one could buy a song from that artist. 

 Agree allowing for “I” to reference the most relevant unique identifier for the context of that client makes sense. Lowers the friction for users/devs and has a nice side effect of incentivizing the media publishers to support as it’s an organic mechanism for discoverability.

Source would also be useful. As just mentioned, loosening the requirements for clients is the way to go - but it points to a future where post processing to clean up, integrate, and present events is going to be required. It’s not so much a negative trade-off, just the reality of open data. Also, if certain communities want to be more strict, they’re free to do integrity checks on write. Only suggestion would be to call it ‘client’ instead of ‘source’. When I read ‘source’ I think of the publisher.