FEP-be68: Audio Objects

[petitminion]

hello @boiert and thanks a lot for your review.

We chose to drop the Channel feature after discussion with mirlo developers. We chose to link the artist metadata to an actor with an attribute on the Artist object. If there is a conflict between two instances (same artist object, different actor) the admin an actors must be informed. This should allow to build a web of trust based on instance moderation.

Thanks for the proposition to make musicbrainzId link mutual. I will create an issue for this and add the suggestion to the FEP.

@boiert

Would you want the pairing described as a normative part of be68, or kept out and referenced as
existing practice via FEP-c390?

I don’t understand how using Musicbrainz is compatible with DID (FEP-c390). I have no knowledge about this FEP so I don’t have a pov. But yes the `Artist` object is the one that needs to be verified, more specifically the artist.actor relationship need to be verified. I guess the child metadata (like tracks) can be verified through public metadata. But this issue was never raised yet.

@boiert

What I would ask of the FEP, in one sentence: make the metadata layer
optional, and say what a consumer must do when it is absent.

I’m not sure I understand. Some metadata is optional but some is needed if you want to support Audio objects properly. I added this “Property with asterisks (*) MUST be present.” I think software that want to implement proper audio federation MUST pass a track object in the Audio and they MUST implement ArtistCredit object too (for albums and track). Without this there is no way to implement a lot of central features (multiple artist, deduplication).

[boiert]

@petitminion

DID (FEP-c390)

Relying on an external datastore for identity proofs is the existing practice even when using DID.

[boiert]

@petitminion

MUST pass a track object in the Audio and they MUST implement ArtistCredit object too (for albums and track).

I read that as creating that federated information from the file (tags, name) if available, and when not? Refuse federation until provided? But a. consumer, can it be lenient or should it remain strict?

[petitminion]

@boiert

Relying on an external datastore for identity proofs is the existing practice even when using DID.

this mean the whole networks become dependent from this datastore… I don’t like it.

[petitminion]

from my pov a consumer can be lenient because some applications will never implement complexes audio metadata handling (too much work). But a provider must implement it, if not, federation should not happen.