Initial dump of possible areas we need to work on #1
rough-initial-plan into main @ -0,0 +9,4 @@
- Content:
- Artists, releases, songs...
- Prior art: RSS, Canimus, Subsonic API, Mirlo API(?), internal Fairplayer scanner serialisation format...
Note: Navidrome supports the subsonic API, not sure if they also include other APIs beyond the scope of subsonic that may be relevant to us.
Navidrome has a Native API for the UI but for third party integrations they point to Subsonic.
https://www.subsonic.org/pages/api.jsp
As far as I've been able to research, I think that Subsonic is not open source. Navidrome adds new features to Sbsonic through the OpenSubsonicAPI which is an open extension of Subsonic
Another existent for interchange of content data is the ERN DDEX standard:
https://ern.ddex.net/electronic-release-notification-message-suite-part-1-definitions-of-messages/
For us to use DDEX and any other party to interact with all of the parties need a ddex licesne identifier (DPID)
https://ddex.net/implementation/implementation-licence-and-ddex-party-identifiers/
@ -0,0 +22,4 @@
- "Reconciliation" across entities (consumer vs producer, player/catalog, player/player, different tools...)
- Auditability (immutable logs etc)
- Prior art: web3 / blockchains
- Identity:
Also in the DDEX standard, there is the the PIE, Party Identification Enrichment, which aims to enhance the identifiers for artists such as legal name vs stage name, abbreviations etc
https://pie.ddex.net/party-identification-and-enrichment/
For release and other stuff enrichment there is the MEAD standard, media enrichment and description
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?