Conversation

Notices

1. LS (lain@lain.com)'s status on Monday, 13-Nov-2023 06:19:33 JST LS

   • Moon
   • NEETzsche
   • The Problem
   @Moon @marine @NEETzsche there's talk about removing it from the backend, but if people are actually using it, maybe it can be saved.
   • LS (lain@lain.com)'s status on Monday, 13-Nov-2023 06:24:19 JST LS

     in reply to

     • Moon
     • NEETzsche
     • Proud owner of a potato sack :flag:
     • The Problem
     @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.
   • Proud owner of a potato sack :flag: (hj@shigusegubu.club)'s status on Monday, 13-Nov-2023 06:24:21 JST Proud owner of a potato sack :flag:

     in reply to

     • Moon
     • NEETzsche
     • The Problem
     @lain @marine @NEETzsche @Moon ActivityPub side of things should be fixed tbh
   • LS (lain@lain.com)'s status on Monday, 13-Nov-2023 06:41:38 JST LS

     in reply to

     • Moon
     • NEETzsche
     • Proud owner of a potato sack :flag:
     • The Problem
     @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.
      likes this.
   • NEETzsche (neetzsche@iddqd.social)'s status on Monday, 13-Nov-2023 06:41:39 JST NEETzsche

     in reply to

     • Moon
     • Proud owner of a potato sack :flag:
     • The Problem

     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.

      likes this.
   • NEETzsche (neetzsche@iddqd.social)'s status on Monday, 13-Nov-2023 07:09:26 JST NEETzsche

     in reply to

     • Moon
     • Proud owner of a potato sack :flag:
     • The Problem

     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.

     LS likes this.
   •  (mint@ryona.agency)'s status on Monday, 13-Nov-2023 17:17:14 JST 

     in reply to

     • Moon
     • NEETzsche
     • Proud owner of a potato sack :flag:
     • The Problem
     @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 (neetzsche@iddqd.social)'s status on Monday, 13-Nov-2023 17:24:14 JST NEETzsche

     in reply to

     • 
     • Moon
     • Proud owner of a potato sack :flag:
     • The Problem

     I don’t think I’ve ever heard of Funkwhale. Anyway, to me, this raises two questions:

     • Will changing the type from Audioto something else make it so that we can’t look at existing Listen actions without modifying the code, and
     • What do you think it ought to be changed to, and why?
      likes this.
   •  (mint@ryona.agency)'s status on Monday, 13-Nov-2023 17:31:39 JST 

     in reply to

     • Moon
     • NEETzsche
     • Proud owner of a potato sack :flag:
     • The Problem
     @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.
   •  (mint@ryona.agency)'s status on Monday, 13-Nov-2023 17:36:21 JST 

     in reply to

     • Moon
     • NEETzsche
     • Proud owner of a potato sack :flag:
     • The Problem
     @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.
   • NEETzsche (neetzsche@iddqd.social)'s status on Monday, 13-Nov-2023 17:40:22 JST NEETzsche

     in reply to

     • 
     • Moon
     • Proud owner of a potato sack :flag:
     • The Problem

     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.

      likes this.
   •  (mint@ryona.agency)'s status on Monday, 13-Nov-2023 17:50:20 JST 

     in reply to

     • Moon
     • NEETzsche
     • Proud owner of a potato sack :flag:
     • The Problem
     @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.
   •  (mint@ryona.agency)'s status on Monday, 13-Nov-2023 17:55:07 JST 

     in reply to

     • Moon
     • NEETzsche
     • Proud owner of a potato sack :flag:
     • The Problem
     @NEETzsche @marine @lain @hj @Moon Nevermind, from the looks of it said fork seems to be just making a request to a third-party service with ID listed on user's profile (in description field, I suppose).
     Husky_1699865635583_I66TRR8FI8.…
   • NEETzsche (neetzsche@iddqd.social)'s status on Monday, 13-Nov-2023 17:55:08 JST NEETzsche

     in reply to

     • 
     • Moon
     • Proud owner of a potato sack :flag:
     • The Problem

     How does Misskey handle scrobbles? Do they come in the same shape as Pleroma scrobbles or are they entirely different?

   • NEETzsche (neetzsche@iddqd.social)'s status on Monday, 13-Nov-2023 18:05:25 JST NEETzsche

     in reply to

     • 
     • Moon
     • Proud owner of a potato sack :flag:
     • The Problem

     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.

     Just my view on the subject.

      likes this.
   • Proud owner of a potato sack :flag: (hj@shigusegubu.club)'s status on Monday, 13-Nov-2023 18:31:42 JST Proud owner of a potato sack :flag:

     in reply to

     • 
     • Moon
     • NEETzsche
     • The Problem
     @NEETzsche @marine @lain @mint @Moon >I don’t see Pleroma absorbing Funkwhale Audio actions soon
     
     it would be pretty nice if it did though, it already understands Peertube actions somewhat
      likes this.
   • NEETzsche (neetzsche@iddqd.social)'s status on Monday, 13-Nov-2023 19:52:24 JST NEETzsche

     in reply to

     • 
     • Moon
     • NEETzsche
     • Proud owner of a potato sack :flag:
     • The Problem

     @mint @hj

     I’m reading this spec here:

     https://www.w3.org/TR/activitystreams-vocabulary/#dfn-listen

     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
      likes this.