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.
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?
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.
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:
Funkwhale Audio documents also have new document types like “Track,” “Artist,” and “Album,” which in turn point to different IDs.
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?
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?
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?
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.
@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.
>Unlike YOU I prefer to work with others, not forcing others to do as I say.
Lol, mald. I literally can't force you to accept/close my PRs, that's the thing. What are you smoking? All I can do is declare that you're being unreasonable, which you are, but if you feel like going through the trouble of "fixing" something that ain't broken in the way you just described, have at it. I'm just not going to do it for you because your reasoning doesn't persuade me. You see that's the thing with unpaid work: you have to convince me to do it. And you haven't.
You can click close merge request. I can click fork repo. And such the balance has been struck.
How is it broken? Show me step by step how to produce a bug in it lol. Things that work, aren’t broken, by definition. HARD MODE: find a bug in it that’s caused by my PRs.
@NEETzsche@lain@Moon easy. Audio document you as referring to in Listen activity isn't ingested and isn't stored. If I try to search for this document in database I wouldn't find it. When getting a Like we can query a document it is referring to, but why should Audio behave differently, what is so special about it, especially when we store Audio objects already? On the other hand if we are going to have distinction between "real" documents and "phantom" documents why should only Audio given a privilege, let's make it possible for people to like and reprööt posts nobody written.
@NEETzsche@Moon@lain and if you want the actual UI bug here is one: if someone "scrobbles" an actual funkwhale audio, clicking the link should open the audio post as it is "seen" by your instance. I.e when I click "reply to" link I open up your post as my instance sees it, it doesn't open a new tab with your instance on it.
Additionally, this situation creates another confusion - we'll have the real Audio document that is posted by a funkwhale instance AND we'll have the "phantom" version of et that we just made up and didn't store, with potentially same URL, so from outside perspective which one is the "real" one? The one that funkwhale created or the "parody" of it that we pretend exists? Especially if metadata (artist/title) doesn't match up since person scrobbling made or mistake or "real" document since has been updated?
>and if you want the actual UI bug here is one: if someone "scrobbles" an actual funkwhale audio
That's not a bug with any of the FEs and the PleromaBE API doesn't let you submit Funkwhale scrobbles. Funkwhale doesn't even issue `Listen` activities. And I just checked the source code for that. So what you're bringing up is purely hypothetical, not reproducible, and basically just a non-issue.
I get that you want to prove me wrong here, but it's getting a bit much. Lain has already determined that Pleroma's use of ActivityPub is fine as-is. You've already admitted that you don't want to click merge because of who I am and not because of the content of the MR. I've moved on. I'm just going to work on my fork (or just stop, I haven't decided on if I want to commit to a fork with all my NEET features) and leave you alone.
@NEETzsche@lain@Moon >This isn’t a bug. A bug is a scenario where it doesn’t work. Can you find one of those?
Here:
pleroma_dev=# SELECT data->>'object' FROM activities WHERE data->>'type' = 'Listen' ORDER BY inserted_at LIMIT 1; ?column? ---------------------------------------------------------------------- https://shitposter.club/objects/13ffa3ec-5114-425d-b6e6-a94091b8805c (1 row) So I search for the object pleroma_dev=# SELECT data FROM objects WHERE data->>'id' = 'https://shitposter.club/objects/13ffa3ec-5114-425d-b6e6-a94091b8805c' ORDER BY inserted_at LIMIT 1; and get basically this { "cc": ..., "id": "https://shitposter.club/objects/13ffa3ec-5114-425d-b6e6-a94091b8805c", "to": ..., "bcc": ..., "bto": ..., "tag": ..., "type": "Audio", "actor": "https://shitposter.club/users/Moon", "album": "Robotnik YouTube Poops", "emoji": {}, "title": "Getaway Submarine", "artist": "iteachvader", "context": "https://shitposter.club/contexts/f45cab46-7de1-4386-a281-3bf5814f05c4", "summary": "", "published": "2023-11-12T22:19:16.655693Z", "attachment": ..., "attributedTo": "https://shitposter.club/users/Moon" } So I was wrong about it not being ingested, at least that is clear, however case for URLs and collision with actual Audio document still exists.
Let's query Audio documents pleroma_dev=# SELECT data FROM objects WHERE data->>'type' = 'Audio' ORDER BY inserted_at LIMIT 1; { "cc": ..., "id": "https://open.audio/federation/music/uploads/0ce93b9d-deb9-426a-86f5-cdf4b18dd42e", "to": ..., "bcc": ..., "bto": ..., "tag": ..., "url": "https://open.audio/library/tracks/111688", "name": "#25 Ende Gelände gegen Erdgas", "type": "Audio", "actor": "https://open.audio/federation/actors/endegelaende", "emoji": {}, "likes": ..., "content": "<p>Unter dem Motto \"Sauberes Erdgas ist eine dreckige Lüge\" ruft Ende Gelände vom 29.7. bis 2.8. zu Blockaden der Erdgasinfrastruktur in Brunsbüttel und Hamburg auf. Denn in Brunsbüttel soll ein neues LNG-Terminal gebaut werden, das wirklich niemand braucht, außer die fossile (Fracking-)Industrie und unser Lieblings-Sozi Olaf Scholz. Wir sprechen mit Fabian von der TU Berlin und Luisa von Ende Gelände über Erdgas, die geplante Aktion und was der Fokus Erdgas für Ende Gelände bedeutet.</p><p>Einige der Studien, die Fabian nennt, findet ihr hier zitiert: <a href=\"https://de.scientists4future.org/erdgas-brueckentechnologie-oder-risiko-fuer-die-energiewende/\">https://de.scientists4future.org/erdgas-brueckentechnologie-oder-risiko-fuer-die-energiewende/</a></p>", "context": "https://shigusegubu.club/contexts/7bd1f36b-1d9e-4ad4-90b0-068f79b7929d", "summary": "#anticapitalism #climate#coal#Ende#Gelände#justice#Klimagerechtigkeit#Kohle", "inReplyTo": null, "published": "2021-07-12T09:53:29.707409Z", "sensitive": false, "attachment": ..., "context_id": 50727800, "like_count": 0, "attributedTo": "https://open.audio/federation/actors/endegelaende", "announcements": ..., "replies_count": 0, "announcement_count": 1 } So now if we merge your url MRs, if I submit a scrobble with url "https://open.audio/library/tracks/111688"
This query will yield two (or more) results: SELECT data FROM objects WHERE data->>'type' = 'Audio' AND data->>'url' = 'https://open.audio/library/tracks/111688' ORDER BY inserted_at; If it does not add duplicate entries with same URL then there should be a way to have a "placeholder" data that gets updated with "real" data, however as far as database is concerned neither of those are "fake" so you'll have somehow distinguish between real and fake, and hope that funkwhale doesn't add "title" property that will make real look like fake.
P.S. had to redact some of the JSON becase BBCode doesn't like it.
if you allow adding URLs to scrobbles you are in fact not only making up "Funkwhale scrobbles" but you also end up creating "parody" "Funkwhale audios" with same url but different attribution and data.
There is also a huge potential for abuse since it would create objects with artist/title user decides on and attribute them to a URL, you can easily just advertise that you listened to a podcast but change the title to something aggravating or change the "artist" to something else. When you are giving an URL you should take the metadata from the URL. If you are making shit up, you should label it as "fake" from the get-go to avoid getting confused later.
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.
@NEETzsche@lain@hj basically if it's a predictable object form and not totally freeform then may as well specify (and version) it is my position. I don't think it really matters if there's a dozen slightly incompatible Audio objects if they're namespaced and you can write separate tests for each one
Your position is easily reconciled with mine: versioning and specifying allows for better interoperability with everybody else’s made-up shit, while still letting us make up our own shit, without apology.
@Moon@NEETzsche@lain point being that they aren't namespaced, and letting users specify URL ends up potentially having two different representations of same thing within same database - one is that entirely up to owner/creator of the url, and another is entirely up to user. There is no clear distinction between this non-existent "Pleroma Audio" and existent "Funkwhale Audio" apart from set of properties which can change at any moment on both sides.
@Moon@NEETzsche@lain url can be anything but there shouldn't be two representations of same url in same database. It's fine to have different representations on different databases but not within one.
You don’t need that. Also, this idea that the url field needs to refer to a URL that yields an ActivityPub Object JSON blob is incorrect. Even without offering a documentation of artist, title, album, and length, this line of thinking that it must refer specifically to what you think it should is not right.
@NEETzsche@hj@Moon yeah, audio inherits all properties from document and doesn't add any, document inherits all properties from Object and doesn't add any. The standard really doesn't say much about how Audio might potentially look beyond 'yeah it's an object'.
@NEETzsche@lain@Moon i do need that. You say that "Pleroma Audio" exists, so show me it. If it ONLY exists as part of a Listen activity, then it doesn't exist on its own (or just Doesn't Exist), it's not a "Pleroma Audio" it's a inseparable part of "Pleroma Listen", and it shouldn't clog the database either.
@NEETzsche@lain@Moon not resolving/querying the url is what blocks it, at least in my opinion. You shouldn't be able to put both metadata and url, only one or another. If you put metadata that's fine, if you put url the metadata should be taken from the url.
If you scroll up I made an argument for writing out a spec sheet for the fields you merged some years ago in the interest of interoperability (taking advantage of Elixir’s polymorphism), but it’s not really pertinent to the outstanding MR: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3977
The outstanding MR is about adding a user-defined url to the scrobbles endpoint, which allows you to do things like this in the FE. (If you click the YouTube link it takes you to the YouTube video)
Your understanding of the url field is incorrect. It’s not supposed to specifically be what you think it is supposed to be, as shown by the examples from the spec, what little of that spec there is. Please stop haranguing me about this topic because I’m not going to budge on it.
At this stage, I’m more likely to move forward with the specification idea that @Moon suggested on my own fork and just never MR it here because of the extreme unreasonableness I’m getting from you here.
I can feel it - a Java developer made this documentation. At least they are being honest when it comes to Place document, like "whatever man just make shit up, this section is non-normative". You might as well replace whole thing with "everything should be an object, make shit up".
So the point is to cooperate with other services in actual practice than following standard and imposing garbage on other services with excuse "standard said so"
This is why I said we write a little documentation file and put it in the @context field array, so that way other services can see that URL in there and know that we formatted it a certain way. This is how you do interoperability with your own custom shit that you made up. It’s also how you’re supposed to make shit up for ActivityPub, since you’re supposed to make shit up, you’re just also supposed to document the shit you made up somewhere.
But for the time being, the issue is user-defined url or not. It’s a tiny commit with not a lot changed. As it stands, you’ve stonewalled me on this for over two weeks and haven’t given me an actual reason for it. Every attempt at giving me a reason for it amounts to some perceived flaw in the way Pleroma handles scrobbles that has nothing to do with this MR, or an incorrect reading of the ActivityPub specification. If your next post isn’t a real thing I need to change in that MR, that is fact-based (I decide if it’s fact-based), I’m going to just mute the thread and move on with my life, because I’m not going in circles with you on this topic in perpetuity.
What is an object? It's a concrete thing, i.e. this specific omori cofe mug on my table, my computer mouse with serial number GB79G0158603A, my cellphone. It is a unique and specific thing, not a "class" of thing, object refers to an instance, object is not just any mug, any computer mouse, or a concept of a cellphone. In our case it's a document or what typical users would call "a post"
What is a representation? Essentially it's a projection or interpretation of the object. A digital photo of my mouse is a representation. A drawing of my cofe mug is a representation. A sheet of paper describing IMEI and technical specs of my phone is a representation. There is intentional one-way relationship between an object and representation. If i show you a picture of my computer mouse and say "that's your computer mouse" or "that's my keyboard" it would be factually incorrect, it's incorrect interpretation that representation is about different object.
In real world there are no clear definitions and relations, but in a computer database there are. You could ask database "what is this representation all about" and it should give you one concrete answer - "this is a representation of object X" however if you have several objects with same representation database would be confused whether it's object X or object Y or possibly object Z, therefore breaking this one-way relationship, we end up having a representation that can represent multiple object. A document spec with IMEI of my phone now can be representative of my phone or your phone, picture of my mouse can be representative of my mouse or my keyboard.
In our case the so-called "Pleroma Audio" is an object, and url is its representation. There is no mechanism to deduplicate and/or verify the url, or just update the "Pleroma Audio" document, so when you query https://www.youtube.com/watch?v=BJCEArh2E1s you'll get possibly half a dozen documents all titled "iteachvader - Getaway Submarine (Clean)" and possibly different spellings, translations and capitalization, even though there's still only one canonical YouTube link. From point of view of database, we have same representation point to several (possibly idential) copies of same object. And in case of url pointing towards a funkwhale audio we'll have several copies in our format as well as as one copy in funkwhale format, so which one is the "real" or "canonical" one?
Otherwise what is the reason or the point of having one representation point towards multiple objects?
To be abundantly clear, it is me who has been correcting you, over and over again, on this topic. Not the other way around. You are the one choosing to be wrong on purpose.
>What is a representation? Essentially it’s a projection or interpretation of the object. A digital photo of my mouse is a representation.
A YouTube video, SoundCloud link, etc, of the song being played, is a representation of that song, that audio file.
>In our case the so-called “Pleroma Audio” is an object, and url is its representation. There is no mechanism to deduplicate and/or verify the url, or just update the “Pleroma Audio” document, so when you query https://www.youtube.com/watch?v=BJCEArh2E1s
The computer does not need to query the URL. The URL can be fucking anything. This has been addressed ad nauseam and I’m not addressing it again.
This concludes code review. The MR is valid as-is. Click merge and do not contact me until you do so. Thread muted.
Nice fucking Hobson's choice. Whatever I say doesn't even matter, you'll just say "that's not fact-based" AS YOU **ALWAYS** DO WHEN YOU DISAGREE
Here is a very simple reason: URLs in objects should be unique, there shouldn't be two different objects pointing to same URL. Reason: representations can only point towards one object, that's what a "representation" is, having multiple objects with same URL breaks this constraint.
And now for real thing.
You are just being a baby, exactly like Alex Gleason. We accept some of your MRs but as soon as there is a conceptual disagreement you start making a fuss and complain how your MRs are not getting merged even though they are small and trivial. Any criticism you receive you constantly deflect with excuses and demands for reasoning, and when provided reasoning you just say "you're wrong" and throw more excuses. Let me re-use your own reasoning. "I'm reluctant to accept this MR if I'm under impression that it will cause issues. You'll notice in the previous MRs with you I accepted the changes because they didn't have issues or any issues were solved." "I decide whether it's an issue or not."