Conversation

Notices

1. Proud owner of a potato sack :flag: (hj@shigusegubu.club)'s status on Wednesday, 29-Nov-2023 18:13:11 JST Proud owner of a potato sack :flag:

   • NEETzsche
   Just so you know, @NEETzsche there has been a tiny misunderstanding. Backend code is a bit of a mess in that part, so I assumed "scrobble" creates a type: "Create" with document "Audio" with url assigned, but it does create a "Listen" to an "Audio" with given url/metadata.
   
   The real problem is in "Audio" it is referencing - even though from ActivityPub perspective nothing matters and you can "Arrive" at nonexistent "Place", much like "Audio" doesn't have to be created in order to be listened to, we do ingest type "Audio" from funkwhale, so we have inconsistency between type "Audio" that we receive from funkwhale, and "Audio" that we make up in "Listen". For now I think we are the only ones who support "Listen" at all, funkwhale doesn't support it, however if they or anyone else DO add support for it we'll have a problem - if we receive a "Listen" we have to figure out if it's a "Listen" for a "real" "Audio" i.e. actual Audio document we ingested from funkwhale or it's a made-up nonsense "Audio" from (older) Pleroma. This is what you've been calling a "non-issue" and I do think that IS an actual issue that needs to be addressed, and I've started addressing it already.
   • NEETzsche (neetzsche@iddqd.social)'s status on Wednesday, 29-Nov-2023 18:13:02 JST NEETzsche

     in reply to

     • Moon
     • LS

     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?
     4. 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?
     5. 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?
     6. 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.

     EDIT: It’s my view that we should, instead of demanding a totally unified shape, get comfortable with the reality that many different outfits will shape their documents in very different ways, and that the more of them you support the better. Source: I worked in medical interoperability for years and if you think this is an issue, you don’t even know. This doesn’t even make me flinch.

   • Proud owner of a potato sack :flag: (hj@shigusegubu.club)'s status on Wednesday, 29-Nov-2023 18:13:06 JST Proud owner of a potato sack :flag:

     in reply to

     • NEETzsche
     @NEETzsche it's in changelog:
     
     ## [2.0.2] - 2020-04-08
     ### Added
     - Support for Funkwhale's `Audio` activity
     
     There are several tests that explicitly verify that Pleroma ingests funkwhale's Audio documents
     
     https://git.pleroma.social/search?search=funkwhale&nav_source=navbar&project_id=2&group_id=3&search_code=true&repository_ref=develop
     
     Best i can tell it stores several activitypub types and puts them in timeline. I haven't seen any funkwhale audios in-wild but at very least i have experience federating with peertube from pleroma - from Pleroma User's point of view it looks like a normal "post" with video as attachment, so from what i see in the OG MR it works the same for Audio.
     
     https://git.pleroma.social/pleroma/pleroma/-/merge_requests/2287
     
     My brain is 99% fried from disasterous day so please excuse me if i'm not making any sense and skipping words.
     
     Long story short - Pleroma understands Peertube Videos and Funkwhale Audios and displays them as regular "posts" with given url as attachment.
     
     Us sending out "Listen" for a made-up "Audio" is inconsistent with this behavior so say the least.
   • NEETzsche (neetzsche@iddqd.social)'s status on Wednesday, 29-Nov-2023 18:13:07 JST NEETzsche

     in reply to

     Sorry I was asleep.

     As far as I’m aware the current codebase doesn’t deal with Funkwhale Audio documents at all. Do you mean to say that you intend to make it use Funkwhale-shaped Audio documents? If it already ingests these Audio documents in some way elsewhere, can you point me to where in the code, and what they’re used for?

     EDIT: Also, the scrobbles-related endpoints will likely need to be completely redone to conform to the shape of Funkwhale’s Audio documents, since their spec has special object types for Album, Artist, etc, which will likely require a user to build all of those out over several requests. This is a waste of time and effort in my view. I don’t endorse this.

     What I do, however, endorse, is using transmogrifier or something like this to pluck out the relevant bits of information from a Funkwhale document and contort it into a Pleroma one, right currently has about the right amount of information in it.

   • Proud owner of a potato sack :flag: (hj@shigusegubu.club)'s status on Wednesday, 29-Nov-2023 18:13:53 JST Proud owner of a potato sack :flag:

     in reply to

     • Moon
     • NEETzsche
     • LS
     @NEETzsche @lain @Moon my idea is that scrobble endpoint will remain the same for compatibility sake, but instead of creating a Listen:Audio activity it will create an Create:OngoingActivity instead, with content being constructed out of provided artist/title/url. like "🎵 $artist - $title" this will break federation with older instances but for local scrobbles we can do a migration if people care (and if it's even possible)
     
     >Funkwhale Audio documents also have new document types like “Track,” “Artist,” and “Album,” which in turn point to different IDs.
     
     We store activities we understand, and this "scrobble" or "Listen for a nonexistent Audio" is an oddball, like a broken symlink that points to a non-existent file. We don't understand Track/Artist/Album types so we don't care about those.
     
     >How will this effect a user who wants to scrobble to Pleroma’s API?
     It will work mostly the same but federation side will change
     
     >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?
     We don't understand Artist, Track and Album so we don't care.
     
     >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?
     No. Scrobbles are going to be separate thing entirely, a RichPresence or OngoingActivity thing, nothing to do with Listen nor Audio so it cannot possibly interfere with those.
     
     >Why do you want Pleroma Audio documents to be subordinated
     There are no Pleroma Audio documents.
     
     >we should just write a documentation for our own format that already exists and already works
     We can write documentation but if format is too confusing nobody is going to bother reading the documentation, let alone support the format. Not to mention, writing documentation for confusing stuff results in being confusing documentation. If you need an example - look at ActivityPub spec.
     
     >doesn’t even think is necessary in the first place?
     it is not strictly necessary, but I prefer going extra mile and future-proofing things to reduce the burden and responsibility. ActivityPub is strictly additive, once you add something it's difficult to remove once it got widespread and massively supported. I want to strike iron while it's hot and make it so that "proper" and less-confusing format is adopted instead of this mess.
     
     >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?
     Sure we can add proper support when that happens, but as of right now
     1. We define format and it's garbage, funkwhale might be inclined to support it and make an even bigger mess or just ignore our Listens altogether even if we "fix" them. Either way it's not a good look for us
     2. Whatever they'll might end up doing will most likely become broken on our side, either spamming error logs or displaying incorrect data in the UI.
     3. This will most likely end up having two formats floating around in the network, which will be extra confusing for any third party trying to implement this.
     
     My logic is - Listen activity is meant for Audio document. There is a service on the network that is distributing Audio documents, so let's leave it to them to define Audio documents and anything related to it. Unlike YOU I prefer to work with others, not forcing others to do as I say.
     
     >This is because in failing to consider these things you’ll just break your repo.
     Everything is considered. You are the one trying to break your fork/repo/whatever.
     
     >get comfortable with the reality that many different outfits will shape their documents in very different ways
     different ways are fine, but collisions and inconsistencies are a different thing. The "whatever, it works" is most likely the reason we have broken bullshit like mastodon scopes. I don't want Pleroma to be Mastodon 2, I don't want to impose garbage formats on others on purpose just because it fits my passing fancy.