FEP-be68 (audio objects) got me thinking… and I’d value this community’s eyes on an adjacent problem before I go down a possibly-wrong path.
FEP-be68 / Funkwhale federate audio as objects, as in recordings, albums, libraries: published artifacts, distributed async.
I’ve been working on something maybe adjacent: federating real-time “places” — rooms where people are present together, live, with audio and concurrent events.
Not “publish a recording” but “two instances, jointly rendering one room, while people are present in it.” (The party line is: “Presence, not posts.”)
A few things make it seem like a genuinely different problem rather than variant:
Presence is the payload. The state I’m trying to pass is “who is here, live” — ephemeral, not a record with an id to dereference. Much of AP’s machinery assumes a durable object; a live room mostly isn’t.
Federation runs during the experience, not after it. A room handed off or mirrored mid-session can’t surface seams to the people inside it.
My instinct is that a chunk of this can’t be retrofitted onto AP’s object/actor model and wants its own minimal protocol — but I’d much rather be told I’m wrong, or pointed at people who’ve already thought about it.
Here’s the concrete Qs:
Any prior art for federated real-time presence (not messaging) I should be reading? Anything in the XMPP/Matrix lineage that carries over?
Where would you draw the line between an AP extension and a separate protocol here?
Any naive mistakes I’m about to make?
Grateful for any pointers / happy to share more about what I’m building if useful.
XMPP is the eXtensible Messaging and Presence Protocol. ActivityPub is a protocol for publishing activities (and sending them as notifications). I suggest reading the XMPP RFC’s section on presence.
It sounds like what you’re trying to do is establish a session, not publish a resource. What you probably want is something like WebSockets, but you’ll need to make sure everyone in the session is using the same identity system.
If any mistakes are about to be made, it would be trying to use ActivityPub as an “everything protocol” for things it wasn’t designed to do. There’s plenty of working deployments of XMPP for this use case, but the vast majority of them just happen to have federation turned off.
If your goal is to have a sort of “live audio stream”, the audio can also be carried by other protocols such as RTSP or Icecast – if you use WebSockets, you will need to handle chunking/encoding/buffering yourself inside your application layer.