>”No you are the one who is incorrect, it is I who is correcting you over and over again, why can’t you stop being wrong?”
yes.jpg
>>The computer does not need to query the URL. >It does.
It does not. You are conflating the url field with the id field. The id field is where you find a standalone ActivityPub Object, if it’s available. The url field is for one or more representations of the thing in question, such as a YouTube link, MP3 file, or Last.fm page in the case of an Audio document. See the attachments.
>>Click merge and do not contact me until you do so. >You can’t tell me what to do, especially if you are being wrong. Especially if you are being wrong on purpose.
I can tell you to leave me alone, and I am.
>>Click merge and do not contact me until you do so. Thread muted. >You harassed me long enough it’s your turn to suffer. “Fix issues in your MR and do not contact me until you do so.”
LOL “NO, NO, YOU HAVE TO KEEP ARGUIGN WITH ME ABOUT THIS!!11”
@NEETzsche you don't have to argue with me but you have to suffer. It wasn't personal before but now it is.
>yes.jpg
is that an answer to "Why can't you stop being wrong?"
>I can tell you to leave me alone, and I am. duly noted and ignored.
>It does not. You are conflating the url field with the id field
No i am not. I do need to get an id for the provided URL.
>See the attachments.
I've seen them multiple times already and neither they nor you so far provided any reason nor explanation why representations should be allowed to point towards multiple origin objects or rather why multiple objects are allowed to have same representation.
I opened up search in PleromaFE, typed in "https://open.audio/library/tracks/111688" which is the url of that post, and it gave me the object with that url, meanwhile the id of it is completely different, it is actually https://open.audio/federation/music/uploads/0ce93b9d-deb9-426a-86f5-cdf4b18dd42e so when user submits an url that happens to be a funkwhale audio we should search for it, fetch the audio document being referenced it and replace the generic target="_blank" link with one that points towards that audio document as it is seen from local instance. Your MR doesn't do that. Stop arguing and fix it, you are wrong.
Not all URLs need to be queryable to the computer. They just don’t. Not only do the docs give examples of such URLs, but the example you sent me does. Look at the second link, which doesn’t come up.
But in spite of you being objectively wrong on this topic, I’ll still work with you a bit. What do you want changed, specifically, for a user-submitted URL that links to a potentially non-ActivityPub representation of the Audio document, to be put into the codebase? Do you want me to call it something other than url?
:gigachad: fix your MR, it has issues :evidence_fan: nooo it's completely fine just hit merge you're just making roadblocks because you hate meeeeeeeeeee
>Look at the second link, which doesn’t come up. And? those are two representations of same objects, which is fine. We're doing two objects with same representations which is not fine.
>What do you want changed, specifically, for a user-submitted URL that links to a potentially non-ActivityPub representation of the Audio document, to be put into the codebase? Do you want me to call it something other than url?
anything that isn't already defined by spec, so, "pleroma:scrobble_link" or something like that.
> Example: there are YouTube videos that include every track in an entire album. In this sense, it represents each track, while also representing all of the other tracks at the same time.
In a sense yes, but that's from real life subjective perspective, from YouTube's internal database objective perspective there are no such thing as "track", they don't care about tracks/albums. YouTube's most basic "unit" is "a video".
Let me draw parallels between youtube videos and audio documents.
An object in youtube case would be some sort of internal canonical record of a video. Let's just say it's something like { id: "8pbzUBg_AjY", video_files: ..., audio_files: ...., metadata: ..., title: ...., language: ..., localizedTitles: .... }
Each of those representation points towards the same video. Now what if youtube would have let user select the URL they want? Someone could reupload same video, set the URL to https://www.youtube.com/watch?v=8pbzUBg_AjY and we'd have same URL pointing to two different uploads. Youtube has to generate media preview for URLs, so when something asks "give me media preview for https://m.youtube.com/watch?v=8pbzUBg_AjY" should it give the thumbnail for the original upload or for the reupload with same URL or somehow reply with "sorry bro this is a representation of two entirely different videos, you have to be specific on which one you want"? What about when user opens the said URL? Should it ask user which version they want to watch?
:soytantrum: fix your MR, it has issues :gigachad: like what? :soytantrum: it uses the url field for urls exactly like the documentation says :gigachad: that’s not an issue, click merge or leave me alone :soytantrum: no, you have to suffer now and argue with me in perpetuity
>anything that isn’t already defined by spec, so, “pleroma:scrobble_link” or something like that.
I’ll actually do this, as long as you meet one of two conditions:
show me what kind of ActivityPub Object http://example.org/podcast.mp3 should return, or
admit that you’re being arbitrary in this demand
Since according to you, ALL url entries MUST include at least one link to a JSON ActivityPub Object, finding that object in MP3s like http://example.org/podcast.mp3 should be trivial.
If we know about document with this url we should return the object with it, i.e. { type: "Audio", title: "Track 1", artist: "Various", album: "Unknown Album", url: "http://example.org/podcast.mp3" } or whatever metadata user submitted. OR if there somehow is a funkwhale instance on example.org with that url, return the audio document they provide. If no one scrobbled this url then we don't know about it and querying for it should return 404.
I don't understand what's so difficult about this, why do you need me to answer such trivial questions?
>admit that you’re being arbitrary in this demand
at this point I am arbitrary in my demand because you caused great suffering to me. :gigachad:
>Since according to you, ALL url entries MUST include at least one link to a JSON ActivityPub Object
once again incorrect. not "at least one" but "at most one"
Not only I filled either one of the conditions you provided, I filled both, now get to work.
@NEETzsche I set it to be auto-merged when pipelines are passed.
Currently they are stuck, however. Something is wrong, unrelated to your MR, need to figure it out.
ActivityPub is a non-standard, but that doesn't mean we don't have to be considerate of others on the protocol, especially when Pleroma at least tries to be as compatible with everyone else as possible.