@hj@marine@NEETzsche@Moon I don't think it's that bad (quotes are much worse), but I would have been in favor of removing it when we planned for that 6 months ago, because nobody was using it. Looks like it's actually being picked up now, pretty bad or good timing, depending on how one sees it.
I said I would fix it if there’s an actual issue, but it seems mostly schema sperging. That is, there are no actual bugs, they just don’t like the shape of the JSON blobs being passed around with AP.
@NEETzsche@marine@lain@Moon it would help if discussion was more civil and people wouldn't just say "non-issue" without delving into how it is a non-issue and without lashing out on other contributors.
@NEETzsche@marine@hj@Moon there is another issue with the thing, it still uses the old object creation system and not the new pipeline version, which isn't a huge deal (landoan already wrote a nearly ready patch), but it just wouldn't be worth it EF there were no users.
Me and some people on my instance for a long time. I just today patched AkkomaFE/BE on BMC. I might re-submit my SoapboxFE PR to display it there. I’m convinced scrobbling really will catch on if allowed to.
@NEETzsche@marine@lain@hj@Moon FWIW, Funkwhale is using Audio activities for its uploads. $ curl -H "Accept: application/activity+json" https://live.grumbulon.xyz/library/tracks/20116/ | jq '.type' "Audio"I imagine deprecation of nonstandard Audio activities used for scrobbles might have something to do with potentially paving the road for supporting Audio activities proper. Leaving them both is nothing that transmogrifier couldn't handle, I imagine, but writing boilerplate to distinguish them can be haunting both from technical standpoint and as a reminder of bad decisions one made much earlier in development cycle.
@NEETzsche@marine@lain@hj@Moon Making existing scrobbles work would require a DB migration to retroactively change object types, otherwise they'll just keep dangling in DB with no queries picking them up. Don't know if any migrations of that kind took place before, and it's likely something that won't be taken lightly. I've already noticed something similar when migrating boymoders from Ackoma to Pleroma, all previous quoteposts were broken since upstream uses quoteUrl instead of quoteUri in fork.
@NEETzsche@marine@lain@hj@Moon As for what it should be changed to, don't know. There's a Listen type but it requires a reference to a object you've listened to.
Really this just reminds me of why I think that there shouldn’t have been such a reliance on these activities/objects in the DB in the first place. It always struck me as them contorting Postgres from a relational database into a document store. Ideally, all this stuff should have been properly processed on arrival, and the activities stored for analytical/forensic purposes, if not outright discarded.
But all that’s water under the bridge now. Considering this, I think just having transmogrifier differentiate between Pleroma scrobbles and Funkwhale audio blobs, plus whatever else we see down the way, is the better option. It might, however, merit adding an entry in the ActivityPub entry specifying that it’s a Pleroma scrobble to make it particularly easy to differentiate. Something like merging this into it:
{
"pleromaScrobble": true
}
The reality of ActivityPub is that it’s pretty open-ended, and so the idea that there’s a “proper” use of these types is fairly dubious to begin with. But we’ll see how things hash out.
@NEETzsche@marine@lain@hj@Moon The question of backwards compatibility would still be open in case you just add a distinctive field, since non-updated pleromas won't be sending it. I believe some Misskey fork mentioned in the original thread I tagged you in was also claimed to support scrobbles.
Yeah I just cloned Misskey and didn’t see the word anywhere in the codebase so I was scratching my head wondering if they had a Japanese word for the same idea.
Anyway, in light of the facts that I don’t see Pleroma absorbing Funkwhale Audio actions soon, ActivityPub is too open-ended for there to be a definitive “proper” use in the first place, Pleroma scrobbling has been around for a long time, and changing the way Pleroma ingests scrobbles would create a need for a migration to retroact all the previous scrobbles… I don’t think it’s worth it to do the change. Just leave it be.
It seems like using the Listen action to an Audio object is actually correct going by the spec. Or at least, as correct as we’re going to get. That is, I’m not seeing any way in this document that’s closer to the exact thing we really want. And that’s of course assuming that an Audio document truly needs to include a direct link to a literal audio file or else it’s “invalid.” I happen to think this interpretation is a bit much. After all, how would we use ActivityPub to reference songs that you can’t freely download legally, like, ya know, most of them? Sorry sweaty, you just can’t scrobble Taylor Swift because to do so would require you to insert a direct FLAC link to her song, which would violate copyright law in your jurisdiction.
I think that’s not correct. I don’t think that an Audio document requires you to link directly to an audio file. I think that you can state that you Listened to something without uploading or linking to that thing. You can just reference it. I think the way Pleroma’s BE is mostly ideal as-is. I think its deprecation is wrong-headed.
That being said, if I had carte blanche to change the way PleromaBE ingested scrobbles, I would change one thing: accepting a url. While I don’t think it should be mandatory, I do think it should be optional. Why? Well, there’s an appeal to be made to end-user utility. That is, you can store that URL and deliver it to the user. That URL format should be as open-ended as ActivityPub itself is, which is to say very. The URL could be a link to the Last.fm page that you ultimately got the scrobble from initially. It could be an audio file somewhere. It could be a YouTube link. It should be freeform and more or less up to the user. If the user submits trash, chalk it up to user error.
But the utility of seeing a song someone scrobbled and being able to click a link that takes you to either an audio file of the song itself, or some website where you can stream it or buy it or whatever, sounds fantastic. I want that feature. I would love to implement that feature.
Arguments for leaving the PleromaBE scrobble spec alone, but adding an optional url field, in more succinct form:
Being able to link to the song itself in one form or another makes the experience for users better
The implementation as-is works outright, and is in line with ActivityPub’s specification, except for perhaps the most anal interpretations of it that run into serious practical problems
Adding a URL field brings us closer to that extremely anal interpretation
Keeping the URL field optional allows people to break “the rules” since they don’t seem to really matter in the first place in this context