Home | Notifications | New Note | Local | Federated | Search | Logout
Note Detail
Reply to @trwnh@socialhub.activitypub.rocks
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---
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
Reply