Home | Notifications | New Note | Local | Federated | Search | Logout
Note Detail
Reply to @silverpill@mitra.social
a@trwnh@socialhub.activitypub.rocks (2026-05-06 09:05:50)
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 t
---Reply---
petitminion@petitminion@socialhub.activitypub.rocks (2026-05-08 22:38:12)
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.
Reply
---Replies---
silverpill@silverpill@mitra.social (2026-05-18 02:32:38)
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