Embed Notice

I understand what you’re saying. I don’t agree with it, but I understand it. The way these AP documents are meant to be created and ingested is supposed to be pretty Wild West. So while Funkwhale formatting might work great for Funkwhale, it might not work so great for Pleroma. Consider these points, which are sort of interconnected and so are in order:

1. Funkwhale Audio documents also have new document types like “Track,” “Artist,” and “Album,” which in turn point to different IDs.
2. How will this effect a user who wants to scrobble to Pleroma’s API? 3. Are you going to change the endpoint to make them have to build out an Artist, a Track, an Album, turning a one-step process into a four-step process?
3. Are you going to leave it a one-step process and then go through a huge rigmarole to transmute the simple album, artist, title, length scalars into full blown Funkwhale objects?
4. Why do you want Pleroma Audio documents to be subordinated to Funkwhale ones when @Moon was probably right that, at most, we should just write a documentation for our own format that already exists and already works, and that @lain doesn’t even think is necessary in the first place?
5. In the event that Funkwhale starts sending Listen actions on their Funkwhale-specific Audio documents, why not just pull out the necessary information from it?

These aren’t demands or commands. These are considerations you will likely need to address, willingly or otherwise, in order to go from what Pleroma currently has (custom Audio document shape that’s simpler than Funkwhale and, in my own opinion, more functional for our purposes) to something more akin to Funkwhale. This is because in failing to consider these things you’ll just break your repo.