[Openid-specs-risc] openid/sharedsignals: New Issue opened

[Shannon Day]

1. Immediate Detection:
   - The components should have documented procedures should be in place:
     - or polling to verify stream status detection fails.
5. State Updates:
   --level systems


On Tue, Aug 19, 2025, 1:01 PM github--- via Openid-specs-risc <
openid-specs-risc at lists.openid.net> wrote:

> openid/sharedsignals event
>
> Issue opened
> Issue Title: Tx sending a Stream Update Event for stream deletion
> https://github.com/openid/sharedsignals/issues/287
>
> Here is the discussion we had in the WG meeting about this topic: - (Yair)
> The spec says to send a Stream Update event when the status changes. -
> (Yair) Do we need a "deleted" status to send when a stream is deleted? -
> (Thomas) If we don't add a deleted status, how will Receivers know that
> resources should be cleaned up? - (Mike) Does that imply that streams live
> on forever with status "deleted"? - (Yair) No, the stream would be deleted
> and gone. - (Thomas) What happens for Receivers that don't get the event? -
> (Yair) This event is for the benefit of the Receiver. - (Thomas) But that
> means the stream can only be deleted after the deleted event was consumed.
> - (Yair) I don't think the stream should wait for the event to be delivered
> before deleting - (Thomas) Should we use something like the inactivity
> timeout to say the stream should hang around for a specific amount of time
> after the event is sent before deleting itself? - (Shayne) It's a little
> bit strange to think about status of "deleted". I wonder if we want a new
> event, StreamDeleted. - (George) I agree with the idea of a specific event.
> There is no way to guarantee that the Receiver will receive the event, but
> having a mechanism to alert in an optimistic case is nice. - (George) Both
> the Transmitter and Receiver should have some documented logic to determine
> when a stream is no longer active. This new event is an optimization, but
> the fallback mechanisms have to be present as well. - (Yair) What is the
> expectation today for what happens when a stream is deleted? - (Shayne) I
> don't think we have any expectations today. - (Yair) For now, we could send
> a "disabled" status before deleting the stream - (Shayne) I'm not against
> the idea of sending a "disabled" in this case. What does the Receiver do
> when it gets that event? - (Yair) I would expect that getting an unexpected
> disabled status would alert a human operator. - (Mike) Someone might
> trigger a verficiation event which would then return a 404 because the
> stream would no longer exist. Is the expectation that a 404 should cause
> the Receiver to shut down the stream on their end? - (Yair) I would expect
> that the customer or Receiver host would want to trigger some kind of
> investigation - (Shayne) Does the deleted event vs a 404 change the
> customer's behavior? - (Yair) It depends on whether the customer triggered
> the action - (Shayne) A deleted event might be a nice thing for a Receiver
> that requests the deletion. - (Mike) A 204 from the delete request should
> be the thing that tells the Receiver the deletion was successful. -
> (Thomas) What about multiple Receivers on the same stream? - (Mike) It
> feels cleaner to have a deleted event to go out before deletion - (Thomas)
> Possible race condition without some kind of timeout before deleting the
> stream - (Yair) For push streams, that shouldn't be a problem, but poll
> streams do have that issue - (Shayne) One more argument for making this an
> event not a status is that statuses seem to talk about whether events can
> "enter" the stream, not whether they can be broadcasted over the stream. -
> (Yair) Is there any other change that can affect the stream besides status?
> If so, why do we only have StreamUpdate events with status info? - (Shayne)
> Some examples of things that could change - the Tx could add or remove
> subjects, could change the delivery method, could change timeout intervals.
> We don't really restrict the Tx's actions. - (Shayne) What I'm hearing is
> that maybe we want to extend StreamUpdated to cover more than just status
> changes. Then we are not creating a new event type for stream deletion, but
> just adding new metadata to the StreamUpdated event.
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-risc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250819/730ced22/attachment.htm>