@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.