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
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!
One question for now, are you planning to copy the object definitions from the Funkwhale site into the FEP?
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 : Activity Vocabulary . 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.idfollowers == $.actor.followerseveryone == https://www.w3.org/ns/activitystreams#PublicThe 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 ?
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.
it is unclear whether this FEP permits standalone
Audioobjects 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
ArtistandAlbumas separate entities, is it allowed to omit theidproperty 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
Audioobjects from aTrackobject.
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)
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?
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: FEP-be68: Audio Objects - #10 by trwnh
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/"
}
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 <actor whose name is "a"> we’re talking about here, although you can probably be reasonably sure you know what is meant by <the thing i listened to which is named "House of Leaves"> and <the thing which is named "Circa Survive"> 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”.)
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 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?
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"
}
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?
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.
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.
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
Relative identifiers are not “theoretical artifacts of JSON-LD”; they’re a fundamental part of URI parsing. Any RFC 3986 compliant URI parser should be capable of handling relative URIs, as described by the RFC. This really shouldn’t be a problem for anyone, and it’s embarrassing that it somehow managed to become a problem for the Fediverse based on ill-advised guidance from AS2-Core creating a problem that had no reason to exist otherwise.
Anyway, that’s neither here nor there. The important thing is that it dereferenced to a local collection of users. Other instances don’t need to understand it; only the local instance distributing to its own users needs to understand it.
Thanks for this, and in particular for naming the hard part out loud instead of leaving it
implicit. The closing question is the one we keep running into as well:
where is the source of truth ? How can we handle artist impersonation (eg fake artist
accounts) ? How to handle an instance going down ?
We have been building a solo-instance Fediverse server with an audio
side, and that constraint turns out to answer part of your question and to sharpen another part.
Two things we can offer, and one we cannot.
In the current draft an artist Channel is an actor hosted on somebody’s instance, and that
leaves open who was entitled to create it. That is exactly where impersonation gets in.
If instead the artist runs their own instance on their own domain, the question moves out of the
protocol and into DNS, where it is already adjudicated, by registrars and ultimately by trademark
law. Nobody has to be convinced that ozzyosbourne.com is the real one, and nobody needs a
registry to say so. This is the origin-based model of FEP-fe34, applied to artists.
Note this does not require your draft to change. It is a deployment shape that satisfies your
Channel design, with the owner actor and the artist actor collapsing into the same origin. Your
two-actor split still earns its keep for labels and radios, where they genuinely differ.
musicbrainzId becomes much stronger if you make the link mutualWe like that the draft already reaches for MusicBrainz rather than inventing a registry. We would
go one step further and make the direction explicit, because the two directions are not worth the
same.
An artist’s MBID as published by the artist’s own server is self-asserted. It disambiguates
(which Ozzy) but it proves nothing: anyone can put Ozzy’s MBID on their own track.
A URL relationship on the MusicBrainz artist page, pointing back at that server, is different.
Adding it needs a registered editor account, it goes through a voting period, it lands in a public edit history, and the community can revert it.
So the useful unit is the pair. When the artist’s server names an MBID, and that MBID’s
MusicBrainz page points back at that server, a third party can check both ends without taking
either side’s word for it. The semantics are already there: MusicBrainz defines the social network relationship as “an artist’s own profile page on a social network which only they (or
their management) can post content to”, which is precisely what a single-account instance is, and
official homepage covers the domain itself.
This is the same shape as Mastodon’s rel="me" verified links and as FEP-c390 Identity Proofs, so
it is not a new trust mechanism, just an existing one pointed at the music case. It also keeps the
adjudication where it already happens, with an editorial community, instead of asking a protocol
to settle who is who.
Would you want the pairing described as a normative part of be68, or kept out and referenced as
existing practice via FEP-c390? We can see the argument for the second, since the mechanism is not
audio-specific, but the Artist object is where the need actually shows up?