Looks good, thank you for writing it!

Is privacy level represented as a single word? Or is it actually an URL?

Thanks for having a look ! It’s a single word.

Thank you for writing this. I’ll need to read more thoroughly, but this looks good to me. I’ll note any extra requests I have on codeberg

Your FEP is definitely NOT too long, so I wouldn’t worry about splitting it into multiple documents.

And, I’m really glad to see Albums in there. It will be a big help for Bandwagon. I’m really excited that we’ll be able to share music across both apps!

@petitminion

One question for now, are you planning to copy the object definitions from the Funkwhale site into the FEP?

@petitminion

This may limit interoperability because audience is supposed to contain IDs (either actor IDs or collection IDs). I think many servers don't even check audience, and rely only on to and cc.

Here's how these special strings could be translated into IDs for to / cc:

- me: current actor ID.
- instance: special collection ID, similar to https://www.w3.org/ns/activitystreams#Public. Prior art: Akkoma uses https://server.example/#Public for local-only posts.
- followers: actor's followers collection ID.
- everyone: https://www.w3.org/ns/activitystreams#Public

yes I guess having the definition on the FEP is the proper way to do it.

\audience\ can be object or link : https://www.w3.org/TR/activitystreams-vocabulary/#dfn-audience . Your proposition is too complicate from my pov. We could, send an object like :{ "type": "Group", "name": audience_string },

That would probably make it compliant with ActivityStreams, but still, it is not good for interop, because other fedi software specifies audience using URIs.

I would be happy to federate with Funkwhale, but with the mechanism described in the FEP it will require special treatment.

Your audience_string is still a form of @id since it is a vocabulary term you define.

{ "audience": {"id": "https://w3id.org/fep/xxxx/everyone"}}

The thing is, 3/4 of your audience_strings already have other identifiers which mean the same thing.

• me == $.actor.id
• followers == $.actor.followers
• everyone == https://www.w3.org/ns/activitystreams#Public

The only one that doesn't currently have a mapping to an existing term is instance, but this could be done with a Collection containing all local users, like a hypothetical https://social.example/users/.

Thanks for your insights

Why not use this approach then. For the \instance\ why no use the instance url ? This would also allow to share activities with one specific instance and not with others ?

it is unclear whether this FEP permits standalone Audio objects that are not part of any library.

Funkwhale approach is that every Audio object has a library at the db level (this allow to know if the url is playable or not, wihtout having to do a request and to update the playable status of batch of audio objects). When we receive an activity, if no library if on the payload we consider the audio acctivity comes from a channels instead of a normal user and we create a public library locally. But I guess it doesn’t have to be mandatory.

For example, if a software doesn’t implement Artist and Album as separate entities, is it allowed to omit the id property in those objects, like so?

I don’t think this should be allowed since it generate a lot of issues like duplication, missing metadata and unknown metadata origin. Also the id in AP is used to fetch the whole object and avoid sending big nested objects. But If a project do not implement \Artist\ or some other objects they can still parse the audio metadata and use it has they wish. They just can’t share the metadata that is missing an id. For example they still can send \Listening\ objects because they only need the track id for this. The remote server can use the track id to get all the associated metadata from the original server.

Also, it is unclear how to fetch Audio objects from a Track object.

Indeed.. Funkwhale parse audio collections (libraries and channels) so we have the Audio object before having the track. We should describe a mechanism to get the Audio object if we only have a Track :

To get playable tracks, a server should parse Audio collections (Library and Channel) since \Audio\ object has a track attribute. If the a server has a Track without any playable audio associated to it, they can request \Audio\ objects to remotes servers. Note that if instance A is the source of the track, it doesn’t mean it has an playable \Audio\ object. While instance B might have one.

We could use the source of the track (instance A) to centralize all the Audio objects by sending the createAudio activity to them. And add an Audio attribute to the Track object. This way other server can request instance A instead of having to parse the whole network for Audio objects. An issue arise when the source instance goes down : we should probably have a mechanism that allow another instance to “claim the responsibility” of the track metadata ? This seem impossible since ids can’t changes… So we need to send the Create Audio to all instance that use the track (we can’t guess all of them but it still better than nothing) or we send it to all the instance ? (might be too much).Another option is to use musicbrainz : give them the audio id has streaming link (its a centralized approach but why not)

the fep has been updated with all the music/audio objects

The definitions of audience are ambiguous. For example, the "Library" table

https://codeberg.org/petitminion/fep/src/branch/fep-be68/fep/be68/fep-be68.md#library

states that audience is a String (URI).

But in the "Privacy level" section, privacy levels are defined as single-word strings, not URIs.

Also, is it correct that Audio objects don't have an audience property?

silverpill:

single-word strings, not URIs

slight pushback on the "not URIs" bit -- even JSON strings that aren't in normal form are still identifiers because "audience" is defined in a way that types its values as identifiers. it could be disambiguated by expanding those (in effect relative) identifiers against a base URI, but you can't make this part of the definition of "audience" without confusing others who don't share this definition. and "audience" is also already defined by AS2 which requires that you MUST NOT override or change its definitions. I think the earlier recommendation to map these to existing identifiers still holds: https://socialhub.activitypub.rocks/t/fep-be68-audio-objects/8614/10

---

petitminion:

Why not use this approach then. For the instance why no use the instance url ? This would also allow to share activities with one specific instance and not with others ?

This is fine as long as everyone agrees on what the "instance URL" is. The service itself isn't necessarily always represented by the HTTP resource /. I think for the Funkwhale concept of instance you could mint an identifier like https://funkwhale.example/users/ and have it represent all users on the host funkwhale.example. You could then describe that as a Collection, as well:

{ "@context": "https://www.w3.org/ns/activitystreams", "id": "https://funkwhale.example/users/", "type": "Collection", "name": "funkwhale.example's users" "summary": "Represents every user on funkwhale.example"}

and then another-funkwhale.example would have its own users:

{ "@context": "https://www.w3.org/ns/activitystreams", "id": "https://another-funkwhale.example/users/", "type": "Collection", "name": "another-funkwhale.example's users" "summary": "Represents every user on another-funkwhale.example"}

Your local instance should know its own local users collection ID. If you knew the collection ID of another instance's users, you could in theory send them activities that would be forwarded (or not) by that other instance. (Say you knew of an "instance actor" that linked to its "users" collection.)

If you used relative identifiers and implicitly expand them against the current network location, it could look like this:

{ "@context": [ "@base": "https://funkwhale.example/", // insert your own instance name here "https://www.w3.org/ns/activitystreams" ], "audience": "/users/" // only you need to know what this means, so there aren't any compatibility/interop concerns}

If you used absolute identifiers it would look like this:

{ "@context": "https://www.w3.org/ns/activitystreams", "audience": "https://funkwhale.example/users/"}

---

petitminion:

If a project do not implement Artist or some other objects they can still parse the audio metadata and use it has they wish. They just can’t share the metadata that is missing an id.

Would it be correct to interpret this as Funkwhale allowing anonymous objects? (Fudging the vocab here a bit):

{ "@context": "https://www.w3.org/ns/activitystreams", "actor": { "name": "a" }, "type": "Listen", "object": { "name": "House of Leaves", "attributedTo": { "name": "Circa Survive" } }}

You could specify any "id" here to enable reuse, but on its own, this document contains enough information to describe a useful activity: a listened to "House of Leaves" by Circa Survive. You could progressively enhance this with other statements, like when the Listen occurred, or so on. You just don't know which specific we're talking about here, although you can probably be reasonably sure you know what is meant by and by context clues -- specifically, that since this is a Listen activity, the Listen.object is probably some listenable thing like a Track, and then a Track.attributedTo is probably the attribution of a Track to an Artist, and then you fill in the gaps that way to understand that we are both talking about the band Circa Survive and their work "House of Leaves".

This is all known as "identity by description", as opposed to "identity by name" which is a thing you can do to enable easier reuse. (The third way to identify something is "identity by possession". If this sounds familiar at all, it's because they map to the concept of "authentication factors" -- "what you know", "what you are", and "what you have".)

---

petitminion:

We should describe a mechanism to get the Audio object if we only have a Track

Couldn't you just link Audio objects to the Track? Or the other way around could work, too.

For Funkwhale this is like saying:

• I have a Library containing an Audio, and the Audio references a Track; or
• I have a Track referencing an Audio contained in a Library.

I assume Funkwhale doesn't store an index of which Tracks correspond to which Audio objects (since what I have seen so far without looking deeply is that Funkwhale prefers to index Audio objects that individually refer to a Track), but it's doable. It would also allow searching for a Track and finding any Library that contains an Audio object referencing that Track ("which libraries contain audio for this track" rather than "which track does this audio represent").

I think this is what you mean by this bit?

petitminion:

add an Audio attribute to the Track object

---

petitminion:

An issue arise when the source instance goes down : we should probably have a mechanism that allow another instance to “claim the responsibility” of the track metadata ? This seem impossible since ids can’t changes…

The "responsibility" is implicitly tied to the id. If you have a "metadata provider" then you can notify them of any new Audio objects referencing it (which is I think what you are proposing with the "source of the track" stuff described above?).

{ "type": "Activity", "summary": "Letting you know that your Track was uploaded as Audio", "audience": "https://track-owner.example/", "object": "https://audio.example"}

petitminion:

Another option is to use musicbrainz : give them the audio id has streaming link (its a centralized approach but why not)

If you're using Musicbrainz to provide Track metadata then why not use their database directly?

Otherwise, you could link a metadata provider's data by declaring it as being equivalent to the Musicbrainz entities.

{ "@id": "https://musicbrainz.org/work/38df7f57-de90-437f-8a61-3dd8f4e2f9af"}

Although this does raise the issue of what to do when the metadata of the Audio doesn't actually match the metadata provider's information. For example, according to Musicbrainz, the Recording is https://musicbrainz.org/recording/7a3fad60-938e-4c17-bc83-342acd713c04 "Meet Me In Montauk", which contains the titular work followed by ~7 minutes of silence, and then the hidden "bonus track" follows afterward. In my personal library, the audio I'm playing has actually been extracted from the official release, so that my copy of "Meet Me In Montauk" is only about 2 minutes long instead of 14:39, and my copy of "House of Leaves" represents something that was never officially released as a singular Track.

If we take the activity from before, then the question is this: what did I actually listen to?

• I didn't listen to "Meet Me In Montauk".
• I didn't listen to the 7 minutes of silence.
• I listened to "House of Leaves".
• What I listened to is not described in Musicbrainz as a Recording.
  • It is described by Musicbrainz as a Work (specifically a Song).

What ends up in the Funkwhale concept of a "Track"? Which musicbrainzId do you use? Does it get an id?

If you knew the collection ID of another instance’s users, you could in theory send them activities that would be forwarded (or not) by that other instance. (Say you knew of an “instance actor” that linked to its “users” collection.)

I guess the nodeinfo could be use to share the instance’s users collection id ? Would you recommend to use absolute or relative identifiers ? From my pov absolute is easier to handle ^^

This is all known as “identity by description”, as opposed to “identity by name” which is a thing you can do to enable easier reuse.

Since the FEP do not forbid it this kind of use case if allowed, but it think we should encourage the use of ids.

trwnh:

The “responsibility” is implicitly tied to the id. If you have a “metadata provider” then you can notify them of any new Audio objects referencing it (which is I think what you are proposing with the “source of the track” stuff described above?).

yes this was my proposition. But the problem comes when the tracks has a mbid. Various AP track with different ids can share the same mbid. So we should send the audio create activity to each one of them.

trwnh:

If you’re using Musicbrainz to provide Track metadata then why not use their database directly? Otherwise, you could link a metadata provider’s data by declaring it as being equivalent to the Musicbrainz entities.

because not all audio files or tracks have mbids. When they have we use their db. The proposition was to use \musicbrainzId\ on any audio object. I updated the FEP explaining the relation between AP audio objects and MusicBrainz audio objects. A funkwhale track is a musicbrainz recording.

absolute or relative identifiers

I think all identifiers should be absolute URIs. If we are talking about actor and collection IDs, ActivityPub requires them to be "publicly dereferencable URIs": https://www.w3.org/TR/activitypub/#obj-id

Relative identifiers are theoretical artifacts of JSON-LD processing that won't be understood by most ActivityPub implementations. The only exception is as:Public, short for https://www.w3.org/ns/activitystreams#Public, but even those are not universally supported.

-----

In the section "Privacy level", the FEP still refers to levels by name (followers and everyone https://codeberg.org/petitminion/fep/src/commit/95fd73232dd1d8f95e6731ccb4ebbc79c5a2e330/fep/be68/fep-be68.md#privacy-level