@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.
@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.
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.
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.
@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@lain i also want to add that "adding new scope" is a bit difficult, because scopes literally do not exist on AP level, it's a mastodonism that only really exists in MastoAPI, i.e. backend-to-frontend communication. In reality scope determines and is determined by whom post is addressed, i.e. what to/cc fields are. I really don't know details but I assume that whether post is public or unlisted is determined whether instance's global inbox is on cc list or not, or something along these lines.
I don't know if it's possible to add attributes/metadata to activities though, i sure fucking hope it's possible, but with API you never know. Last time it went something like this (from discussion on adding detection if server supports chats) >won't sever respond with 400 Bad Request if it receives an activity it doesn't understand? <no, by standard it has to respond with 200 and just don't say anything
@NEETzsche@lain there might be a bit of confusion from UX/UI standpoint - how's "display only to followers" different from "followers only scope" and why are there different settings?
From security/privacy standpoint it's bullshit because every software has to support it properly, and by default everything will not since it's a new thing. And our experience in this field shows that only way to ensure privacy is to break compatibility (by changing the AP type, essentially), and as you can see Pleroma Chats got jack shit support from other server software (honorable mention - fork of Pleroma, creatively called Akkoma, removed support for them entirely).
We can have "suggest" flags, that can be used to "hint" software to display a post in some different way (collapse by default, display attachments in certain way, suggest that "subject line" is used as a CW, etc), for stuff that we don't necessarily care that other side might display it incorrectly.
@NEETzsche@lain scopes are shit. I would rather have an MRF or a setting so that hellthreads (posts that have more than N mentions) do not show up on timelines but still are accessible.
Unstable Internet Weirdo. Name pronounced as Hee Jay.I love sampo and lain.Jabber is same: hj@shigusegubu.clubPronouns are whatever.Do not DM me unless it's truly private matter and you're instance's admin or you risk your DM to be reposted publicly.Wish i was Finnish futa.if you want to send your shekels hj-wards i have a Liberabay https://liberapay.com/hj/ :DDDDDDD and a Badreon bage :DDDDD https://www.patreon.com/hj:haggarspin: