FEP-be68: Audio Objects

ActivityPub Server to Server
1

I writing a big fep covering various mechanisms around audio federation. This describe how Funkwhale federation works. I never writed a protocol enhancement proposal. Maybe I should split it into various fep ? the draft is here --batch --follow-symlinks would print ce013625030ba8dba906f756967f9e9ca394464a blob 6 And echo.

also created a post here : FEP-be68 Audio objects - General - The Social Music Network

3 Likes
2

Looks good, thank you for writing it!

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

1 Like
3

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

4

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

1 Like
5

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

@petitminion

1 Like
6

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

1 Like
7

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

8

`audience` can be object or link : Activity Vocabulary . Your proposition is too complicate from my pov. We could, send an object like :
{
"type": "Group",
"name": audience_string
},

1 Like
9

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.

10

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

11

Thanks for your insights :slight_smile:

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 ?

13

I help with music support in Smithereen, and it’d be great to federate with Funkwhale.

I like the idea of extending Audio objects with metadata. However, it is unclear whether this FEP permits standalone Audio objects that are not part of any library. 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?

{
  "type": "Audio",
  "id": "https://awesome.music/federation/music/uploads/88f0bc20-d7fd-461d-a641-dd9ac485e096",
  "name": "Krav Boca - Mortem",
  "size": 8656581,
  "bitrate": 320000,
  "duration": "PT1312S",
  "track": {
    "type": "Track",
    "name": "Shock! Extinction de masse",
    "position": 3,
    "artist_credit": [
      {
        "type": "ArtistCredit",
        "artist": {
          "type": "Artist",
          "name": "Krav Boca"
        },
        "joinphrase": "feat. ",
        "credit": "Crav Boka",
      }
    ]
  },
  "url": {
    "href": "https://awesome.music/api/v2/listen/82ece296-6397-4e26-be90-bac5f9990240/?upload=88f0bc20-d7fd-461d-a641-dd9ac485e096",
    "type": "Link",
    "mediaType": "audio/mpeg"
  }
}

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

14

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 (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). 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 create Audio 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)