Embed Notice

Do you want to know why I’m persuaded that Moon was correct to want a better documentation for Pleroma-specific Audio documents, and to update the shape of the ActivityPub JSON Pleroma generates to accommodate that? The reason is a bit oblique, but it’s rooted in my professional experience with ETL and with interoperability in the medical industry, so hear me out:

That string that is the URL of the documentation page, can be used by transmogrifier, or something like it, to basically route the ingestion of the Audio document into the right thing. As it stands, there are currently two Audio document formats being supported, that we know of:

• the Funkwhale version, and
• the Pleroma version

Neither of them are really wrong, and there could be even more out there in the wild that we’ve just never heard of or that will eventually be created. In actually using the AS spec, the part of it that says we can make shit up as long as we specify the shit we’re making up and link to the documentation, allows us to separate the different shapes, chop them up using different functions, and then submit them into the same pipeline that pulls out the key data we care about in the context of Pleroma: artist (string), title (string), album (string), length (integer), url (not yet approved, string)

This is one case where functional programming is actually an excellent tool for the job, since you can just specify that one version of the function runs when the Activity is shaped a certain one and another version of that same function runs when it’s shape a different way. FP polymorphism is fantastic for this.

Insisting on making Pleroma Audio documents identical to Funkwhale Audio documents subordinates Pleroma to Funkwhale in a way that isn’t healthy. The shape of Pleroma Audio documents were designed with Pleroma’s use case in mind, and it shows, and that’s a good thing. The same can be said for Funkwhale.

I’m saying this as someone who, for a living, dealt with medical records that came in a bajillion different formats and permutations, where each major hospital had its own custom-built system entirely, and each of the rinky dink hospitals chose from one of dozens of commercial solutions that all made up their shit from scratch, and knows first hand that efforts at a unified Standard, with a capital S, have utterly failed. The same is going to be so in this case, assuming a bunch of different programs use Audio documents of some form or other. It’s because they’re all going to have their own use cases, and they’re going to make up their own shape to accommodate that use case.

So instead of removing Pleroma Audio document support, I suggest adding Funkwhale Audio document support. This is because in marrying yourself to Funkwhale’s insanity, you are forsaking the use case of Pleroma and subordinating it to Funkwhale.

But this really concludes my input on the topic, I think. I might reply more, but I’m leaning toward not doing so, because I don’t think you’re really hearing me. I think you’re insisting on doing things a certain way, which you have license to do, as it is more your repo than it is mine. I just don’t really want to participate in it because I disagree with it.