Event stream status messages (Subscription delete, etc.) #4

steve-bate commented 2026年04月17日 13:41:27 +02:00

From @FenTiger (from #2)

Deleting a subscription using DELETE {subscriptions_url}?topic={topic} happens asynchronously - outside the event stream - and so the client has no way to know when it is complete, i.e. that the pipeline has drained and it is guaranteed to receive no more events from the subscription.

Would it make sense for deletion to send an "ack" message of some sort back as part of the event stream? This would allow a client to send the delete request and then wait for the "ack" before tearing down its internal data structures relating to the subscription.

The events in the stream are supposed to be ActivityPub/AS2 entities. For this subscription deletion status messages, do you have an idea for the representation? One option is that we consider the subscriptions to be a virtual Collection and use Delete as the status message. The status URIs would possibly be URNs since they are internal. We could either automatically subscribe to the status topic (no deletion available for this built-in system topic) or allow clients to opt-in to the control signals with an explicit subscribe. Thoughts?

From @FenTiger (from #2) > Deleting a subscription using DELETE {subscriptions_url}?topic={topic} happens asynchronously - outside the event stream - and so the client has no way to know when it is complete, i.e. that the pipeline has drained and it is guaranteed to receive no more events from the subscription. > > Would it make sense for deletion to send an "ack" message of some sort back as part of the event stream? This would allow a client to send the delete request and then wait for the "ack" before tearing down its internal data structures relating to the subscription. The events in the stream are supposed to be ActivityPub/AS2 entities. For this subscription deletion status messages, do you have an idea for the representation? One option is that we consider the subscriptions to be a virtual `Collection` and use `Delete` as the status message. The status URIs would possibly be URNs since they are internal. We could either automatically subscribe to the status topic (no deletion available for this built-in system topic) or allow clients to opt-in to the control signals with an explicit subscribe. Thoughts?

FenTiger commented 2026年04月27日 10:54:17 +02:00

I don't think it makes much sense to encode these messages as ActivityPub:

• They're internal implementation details of the protocol, not something a user might want to think about or interact with; they should be hidden by the abstraction.

• Some implementations might want to support other "social protocols" too, eg ATProto's lexicon encoding, ideally without opening separate SSE streams for them. So I think this FEP should treat ActivityPub as just one of potentially several upper layer protocols that it can transport.

Off the top of my head I'd give these ACKs their own type field, event: internal or something, and encode them as a basic JSON object.

{
 "type": "delete",
 "topic": <ID of no-longer-subscribed topic>
}

I hadn't thought of making it a topic which could be subscribed to / unsubscribed from. I suppose unsubscribing might save a bit of bandwidth in the case where the application is creating and deleting a lot of subscriptions. I don't have a feel for how significant this might be though.

I don't think it makes much sense to encode these messages as ActivityPub: * They're internal implementation details of the protocol, not something a user might want to think about or interact with; they should be hidden by the abstraction. * Some implementations might want to support other "social protocols" too, eg ATProto's lexicon encoding, ideally without opening separate SSE streams for them. So I think this FEP should treat ActivityPub as just one of potentially several upper layer protocols that it can transport. Off the top of my head I'd give these ACKs their own type field, `event: internal` or something, and encode them as a basic JSON object. ``` { "type": "delete", "topic": <ID of no-longer-subscribed topic> } ``` I hadn't thought of making it a topic which could be subscribed to / unsubscribed from. I suppose unsubscribing might save a bit of bandwidth in the case where the application is creating and deleting a lot of subscriptions. I don't have a feel for how significant this might be though.