Home | Notifications | New Note | Local | Federated | Search | Logout
Note Detail
Reply to @petitminion@socialhub.activitypub.rocks
petitminion@petitminion@socialhub.activitypub.rocks (2026-05-05 03:57:21)
the fep has been updated with all the music/audio objects
---Reply---
silverpill@silverpill@mitra.social (2026-05-06 04:04:36)
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?
Reply
---Replies---
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